AI Made Code Cheap and Review Expensive

AI-assisted coding sped up one half of the engineering loop, the writing of code, and moved the cost into the other half, the decision about whether that code is safe to merge. Most organizations still measure the fast half and staff the slow half as if nothing changed. That is why velocity charts improve while delivery, quality, and the people doing the verifying do not. The fatigue that follows is a load problem, not a skill problem. The levers that matter are adoption pacing, review capacity, and delivery expectations, and those levers sit with leadership. Pulling them well takes three things: knowing what the public data shows, choosing the first lever by company size, and recognizing where the published benchmarks get over-read.

What the Velocity Number Misses#

Start with the numbers that reach a board deck, with their origin attached. Most come from vendors that sell engineering analytics, so treat them as vendor telemetry; the independent anchors are DORA, Stack Overflow, and the academic studies. DX reports that developers using AI tools save four to six hours per week. The same DX dataset shows the downstream half absorbing the gain: median pull request size grew from 44 to 72 lines between July 2025 and June 2026, and DX’s Developer Experience Index slipped from 67 to 65 over four quarters, through Q2 2026. Faros AI, drawing on telemetry from 22,000 developers, measured average PR size up 51% and files edited per PR up 59.7% at high adoption, alongside 31% more pull requests merging with no review at all.

The queue is where the shift concentrates. LinearB’s benchmark across 8.1 million pull requests found AI-assisted PRs waiting 4.6 times longer for a reviewer to pick them up, and PRs from coding agents waiting 5.3 times longer. Yet once someone starts, review completes roughly twice as fast. Faros, by contrast, reports median time in review itself rising sharply. The vendors disagree about which stage hurts most, the waiting or the reviewing; they agree that the review side is where cycle time now lives. The distinction is operational, not academic. Long pickup waits point at routing, ownership, and work-in-progress limits; long active review points at change comprehensibility and batch complexity. Which one your own data shows decides the first intervention.

The independent sources describe the same shape in human terms. In the 2025 Stack Overflow survey, 66% of developers named AI solutions that are “almost right, but not quite” as their top frustration, 45.2% said debugging AI-generated code is more time-consuming, and 75.3% said they turn to a person when they do not trust an AI answer. DORA’s 2025 research found 90% of respondents using AI at work and more than 80% believing it made them more productive, while 30% report little or no trust in the code it produces. Read together: people use the tools, believe in them, and spend a growing share of the day verifying their output.

From Authoring to Verifying#

Review was never free, but AI adoption changes what kind of work fills an engineer’s day. Lisanne Bainbridge described the pattern in 1983, decades before coding assistants: automation turns a skilled operator into a monitor of the automation, and monitoring is the harder job, because it demands sustained attention to work the person did not do. Code review research points the same way. An observational study of experienced reviewers by Gonçalves and colleagues found that comprehending the change is the central cognitive challenge of review; the reviewer reconstructs an intent the author already holds. When implementation is delegated to a model, intent still exists, in the head of whoever commissioned the change, but it rarely travels with the diff unless that person records it; the reviewer then builds it from nothing.

Two documented effects compound the load. Ownership thins out: a study presented at IUI 2026 found that as AI autonomy rises, developers attribute responsibility toward the AI and become less comfortable claiming ownership of a change in front of technical reviewers. The same study found their willingness to accept accountability for production systems stayed consistent, so what weakens is the felt connection to the change, not the professional obligation. The organizational risk is ambiguity: unless each change carries a named human sponsor, responsibility blurs exactly where verification needs it sharpest. The load also concentrates: Faros AI describes a senior engineer tax, its term for experienced engineers absorbing a disproportionate share of review because they are the ones who catch what AI gets subtly wrong. That is a vendor observation; no public dataset measures the distribution. The mechanism is still plausible, because the pattern recognition that catches a subtly wrong change is precisely the scarce, senior skill.

This is where the word burnout belongs, used precisely. The WHO’s ICD-11 classifies burnout as an occupational phenomenon resulting from chronic workplace stress that has not been successfully managed, with three dimensions: exhaustion, mental distance from the job, and reduced professional efficacy. Maslach and Leiter locate its causes in six areas of worklife: workload, control, reward, community, fairness, and values, most of which are set by how an organization plans and staffs. No public source shows AI adoption causing burnout, and DORA found burnout and friction essentially unchanged with adoption. What the data does show is load moving toward the conditions the burnout literature warns about: workload rising on the review side, control falling for the people absorbing it, and accomplishment thinning when a day spent rejecting near-misses produces nothing visible. Managing those conditions is operating-model work, and it cannot be delegated to the individual engineer.

