AI autocomplete raised the stakes for code review

AI autocomplete did not make code review less important. It made bad code review easier to hide.

That is the part I think people underplayed in the first wave of coding assistants. The tool got good enough to keep you moving. It could finish a branch condition, sketch a helper, write the obvious test, or imitate the surrounding style well enough that the diff felt less like a stranger had touched it.

That is useful. I use these tools. I like them.

But plausible code is not the same thing as reviewed code. In some ways, plausible code is harder to review because it does not trip the same alarms.

the texture changed

Before AI autocomplete, a lot of low-quality code looked low quality. The naming was off. The structure was weird. The person clearly had not read the neighboring function. Reviewers could spot the mismatch quickly.

Autocomplete is better at surface matching. It sees the local style. It borrows names. It fills in the expected shape. That means the first read can feel smoother than it should.

The failure moved from syntax and style toward intent.

Did this helper handle the edge case the product actually cares about? Did the generated test assert behavior or copy the implementation? Did the code use the right abstraction, or just the nearest one? Did it preserve ownership boundaries? Did it make a security assumption because the surrounding examples did?

Those are review questions. The autocomplete tool cannot own them.

generated code borrows confidence

The thing that bothers me most about autocomplete is how easily it borrows confidence from the surrounding code.

If the file has strong patterns, the generated code often looks strong. If the file has bad patterns, it can reproduce them with the same enthusiasm. The tool does not know which local convention is intentional and which one is historical damage. It does not know that the previous function is the thing everyone wants to delete after the release.

That makes review more responsible, not less.

A reviewer has to ask whether the new code is following the right local pattern. Sometimes the answer is yes. Sometimes the answer is “this matches the file, but the file is wrong.”

AI tools are especially good at extending a bad pattern neatly. That is a dangerous kind of helpful.

tests can get performative

Autocomplete also changes the feel of tests.

It is now very cheap to generate a test that looks like coverage. That sounds good until the test is mostly asserting the implementation’s current shape. A generated test can be syntactically correct, locally consistent, and almost useless.

I want code review to ask blunt questions about tests:

• Would this test fail if the bug came back?
• Does it describe behavior a user or caller depends on?
• Is it testing the branch that changed?
• Did the assistant invent a fixture that avoids the hard case?
• Does the test name explain the failure it protects against?

That last question is small but useful. A test named works correctly is a smell. A test named rejects archived projects during sync tells the next reviewer what kind of mistake happened or could happen.

review needs to slow down at the seams

I do not think reviewers need to distrust every AI-assisted line. That would be exhausting and mostly fake discipline.

I do think reviewers should slow down at seams:

• authorization checks
• input validation
• cache keys
• retries
• data migrations
• error handling
• file or network boundaries
• user-visible state changes

Autocomplete can write the easy middle of a function. The seams are where systems break.

If a generated change touches ownership, permissions, money, secrets, or persistence, the review bar should go up. Not because AI wrote it. Because those are the places where plausible code can do real damage.

the author still owns the diff

The worst habit is treating autocomplete as a second author.

“Copilot wrote that” is not a review defense. Neither is “the model suggested it.” The human who sends the diff owns the diff. They own the decision to accept the suggestion, the decision to leave it shaped that way, and the decision to ask someone else to review it.

That should change how people prepare reviews. If autocomplete produced the first pass, the author should still do the boring work before asking for approval:

• read the diff out of order
• remove code that exists only because the tool kept going
• check names against the domain, not only the file
• run the relevant tests
• add a note for any non-obvious tradeoff

Review is expensive attention. Do not spend it on cleanup the author should have done.

what changed for me

AI autocomplete made me less tolerant of lazy review comments and lazy pull requests.

If the code was easier to produce, the review needs to be more deliberate. The time saved in typing should move into better judgment: clearer tests, smaller diffs, better explanations, and more attention to the boundaries where mistakes matter.

That is not anti-tool. It is the opposite. The tool is useful enough that the process around it has to grow up.

the smaller diff wins

One practical change I like is asking for smaller diffs. Autocomplete makes it easy to accept one more helper, one more branch, one more cleanup near the original change. That extra work feels cheap while writing and expensive while reviewing.

If a suggestion is good but unrelated, I would rather park it. A focused pull request makes the AI-assisted parts easier to inspect because the reviewer can keep the original intent in their head. Big mixed diffs give plausible code too many places to hide.

Autocomplete can help write code. It cannot care whether the code belongs in the system. That job is still ours.