In short: When agents write most of the code, line by line review stops scaling. The answer is the Verification System: requirements explicit enough to test, checks built into every stage, risk tiers, a release decision kept apart from generation, and people who supervise by exception. Its limit is verification capacity, the volume of change an organisation can prove without lowering the bar.

What happens when nobody reads the code?

New Relic's 2026 State of AI Coding report asked technology leaders how AI generated code performs. Most rated it higher quality than human code at review. Once it shipped, 78% reported more incidents, and 82% had seen at least one production failure tied to AI generated code in the previous six months.

The same report found that 62% of leaders say their teams often trust AI code enough to ship it without line by line verification. Faros AI's telemetry, which measures repositories rather than opinions, shows the habit in practice: under high AI adoption, 31% more pull requests merged with no review at all. Both companies sell into this problem, so the figures are best read as directional.

Together they point to an uncomfortable pattern. Organisations are already absorbing the extra supply, and the main absorber is a lower bar. Review rated the code well and production disagreed, which suggests review has stopped measuring what it used to measure.

Why can't review keep up?

Code review is a person reading a change. Its capacity is set by the number of qualified people and the hours they have, and agents add to supply without adding to either. When supply outgrows it, work queues in front of the reviewers, or the bar quietly drops so the queue can clear. The data above shows both.

That review has become a bottleneck is no longer news. Constraint Migration places verification first among the stops the constraint reaches. The more useful question is what to build in its place, and how to tell whether it is enough.

This piece calls that limit verification capacity: the volume of change an organisation can prove, at each level of risk, in a given period, without lowering the bar. Supply on one side and verification capacity on the other is the Absorption Gap at its first stop. Hiring reviewers raises verification capacity in a straight line, while the architecture below raises it by changing what people have to prove at all.

Figure 1. Verification capacity against supply. Hiring reviewers moves the line slowly; redesigning what needs a human moves it faster. Illustrative.

Figure 1. Verification capacity against supply. Hiring reviewers moves the line slowly; redesigning what needs a human moves it faster. Illustrative.

Why don't generated tests solve it?

The obvious move is to let agents write the tests as well. Coverage improves, and a quieter problem appears. When the same kind of model writes the code, the tests and the review, the pipeline turns green because the code agrees with itself, and nothing in that loop checks the change against what the business meant.

Practitioners have started calling this a self-confirming loop. The way out is independence. The evidence that a change is right has to come from somewhere the generator did not write, and the most reliable source is the intent the change was built to serve.

Where does verification start?

Verification starts before any code exists. Requirements-based engineering and test-driven development are decades old, widely cited and rarely mastered. Where teams practise them, it is usually at the level of code, with a unit test written before a function, while the documents that carry most of the intent, the product requirements document and the solution design, remain prose that nothing can execute.

Agents make that gap expensive. An agent acts on whatever the requirement says, so an ambiguity in a requirements document becomes a wrong implementation at agent speed, which a reviewer then has to catch by reading. Shifting verification left means making each upstream document carry requirements explicit enough to be tested.

In a product requirements document, that means acceptance criteria written as concrete examples, plus the business outcome the change should move, declared before build. In a solution design, it means stating constraints as testable statements: response time and availability budgets, data rules, contracts with other systems, and how the change should fail and be rolled back. Each statement becomes a check that runs later, so the design is verified as well as approved.

This discipline is what makes the rest of the architecture work. Without explicit requirements, every downstream check can only confirm that the code is consistent with itself.

What does the Verification System look like?

The Verification System is the architecture an organisation uses to prove agent output before and after it ships. In the AI Engineering Production System it has two homes. Checks sit in the Context & Control layer, so every stage proves its own output where it is produced. The release decision stays a stage, Verify & Release, because that is where work waits and someone signs.

Figure 2. The Verification System. Checks where work is produced, release authority by risk tier, people on the exceptions, escapes fed back to intent.

Figure 2. The Verification System. Checks where work is produced, release authority by risk tier, people on the exceptions, escapes fed back to intent.

Six building blocks make it up.

Testable intent. Every requirement arrives with the tests that will prove it and the outcome it should move, from the requirements document and the solution design down to the code. At La Redoute this was framed as requirements-based engineering: each change was validated against its requirements through a test plan, carried from definition to execution in Cerberus Testing, the open-source platform that started there.

Checks at every stage. Generated unit tests, contract tests between services, policy as code, security and licence scans, and evaluations of agent behaviour wherever the same input can produce different output. Each stage runs the checks that prove its own work, so defects are caught where they are cheapest to fix.

Risk tiers. Each change is classed by how far its effects reach and how easily it can be reversed. The tier decides which checks run and who may release the change; the next section sets out how.

Release authority kept apart from generation. Whoever produced a change, agent or team, does not decide that it ships. Lower tiers release automatically once the evidence is complete, and higher tiers need a named person to sign, on the evidence rather than the diff.

Supervision by exception. People look at what the checks flag and at the highest tiers, through a view that shows the evidence: intent, tests, results and risk. Reading every diff is the habit to retire, because it is the part that cannot scale.

Escape telemetry. Defects that reach production, and the hours people spend supervising, are measured and fed back. Escapes sharpen the next requirement and adjust the tiers. Turning that data into decisions is the subject of A Technology Leader's Playbook for AI-Powered Test Intelligence.

How should the risk tiers work?

