Faster Writing, Thinner Review: When an AI Productivity Target Is Met and Code Review Becomes the Bottleneck

When the Output Target Doubles, Where Does the Pressure Go?

Consider an engineering organization whose leadership sets a public goal: within twelve months, use AI to double merged pull requests (code changes accepted into the codebase) per engineer per month. Eventually the dashboard crosses the target. But if the number of reviewers does not grow with it, the extra changes can only be absorbed by automated checks and by approvals nobody comments on.

Our thesis: the binding constraint is human review capacity under a throughput target. When leadership sets an AI target on an output count, the count can be met—slowly, through each person’s accumulated use rather than the announcement, and with the cost landing downstream on review^[1].

From Gradual Throughput Gains to Thinner Review

He, Agarwal, Denisov-Blanch, Azaletskiy, Koyejo, and Vasilescu (2026) followed one such mandate in a longitudinal case study^[1]. In June 2025, the technology chief of a mid-sized, AI-forward software company publicly set a goal of doubling merged pull requests per engineer per month within twelve months using AI, with uncapped budgets^[1]. Across 802 developers and 196,212 pull requests from January 2024 to April 2026, internal telemetry and change history compared each developer’s throughput after starting AI with their own before, relative to colleagues whose use did not change that month (staggered difference-in-differences, not randomized)^[1].

The mandate date itself moved throughput little^[1]. Throughput rose about 12% when each developer started using AI and grew with accumulated use: about 1.5× at observed usage under strict calendar-month controls, and 2× only after roughly nine months on the tools; company-wide per-capita 2× was reached only in April 2026, the tenth month after announcement^[1]. Extra working days explained at most one-fifth of the gain, changes got larger (median 35 to 61 lines), and feature and bug-fix changes grew faster than routine maintenance^[1]. Gains were similar across seniority, concentrated in repositories created since 2022 (+44%) and small and not significant in older ones (+12%)^[1].

The strain landed on review. As AI-authored changes reached about 90% of the total, change volume grew 3.1× over the early-2025 baseline while the reviewer pool grew only 1.5×, doubling load per reviewer (2.0×)^[1]. Changes with at least one human review fell from 89% to 68%, while automated AI review rose from about 19% to about 84%, overtaking human review shortly after the mandate and replacing part of it rather than only adding to it^[1]. Substantive human review (with a human comment) fell from about 39% to about 21% of changes, while silent approvals (no comment) held at about 50%; the median reviewer’s commented reviews stayed flat (about 3 per month) while silent approvals roughly doubled^[1]. Within author and month and controlling for size, AI-authored changes took about 20% longer from first human review to merge and 22% longer in total cycle time (correlational)^[1]. Late in the window, the company routed changes through AI review and auto-approval, keeping pace by routing around human review rather than reviewing faster^[1].

Short-horizon proxies showed no acute quality collapse: merge rate stayed flat, revert share did not rise, and authors were no more likely to open a follow-up bug fix after AI-authored changes^[1]. Yet these proxies miss defects, incidents, and maintainability, and the merged-change count recorded the speed-up without recording the shift in who reviews the code^[1]. The authors advise treating a mandate as the start of a transformation rather than a tooling rollout, setting the horizon in quarters, investing in use intensity first, pairing the target with other signals (by Goodhart’s law, a count that becomes a target stops measuring what it was meant to), and planning review capacity like authoring capacity^[1]. Limits: one AI-forward firm with uncapped budgets and many new repositories (closer to an upper bound than an average); non-randomized adoption (uncertain effect size, robust direction); change counts capturing activity only; and short-horizon quality proxies^[1].

In a randomized controlled trial of 16 experienced developers across 246 tasks in mature open-source projects (average 5 years prior experience), Becker, Rush, Barnes, and Rein (2025) randomly allowed or disallowed AI tools per task^[2]. Developers forecast AI would cut completion time by 24% and afterwards estimated a 20% cut, yet allowing AI increased measured completion time by 19%^[2]. Short-horizon impressions are not evidence, and the slowdown on mature projects is consistent with the small gains in older repositories in ^[1].

Classic automation research explains the risk. Parasuraman and Riley (1997) define misuse as over-reliance on automation, producing monitoring failures or decision biases (affected by workload and reliability), while disuse stems commonly from false alarms^[3]. They define abuse as automating functions without due regard for human performance consequences, defining the operator’s role as a by-product of automation and promoting misuse and disuse^[3]. When review load doubles and automated review takes over coverage, silent human approval risks becoming a by-product^{[1, 3]}.

Engineering Mapping on rlab.works: Review Capacity, Approval Boundaries, and Attention Queues

In our engineering view, teams should: (1) report review metrics next to throughput—substantive human review share, silent-approval share, load per reviewer, and time in human review; (2) write down before rollout which change classes automated review may approve alone and which always need a human comment; (3) treat the attention queue as a capacity, not a formality—slowing intake or adding review capacity when load outgrows reviewers; (4) record who approved what and with what evidence, distinguishing “approved” from “read”; and (5) judge the programme in quarters across multiple metrics rather than perception surveys^[2].

In Agent OS on rlab.works, three proposed skill packs and three components map these gates:

• Task delivery: Plan and deliver work (S01) runs Plan the steps → Approve the scope (human gate) → Run and collect → Review and hand over (human gate), using Collaborative delivery, approvals and evidence gates (conversation rooms, held drafts, attention queues, decisions, artifact versions, approvals, and evidence-backed completion and handoffs) and Auditable workflows, human confirmation and decision review (versioned workflows and steps, permissions, pauses for human decisions, and recorded reviews). Manufacturing transferable: orchestrates software tasks and human records only; people perform physical repairs; work permits and checkpoints need configuration. In our view, Review and hand over (human gate) should enforce which changes require a human comment.
• Local execution: Approve computer actions (S03) runs Check readiness → Approve the action list (human gate) → Act and retain evidence → Check the changes (human gate), with Local coding-agent execution governance (normalises coding-agent hook events, decides allow, deny, or approval before local tool execution, and records the result). Legal transferable: limit read and write folders explicitly; external filing is outside default permissions. In our view, retaining evidence at Check the changes (human gate) bounds downstream review load.
• Release gating: Release and restore apps (S05) runs Prepare release manifests → Check recovery readiness → Approve release conditions (human gate) → Stage the release → Accept or restore (human gate). Energy transferable: supports software delivery only, no plant equipment control; adapt offline environments, trusted signing, and site change processes. In our view, Approve release conditions (human gate) should verify whether changes received a substantive human review or only auto-approval.

All three packs are proposed and not integrated, demonstrated with synthetic data. Collaborative delivery, approvals and evidence gates and Local coding-agent execution governance have “working” maturity, while Auditable workflows, human confirmation and decision review is a prototype. None of these measures reviewer load, review depth (commented versus silent approval), or automated-approval share—those are requirements we draw from the papers.

Three Checks Before Setting an AI Coding Target

• Pair throughput with review depth and load: Next to merged changes, track human review coverage, substantive review share, silent-approval share, and load per reviewer^[1].
• Define auto-approval boundaries up front: Specify before rollout which changes automated review may approve alone and which require a human comment at Review and hand over (human gate) or Approve release conditions (human gate).
• Set the horizon in quarters and cap queue load: Judge multi-quarter cycle and review times rather than perception surveys^{[1, 2]}; in our view, slow intake or add reviewers when attention queues back up.