The Developer Who Stopped Using AI for Code Review

James had been using AI assisted code review for about four months when he noticed something that took him a while to name. The review process had got faster. The number of issues flagged had gone up. The code he was shipping felt cleaner. All the indicators pointed the right way.

But the quality of his thinking had quietly shifted. He was catching fewer things himself. He was leaning into the AI's assessment rather than forming his own first. And when the AI told him the code looked good, he felt a small, comfortable sense of permission to move on.

It took a production incident to make the pattern visible.

What the AI missed and why

The bug was not subtle. A race condition in a payment processing flow that had passed every automated check, every lint rule, and a full AI assisted review. It surfaced under a specific combination of load and timing that none of those checks were designed to catch.

When James went back through the review output, the AI had flagged seventeen issues, all of them real, none of them the one that mattered. The race condition was not a pattern violation. It was a logic error that only became visible when you understood the sequence of concurrent operations and the specific way the payment service upstream batched its responses under load.

The AI did not have that context. It had the code.

James sat with the post-mortem for a long time. The conclusion he came to was uncomfortable: the AI had not failed to find the bug. He had failed to look for it, because the presence of a thorough looking review had satisfied his instinct that the code had been checked.

He had outsourced his attention.

“The AI had not failed to find the bug. He had failed to look for it, because the presence of a thorough looking review had satisfied his instinct that the code had been checked.”

The confirmation bias problem

What James had encountered has a name in cognitive psychology: automation bias. The tendency to favour the output of an automated system over contradictory information from other sources, including your own judgement.

It is not a character flaw. It is a structural feature of how humans respond to authoritative seeming output, and AI code review produces authoritative seeming output very reliably.

The practical problem is this. AI assisted code review is genuinely good at a specific category of things. Pattern recognition. Convention checking. Security antipatterns. Test coverage gaps. Obvious null pointer risks. These are things that benefit from exhaustive rule matching across a large surface area, and AI does them better and faster than a human reviewer doing the same pass.

What it is not designed for, and cannot do, is understand the intent behind the code, the history of the system it is joining, the behaviour of the upstream service under conditions not present in the test suite, or the business logic decision that makes a technically valid implementation semantically wrong.

Those are the categories of issue that cause production incidents. They are also the categories a human reviewer is most likely to skip when the AI has already told them the code looks clean.

What James changed

He did not stop using AI for code review. He restructured when in the process it appeared.

The new order was: James reviewed first, noted his own observations, formed a view about whether the code was doing what it should, and identified the specific things he was uncertain about. Then he ran the AI pass and compared the outputs.

The comparison itself became valuable. Where the AI flagged things he had missed, those were mostly in the pattern matching category: a missing error boundary, an inconsistent naming convention, a potential injection risk. Where James had flagged things the AI had not, those were mostly in the reasoning category: a function that was technically correct but would not behave correctly given how a downstream service actually worked.

The two passes covered different ground. Running them in sequence, with a gap between them, meant neither cancelled the other out.

He also made one rule for himself: before approving any PR on a system he was responsible for, he had to be able to answer two questions without consulting the AI output. What is this code actually doing, in the context of the system it is joining? And what would have to be true for it to behave incorrectly in production?

If he could not answer both questions, the review was not complete, regardless of what the AI had found.

The habit underneath the process

The thing James changed was not really a process. It was an attention habit.

AI assisted code review is most dangerous not when it misses something, but when its presence reduces the reviewer's own vigilance. The tool is doing something. It looks thorough. It produces structured output. The human nervous system reads that as evidence that the work is being done and relaxes accordingly.

The developers who use AI review well have found a way to keep their own attention engaged alongside the tool, not instead of it. They use the AI to cover ground they should not be spending human attention on. They direct their own attention at the ground the AI structurally cannot cover: intent, context, system behaviour, and the categories of error that only become visible when you understand what the code is trying to do and whether it is doing it.

That is a discipline. It requires actively resisting the comfort of a clean AI review output when you have not yet done your own thinking.

“The AI tells me what the code does. My job is to decide whether what the code does is what it should do. Those are different questions, and one of them is mine.”