Self-Improving AI Isn't Close. Google's Own Numbers Admit It

Ask what percentage of Google's code is AI-written and you get a dazzling number: roughly 75 percent of new code, per remarks from Google engineer Haydn Belfield reported by The Decoder. The same report carries a second figure that rewrites the first. About 88 percent of AI-driven changes still require human oversight or intervention. Pair them, and two of the loudest stories in AI coverage, the vanishing engineer and the research flywheel that spins itself, both lose their footing. Self-improving AI, judged by the lab's own accounting, is gated by human verification bandwidth rather than model capability. That inversion is the planning story for anyone who has to convert lab claims into headcount, tooling, and roadmaps.

What Google Actually Said, in Three Numbers

Three data points, with one attribution caveat up front. As The Decoder reported, Belfield shared that AI now writes more than 75 percent of Google's production code, that 88 percent of AI-driven changes still need a human in the loop, and that AI has not measurably accelerated DeepMind's own research. Google's internal General Capability Index, per the same report, shows steady growth with no sudden speedup. Demis Hassabis has made a similar point from the top of the organization, publicly framing meaningful self-improvement as years away rather than quarters away.

These are executive and engineer statements relayed through reporting, not peer-reviewed measurements or published telemetry. Treat them accordingly: as unusually candid calibration data from the one lab with the strongest incentive to claim the opposite. The candor is where the value is.

The reporting does not specify what "code" counts (lines, tokens, or diffs) or what a "change" is (a pull request, a commit, an accepted suggestion). Google's codebase is also an extreme outlier in size, age, and test coverage. The right posture is neither dismissal nor adoption. It is arithmetic on the reported ratios, with assumptions stated.

The Review Tax Inside the 75/88 Pairing

Generation share and oversight ratio sit on different denominators. The 75 percent figure describes input volume, how much code got typed by a model. The 88 percent figure describes a constraint, how much of that output still consumes human judgment before it ships. Coverage quoting the first without the second is incomplete by construction, because the second is where the cost lives.

Run the pairing through a simple scenario. Assume "changes" as the unit, and assume human-written changes are all reviewed:

1. 100 changes land in a sprint.
2. 75 arrive AI-drafted, 25 human-written.
3. 12 percent of the AI changes, about 9, merge with no human involved.
4. The other 66 AI changes, plus the 25 human ones, still route through review. That is roughly 91 of every 100 changes.

Writing effort fell by about three quarters across that mix. Review coverage fell by about nine points. AI scales writing code; it does not yet scale verifying it, and the shortfall lands on your most senior people.

The review tax is the share of AI-generated output that still bills a human for verification. At an 88 percent oversight ratio, roughly seven of every eight AI-made changes charge that bill anyway.

The tax compounds because assistance inflates author confidence faster than code quality. In a controlled Stanford experiment, participants using an AI assistant produced code with more security vulnerabilities while simultaneously feeling more convinced their code was secure. Review is the control loop that catches what confident authors miss, and it does not parallelize with generation.

Myth One: AI-Written Code Means Engineers Are Done

If nearly every AI-drafted change still bills a reviewer, codegen does not eliminate engineering cost so much as relocate it from writing to verifying, and verification is the scarcer skill.

Take a 10-engineer team with 400 engineer-hours per week. Suppose AI drafts 75 percent of the code and writing time collapses accordingly. Suppose the team ships 75 AI-drafted changes a week, and a careful review of each small diff costs about 30 minutes including context switching. Review alone consumes roughly 37.5 hours, close to a full engineer-week, concentrated on senior reviewers whose hours were already the team's most expensive. Now let generation get cheaper. Agent output doubles, then triples, then approaches free. Writing cost trends toward zero while review load scales linearly with volume. This is the AI code review bottleneck in one line: generation scales, judgment does not.

Independent evidence is directionally consistent with a nonzero review tax, with effect sizes varying by team, task, and seniority:

• A 2025 randomized controlled trial by METR found experienced open-source developers were roughly 19 percent slower on familiar repositories when using AI coding tools, while estimating they had been faster.
• The 2024 DORA report associated broad AI adoption with throughput gains that arrived alongside delivery-stability costs at higher adoption levels.
• GitClear's multi-year analyses of commit data report rising churn and code duplication in AI-heavy codebases, which reads like deferred review debt surfacing months later.
• A Google-commissioned IDC survey reports developer productivity gains, but that evidence is survey-shaped and self-reported, the tier to discount hardest.

