Verification Is the Bottleneck Now

Writing code is no longer the constrained resource. Reading it is.

That inversion happened quickly and most teams have not re-planned around it. The tooling budget went to generation, the process stayed the same, and the queue moved to the one place nobody added capacity.

There are numbers attached to this. Some of them are worth quoting and some are not, and telling them apart turns out to be the useful exercise.

Who This Is For

• Tech leads whose review queue got longer the month the team adopted an agent
• Engineers being asked to approve more diffs than they can genuinely read
• Founders deciding whether the productivity claims justify the tooling spend
• Anyone who has seen a number about AI code quality in a deck and wondered where it came from

What You Will Need

A CI pipeline you are allowed to change, and the willingness to let it block a merge. Everything here fails without that second part.

The Pattern

Nothing about the shape of software delivery changed except throughput at one stage. That is enough to move the constraint.

flowchart LR
  W[Write] --> R[Review]
  R --> M[Merge]
  M --> P[Production]
  W -.->|3-5x faster| R
  R -.->|unchanged| M

A stage that got five times faster feeding a stage that did not is not a productivity gain. It is a queue.

What the Numbers Actually Measure

Four figures circulate in every article on this subject, usually in the same paragraph and the same tone. They are not the same kind of claim, and the differences matter more than the values.

Google’s CEO says 75% of the company’s new code is AI-generated, up from 50% in late 2025 and around 25% in 2024. This is a self-report from the company with the largest commercial stake in the answer. There is no published definition of new code, so nobody outside Google knows whether a generated import counts the same as a generated function. There is no denominator and no external audit. You can quote it as a statement Google’s CEO made. You cannot quote it as a measurement.

GitClear and GitKraken analysed 623 million real code changes from 2023 to 2026. Duplicated blocks rose from 40.3 to 73.0 per million changed lines, an 81% increase and the highest on record. Refactoring commits fell 70%. Legacy refactoring fell 74%. Functional connectivity, meaning how often new code calls existing code, fell 35%.

Two honest caveats, both of which the trend pieces drop. GitClear sells code-analysis tooling, so it benefits from this conclusion. And the corpus is not split by authorship, so this is what happened to codebases during the AI era, not what AI did to codebases. It is still the strongest evidence in the set, because the method is published and the subject is real repositories rather than opinions.

Stack Overflow’s 2026 survey puts adoption at 84% while 46% actively distrust the accuracy of the output against 33% who trust it, and 3% who trust it highly. Usage and trust are moving in opposite directions.

Veracode tested more than 100 models across four snapshots: an average security pass rate of 56%, flat year on year. Given no security-specific guidance, models introduce a known vulnerability pattern roughly 44% of the time. Cryptographic checks pass 87% of the time and SQL injection defences 83%, but cross-site scripting passes just 15%.

So: one figure that cannot be checked, one that can be checked but not attributed, one that reports feelings accurately, and one that measures a specific property under a stated method. Use them accordingly.

The Almost-Right Problem

The most useful number in the set is also the least quoted. Asked for their single greatest frustration, 66% of developers named “AI solutions that are almost right, but not quite”.

That is a precise description of a failure mode, not a complaint. Wrong code is cheap: it fails a test, it throws, somebody notices. Nearly-right code passes the skim. It compiles, the happy path works, the variable names are plausible, and the defect is one unhandled case down a branch nobody read for.

Veracode’s split says the same thing from the other direction. A syntax pass rate near 100% against a security pass rate of 56% means the code almost always looks finished and is a coin flip on whether it is safe. Think about the heuristics reviewers actually use. Does it build, does it read cleanly, does it look like our code. Those are precisely the signals generated code satisfies most reliably.

flowchart TD
  D[Generated diff] --> C{Compiles?}
  C -->|Almost always| S{Reads plausibly?}
  S -->|Usually| E{Edge cases handled?}
  E -->|Coin flip| X[Merged anyway]
  E -->|Checked| G[Genuinely reviewed]

Making Review Cheaper

You cannot read twice as much code. You can make sure a human never reads anything a machine could have judged.

The rule: every mechanically checkable property moves into CI, and CI blocks the merge. Human attention is reserved for the two questions no tool answers. Is this the right thing to build, and will the next person understand it.

# .github/workflows/verify.yml : the gate, not a suggestion
name: verify
on: [pull_request]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1. Does it do what the tests say?
      - run: pytest -q --cov=src --cov-fail-under=80

      # 2. Known-bad patterns, the 44% Veracode measures
      - run: semgrep --config=p/security-audit --error

      # 3. Duplication, the GitClear signal, as a budget rather than a report
      - run: |
          jscpd src/ --threshold 3 --reporters console \
            --min-lines 8 --format python,typescript

      # 4. Size cap. A diff nobody can read does not get reviewed, it gets approved.
      - run: |
          CHANGED=$(git diff --numstat origin/main...HEAD \
            | awk '{ added += $1 } END { print added }')
          echo "added lines: $CHANGED"
          [ "$CHANGED" -le 400 ] || {
            echo "::error::Split this. 400-line cap on a reviewable diff."
            exit 1
          }

That last step is the one people argue with and the one that changes behaviour. A 900-line generated diff is not reviewed, it is approved. Capping the unit of review is the cheapest intervention available, and it costs nothing but the discomfort of splitting work.

The duplication check deserves the same framing. Treating duplication as a budget that fails the build, rather than a metric on a dashboard nobody opens, is the difference between knowing about the GitClear trend and doing something about it. The same argument applies to test coverage. A number that only informs is a number that gets ignored, which is a pattern worth recognising from dashboards that nobody acts on.

Before and After

Failure Modes to Avoid

• Adding tooling that reports instead of blocking. A warning in a log is a warning nobody read. If it does not fail the build, it does not exist.
• Quoting the 75% as a measurement. It is a sentence a CEO said. There is a version of this argument that survives scrutiny; that is not it.
• Blaming the model for the duplication. GitClear’s corpus is not split by authorship. Codebases got more duplicated during the AI era. Anything stronger than that is overclaiming, and overclaiming is how you lose the argument with the one engineer who checks.
• Treating trust as a proxy for quality. Stack Overflow measured what developers feel. Feelings can be correct and are not evidence.
• Reviewing generated code the way you review a colleague’s. A colleague’s diff carries an implicit claim that a person thought about it. A generated diff does not, and the surrounding cues are identical.
• Raising coverage and calling it verification. Coverage says a line ran, not that anything asserted its behaviour. If your suite is the thing you are trusting here, it is worth reading how to test a pipeline properly before you trust it further.

What to Build First

1. Put a size cap on pull requests. One line of CI, immediate effect, no tooling to buy.
2. Promote your existing linters from advisory to blocking. You almost certainly already run them and ignore them.
3. Add a security ruleset to the gate, on the strength of the 56% pass rate rather than any incident you have had yet.
4. Set a duplication threshold slightly under today’s number and hold it. You are defending a trend line, not chasing zero.
5. Measure review time per merged line, not per pull request. That is the number that tells you whether the queue is real.
6. Then reconsider the tooling budget with the constraint in the right place.

Final Take

There is a version of this argument that says AI code is bad. It is not supported by the evidence and it is not the interesting claim.

The supported claim is narrower and more actionable: generation improved by several multiples, verification did not improve at all, and almost every team invested exclusively in the half that was already fast. The queue moved. The remedy is unglamorous: gates that block, diffs small enough to read, and a clear head about which numbers you can check and which ones you can only repeat.