Adoption on a Ratchet#

The common rollout plan is a seat count and a training session. Replace it with a ratchet: expand AI usage one cohort at a time, and hold each step until the review-side metrics stay inside a band set in advance, covering time to first human review, unreviewed merge share, and median PR size. If a metric leaves the band, the next expansion waits until it returns. Adoption stops being a procurement decision and becomes a capacity decision.

The contrast with the field’s default answers is the point. More training assumes the engineer lacks a skill. A newer tool assumes generation is still the constraint. An AI review agent assumes review capacity can be bought back with the same technology that consumed it. The telemetry gives that assumption no comfort, though it does not settle the question either: Faros reports average time in review up nearly 200% under high adoption in the same period in which roughly a quarter of PRs received some AI review. That is two aggregate numbers on one population, not an experiment isolating the agent’s effect. Each answer is right somewhere; none is the right first move while the queue is the constraint.

Observed constraint	First intervention	Evidence required
Review side not measured	Instrument first: time to first human review, time in review, PR size, unreviewed merge share	None; without a baseline no pacing decision is ready
Review wait dominates cycle time	Pace rollout to review capacity and cap batch size	Time to first human review rising while active review time holds
No written stance with a named exception owner	Publish the stance before adding tooling	Similar changes merging on divergent individual judgment
Review load concentrated in a few seniors	Fund the tier as planned capacity and start succession	High, rising review concentration next to senior attrition signals
Metrics healthy, tool value still low	Targeted enablement first	Short queue, stable batches, near-zero unreviewed merges

The trade-off deserves plain statement. A ratchet slows the stated adoption number, which is uncomfortable when a board wants one. It requires instrumenting the review side before pacing against it. And it has a known failure mode: the ratchet becomes a permanent freeze because nobody owns the decision to advance it. Give the ratchet an owner and a standing review date, the way any other operating limit gets one.

Small Batches as a Hard Limit#

DORA’s AI Capabilities Model names working in small batches among the seven capabilities that decide whether AI adoption amplifies performance or instability. Its stated reason matches the queue problem exactly: small changes counteract the risk of large, hard-to-review blocks of generated code. A batch-size limit pushes the cost of a large diff back to where it is visible.

Make it a hard limit. A norm loses to release pressure: under a deadline the oversized PR merges anyway, and the norm quietly resets to whatever shipped last. A limit survives pressure because it removes the negotiation. Size it on more than lines: review cost scales with the domains a diff touches, the contracts and migrations it changes, and how hard it is to roll back, so a change that touches auth, payments, or a public contract counts as large however short it is. Pair the limit with a documented escape hatch for mechanical diffs (generated migrations, formatting passes, dependency updates) and a named approver for each exception. Without the escape hatch the limit becomes theater: people split changes along arbitrary lines to satisfy a counter, and review gets harder.

The cost is more pull requests, more merge coordination, and more reviewer context switches. It is worth paying because each review becomes tractable, and tractable reviews are the ones that happen. The 31% rise in unreviewed merges in the Faros data is what intractable review looks like once load finds another way through.

Making Verification Cheaper#

More review capacity is half an answer. Human attention cannot scale linearly with generated code, so the durable move is to lower the cost of verifying each change. Put differently, AI made implementation cheap and trustworthy evidence scarce; the lever with compounding returns is making evidence cheap again.

The review research explains how. Reviewers do not read a diff in isolation; they rebuild intent from descriptions, tickets, tests, and architecture. A generated change should arrive with a verification packet: the intent and non-goals, the behavior that changed, the invariants that must hold, the risk class, the scenarios tested with their results, and the rollback path. The generating tool can draft most of it; the engineer sponsoring the change confirms it. A reviewer holding that packet verifies claims instead of reconstructing intent, which cuts cost exactly where the load grew.

Deterministic checks come before human eyes: tests, static analysis, policy-as-code on the risk classes above. That order is also where an AI reviewer earns a place, not as recovered capacity but as a spotlight in front of the human gate, flagging where a diff drifts from its stated intent and where attention should land first.

Staffing the Verification Tier#

Review is invisible in most planning. It happens in the gaps between planned work, which is why a doubling of generation capacity quietly taxes focus time first. The fix is unglamorous: give review a named budget, a share of team capacity that appears on the plan, and report it with the same weight as feature throughput.

