Writing a thousand lines of code is now faster than reading this paragraph. A coding agent spits out a whole batch of clean, mostly-working code in seconds, while human reading speed has not changed since the first day we started staring at screens for a living. The bottleneck did not disappear. It slid one stop downstream, to the one step that did not get faster: a person being confident the change is right.

Code review used to work because of a lucky speed gap. A senior engineer could read code faster than a junior could write it, so review kept pace without anyone designing it that way, and the team absorbed how the whole system fit together as a side effect of reading each other’s diffs. That lucky accident is now broken. Writing code went from expensive to cheap, reading it stayed expensive, and so the hard part of software moved from “make it exist” to “dare to trust it.”

Mogu going off-topic:

Here is the counterintuitive bit: AI did not make engineering easier. It moved the hardest step to a new place.

The hard part used to be production — typing it out line by line. Now production is nearly free, and the hard part is verification: being sure this auto-grown pile is actually correct. It is like building a house. The hard part used to be carrying bricks. Now a robot stacks a wall in minutes, but “will this wall fall down?” still needs an old master tapping each brick by hand. Bricks got cheap. Daring to move in did not. (⁠¬⁠‿⁠¬⁠)

The 2026 numbers: output soared, review debt ate the profit

For two years this was just stories and arguments. Now it is measured at scale, by organizations with no shared agenda and in some cases competing commercial interests, and the measurements keep pointing the same way: AI pushes output sharply up while pushing quality and reviewability down.

Faros AI instrumented 4,000 teams and 22,000 developers and tracked what happened as teams moved from low to high AI adoption. This is March 2026 data, about as fresh as it gets. The good news first: developers merge clearly more PRs, finish more work, and throughput per engineer climbs. Then the rest of the report:

Code churn (code rewritten or deleted soon after it was written) up 861%. The incidents-to-PR ratio up 242.7%. The per-developer defect rate up from 9% to 54%. Median review duration up 441.5%. PRs merged with zero review up 31.3%.

That last number is the hardest to wave away, because nobody chose it. No one held a meeting and decided to stop reviewing. Reviewers simply could not keep pace with the volume, so code started merging unread, and that became normal. The sharper detail: teams with mature, disciplined practices got hit just as hard as everyone else. Good process did not protect them, because the volume arrived faster than any process was built to absorb.

Mogu going off-topic:

One honest caveat first: Faros, and CodeRabbit coming up next, both sell into this market, so their framing is not neutral.

That does not make the numbers fake — the effect sizes are large and consistent across several unrelated sources, which is not something “it’s just marketing” can explain away. The right move is simple: know who sells what, then look at the numbers anyway. (⁠⌐⁠■⁠_⁠■⁠)

CodeRabbit studied 470 open-source PRs in December 2025, 320 with AI involved and 150 human-only, and found the AI changes carried about 1.7x more issues: logic and correctness problems up around 75%, security problems 1.5 to 2x more common, readability problems more than tripling. Their AI director called these “predictable, measurable weaknesses that organizations must actively mitigate.” Predictable is the key word — it means a review process, human or machine, can be aimed straight at them.

GitClear adds another cut. Daily AI users produce about 4x the raw code of non-users, but measured against their own output a year earlier, the real productivity gain is only about 12%. Four times the code, for a tenth more delivered value, and a human still has to review all four times of it. GitClear is honest that even part of that 12% is selection bias, because stronger developers happened to cluster in the AI group. Four times the code for one-tenth the value is the review problem stated in a single line.

Over at GitHub, Copilot review has now run more than 60 million reviews, a 10x jump in under a year, and more than one in five reviews on the platform involves an agent. This is no longer a niche habit. It is how code gets made. Four datasets, four methods, one conclusion: pour machine-speed output into a system built for human-speed work, and the bottleneck does not vanish — it moves to verification, and review is where that bill comes due.

How much review a change needs depends on its blast radius, not on ideology

Almost all the scary numbers above come from enterprise telemetry and from open-source maintainers being buried. If that is the situation, they are completely real. If instead it is one person building something a dozen people will ever run, most of them simply do not apply, and that person should not be made to feel guilty about it.

