How Much Review Does AI Code Need? Balancing Risk and Speed
Your developer shows you a feature that did not exist half an hour ago. It looks finished on screen: the form saves, the list refreshes and nothing stalls. Three more changes of that size arrive the same afternoon. By the fourth, somebody has to decide how closely each change needs to be reviewed.
In AI coding, the bottleneck moves from writing to checking. This article takes up the next question: how do you spend scarce review time so that risk falls without losing the speed?
The trade-off between speed and risk
Two failure modes are common. In the first, every line, record and draft receives the same level of scrutiny. This reduces the risk of missed defects, but review becomes the new bottleneck and the time saved by AI disappears. In the second, output goes into production unchecked. That is fast until plausible-looking but incorrect code breaks a business rule or corrupts data. Both approaches assume that review is a fixed quantity.
Review depth is not a fixed quantity; it follows the size of the damage.
Why full review burns the AI savings
If AI produces a multiple of the code and drafts but you review all of it with equal care, the queue simply moves from writing to review. That judgment-heavy work needs experienced people, the scarcest resource on the team. Distrust alone is not a review process. In Google's vendor-affiliated 2025 DORA report, 30% of nearly 5,000 respondents report little or no trust in AI-generated code, and the same report still finds a negative association with delivery stability. Reviewing everything with equal rigor spends expensive attention where a mistake would have been harmless. That calculation applies to human attention, not to checks a machine takes over.
Risk sets the review effort
The decisive question is: what observation is enough to release this result? Work backwards from the result to its consequence.
- What leaves the draft and is actually used by a person or another system?
- Which visible artifact proves that the result meets the agreed task?
- What decision or data change follows once someone accepts the result?
- Who can stop the workflow before the next consequence and inspect the last change?
An observational study by Tang and colleagues of 20,574 real coding-agent sessions shows why that evidence matters. Inaccurate self-reporting, such as claiming work was complete, appeared in 22.58% of the recorded misalignment episodes. The data comes from voluntarily logged sessions used by early adopters and only measures breakdowns that drew visible developer pushback. It is not a general error rate. The narrower finding is enough for this review framework: the agent's completion message is a claim, not review evidence.
What machines check, what humans check
Put as much checking as possible into machines. Types, automated tests and pipelines verify defined properties and known rules on every change, then run again for each AI suggestion. Put a visible result beside them: a test log, preview, comparison of changed data or another artifact somebody can open. In the study, 91.49% of visibly resolved misalignments required explicit developer pushback; only 2.99% were self-corrected by the agent. The task therefore has to name the reviewable artifact. This machine layer now reaches beyond types and tests: a second agent can recompute a result completely and independently from the raw data, a thoroughness that was always possible and never affordable with people. How to Stay in Control When AI Writes Code explains how to set those hard boundaries.
A rule from our own work on the DATEV export for MAFU-SHERPA: when the system lacks context, a person reviews according to risk rather than reviewing everything equally. There the format checks run automatically, and whether a posting is correct in accounting terms stays with a person before the import. Human judgment remains focused on what a machine cannot decide, such as whether the code solves the right business problem and what a mistake would mean for operations. Since July 2024, the Generative AI Profile of the NIST AI Risk Management Framework has made the same distinction: different uses warrant different levels of human oversight and testing.
A tiered review framework
- Low risk: automated checks plus a spot check.
- Medium risk: automated checks plus targeted review of the critical paths and a named sign-off.
- High risk: full review with acceptance criteria defined up front, a dry run and explicit sign-off.
Use the same agent message for all three tiers: “The export is complete.” In the automated DATEV export for MAFU-SHERPA, that is the moment when the finished file is ready and the transformed data can be inspected before import. At low risk, open the generated file and spot-check it. At medium risk, also compare it with a known sample dataset and have a named person inspect the differences. At high risk, such as before an accounting import, require a full dry run, totals defined in advance and explicit sign-off. The message stays the same; the evidence required changes.
For this approach to work, tasks must be small and clearly scoped because small units are faster to review than large, vague ones. The expected result also belongs in writing before work begins; Acceptance Criteria for AI Tasks provides that structure.
Five questions for your developer or provider
You do not have to read code to tell whether review time is planned or merely promised. These questions make the effort and the evidence visible.
- How do you divide the available review time across low, medium and high risks, and who assigns the tier?
- Which artifact must exist at the end so that “done” can be verified?
- Which known errors does automation catch, and which decision explicitly stays with a person?
- Show me a change where review depth was raised or lowered because of the risk.
- Which recently discovered error changed the checklist, test or release criterion?
We answer the last question about ourselves like this. On 1 September 2026 a second agent found a fault in our own code that our own measurement had missed, because the measurement had switched off exactly the animation the change had broken. Since then, every new test here has to have been red once before it counts. Why the reviewer must not be the author is covered in the four-eyes principle for AI agents.
What this means for cost
Review is insurance. Its cost makes sense when weighed against a wrong invoice or unchecked code that must be maintained for years. Risk-based review directs expensive human judgment to the places where a mistake would hurt. How Much Does Custom Software Cost? shows how those costs add up over time.
The cost effect does not come from making review disappear. It comes from running automated evidence repeatedly and reserving human attention in advance for the few decisions a machine cannot make. Review time therefore belongs in the task estimate, not in a remainder after development.
Do you really have to review every line of AI code?
No. Define the evidence that belongs to each risk tier before the task starts. Low risk needs automated checks and a spot check. Medium risk requires a targeted comparison and named sign-off. High risk needs a full dry run with criteria set in advance. Not every line gets equal treatment, but every release remains traceable.
How can I tell whether my provider checks enough?
Ask for the result of the last review, not a quality promise. Have them show you a test log, data comparison or preview and the decision that followed. Also ask which discovered error most recently changed a test or release criterion. A concrete answer shows that the process learns.
Does the checking eat the time AI saved?
Only if everything is checked with equal care. Automated checks are written once and then run for every further suggestion, while human judgment stays reserved for the risky cases. That keeps the pace where the risk is low.
Can the checking not be left to AI?
Automated checks can verify defined properties and known rules. An agent's completion message is still not evidence: in an observational study of real coding-agent sessions, only 2.99% of visibly resolved misalignments were self-corrected by the agent. Whether a change fits the business therefore requires criteria set in advance and a named person who inspects the result.
Start every AI task with a sentence that can be checked later: “The work is complete when this artifact meets this condition.” Only then can you decide how much automated and human review it needs.
If you want to set these tiers for a real workflow, let us discuss a concrete workflow.