The harder question is who carries it, and the popular answer is rotation: spread review across everyone so nobody drowns. The position here is the less popular one. Protect the senior review tier instead of rotating it away. Verification of AI output is a scarce skill, and the reviewers who catch subtle wrongness are the reason the merge gate means anything. Rotation spreads that scarce skill thin and dilutes the standard the gate enforces. It also makes understaffing invisible by dressing it as fairness, so no chart ever shows a handful of real verifiers serving hundreds of engineers. A protected tier keeps the bottleneck visible, and a visible bottleneck can be argued for at budget time. Protecting the tier does not mean making it the gate for every change; that would recreate the overload it exists to manage. Route its attention by risk class (authentication, payments, migrations, personal data, infrastructure, public API contracts) and let low-risk mechanical changes flow through ordinary peer review.

The cost of that choice is key-person risk. A protected tier concentrates judgment in a few heads, and losing one of them hurts. A succession plan is the price of the choice: apprenticeship inside the tier, reviews done in pairs where one member is learning the standard, and an explicit expectation that the tier trains its successors. Ownership stays personal throughout: every merged change carries a named accountable human regardless of what wrote the code, with authorship and accountability recorded as separate facts. How ownership survives handovers and departures is its own subject, covered in the post on accountability without blame.

A Stance That Changes a Merge Decision#

DORA’s first AI capability is a clear and communicated AI stance, and the mechanism its research describes is psychological safety. Without a stated position, ambiguity produces over-cautious engineers who under-use the tools and reckless engineers who overstep. The decision still gets made; it shifts to individual judgment, one pull request at a time, and the risk shifts with it.

Most written stances fail a simple test, because they stop at a list of approved tools, which is procurement guidance and changes nothing. A stance becomes governance when it names two things. First, what the team will not do: categories of change that never merge without human review, categories of code that are not generated at all. Second, who decides exceptions, by name or by role, reachable this week. The test is direct: does the document change at least one merge decision this week? If it cannot, it is shelf-ware, and the engineers have already routed around it.

Maintenance is part of the deal. A stance that lags the tools by two generations teaches the team that policy and practice are unrelated. Give it an owner, a revision cadence, and a length short enough that revising it stays cheap.

The First Lever at 30 People and at 300#

Which lever to pull first depends on organizational shape more than on the tools, and the fork is worth making explicit. The headcounts are shorthand: the real variable is whether the org is one team or many, how coupled the codebase is, and how much of the work is regulated. A thirty-person team on a regulated monolith can need heavier review governance than three hundred people on loosely coupled services; read thirty as single-team and three hundred as multi-team.

At around thirty engineers there is no separate review tier; the same handful of people generate code and verify it, and a queue metric mostly measures their calendars. The first honest move at this size is to name verification as work: put review time on the plan, budget it, and let the roadmap absorb the fact that part of the team’s week now goes to checking generated output. Pacing bands and cohort rollouts come later. The binding constraint at thirty is that verification is invisible, and making it visible costs one planning meeting.

At around three hundred, the queue is where the organization stalls, and no individual calendar explains it. Batch size is the first lever there, because it is the one lever that changes queue behavior without hiring: smaller changes route to reviewers faster, wait less, and avoid the oversized diffs that sit until someone finds a free afternoon. The structural moves, funded review capacity and a protected tier per group, matter at that size too, and they take quarters. A batch-size limit takes a week to enact and buys the time to do the rest.

What to Measure#

Most organizations already measure the generation side: deployment frequency, lead time for changes, PR throughput, the AI-authored share of code. Keep those, holding the AI-authorship share as a diagnostic rather than a target. What is usually missing is the review side, and instrumenting it is the prerequisite for every lever above.

Metric	Unit	What it tells you
Time to first human review	hours, median and p90	queue behavior, the stage LinearB found dominating AI-assisted cycle time; an agent comment does not stop the clock
Time in review	hours, median and average separately	active verification cost; the two diverge sharply in the vendor data
PR size and files touched	lines changed, files per PR, production code, tests, and generated files counted separately	whether the risk-adjusted batch limit is holding
Unreviewed merge share	percent of merged PRs	whether load is bypassing the gate
Review concentration	share held by the busiest reviewers, normalized to team size	whether the verification tier is absorbing the shift silently
Rework and churn	percent of lines revised within two weeks	whether merged speed is real or borrowed from next month