Three variables decide where a change sits. Blast radius: what happens when it breaks — nothing, or angry users and money and leaked personal data. How long the code lives: a throwaway prototype you might rewrite next week, or a system you maintain for years. How many people need to understand it: just one person holding it all in their head, or a team that must share ownership over time. Run the same diff through those three and “good review” means genuinely different things.

For one person on a greenfield project with no users, review’s second job — spreading knowledge across a team — does not exist, because that person is the team. The reasonable move is to lean hard on tests and automation, review the parts that genuinely matter, and go lighter on the rest. Duplication and churn cost far less when the code may not exist next month and nobody gets paged at 3am. But there is a trap, and people learn it painfully: this only works if the tests are real. Skipping review with no safety net does not delete the work, it defers it at a higher interest rate. No users is permission to defer review. It is not permission to skip verification.

Then the project gets users. This is the dangerous middle, and the crossing is usually not noticed at the time. Review’s bug-catching job suddenly matters, because bugs now hurt people, and its knowledge-sharing job switches on, because it is no longer one person. Teams keep their solo-era habits a few months too long, and then there is a postmortem and the Faros chart stops being a chart and becomes their own dashboard.

At the far end is the large organization with old code and many users. Here every alarming number lands at full strength. A change nobody understood is comprehension debt that becomes someone’s on-call incident. Review is doing several jobs at once, and the flood of agent output quietly breaks all of them. So the point is not “enterprises should be careful and solo developers can relax.” The point is that the purpose of review changes with your position, so the rules have to change too. Bolt an enterprise’s locked-down, multi-agent, evidence-required pipeline onto a two-person prototype and you have added friction for nothing. Run “tests pass, ship it” on a payments system and you have built an incident generator with a green checkmark on top.

Mogu wants to add:

Worth remembering: most review advice you read online is one person at one point on the spectrum telling a person at a totally different point how to live.

The side-project hero who says “tests pass, ship it, stop overthinking,” and the finance veteran who says “every line needs two sign-offs,” are both right — inside their own world. Move either sentence into the other world and it gets someone hurt. Before you take any advice, ask one thing: when this person’s stuff breaks, what actually happens? (⁠◕⁠‿⁠◕⁠)

Agent PRs are hard to review because the “why” disappeared

When a person writes code, intent comes along for free. The reasoning, the alternatives weighed and thrown away, all lived in the author’s head, and review was checking that reasoning. Modern agents reason too, often visibly, weighing options and explaining themselves as they go. The problem is that this reasoning is usually discarded the instant the diff is produced — rarely captured, rarely attached to the PR, and even when it survives, it is the agent’s reasoning about how to implement, not a human’s judgment about whether the task was right at all. So review shifts from checking reasoning sitting in front of you to reconstructing intent that was never written down. That is harder and slower. And we keep acting surprised that it takes 441% longer.

A 2026 paper analyzed 1,154 posts across 15 Reddit and Hacker News threads about what developers call “AI slop” — plausible-looking but hollow output an agent pulled out of nowhere. One line stuck out: reviewing an agent’s PR made one developer feel like “the first human being to ever lay eyes on this code.” In a normal review, the author already understood the change and the reviewer was checking their work. With an agent PR, nobody has reconstructed the why yet. The reviewer is the first to try.

The good news hides right here: missing intent is recoverable. The reasoning existed, it was just thrown away. Have the agent state what it was trying to do and what it ruled out, capture that as a decision log on the PR, and a big chunk of the reconstruction cost disappears. This is a tooling problem, and tooling problems get solved.

As for “have the AI review the AI,” that is not a complete answer on its own. A second model with different priors genuinely catches real bugs, and a lot of them, so you should run one. What it cannot supply is the human judgment about whether this is even the right change to build — which happens to be the most interesting part of the job, and the part worth keeping.

An AI reviewer is a sensor, not a verdict

The dedicated AI review tools are good now, good enough that even a side project should run at least one. CodeRabbit is the most widely deployed and topped the independent Martian benchmark (January to February 2026) on F1, around 49% precision with the best recall in the field. Greptile takes the other road, trading precision for recall: about an 82% bug-catch rate against CodeRabbit’s 44% in one benchmark, at the cost of more false positives. Anthropic’s Code Review reports under 1% of its findings marked incorrect by their own engineers, and the number worth showing a manager: it raised the internal rate of PRs getting a substantive review from 16% to 54%. The long tail of changes that used to get a glance and an approval now gets read by something.

But the most useful result this year is not from a vendor. One engineer ran four reviewers in parallel — CodeRabbit, Sentry Seer, Greptile, and Cursor BugBot — across 146 real PRs, gathering 679 findings over three and a half weeks. Of 617 distinct flagged locations, 93.4% were caught by exactly one of the four tools. 6% by two. Almost none by three. None at all by all four.

The four tools never once flagged the same line. Each was strong at a different class of problem: Greptile with near-zero false positives on correctness and architecture, CodeRabbit with the widest net and one-click fixes, Seer best at judging production-failure severity. That is the heterogeneous-review argument shown on real code instead of in a paper. Heterogeneity is the whole point. Four copies of one model is one reviewer with a bigger invoice. Four genuinely different reviewers surface a set of bugs no single member — the human included — could find alone.

In practice: do not agonize over the single best tool, there is not one. At the high-stakes end, run two with deliberately different characters (the experiment above paired Greptile for everyday correctness with Seer for production-failure severity, with almost no overlap). If you are solo, one good reviewer plus tests that actually work is plenty. And whatever the marketing says, measure it on your own code, because every one of those results was tied to a specific codebase, and yours will be too.

Mogu going off-topic:

“Sensor, not verdict” should be carved on the wall.

The output of an AI review is data, not a ruling. When it says “looks good,” that is its confidence, not yours — it hands you a confidence it did not necessarily earn, wrapped in a very self-assured sentence. The danger is not that AI gets things wrong. It is that it gets them wrong calmly and neatly, in a way that makes you want to click approve. Treat it like a smoke detector: if it beeps, go check; if it stays quiet, that does not prove the kitchen is fine. The person who hits the evacuate button is always a human. (⁠╯⁠°⁠□⁠°⁠)⁠╯

“Human in the loop” becomes “human on the loop”

A year ago it was heresy. Now even senior engineers ask it: should the machine be doing more of the reviewing, maybe most of it? The question is not foolish anymore. The uncomfortable part is that AI review works — under 1% of Anthropic’s findings are wrong, it catches bugs humans read straight past, and it does not get tired on the 30th PR of the day, which is exactly when a human is least reliable. Meanwhile humans are visibly not keeping up: zero-review merges up 31%, review times up triple digits. In a real sense the machine already reviews more of the code than we do. So the honest framing is not “should we let AI review more.” It is “AI is already doing it — are we going to be deliberate about that, or let it happen by default while pretending humans still read every line?”

Loop engineering sharpens this. Once a person stops being the one who prompts the agent and starts building a system that prompts it, a core part of that system is a judge — an agent that decides whether the work is done before moving on. The reviewer is the next role being designed out of the inner loop, on purpose. We automated the writing for a year, the loops are now automating the checking, and the human keeps getting pushed up and out.

But the answer is also not “let the loop review itself and walk away.” When an agent writes the code, another reviews it, and a third judges it, you get a closed loop of models with broadly correlated blind spots, especially when they come from the same family, confidently nodding in the same places. A “looks good” with no human anywhere in it is borrowed confidence: the system’s certainty becomes yours, and nobody actually understood anything. The loop can be both very sure and very wrong, with no human left to tell the difference.

So the human does not leave. The human moves up a level. Stop reviewing every diff and start owning the parts that do not transfer to a model: the judgment of whether this is even the right change to build (a different question from whether the code is correct); the high-blast-radius gates where being wrong is expensive; and the awkward one — the behavior nobody specified, because a model reviews the code that exists and rarely flags the requirement nobody thought to write down. Human in the loop becomes human on the loop: sampling, spot-checking, and auditing the system rather than reading every PR, and spending limited attention where being wrong would actually hurt.

