Sign in Subscribe
By Marvin in AI code generation —

The Economics of Code Just Inverted: Generation Is Nearly Free, Assurance Is the Bottleneck

AI generates up to half of new code, but security pass rates remain flat at 50%. Why assurance is now the scarce resource, with four patterns to close the gap.

For most of software history, writing code was the expensive part and checking it was comparatively cheap. In 2026, that equation has flipped. AI now writes somewhere between a quarter and three quarters of new code at major companies, at a marginal cost heading toward zero, while the machinery for verifying that code (human review, security analysis, testing discipline) has barely scaled at all. The result is a widening gap between how fast organizations can produce code and how fast they can trust it. That gap, not model capability, is becoming the defining engineering-management problem of the AI era. Teams are drowning in plausible code they can't fully vouch for, and the scarce resource is no longer output. It's assurance.

The generation numbers are real, even after you discount the hype

Start with scale, because scale is what makes everything else matter.

Google reported in April 2026 that roughly 75% of its new code is AI-generated (and engineer-approved). Satya Nadella put Microsoft's figure at 20 to 30% of repository code a year earlier. The largest empirical study to date, covering 4.2 million developers between November 2025 and February 2026, measured AI-authored production code at about 27%. Survey-based industry estimates run to 42% of committed code today, with projections of roughly 65% by 2027.

These numbers deserve one honest caveat: many headline figures blur "AI-assisted" (a human accepted an autocomplete) with "AI-generated" (an agent wrote the diff). The defensible range is somewhere between 27% and 50%, depending on definition. But even the conservative end of that range represents a historic shift in who, or what, authors production software. And every one of those lines still has to be reviewed, secured, and maintained by processes designed for an era when a developer shipped a few hundred lines a week.

Fluency soared. Judgment didn't.

The core mechanism behind the trust gap shows up in one of the most striking findings of the past three years of AI-code research: security quality has not improved with model capability.

Veracode's GenAI Code Security research, which ran 80 curated coding tasks across more than 100 LLMs, found that when a secure and an insecure implementation both exist, models pick the insecure one about 45% of the time. More telling is the trend line. Since 2023, syntax pass rates have climbed from roughly 50% to 95%: the code compiles, runs, and looks right almost every time. Security pass rates stayed stuck at 45 to 55% across every model generation. Veracode's Spring 2026 update confirms the plateau persists, despite vendor claims to the contrary.

The breakdown by category makes the pattern legible. Java fares worst, with only 28.5% of generated solutions secure. Context-dependent flaws like cross-site scripting are handled securely just 12 to 13% of the time, because avoiding them requires understanding where data comes from and where it flows, not just what idiomatic code looks like.

This is the empirical anchor for the whole thesis: scaling made models fluent, not judicious. A model that produces working code 95% of the time and secure code 50% of the time is a machine for manufacturing confident-looking liabilities, unless something downstream catches them.

Structural debt is compounding too

Security is only one symptom. GitClear's longitudinal analysis of 211 million changed lines of code (2020 through 2024, updated through 2026) documents what AI authorship does to codebase structure:

  • Duplicated code blocks rose 8x in 2024 alone.
  • Code churn (lines rewritten or reverted shortly after being committed) climbed from 3.3% in 2021 to 5.7% in 2024, and roughly 7.1% in 2025.
  • Refactored or moved code collapsed from about 25% of changed lines to under 10%. 2024 was the first year on record in which copy-pasted code exceeded moved code.

The pattern makes sense once you consider how generation works. An AI assistant produces new, plausible code on demand; it has little incentive and often little context to find and reuse the existing helper function three modules away. Every generated duplicate is a small contribution to technical debt, and cloned code carries 15 to 50% more defects than consolidated code. It's a flywheel: more generation, more duplication, more surface area to assure.

The 2025 DORA report supplies the delivery-level confirmation. With 90% of respondents now using AI, adoption correlates positively with throughput but still negatively with delivery stability. DORA's framing is the right one: AI is an amplifier, not a fix. Acceleration exposes whatever weaknesses already exist downstream, and the value you get depends on the surrounding control systems (automated testing, fast feedback, loosely coupled architecture), not on the generation tools themselves.

The pipeline math: a queue with no exit

Where does the asymmetry actually bite? In review. The software delivery lifecycle is a pipeline, and one stage of that pipeline just got a 5 to 10x speedup while the stage after it did not.

Codacy and others have measured the congestion directly. Developers using AI assistants now ship five to six pull requests a day. Organizations see roughly 98% more PRs that are about 154% larger, and average review time rises about 91% after AI-assistant adoption. Meanwhile, AI-written code surfaces about 1.7x more issues than human-written code, so each of those larger, more frequent PRs needs more scrutiny, not less. Human review throughput, the service rate of the queue, is unchanged.

Anyone who has taken a systems course knows what happens when arrival rate exceeds service rate: the backlog doesn't grow linearly, it grows without bound. The arithmetic fits in a few lines:

review_capacity = 20        # PRs a team can properly review per day
pr_rate = 18                # PRs arriving per day, pre-AI
backlog = 0