On the outcome side, keep change failure rate and recovery time. Read two sustainability signals together: voluntary attrition in the senior tier next to review concentration, and a validated wellbeing instrument run at team level on a fixed cadence. Team level matters: the trend stays readable, and no individual is being assessed. Track uninterrupted focus time per engineer as well; rising review load is a claim about where attention goes, and focus time is where the cost lands first.

How the Benchmarks Get Over-Read#

Every figure above comes from someone else’s population, and the two most-quoted families of results are over-read in opposite directions.

The throughput numbers get read as productivity. Acceptance rates, PRs per engineer, and hours of typing saved measure generation, and generation was never the whole loop. Jellyfish, a vendor selling engineering analytics, illustrates it across two studies. Its analysis with Harvard researchers, covering roughly 100,000 engineers, found no detectable aggregate decline in code quality. Its separate study with OpenAI found a 26.8% relative rise in the share of pull requests linked to bug tickets at the highest adoption levels. Output got faster, and more of the output is corrections. GitClear, a vendor whose product measures code quality, points the same direction at the level of the code itself: duplicated blocks at the highest level it has recorded, and moved-or-refactored code down to 3.8% of changed lines year-to-date. Aggregate quality holding while duplication climbs is consistent; averages and per-change composition answer different questions.

The METR result gets over-read the other way. In that randomized trial, experienced open-source developers were 19% slower with AI assistance while believing they were 20% faster, which is a genuinely important perception finding. It is also sixteen developers on 246 tasks, in mature repositories they knew deeply, with early-2025 tools. It does not establish a general law that AI slows developers down, and METR itself has moved on: a February 2026 update reported that the follow-up study could not produce a reliable estimate, because developers increasingly refused to work without AI and that selection biased the result downward. The raw numbers in the follow-up leaned toward speedup, and the researchers say developers are likely more sped up by early-2026 tools than the early-2025 estimate suggests, while calling their own data very weak evidence for the size of it. The counterweight is the randomized trial by Peng and colleagues with GitHub, Microsoft, and MIT, which found a 55.8% speedup on a greenfield task. Task type and codebase familiarity separate the two results, and that separation is precisely what a CTO needs. Most production work resembles the METR setting more than the greenfield one, and neither study measured your codebase. The individual side of that perception gap is a separate subject, covered in the post on practical judgment with coding agents.

The burnout question splits along method. DORA’s survey research finds burnout and friction at similar levels with or without AI adoption. Faros, measuring workflow telemetry, presents its findings as directly contradicting DORA’s and argues that the senior review burden carries fatigue and attrition risk. Self-report and telemetry measure different things, and the uncomfortable reconciliation is that workload tends to appear in the systems before it appears in a survey. A related disagreement sits behind it: DORA’s amplifier thesis holds that strong existing practice magnifies AI’s benefits, while Faros argues that engineering maturity does not shield a team from the review shift. Treat both as open questions and answer them from your own instrumentation.

Moves That Backfire#

Four moves recur in AI rollouts. Each looks reasonable in the quarter it is made, and each makes the review problem worse.

Repricing the roadmap off generation speed. Reading the velocity increase as new baseline capacity and committing the roadmap against it is the most damaging move on this list; the gap gets absorbed silently by the people doing the verifying. Commitments should track delivered, verified change, which in the DX and Faros telemetry moved far less than throughput did. The broader argument, that pace bought this way is borrowed, appears in the post on sustainable engineering pace.

Making AI usage a target. The share of AI-authored code and suggestion acceptance rates are adoption telemetry. Turned into targets, they push volume directly into the constraint. Keep them diagnostic and set targets on delivery and stability outcomes instead.

Booking an AI reviewer as recovered capacity. A review agent changes the shape of the load; the accountable human remains, and in the Faros telemetry review time stayed heavily elevated even where agents reviewed a quarter of PRs. After deploying one, measure whether time to first human review actually fell.

Answering a workload signal with a wellbeing program. If review load is the cause, perks are a category error. Maslach and Leiter’s six areas of worklife put workload, control, reward, and fairness inside ordinary planning and staffing decisions; check those before adding a benefit. Read DORA’s flat burnout finding in the same spirit: unchanged with adoption is a missed opportunity. DORA’s own team profiles include a foundational-challenges cluster where low performance, high burnout, and high friction travel together. Find out which profile your teams are in before assuming the flat average describes them.

A fifth, quieter one: rolling out to the whole organization at once. A cohort rollout preserves a comparison group. Without one, no before-and-after number from your own org means much, and the vendor benchmarks become the only thing left to steer by.

When the Constraint Is Elsewhere#

