AI autocomplete raised the stakes for code review

AI autocomplete did not make code review less important. It made plausible code cheaper to produce.

That changes the reviewer’s job. The generated code usually matches the local names and formatting, so the old visual alarms are quieter. The question moves from “does this look like code?” to “does this preserve the intent of the system?”

I use these tools. I like the speed. I do not trust the first pass.

The places I slow down are the seams:

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

Autocomplete is good at the easy middle of a function. The seams carry the consequences.

Tests need the same suspicion. A generated test can be tidy and still assert the implementation instead of the behavior. I want to know whether it fails when the bug returns, whether it covers the changed branch, and whether the fixture avoids the hard case.

A small test name can help:

rejects archived projects during sync

That says what the test protects. works correctly says almost nothing.

The author still owns the diff. “The assistant wrote that” is not a review defense. Before opening a pull request, the author should read the change out of order, remove unrelated suggestions, check the names against the domain, run the relevant checks, and call out the tradeoffs that are easy to miss.

I also prefer smaller diffs. Autocomplete makes one more helper and one more cleanup feel nearly free. Those additions are expensive when a reviewer has to reconstruct the original intent around them.

The tool can suggest code. It cannot decide whether the code belongs in the system. That remains the reviewer’s job, and the author’s first.