Review didn't slow down because AI writes worse code. It slowed down because AI writes foreign code, and someone has to translate it back.
Our field study told us where the value went. Implementation time dropped about 14%. Review and rework grew enough to consume more than half of it, so only about 6% reached delivery. The bottleneck moved to review.
That's a location, not a cause. It tells you which step got slower. It doesn't tell you why a reviewer now spends longer on a pull request than they used to, and if you don't know why, every fix you try is a guess.
So I took the question to the people most likely to have felt it from the inside, and asked a narrower thing: not where does review slow down, but what is the reviewer actually doing with that extra time. The answer that came back, from several people who had never spoken to each other, was the same. And it wasn't the answer I'd assumed.
The obvious first guess is volume. AI generates more code, more code means more to review, review takes longer. True as far as it goes, but it doesn't explain the shape of what people described. A senior staff engineer who does most of his work through AI now - generating code, tests, and test cases - pointed out that more pull requests obviously means more review, because each one carries a fixed minimum cost. But that's linear and boring. It doesn't explain why a single AI-generated change can sit in review longer than a human-written one of the same size.
The second guess is quality, that AI writes worse code and reviewers are catching more defects. This one is almost the opposite of what people report. In one case, a team deliberately asked their AI to generate more kinds of tests than they'd been writing by hand, and downstream defect rates went down. The code wasn't worse. Review still got longer.
If it's not volume and it's not quality, what's left?
Here is how one engineer described the actual experience of reviewing AI-generated code, and I haven't been able to improve on it:
"It looks correct, but honestly I have no idea whether it'll work. This way of using the code is foreign to me as a reviewer, because we write it differently. So now what, am I supposed to compile it in my head?"
That sentence contains the whole thing. The problem isn't that the code is bad. It's that the code is unfamiliar, written in a style the team didn't develop, following conventions the team doesn't use, solving the problem in a way no one on the team would have solved it. And so the reviewer can't do the fast thing a reviewer normally does, which is glance at code that looks like their team's code and pass it. He has to reconstruct the reasoning from scratch. He has to translate it back into the team's own language before he can judge it.
An engineering executive I traded notes with named the underlying idea precisely: every team develops a dialect. After enough time working together, a group of engineers converges on an unwritten way of doing things, naming, structure, the shape of a "normal" solution, the things that go without saying. It's real, it's load-bearing, and almost none of it is written down. It lives in people's heads as this is how we do it here.
AI is the most foreign new hire imaginable. It has never sat in your architecture discussions. It didn't absorb the reasons behind the conventions. And crucially, unlike a human new hire, nobody is actively teaching it the dialect. It produces code that is often correct and always foreign, and the cost of that foreignness lands entirely in review.
The same person pushed the idea somewhere I found genuinely clarifying. Melvin Conway's 1968 observation is that a system's structure mirrors the communication structure of the organization that built it. Teams also go through the familiar forming–storming–norming arc, and a mature team is one that has already stormed and settled.
Now add a new member. Any new member (human or AI) drops the team back into storming, because the communication structure just changed. The new arrival doesn't speak the dialect; friction follows; and historically that friction resolves through mutual adaptation, with each side adjusting until a new equilibrium forms.
The uncomfortable implication is that nobody is running that adaptation for AI. When a human joins and refuses to adapt to the team, the outcome is well understood: you part ways after the probation period. AI doesn't adapt on its own and can't be let go, so the storming just… continues, quietly, inside every review queue, indefinitely. The review load isn't a transition cost that resolves. It's a permanent tax on a team that never finished onboarding its newest and most prolific member.
If the cause is dialect mismatch, the fix is to make the dialect explicit, and here the same practitioner drew a distinction sharp enough to build on.
There's the standard a team thinks it follows, and the standard it actually follows. These are rarely the same. Most teams, asked to write down their conventions, produce an idealized version from memory, the norms they'd like to have. The real standard is latent in their history: in what actually got merged, what got flagged in review, what quietly got rewritten. One is declared; the other is revealed. And the revealed one is the one AI needs.
The declared standard can be written from memory in an afternoon and will be subtly wrong. The revealed standard has to be extracted (from merge history, from the pattern of what reviewers actually correct). which is more work, and almost nobody does it. Which means almost everybody is trying to teach AI a dialect that the team doesn't actually speak.
A director of software development put the consequence bluntly, and it reframes where the work belongs: if you hand a junior developer a task and then judge their pull request against standards you never gave them, is that reasonable? Standards enforced at the PR are standards introduced too late. The conventions have to be present during the work, not applied to it afterward.
This is the same lesson our study organization reached from the delivery side and several practitioners reached independently: value is recovered upstream, by prevention, not downstream, by correction. A senior staff engineer described his own version: when a task description is poor, AI gets lost, so he now runs the description through AI first to structure it before any code gets written. He fixes the input rather than the output. Same principle, one step earlier: don't correct the foreign code at review, prevent the foreignness at authorship by making the dialect available going in.
There's a reason this doesn't reduce to "just write the standard down and enforce it," and it's the sharpest objection I got.
Code review was never only quality control. Its quieter and arguably more important function is knowledge transfer, the way engineers learn a codebase's structure and history in context, through the practice of reviewing real changes, rather than through a formal onboarding that never happens. Review is how the dialect gets taught in the first place.
So here's the trap. Suppose you get good at automating the quality-control half, a pre-review pass that catches the dialect mismatches before a human sees them. You've made the review faster. But you may have also removed the thing that made people review deeply. If a machine catches the problems, humans start skimming. And if humans skim, the knowledge stops transferring, which means the next generation of engineers never learns the dialect either, which means the thing you were trying to teach the AI is now also not being taught to the humans.
I don't have a clean answer to this, and neither did the person who raised it. The honest question is whether offloading the quality-control half of review gives people more room for the knowledge-transfer half, or whether it quietly kills the knowledge-transfer half by removing the reason to look closely. Those are opposite outcomes from the same intervention, and which one you get probably depends on choices nobody is currently making on purpose.
If review time went up after you introduced AI, the useful next question isn't "is the code worse." It almost certainly isn't. The question is how much of your reviewers' time is going to translation, reconstructing the intent of code written in a style the team didn't develop.
Three things worth checking:
None of this shows up if you only measure review duration. Duration tells you the review got slower. It doesn't tell you the reviewer spent that time translating a foreign dialect back into their own, which is the difference between a problem you fix with more reviewers and one you fix by teaching your newest team member how your team actually writes code.
The teams getting the most out of AI aren't the ones with the best model. They're the ones who noticed they'd hired a brilliant, prolific engineer who doesn't speak the language, and decided to teach it, instead of translating, one pull request at a time, forever.
