Nobody Read the Code: Why I Changed My Mind About AI Review

Right now I have 13 Ghostty tabs open and around five agents actively running. Three features are being built on separate git worktrees, and two tabs are running PR reviews I'm working through. My workflow for each one is the same: I chat with the agent about the problem first, building context naturally the way I would with a colleague, and then hand it a /goal task once we're aligned. It works well. I ship more than I ever have.

Which is exactly why I want to talk about the part of this workflow I got wrong.

What I used to believe#

Six months ago I would have argued, confidently, that AI could review all of our code. Not just assist with review - do it. Models don't get tired, they don't skim, they don't get bored on line 1,800 of a diff. Point one at a PR and it will read every line with the same attention it gave the first. I thought AI review would catch far more than humans ever did, and that manual review was on its way to becoming a ceremony we performed out of habit.

I've reversed that position. Not because AI review doesn't work - it does - but because of what happens to everyone else in the loop when it becomes the only reader.

What actually happens#

Here's the failure mode, and once you see it you can't unsee it.

PRs get big. 2,000 lines, 5,000 lines, sometimes 10,000. The author hasn't read all of it, because an agent wrote it and the author was orchestrating three other things at the time. The reviewers open the diff, see the line count, and quietly hand it to an agent too, because no reasonable person is reading 8,000 lines with care. The agent leaves some comments, the author's agent resolves them, two approvals appear.

Now nobody has read the code. And everyone assumes someone has.

To be fair to the machines, this hasn't taken our site down repeatedly. Things mostly work. But "it hasn't broken yet" is not the same as "this is fine", and I've stopped pretending otherwise. What we'd actually built was a system where the appearance of review was fully intact and the substance of it had quietly evaporated.

To be clear, I'm not against AI review, and this isn't a piece about turning it off. CodeRabbit catches things I would have missed, and I'd keep it tomorrow. The problem is not that an agent reviewed the code - it's that an agent was the only thing that read it. Those are very different failure modes, and everything that follows is about the second one.

What agents catch, and what they miss#

The interesting part is that AI reviewers genuinely find bugs. Real ones - race conditions, unhandled nulls, off-by-one errors buried in pagination logic. If your only definition of review is "find the defects", they're good at it and getting better.

What they miss is readability and repo-level code quality, because humans read code differently to models. A few examples from my own PRs and reviews:

Unnecessary inline comments. To be precise about this: a comment that explains why - a constraint, a workaround, a decision that would surprise the next reader - genuinely earns its place, and I'd keep every one of them. What I'm against is comments that restate what the code is doing, and agents love those. They're noise, they're one more thing a developer has to maintain, and they drift out of sync the moment someone edits the line below without touching the line above. Well written code should mostly speak for itself, and when it can't, the fix is clearer code, not prose stapled to it. There's an AI-specific danger here too: an agent reviewing code will often believe the comment over the code - if the comment says "returns the cached value" and the code doesn't, the comment wins the argument. A stale "what" comment is worse now than it has ever been. An AI reviewer will almost never flag one as a smell. A human who's been burned by a lying comment will flag it immediately.

Over-engineering. I've watched agent-written code do genuinely elaborate things - custom state tracking, wrapper layers, careful orchestration - to achieve something the package already supported directly via a hook. The code was correct. It compiled, it passed tests, an AI reviewer approved it. It was also thirty lines solving a problem that one documented line solves, and only a human who knew the library would say "why didn't you just use the hook?"

The .map() incident. My favourite example is from my own agent. It needed to change some default values in a hardcoded array from false to true. Instead of editing the array, it appended a .map() that transformed the values at runtime. Technically correct. Obviously, laughably silly to any human who looks at it - you'd just change the literals. No AI reviewer I've tried flags that kind of thing, because nothing about it is wrong. It's just not how a person who read the code would leave it.

That last category is the one that compounds. None of these things break production on day one. They break the codebase's legibility over months, and legibility is the thing you need most when something does break.

Where I landed: small PRs, humans who actually read#

The fix wasn't a better review agent. It was making the code reviewable by humans again.

My CLAUDE.md now targets 400 lines per PR, counting only new lines. Migrations and similar mechanical changes are exempt - once a change is 6,000 lines of generated schema churn, line counts stop being meaningful, and pretending otherwise just trains people to ignore the rule.

The important part is when the splitting happens: at the start of the task, not at the end. My CLAUDE.md instructs the agent to split the work before writing anything, and I have a /slice-feature command that has Claude analyse the whole feature and propose sensible splits - by layer, by route, by data model, whatever the shape of the work suggests. Slicing a feature after it's built is miserable; slicing it before is just planning.

Our review model is now one AI reviewer plus two human reviewers. We use CodeRabbit as the AI pass, and it's genuinely useful - it catches the mechanical stuff early so humans don't spend their attention on it. The humans are welcome to use AI to help them, but they must actually read the code themselves. And here's the thing: if the PR is small enough, they naturally will. Nobody needs to be told to read a 300-line diff. The 400-line target isn't really a code quality rule - it's a rule that makes the human review rule enforceable.

The part where I admit something#

I review manually now. I spend a lot of time reading code - more than I did before agents, not less, which is not where I expected this to go.

In practice it looks like this: when a PR lands on me, I kick off the agent review and then read the PR myself while the agent is working. The two runs happen in parallel, and when the agent finishes I compare notes. The agent usually finds something I missed - a real defect, buried somewhere I skimmed. And I usually find things the agent didn't think mattered: naming, structure, a comment that shouldn't exist, a function that's harder to read than it needs to be. Neither pass replaces the other, which is rather the point of this whole post.

And I'll be honest about what that's like: I sometimes read a PR and wonder whether the author has read it themselves. Then I wonder, with complete sincerity, whether people think exactly the same about mine. That mutual suspicion is new. It didn't exist two years ago, because two years ago the author of a PR had, by definition, read it - they'd typed it. The uncomfortable truth of agentic development is that authorship and familiarity have come apart, and review is the only place we can put them back together.

The take everyone gets wrong#

The common line is that AI makes PRs huge. I want to push back on that properly, because I think it's exactly backwards.

AI doesn't make PRs huge. The agent will keep coding for as long as you let it - it has no sense of when a change has become too big to review, and it never will, because "too big to review" is a fact about humans, not about code. Splitting the work was the developer's job before agents, and it is still the developer's job now. The agent just removed the natural friction - typing fatigue - that used to enforce it accidentally.

So when a team says "review has become our bottleneck since we adopted AI", what I hear is that someone upstream chose to stop slicing work, and the cost landed downstream on the reviewers. That's not a tooling problem. That is a choice someone made, and it can be unmade in an afternoon by editing a CLAUDE.md.

One last observation, and it's the one I keep turning over. The style of code has changed a lot since teams started handing most of the writing to agents. It reads differently - the naming, the comment density, the shape of the abstractions. Some of that is fine, maybe even better. But codebases are read for a decade after they're written, and we're currently changing what "normal code" looks like at enormous speed, mostly without anyone deciding to. That seems worth being careful about. And being careful about it requires the one thing this whole post has been circling: somebody has to actually read the code.