The default assumes the review side is the constraint, and it will not always be. If review metrics are healthy (short queue, stable batch sizes, unreviewed merges near zero) and engineers still struggle to get value from the tools, the gap is genuinely skill, and targeted enablement is the right first spend. If the work is mostly greenfield (prototypes, new scaffolding, products before their first customers), the Peng result is closer to that reality than the METR one, and generation capacity may still be the constraint worth investing in. And if nothing on the review side is measured, no pacing decision is ready to be made; instrumentation precedes policy.

Everywhere else, hold the default: pace adoption to what review capacity demonstrably absorbs, cap batch size with a real escape hatch, staff verification as planned work, and keep a named human accountable for every merge. If only one step fits this week, instrument time to first human review and the unreviewed merge share; every other decision depends on seeing those two numbers.

References#

• DORA: State of AI-assisted Software Development 2025 (opens in new tab) - Survey research across roughly 5,000 technology professionals: adoption levels, throughput and stability findings, trust figures, team profiles, and the unchanged burnout result.
• Google Cloud: Putting the DORA AI Capabilities Model to work (opens in new tab) - The seven organizational capabilities that determine whether AI amplifies performance, including a clear AI stance and working in small batches.
• Stack Overflow 2025 Developer Survey: AI (opens in new tab) - Adoption, trust, and frustration data, including the “almost right, but not quite” finding and how often developers turn to another person.
• METR: Measuring the impact of early-2025 AI on experienced open-source developer productivity (opens in new tab) - The randomized trial in which experienced developers were 19% slower on their own mature repositories while believing they were faster.
• METR: We are Changing our Developer Productivity Experiment Design (opens in new tab) - The February 2026 update declaring the follow-up study unreliable due to selection effects; raw point estimates moved to 4% and 18% speedup with wide, zero-crossing intervals.
• Peng et al.: The impact of AI on developer productivity, evidence from GitHub Copilot (opens in new tab) - The randomized trial reporting a 55.8% faster completion on a greenfield task; the counterweight to the METR result.
• GitClear: The Maintainability Gap, 2026 AI code quality research (opens in new tab) - Vendor analysis of code-change composition showing duplication rising and refactoring collapsing as AI authorship grows.
• Faros AI: 2026 AI Engineering Report, The Acceleration Whiplash (opens in new tab) - Vendor telemetry from 22,000 developers on PR size, review time, unreviewed merges, and delivery outcomes under AI adoption.
• Faros AI: AI code quality and the senior engineer review burden (opens in new tab) - The vendor’s argument that experienced engineers absorb a disproportionate share of AI review load.
• LinearB: 2026 Software Engineering Benchmarks Report (opens in new tab) - Vendor benchmarks across 8.1 million pull requests, including queue wait and review speed for AI-assisted and agentic PRs.
• DX: The State of AI Impact in Engineering, Q2 2026 (opens in new tab) - Vendor data on developer time saved and the four-quarter Developer Experience Index decline.
• DX: AI-authored code has nearly doubled (opens in new tab) - The vendor’s line-level PR size figures, 44 lines to 72 lines between July 2025 and June 2026.
• Jellyfish and Harvard: AI is making developers faster, so where is the business impact? (opens in new tab) - Vendor analysis with Harvard researchers across roughly 100,000 engineers, finding no aggregate decline in code quality.
• Jellyfish and OpenAI: Measuring the impact of AI coding tools (opens in new tab) - The vendor’s separate study, source of the 26.8% relative rise in the share of pull requests linked to bug tickets at high adoption.
• WHO: Burn-out an occupational phenomenon, ICD-11 (opens in new tab) - The official classification of burnout as an occupational phenomenon with three dimensions, anchoring the term precisely.
• Maslach and Leiter: Understanding the burnout experience (opens in new tab) - The three-dimension model and the six areas of worklife that locate burnout’s causes in the job environment.
• Bainbridge: Ironies of Automation (Automatica, 1983) (opens in new tab) - The classic analysis of how automation turns a skilled operator into a monitor, and why monitoring is the harder job.
• Gonçalves et al.: Code Review Comprehension (opens in new tab) - An observational study of experienced reviewers establishing comprehension of the change as the central cognitive challenge in review.
• Seo, Deldari and Mentis: Whose Code Is It? (IUI 2026) (opens in new tab) - Peer-reviewed evidence that psychological ownership shifts away from the developer as AI autonomy rises, while willingness to accept accountability for production systems stays consistent.