for week in range(1, 5):
    pr_rate *= 1.25         # generation keeps getting cheaper
    backlog += (pr_rate - review_capacity) * 5   # workdays per week
    print(f"Week {week}: {pr_rate:.0f} PRs/day, backlog {max(backlog, 0):.0f}")

# Week 1: 22 PRs/day, backlog 12
# Week 2: 28 PRs/day, backlog 53
# Week 3: 35 PRs/day, backlog 129
# Week 4: 44 PRs/day, backlog 249

There is no steady state. Teams resolve the pressure the only way an overloaded queue can be resolved without adding capacity: by lowering the quality of service. Reviews get faster, shallower, and more ceremonial. Which brings us to the most uncomfortable number in this story.

The trust paradox: everyone doubts, half verify

Sonar's 2026 State of Code survey puts the human-factors problem in two figures: 96% of developers say they don't fully trust the functional accuracy of AI-generated code, yet only 48% verify it before committing.

Read that again. Distrust is nearly universal; verification is a coin flip. This isn't hypocrisy so much as the predictable behavior of people inside an overloaded system. When the backlog is growing, the organization measures shipped features, and the code looks right (remember, syntax pass rates are at 95%), skipping verification is the locally rational move. Mid-2025 industry reports describing "10x more security findings for 4x faster generation" are what that rational shortcut looks like at aggregate scale.

The developer's job is quietly shifting from producing code to underwriting it. But almost every incentive structure in the industry still measures and rewards production.

What assurance-first engineering looks like

The response is already taking shape: an assurance industry is forming around the generation boom, the way the testing and CI industries formed around earlier booms. Four patterns are emerging in organizations that are ahead of the queue.

1. Two-pass review: AI reviews AI, humans review the residue. An AI review layer runs in CI before a human is ever requested, catching the mechanical findings (duplication, known-vulnerable patterns, missing tests) so the human reviews a cleaned diff and spends attention on design and intent. Teams adopting this pattern report roughly 30% faster release cycles, because the human queue receives less noise. A minimal gate looks like this:

# .github/workflows/two-pass-review.yml
name: AI pre-review gate
on: [pull_request]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    env:
      GH_TOKEN: ${{ github.token }}
    steps:
      - uses: actions/checkout@v4
      - name: AI review pass    # ai-reviewer stands in for your tool of choice
        run: ai-reviewer scan --diff origin/main --fail-on high
      - name: Request human review once the gate passes
        run: gh pr edit ${{ github.event.number }} --add-reviewer team-leads

2. Provenance receipts. A lightweight, machine-readable record attached to every AI-authored change: who asked for what, which agent and model produced it, what it touched, and what evidence backs it. It turns "where did this code come from?" from an archaeology project into a lookup:

# .provenance/PR-4821.yml
task: "Add rate limiting to public API endpoints"
agent: code-agent/v3
model: claude-sonnet-4-6
files_touched: [api/middleware/ratelimit.py, api/config.py]
tests_added: [tests/test_ratelimit.py]
risk_tier: high          # touches auth-adjacent request path
ai_review: passed (2 findings auto-fixed)
human_reviewer: m.chen
verified: 2026-07-16

This is not just hygiene. NIST's SSDF guidance for AI-generated code and the EU AI Act's traceability requirements are pushing provenance from best practice toward compliance obligation.

3. AI-defect metrics with security-incident rigor. Leading teams now track AI-attributed regression rates and review-confidence scores the way they track incident counts: as first-class engineering metrics, with owners and trend reviews. You cannot manage an assurance bottleneck you don't measure.

4. Independent verification layers. Early academic work is formalizing pre-deployment "trust certification" for coding agents, and the direction of travel is clear: assurance becomes a distinct layer of the stack, with its own tooling, budget, and headcount, rather than a tax on developer time.

Who assures the assurers?

There is a recursive catch, and it deserves to be named rather than waved away. If AI reviews AI code, the findings themselves are AI-generated artifacts that need verification. SRLabs and Futurum both flag the same second-order requirement: the review layer must be independent of the generation layer (in models, prompts, and incentives) or it inherits the very blind spots it exists to catch. Automating review doesn't eliminate the bottleneck; it moves it up a level, to the question of whether your verification infrastructure is itself trustworthy.

That is the deepest version of the thesis. Tokens scale. Compute scales. Generation scales. Trust does not scale the same way, because trust is earned through independent verification, and verification always costs something that generation doesn't: judgment.

Budget for confidence, not output

The marginal cost of writing code is heading toward zero, and it isn't taking the cost of trusting code with it. The evidence converges from every direction: security quality flat across model generations, structural duplication at record highs, delivery stability declining even as throughput rises, and a review pipeline whose arrival rate now persistently exceeds its service rate. Organizations that keep treating generation speed as the metric will accumulate an inventory of unverified code that behaves, on the balance sheet, exactly like unaudited debt.

The winners of the next few years won't be the teams that generate the most code. They'll be the ones that industrialize assurance: two-pass review, provenance by default, defect attribution, and verification layers independent enough to be believed. Code became nearly free. Confidence didn't. Budget accordingly.

Sources and further reading

Subscribe to Marvin G6 | Engineering, AI & Automation

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe