Fast Code, Tired Developers: Reviewing AI-Generated Code Without Burning Out
Why reviewing AI-generated code, not writing it, is the real bottleneck — and how to fix developer experience in the agentic era.
Agents made writing code nearly free. They did not make understanding code any cheaper. That gap is the whole story, and most teams have not priced it yet.
TL;DR
Agents made writing code nearly free. They did not make understanding it any cheaper. The bottleneck moved from writing to comprehension, the one place you can’t scale by buying compute.
Across five datasets the pattern holds: individuals speed up, teams slow down. Around 98% more PRs, 91% longer reviews, code churn up from 3.1% to 5.7%.
Agent code is harder to review because there’s no author reasoning to recover. You reconstruct intent that never existed. Approval is not understanding.
The bill arrives later, in a different currency: people who ship more, understand less, learn slower, and enjoy the work less.
The fix isn’t slowing agents down. Make agents emit intent, risk-tier review by blast radius, raise the safety floor, cap work to comprehension capacity, and measure the human cost.
The pitch is seductive. An agent produces in an afternoon what used to take a week. Leadership sees the throughput and assumes the rest of the system will keep up. It does not. The constraint simply moved, and it moved to the one place that cannot be scaled by buying more compute: the human who has to decide whether the output is correct, safe, and worth merging.
This is a write-up about where the work actually went, why the speed turns into a burden, and what to build so the business wins on speed without paying for it in developer learning and happiness.
The bottleneck moved, it did not disappear
For decades, code review worked because of a quiet accident of relative speed. A human wrote code at human speed, and another human read it at human speed. Reading was faster than writing, so review kept up. Agents broke the accident: generation now runs at machine speed while reading still runs at human speed.
The data tells a consistent story, and it is the same story across five independent datasets: individual output went up, and the cost of absorbing it went up faster.
“We bought faster cars and the roads got more congested.”
The headline is not that agents are bad; it is that team delivery slows even as individuals speed up
Why agent code is harder to review than human code
The deeper problem is not volume. It is intent.
A colleague writes it: There is reasoning behind every choice, and review is a conversation with that reasoning. You can ask why.
An agent writes it: There is no reasoning to recover. The reviewer reconstructs a rationale that never existed, which is slower and more draining than reading code a person thought through.
Plan mode narrows this gap. When the agent writes a plan you approve before it touches code, intent exists again, and the human checkpoint moves upstream to the spec, which is where the expensive mistakes start. But plan mode does not close the gap, it relocates it. You still have to verify that the execution matched the plan, and that the plan you approved was the one you actually wanted rather than a coherent proposal you waved through. Approval is not understanding.
And a single agent in plan mode is the easy case. The real 2026 workflow is several agents at once, across different stories, issues, and research threads, each moving faster than you can context switch into it. You are not going to read every line, and anyone who claims they do across that many parallel streams is rubber stamping with extra steps.
Atlassian’s 2025 State of Developer Experience survey found 68 percent of developers saving more than ten hours a week with AI, while half of them lost ten or more hours a week to organizational inefficiencies: finding information, adapting to new tools, and switching context between them. The time saved came back in a different pocket.
So the honest question is the one in the margin: where does trust live now?
It stops living in line-by-line reading and moves into a layered stack.
This is where the two skills come apart. Generating code and discriminating good code from bad are different cognitive capabilities. You can keep reviewing competently long after your ability to write from scratch has faded. That sounds fine until you notice the threshold where review quietly becomes rubber stamping.
If your ability to read does not scale with the agent's ability to output, you are no longer engineering. You are hoping, and shipping the hope.
The hidden cost: Learning and happiness
Here is the part the throughput dashboards never capture. Every nuanced decision an agent makes is a decision the developer used to make and learn from: which abstraction to reach for, when to duplicate instead of generalize, how to name the thing, where the concurrency bug hides. Under human-speed authorship, those decisions were the daily curriculum of becoming a better engineer. Under agentic authorship at full volume, they stream past faster than anyone can absorb them. The reviewer approves the decision without internalizing it. The learning loop breaks. Compound that over months and you get a specific kind of exhaustion that is now well documented.
“The invoice arrives later, in a different currency: people who ship more, understand less, learn slower, and enjoy the work less.”
that is a bad trade, and it is avoidable
The Fix?!?: What to build
The goal is not to slow agents down. It is to design the developer experience so speed is safe and so understanding keeps pace with generation. Eight things matter.
Make agents emit intent, not just diffs
The highest-leverage change. Require the agent to produce a decision log with every change: what it chose, what it rejected, and why. This attacks the intent-less-code problem at the root, because the reviewer stops reconstructing reasoning that never existed and starts evaluating reasoning that is written down. It also restores the learning loop, because the nuanced decisions become legible, teachable artifacts instead of invisible ones.
Risk-tier review by blast radius
Human attention is the scarce resource, so spend it deliberately. Low-risk, well-tested, reversible changes can lean on AI reviewers, tests, and policy gates. High-blast-radius changes, including interfaces, data migrations, auth, and money paths, get a human who owns the merge. A solo developer with no users and a team maintaining a ten-year-old system are not solving the same problem, and the review policy should say so explicitly.
Raise the safety floor so speed stops being scary
The release process feels like a burden because a fast merge can do real damage. Fix the floor, not the speed. Feature flags, canary releases, automatic rollback on error-budget breach, and small blast radius make reverts cheap. When a mistake costs a flag flip instead of an incident, fast becomes fine.
Cap work in progress to verification capacity
Throughput is bounded by the slowest necessary step, and that step is now understanding. Letting generation outrun the team’s ability to comprehend does not increase delivery, it increases the queue and the churn. Manage the system as a queue: limit open agent-generated PRs per reviewer rather than celebrating raw PR count.
Make learning a first-class output of the loop
Treat a capable agent like a strong junior whose work you mentor. Rotate a review owner, pair or mob on agent output for tricky areas, and turn recurring agent decisions into short internal write-ups. The point is to convert review from a tax into the primary way the team keeps learning.
Keep humans authoring where judgment compounds
Protect a deliberate-practice budget. Architecture, public interfaces, and security-sensitive paths should still see human hands regularly, so the discrimination skill does not quietly atrophy into rubber stamping.
Instrument developer experience, not just velocity
Track review latency, reviewer queue depth, churn, and the lag between merge and defect discovery. Then track the human side directly: cognitive load, decision fatigue, and sentiment. Manage to those numbers. A team that ships 40 percent more while its review queue, code churn and burnout climb is not winning, it is borrowing.
Assign clear merge ownership
Someone human owns every merge into a system with users. Accountability is what keeps review from decaying into hope. This is a cultural rule as much as a tooling one.
None of this is anti-agent (I live by agents and I dearly feel the pain of the transition) It is how you let agents run fast without leaving the people behind them drained and deskilled.
Make the pipeline as fast as the generator
Even once review is sorted, the pipeline itself becomes the wall. Human review, agent review, CI checks, builds, each was sized for the rate at which a person commits. At agent rate they back up, and the developer sits in the queue, drained, while the platform catches up. This is the part of the original complaint that no amount of CD fixes by itself: a pipeline tuned for human throughput is now the bottleneck. Closing it is mostly unglamorous platform work, and it pays for itself fast.
left | Push verification to the agent
Give the agent a local test harness it can run before it ever raises a PR: fast unit tests, contract and integration checks, linters, and type checks that run in seconds on the agent’s machine. Most failures then get caught and fixed inside the agent’s own loop, before they consume a CI runner or a human’s attention. Fail fast and fail local. The cheapest failure is the one that never reaches the pipeline.
order | Order the pipeline to fail fast too
Run the cheapest, most-likely-to-fail checks first, parallelize the rest, and surface the first red signal immediately rather than after a twenty-minute full run. A feedback loop measured in seconds keeps both the agent and the human in flow. A loop measured in tens of minutes is where context and patience leak away.
build | Fix the build, not just the tests
On a lot of pipelines, more than half the wall-clock time goes into building and uploading artifacts, container images especially, not into running tests. Layer Docker builds so dependencies cache and only the changed layer rebuilds, cache build artifacts between runs, and stop rebuilding and pushing images that did not change. This is often the single largest and most ignored speedup available, and the agent feels it on every iteration.
brief | Make the PR explain itself
A wall of text, or a wall of agent comments, is not review, it is homework. Have the agent generate a PR description a human can digest in under a minute: what changed, why, the risk, what was tested, and the diff against the approved plan. A short summary up top, visuals where they help, detail collapsed below. The reviewer should read a briefing, not perform archaeology. This is the same decision log from the principles above, rendered for a human instead of dumped as raw output.
ping | Keep the human in the loop by default, not by interruption
Coding-agent plugins that watch a PR, post the digestible summary, flag the risky hunks, run the agent reviewer’s first pass, and ping the human only when judgment is actually required turn review from a constant tax into an exception process. The human stays informed continuously and gets pulled in deliberately, instead of either babysitting every PR or rubber stamping a backlog.
gate | Ask whether you even need a PR
For a trivial, well-tested, reversible change, the PR can be pure ceremony. For anything with blast radius, it is the gate that catches the accidental violation the agent did not know was a violation: the migration it ran without thinking, the dependency it quietly pulled in, the public interface it changed. The answer is usually yes, keep the gate, but automate it. Auto-merge on green for low-risk tiers, require a human owner for high-risk ones, and let policy decide which is which. The PR becomes a risk-weighted checkpoint, not a reflex.
teach | Make the pipeline teach
Every run already produces the raw material for learning, so capture it instead of throwing it away. Have the agent emit two artifacts at merge. One is for the organization: a short record of the decision, the pattern, and the tradeoff, so the knowledge does not stay locked inside a single PR. The other is for the individual: a personal learning note that turns the nuanced decisions the agent made into something the developer can read and absorb later, on their own time. It costs almost nothing, because the agent is already holding the context the moment the work is done.
The cautionary tale: how not to treat developers
There is a version of the agentic future that takes the speed obsession to its logical, and cynical, end. Meta is the clearest current example, and it is worth naming because it is the inverse of everything above.
That is the anti-pattern in its purest form. It optimizes for the speed of generation and treats developer learning and happiness not as costs to be managed but as resources to be mined. The choice in the agentic era is not whether to use agents. It is whether the developer comes out of the loop sharper and more energized, or hollowed out and surveilled.
Writing got cheap. Understanding did not. A team that respects that asymmetry, by making agent reasoning legible, spending human judgment where it counts, raising the safety floor, capping work to comprehension capacity, and measuring the human cost, gets the speed and keeps its people.
A team that ignores it gets a quarter or two of impressive dashboards, followed by brittle software and exhausted engineers.
Speed is worth having. It is only worth having if the people building with it are still learning, and still want to be there.
FAQ
What is the AI productivity paradox in software development?
Individuals ship more with AI coding agents, but team delivery often slows. Generation runs at machine speed while review and comprehension still run at human speed, so the constraint moves to the human who has to understand and approve the output, not to writing the code.
Why is AI-generated code harder to review than human code?
When a colleague writes code, there’s reasoning behind every choice and review is a conversation with that reasoning. When an agent writes it, there’s no author rationale to recover, so the reviewer reconstructs intent that never existed, slower and more draining than reading code a person thought through. Approval is not understanding.
How do you review AI-generated code at scale without burning out?
Make agents emit a decision log of what they chose and rejected, risk-tier review by blast radius, raise the safety floor with feature flags and fast rollback, cap work-in-progress to the team’s comprehension capacity, keep humans authoring where judgment compounds, and measure developer experience, not just velocity.
Why do AI coding agents make developers more tired?
Every nuanced decision an agent makes is one a developer used to make and learn from. At full volume those decisions stream past faster than anyone can absorb them, the learning loop breaks, and senior engineers, who hold the quality bar, absorb a disproportionate share of risk. The result is exhaustion plus deskilling.
Does plan mode solve it?
It helps but doesn’t close the gap. Plan mode restores intent by having you approve a spec before code is written, moving the human checkpoint upstream. But you still have to verify execution matched the plan, and that the plan you approved was the one you actually wanted. It relocates the work rather than removing it.