The mechanics of a pull request haven’t changed: a set of commits, a description, a review, a merge. What has changed is the volume of code in each PR, the patterns of mistakes, and what reviewers need to pay attention to.

AI coding assistants have made it faster to produce code. They haven’t made it easier to produce well-structured, reviewable changes. If anything, the opposite: the ease of generation encourages large, unfocused PRs. The patterns of AI mistakes require reviewers who know what to look for. And the risk of accumulated unknown problems is higher when code is written faster.

What Still Makes a PR Good

The fundamentals haven’t changed.

A PR does one thing. Not one commit - one logical change. “Add user authentication” is not one thing. “Add password hashing for new user creation” is one thing. The discipline of keeping PRs focused isn’t about the tools; it’s about making the change reviewable and reversible.

The description explains the why. The diff shows what changed. The description should explain why this change is the right change, what alternatives were considered, and what tradeoffs were made. A good description makes the review faster and serves as documentation when the code is read later.

The author has reviewed their own code before requesting review. Read the diff yourself before you ask others to. Obvious issues should be caught by the author, not the reviewer. AI-generated code especially: the author should have read every line before the review request.

Tests exist and they test the right things. Not coverage for the sake of coverage - tests that specify the intended behavior and catch the non-obvious failures.

What Changes With AI Assistance

Scope creep is easier and more common

When generating code is fast, the temptation is to fix related things while you’re in the area, add the extra feature that seemed obvious, clean up the surrounding code. The result is a PR that does several things, is harder to review, is harder to revert, and mixes unrelated intent.

This was always a problem. AI assistance makes it worse because the cost of adding more code drops. A PR that would have taken a week to build might now be written in a day - and might include twice as much scope because it was cheap to generate.

The discipline: keep the scope to what the PR description says. If you find something to fix while implementing, open a separate PR. If you want to refactor the surrounding code, do it in a separate commit or PR.

Verbosity increases

AI-generated code is often more verbose than hand-written code. It handles more cases explicitly, adds more comments, generates longer function names. Not all of this is bad. But it means PRs get larger, and larger PRs get worse reviews.

Research consistently shows that review quality drops on large PRs - reviewers get fatigued, miss things, approve to get through the queue. A PR with 400 lines gets a better review than a PR with 1,500 lines, and the code it introduces into the codebase is proportionally more understood.

If AI assistance is generating verbose code, the author’s job is to edit it down before the review. The model’s first draft is not the PR. It’s material to work with.

The “it works” standard is insufficient

When you write code manually, the act of writing forces engagement with the logic. You have to think through the implementation even if you don’t do it perfectly. With AI assistance, you can have working code without having engaged with the logic at all.

“The tests pass” is not sufficient evidence that the code is correct. It’s evidence that the code passes the tests. The tests themselves need review: do they test the right things? What scenarios are missing?

A PR description that says “added feature X, all tests pass” when some or all tests were AI-generated is describing less than it appears to.

Context gaps are a new failure mode

AI-generated code can be correct in isolation and wrong in context. It doesn’t know that your team uses soft deletes. It doesn’t know about the performance constraint on that table. It doesn’t know that the library it chose to use has a known issue in your version.

These context gaps are hard to catch in review because the code looks correct. The reviewer needs to know what context the author provided to the model - or more practically, the reviewer needs to be the one supplying context awareness.

Reviewers should be asking: does this fit the patterns we use elsewhere? Does this account for the constraints I know exist? Does this align with recent architectural decisions? These questions catch context gap failures.

What a Good PR Description Looks Like Now

A good PR description in 2026 is similar to what it was before, with one addition: transparency about the approach.

## What
Adds rate limiting to the /api/auth/login endpoint.

## Why
The endpoint was accepting unlimited attempts per IP. 
This is required before the public beta.

## How
Using the existing Redis rate limiting infrastructure 
(see RateLimiter class in services/rate-limiter.ts).
Limits to 10 attempts per 15-minute window per IP.
Behavior on limit: 429 with Retry-After header.

## What was considered
- In-memory rate limiting: rejected because it doesn't 
  work across multiple instances
- Per-account vs per-IP: per-IP chosen because we don't 
  have account context at this point in the auth flow

## Testing
- Unit tests for the rate limiter integration
- Manual test: confirmed 429 after 10 attempts, 
  confirmed reset after 15 min window

The length is appropriate to the complexity. A one-line fix can have a one-paragraph description. What matters is that the reviewer gets the information they need to evaluate the change.

The Review Side

Reviewers also need to adjust.

Read the code, not just the diff. AI-generated code that passes review often fails because the reviewer read the changed lines in isolation, not in the context of the surrounding code. A change that looks correct in diff view may conflict with something in the same file.

Ask the author to explain it. Not as a quiz - as a check. “Can you walk me through the error handling here?” If the author can’t explain why the code is correct, that’s information. It means the code needs more review, not less.

Check for consistency with existing patterns. AI generates code that is internally consistent. It may not be consistent with the rest of your codebase. Reviewers who know the codebase catch this. Reviewers who only read the diff don’t.

The bar for merging should be “I understand this and it’s correct,” not “it looks reasonable.” The distinction matters. Code you understand can be debugged. Code that merely looked reasonable becomes the mystery at 2am when it fails in production.

The PR process is where understanding gets transferred from author to team. When that transfer doesn’t happen - when code is generated, cursorily reviewed, and merged without genuine understanding on either side - you’re not building a codebase. You’re accumulating artifacts.