Risk tiers decide where people spend their attention, so they carry more of the design than any other block. Four tiers are usually enough to start, each defined by how far a change reaches and how easily it can be undone. The examples below are a starting point to adapt, since what counts as high risk depends on the business.

Six guidelines tend to decide whether tiers work in practice.

Declare the tier at intent. The tier is set in the requirements document or the solution design, before build, and an agent cannot lower it. Automated rules can raise it: a change that touches the payment path moves up whatever its description says.

Classify by reach and reversibility. The size of a change and who wrote it are poor proxies. A one-line change to a rounding rule can belong in the top tier, and a large generated refactor behind a flag in the second.

Make the lower tiers genuinely automatic. If people still read every contained change just in case, verification capacity does not move and the tiers become paperwork.

Keep sampling. A small random share of automatically released changes gets a human look after release. Sampling is how drift in the checks is found before an incident finds it.

Recalibrate from escapes. A tier whose changes escape into incidents moves up or gains checks. A tier with no escapes over a quarter can be reviewed for checks that cost more than they catch.

Give the policy an owner. The tier definitions belong to the owner of the Verification System, are agreed with the business, and are reviewed on the same cadence as Direction.

In what order should you build it?

The order that tends to hold starts upstream. Testable intent comes first, because a change that was never specified can be inspected but not verified. Risk tiers come next, since they decide where human attention goes. Then come the checks for each tier, then release authority, and last the telemetry that tunes all of it.

An organisation with strong test automation already in place may reasonably start at the tiers and work back towards intent. What tends to fail is buying review automation first and discovering that there is nothing independent to check the code against.

What happens to the QA team?

It becomes the team that owns the Verification System. Its work moves from running tests to designing checks, setting tier policy, building evaluations of agent behaviour and supervising at release. QA teams are becoming AI supervision teams, and the ones that see it early get to design the role.

Little of this is new. At La Redoute, the ecommerce test base in Cerberus grew to more than 7,500 automated tests, which allowed daily production releases of the website and the mobile apps across international markets. It worked as a verification system of this kind: tests derived from requirements, lean integration, and environments and test data kept aligned with production. Extending the same approach to the rest of the platform's applications took the platform as a whole from 40 to 80 deployments a day.

The discipline was called Quality at Speed. Agents raise the volume it has to absorb, and the discipline still holds.

What happens once verification is no longer the constraint?

Design one stop ahead. A Verification System that works lets more change through, and that change lands next on integration and environments: the main branch, the pipeline and the test environments it depends on. Sizing those for agent volume is the subject of the next piece in this series.

How do you know it is working?

Track verification capacity against supply, by tier, every month. If supply grows faster, the Absorption Gap is reopening, whatever the pass rates say. Track the escape rate per tier as well, which shows whether the bar held.

Supervision hours belong in the picture too. They are human intervention, so they sit in the denominator of validated business value per unit of human intervention. The Verification System earns its place when validated change rises and human hours per change fall in the same quarter.

What should a CTO decide?

Give the Verification System a named owner and run it as a product with a roadmap. Fund it as capacity, sized to the supply that the agent programme will create.

Write the separation of release authority from generation into policy before agent volume makes it urgent. Set the risk tiers together with the business, since what counts as high risk is a business judgment before it is a technical one.

The question for next quarter

Every AI programme will raise supply this year. The programmes that raise verification capacity with it will be able to say what they shipped, and why it was safe to ship.

If your agents doubled their output next quarter, how much of it could you prove, and who would decide what ships without proof?

Read further

FAQ

What is a verification system for AI generated code?

It is the architecture an organisation uses to prove agent output before and after release. It combines requirements explicit enough to test, automated checks at every stage, risk tiers, a release decision kept apart from whoever generated the change, people who supervise by exception, and telemetry on the defects that escape. It replaces line by line review as the main way of deciding what is safe to ship.

How should code review change when AI writes most of the code?

Review should move from reading every diff to examining evidence for the changes that need human judgment. Automated checks handle most changes in the lower risk tiers, and people sign the higher tier changes on the strength of tests, results and declared intent. Reading every diff fails at agent volume, and the data suggests many teams have already stopped doing it without saying so.

What does shift left mean for requirements when agents write code?

It means making the product requirements document and the solution design carry requirements explicit enough to be tested, as well as the code. Acceptance criteria become concrete examples, the intended business outcome is declared before build, and design constraints such as response time budgets, data rules and rollback behaviour become testable statements. Tests derived from those requirements are the independent evidence that generated tests cannot provide.

Should AI review AI generated code?

It can be one useful check, for triage and for catching known patterns at volume. It should not be the only evidence, because a model reviewing output from the same kind of model tends to share its blind spots. Independent evidence, above all tests derived from the requirement and behaviour observed in production, needs to sit alongside it.

What is verification capacity and how do you measure it?

Verification capacity is the volume of change an organisation can prove, at each level of risk, in a given period, without lowering the bar. Measure it per risk tier as changes fully evidenced and released per month, and set it against supply, the changes produced. Watch the escape rate per tier at the same time, since a rise in capacity that comes with more escapes means the bar has dropped.

How do risk tiers work for AI generated changes?

Each change is classed by how far its effects reach and how easily it can be reversed, often in four tiers: contained, customer facing and reversible, hard to reverse, and regulated or irreversible. The tier is declared at intent, can be raised by automated rules but not lowered by an agent, and sets which checks must pass and who may approve the release. Tiers are recalibrated from escape data and agreed with the business.

Sources