The planning consequence is direct. If 88 percent oversight holds, the binding unit is marginal review load per engineer-day, and engineering capacity planning for AI-generated code becomes review-capacity planning. Verification infrastructure turns into the highest-leverage spend: smaller diffs, deeper test suites, and automated gates that filter obvious failures before a human ever looks. Those are not hygiene projects; they are capacity. Under an 88 percent assumption, an hour of review automation buys more shipped AI code than another codegen seat.

Myth Two: Self-Improving AI Is Accelerating Research

The second myth is the bigger one. Recursive self-improvement, the idea of AI improving the AI that improves the AI, powers the most aggressive timelines in the field. It is why some executives talk about capabilities compounding within quarters. So the most interesting sentence in the whole episode is the quiet one: a Google engineer stating there has been no measurable AI-driven acceleration of research at DeepMind, with the internal capability index showing steady rather than compounding progress. Demis Hassabis's public timeline points the same way, placing meaningful self-improvement years out.

Read that against incentive. This is the lab whose public narrative is acceleration, reporting that its own research has not sped up. When the party with the most to gain from claiming a flywheel declines to claim it, the absence carries information.

The roadmap consequence: pace agent autonomy to verification capacity, not model releases. The oversight ratio is a direct proxy for how much autonomy current tooling actually supports in production, so gate autonomy tiers on it.

• Allow autonomous merge for a class of changes only when that class's observed oversight ratio falls below a threshold you set, say a quarter, with stability flat or better.
• Expand agent scope when the ratio falls, not when a new model launches.
• Track the ratio per change class and per repo; a single blended number hides the classes that are genuinely ready.

If someone on your leadership team asks whether AI accelerates AI research, the honest current answer from inside DeepMind is not measurably yet. Build the agent roadmap on that answer, not on the launch cadence.

How to Audit the Next Viral Lab Claim

The most durable skill from this episode is evidence triage, and knowing how to evaluate AI lab claims will outlast any single statistic. Capability numbers arrive in three tiers, and most coverage flattens them into one.

Even the top tier deserves questions. A CACM review of Copilot measurement walks through why suggestion-acceptance rates and self-reported speed make shaky proxies for delivered productivity, a useful reminder that "measured" claims get audited too.

Five questions for the next viral claim:

1. Who said it, in what venue, and what do they gain if you believe it?
2. What is the denominator: lines, diffs, changes, or accepted suggestions?
3. Is it an input metric (volume generated) or a constraint metric (what shipped and held)?
4. What internal index would confirm or falsify it, and is any of it published?
5. What is the comparison class: whose codebase, which teams, against what baseline?

Apply the filter to the 75 percent claim itself. Who: an engineer's remarks relayed through a reporter, mid-tier, and unusually counter-narrative, which raises its credibility. Denominator: unspecified, dock it. Input or constraint: pure input, dock it. Falsifier: an internal index exists but is unpublished, partial credit. Comparison class: Google's outlier codebase, not yours. The claim survives as a volume statement and fails as a value statement, which is exactly the distinction the 88 percent figure was carrying all along.

What Would Change This Picture

Calibration cuts both ways, so name the falsifiers:

• The oversight ratio falls and gets published, drifting from 88 percent toward 50, then 20, quarter over quarter.
• The General Capability Index or comparable lab telemetry shows a measured inflection in research velocity.
• Randomized trials at METR's standard of care reverse direction and show real speedups for experienced developers at scale.
• Benchmark gains start transferring to production throughput instead of stalling in the review queue.

Any of those would change the plan: more codegen seats, faster autonomy tiers, smaller review budgets. None of them describes what the current numbers show.

Until one lands, the builder's posture is straightforward. Budget engineering capacity to review throughput under the 88 percent assumption, spend first on verification infrastructure, pace autonomy to the oversight ratio, and run every frontier-lab claim through the five questions. The 75 percent figure is real and useful. It measures how cheap writing has become. The 88 percent figure measures what still is not, and until that number moves, self-improving AI stays gated by the scarcest resource in the building, human attention that can say no.