Agents write most of the code now. Nobody checks it against the product spec.

At Google Cloud Next 2026, Sundar Pichai said 75% of all new code at Google is now AI-generated and approved by engineers — up from 50% six months earlier. Meta’s DevMate submits roughly half of all code changes. Microsoft crossed 30% back in 2025 and has not slowed. Across OpenAI’s enterprise customers, Codex now accounts for 64% of output tokens, which is to say the majority of enterprise AI consumption is no longer people chatting with a model. It is agents doing work.

Every one of those numbers is quoted as a productivity statistic. None of them is. They are all statements about how much code is now entering production systems, and the only thing that makes a generation number good news is a validation number to put beside it. Almost nobody has one.

The arithmetic that nobody runs

Take the measured effects rather than the anecdotes. Faros AI’s telemetry study across more than 10,000 developers and 1,255 teams found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. That is the win, and it is real. In the same teams, average pull request size grew 154%, review time rose 91%, and bug counts went up 9%.

Read those five numbers as a system rather than a scorecard. Roughly twice the volume of change, in units two and a half times larger, taking nearly twice as long each to review — against a reviewing population that did not grow at all. LinearB’s 2026 benchmarks put a finer point on it: agentic pull requests sit waiting 5.3 times longer before anyone picks them up. That is not a queue. That is a queue that is diverging.

What happens next is predictable and is already visible in the survey data. Review becomes ceremonial. A reviewer facing eleven agent-authored pull requests before lunch, each one 154% larger than the ones they used to read, does not review them in the way the word implies. They skim the diff, check the tests are green, and approve. LeadDev’s 2026 survey found 38% of teams doing fully manual review now spend more time reviewing than before adopting AI — and they are the diligent ones. The 2026 State of Code survey found 96% of developers do not fully trust the functional accuracy of AI-generated code. They are approving it anyway, because the alternative is being the person who blocked the roadmap.

And the code being waved through is not neutral. CodeRabbit’s analysis found AI-written code surfaces 1.7 times more issues than human-written code, with logic errors appearing 1.75 times more often — and, critically, surfacing after release rather than during review. Logic errors are precisely the class that a green test suite does not catch and a skim-read does not see.

Correctness is not the gap. Conformance is.

Here is the part that gets missed, and it is the part that matters commercially. The industry is treating this as a code quality problem, so the industry is buying code quality tools — static analysis, AI reviewers, better test generation. Those help with the question “does this code work”. They do not touch the question that is actually going unanswered: does this code do what the product requires.

An agent given a ticket will produce something that compiles, passes the tests it was asked to write, and satisfies a reviewer that the logic is sound. It will do this while quietly violating the rules that were never written into any file it could read. In the last year the recurring examples we see look like this:

• Entitlement logic that is subtly wrong at the boundary. The feature works. It also works for a tier that should not have it, because the agent inferred the pricing model from the surrounding code rather than from the commercial policy nobody had encoded.
• Error states that violate the product’s own conventions. Correct handling, wrong behaviour — a modal where the design system mandates an inline message, a retry where the product rule is fail-closed.
• Data handled correctly and stored in the wrong jurisdiction, because the residency requirement lives in a compliance document and not in the schema.
• Accessibility regressions that pass automated checks. Contrast and labels are fine; focus order and keyboard traps are not, and no linter has an opinion.
• User-facing strings that are grammatically perfect and off-brand, generated at a volume no content designer was ever staffed to review.
• Audit logging omitted from a code path that regulation requires it on, because the requirement was in a slide.

Every one of those passes code review. Every one of them is a product defect, several are compliance defects, and none is a bug in the sense a test suite understands. They are conformance failures — code that is correct against itself and wrong against the product.

Why no existing role catches this

This is a structural gap, not a competence failure, and it is worth being precise about because the usual framing is both rude and wrong.

Engineers review for correctness, and they are the constrained resource — they are the ones absorbing the doubled volume. Asking them to also hold the entire product rulebook in their heads while triaging eleven pull requests is asking the bottleneck to do more work. QA validates against acceptance criteria, which are written per ticket and by construction cannot cover the standing rules that apply to everything. Product managers own the guidelines and always have. What changed is not their capability but the artefact: validating a product rule used to mean using the feature in staging, and now the unit of change is a diff that lands faster than anyone can exercise the thing it changed. The rulebook did not move out of the PM’s reach because PMs got less technical. It moved because the place where conformance is now decided is inside a pull request, and a pull request is not a surface product management was ever built to inspect.

So the work falls in the gap between three functions, all of which are doing their jobs correctly. Nobody in the organisation has the sentence “does this change conform to our product guidelines” in their objectives, and the one person who could answer it would need to be fluent in both the diff and the rulebook. That combination is rare, expensive, and almost never hired for — which is exactly why we now field it as an embedded capability through our AI talent on demand practice: senior engineers who read agent output for conformance rather than syntax, sitting with your PMs to turn the rulebook into something checkable rather than something remembered.

The honest counter-argument

The strongest objection is that hiring humans to read machine output is a losing race, and it is a good objection. Generation scales with spend; human review scales with headcount; anyone betting on the second to keep up with the first is going to lose slowly and expensively. The intellectually honest answer is that the durable fix is encoding — turning product guidelines into machine-checkable artefacts, so entitlement rules become tests, residency becomes a schema constraint, design conventions become lint rules, and the agent is graded automatically against an eval suite that represents the product rather than the ticket. That is the direction the specification-driven governance research is pointing, and it is where this ends up.

We agree with that, and it does not rescue anyone this quarter. Somebody has to write the encoding, and that somebody must be able to read a diff, interrogate a PM about what the rule actually means at the boundary, and express the result as an executable check. If your organisation had that person, the rules would already be encoded. The realistic sequence is people first and briefly — expert review to find which guidelines are actually being violated — then encoding, so the humans hand the recurring checks to the machine and move to the next class of failure. Buying permanent human review capacity is the wrong purchase. Buying the capability that converts your rulebook into automation, starting with review because that is how you discover what the rules really are, is the right one. Judge any offer here, ours included, on whether it is trying to sell you the first or the second.

What to do in the next 30 days

• Measure your review ratio. Pull requests merged per week against reviewer-hours available. If merges have doubled and reviewer-hours have not, you already know the answer and can stop debating it.
• Audit backwards, not forwards. Take twenty agent-authored changes that shipped in the last quarter and check them against the product guidelines rather than the tickets. The defect rate in that sample is your actual exposure, and it is the only number that will move an executive.
• Find out where the rulebook lives. If your product guidelines exist as slides, Notion pages, and institutional memory, no agent can follow them and no reviewer can check them consistently. Inventory them before you try to enforce them.
• Encode the three rules that would hurt most if violated. Not all of them. The three where a breach is a customer incident or a regulatory finding. Make those executable this month.
• Name an owner. Conformance needs to be in somebody’s objectives. While it is everyone’s responsibility it is nobody’s job, and the queue will keep diverging.

The 75% number is going to keep climbing, and the honest read is that it should — the productivity gain is real and no serious organisation is giving it back. But a generation figure quoted without a validation figure beside it is half a sentence. The teams that come out of this well will be the ones that treated the volume of AI-authored code as a validation requirement rather than a productivity headline, and who worked out early that the thing they needed to scale was not review capacity but the encoding of what “correct” means for their product.

Agents writing most of your code and no one able to confirm it follows your product guidelines? Talk to Cravings about embedded conformance review — senior engineers who read agent output against your rulebook, find what is already shipping wrong, and convert the recurring checks into automated gates your team keeps.