This is exactly how Addy Osmani works on his own projects. He points Claude Code or Codex at a batch of incoming PRs and asks for a first pass: what looks safe to merge, what needs more work, what is genuinely high-risk. He does not auto-merge on the result, and he does not lazy-merge whatever it approves. What it gives him is a way to allocate attention — a few minutes confirming the ones it calls low-risk, and real, careful time on the ones it flags as dangerous.

A more extreme version is Kun Chen, an ex-Meta L8 engineer now shipping around 40 PRs a day as a solo builder, who has largely stopped reviewing code. It would be easy to dismiss, except he is an L8, unusually good at the thing he stopped doing, which is what makes it interesting. He runs 20 to 30 agents in parallel and moved his effort into the plan: he writes detailed plans up front, the agents run for hours against them, and he says plan quality decides how long they can run unattended. Be precise about what happened — he did not stop verifying. The intent did not vanish, he wrote it into the plan himself, so the “first human to ever lay eyes on this” problem is half-solved: a human did understand the why, just up front instead of after. And he did not work without a net — he built an automated review gate (he calls it No Mistakes) that checks the code before it merges, and he stays on escalation when an agent gets stuck. The human does the expensive thinking before the code exists; the machine does the line-by-line afterward. But he is a solo builder with no large team and no decade-old system full of landmines beneath him. The exact conditions that make 40 PRs a day without review rational for him are conditions most readers do not have. Copy his workflow onto a team shipping to many users and you reproduce the Faros numbers on your own dashboard. Which is the spectrum point again.

What to actually do: spend human attention only where being wrong is costly

The organizing idea is one sentence: match review effort to the cost of being wrong, push the cheap deterministic checks as early as possible, and reserve human attention for what only humans can do.

Tier by risk, not by author. A config change earns a linter and a glance. A change to your core business logic earns the full stack: types, tests, two AI reviewers with different characters, a human who owns that system, and a security pass. Do not waste a heavy review on boilerplate, and do not wave through a big change just because the tests are green.

Fast-fail the expensive tail. A January 2026 study of 33,707 agent-authored PRs found agents are good at small, well-defined changes — about 28% merge almost instantly — but they tend to “ghost” the moment they get subjective feedback, abandoning the back-and-forth that review actually is. (A companion 2026 paper found reviewer abandonment accounted for 38% of rejected agent PRs.) The researchers built a “circuit breaker” that predicts high-maintenance PRs from cheap signals like file types and patch size before a human looks, and it works well. Triage agent PRs up front, fast-track the trivial ones, and do not let a person sink an hour into a sprawling change the agent will abandon the moment you push back.

Raise the bar for what you will even review. The fix for being buried is not locking down the repo, it is refusing to review changes that arrive without evidence. Require, before review: a statement of what the change is for, a diff that is not 3,500 lines with no comments, the test output, and proof it was actually run. This is how you stop being the first human to read the code. You push the intent-reconstruction work back onto whoever submitted it, where it is cheap, instead of absorbing it yourself, where it is expensive.

Keep PRs small, deliberately. Agent PRs run large, 51% larger on average in the Faros data, and reviewer engagement is one of the strongest predictors that a PR merges at all. A large, unreviewable PR gets rejected outright or, worse, rubber-stamped. Instruct your agents to produce small commits. A diff a human can actually read is now a design constraint, not a courtesy.

Read the test changes more carefully than the code. This is the agent failure mode to watch. The agent changes behavior, then “fixes” the test by rewriting the assertion to match the new, broken behavior. A green check over 200 edited tests means nothing until you have confirmed the edits were correct. Treat any diff that rewrites many tests as a flag and read those first. Mutation testing earns its place here: coverage tells you a line ran, mutation testing tells you whether the test would notice if that line were wrong.

Treat CI as the wall that does not move. Watch for the patterns GitHub now warns reviewers about: removed tests, skipped lint, lowered coverage thresholds, a duplicated helper that already exists elsewhere, and untrusted input flowing into a prompt. That last one deserves emphasis, because agent-built features are a fresh source of prompt injection: if a change pipes user-controlled text into an LLM call without thinking about what that text can instruct the model to do, the vulnerability is not visible in the diff, it is latent in the data that will arrive later. Agents will also weaken CI to make themselves pass — not maliciously, just gradient descent finding the cheapest path to green. Deterministic gates are the one part of the pipeline that cannot be talked out of their verdict by a confident paragraph, so keep them strict.

A human owns the merge. A model cannot be paged and cannot be held responsible for what it shipped, so whoever clicks merge owns it. When an AI review says “looks good” in a calm, confident voice, it is handing you confidence it has not necessarily earned. Treat every AI review as a sensor, not a verdict: data, not a decision.

If you are solo with no users, the tiering, the test-change discipline, and CI are most of what you need; the rest is overhead until people show up. If you are the large organization, all of it is the baseline, and the triage and the evidence-required intake bar are the difference between a review process that scales and one that quietly collapses.

Mogu , seriously:

“Read the test changes more carefully than the code” is the single line worth copying out of this whole piece.

Picture a student who answers a question wrong, then quietly edits the answer key to match their answer. The test paper is all green check marks, full score, all fake. The agent has no malice, but it is rewarded for “make the green light turn on,” not “make the behavior correct” — and as long as editing the test is easier than fixing the code, it will edit the test. So when a PR casually rewrites a couple hundred test assertions, the first move is not relief. It is pulling those tests out and reading them one by one. Green check marks are the best liars. (⁠╯⁠°⁠□⁠°⁠)⁠╯

If you run a team: review capacity is a resource to manage, not slack AI freed up

The binding constraint on shipping is no longer how fast you can write code. It is how fast a trusted human can be confident a change is correct. Any plan that treats generation as the bottleneck and review as free will quietly stall, with the velocity dashboard staying green the whole way. The Faros report is direct about this: QA and review work rises even as output rises, so cutting engineering headcount because “AI made us faster” is dangerous unless you have closed the review gap first. The senior-engineer tax — review time up triple digits — falls hardest on the people you can least afford to bottleneck, and it is invisible to any metric that only counts merged PRs.

Open-source maintainers hit this wall first and hardest. The steady stream of plausible but hollow contributions costs real triage time even when it is well-intentioned, and that is the canary. Companies are next. The ones handling it well treat review capacity as a real resource to be measured, protected, and spent deliberately, not as slack that AI has freed up.

Mogu real talk:

The most sneaky sentence in the whole piece is this: the velocity dashboard can stay green the whole way to the wall.

Merged-PR counts go up, cycle time goes down, every chart the boss sees is good news. But defect rate, churn, and 3am pages are a different set of gauges, and they are usually not bolted to the same wall. Treating review capacity as “slack AI freed up, go cut some heads” is trading future incidents for one pretty report today. Review capacity is a resource, not fat to trim. ┐⁠(⁠￣⁠ヘ⁠￣⁠)⁠┌

In closing

Writing code got cheap. Understanding it did not. Code review did not become less important when agents arrived — it became the central activity. Do not take a one-size answer in either direction. If you are solo with no users, the enterprise horror stories about churn and duplication are a future risk, not today’s fire, so lean on your tests, review what matters, and stay honest that the deferred work is still owed. If you maintain something large for many people, every alarming number here is about you, and the only thing that holds is a tiered, evidence-required, deliberately heterogeneous review process with a human owning the merge.

What stays constant across the whole spectrum is the underlying economics: we made writing cheap, and understanding stayed exactly as expensive as it always was. The teams that do well over the next few years will not be the ones generating the most code. They will be the ones who built a review system they can actually trust, and who never confuse “the tests passed” with “a person understands what this does and why.”

Or, as Simon Willison keeps putting it: your job is to deliver code you have proven to work. Agents have not changed that. They have made the proving the center of the job instead of an afterthought. Understanding a system well enough to stand behind it is the most durable and most interesting skill in software — and there has never been a better time to get extraordinarily good at it.