Markus Eisele argues that accepting agent-generated code should require inspectable evidence that links the agreed behavior to the implementation and its tests. Review effort should be allocated according to a change’s "blast radius" — how widely a mistake can affect the system — rather than merely the number of changed lines. Decisions and open questions must be recorded so reviewers can determine when direct code inspection is necessary.
The problem
Agents can generate working implementations and tests quickly, but a human must still approve pull requests. If human inspection scaled with every generated line, review capacity would bottleneck acceptance. The key question is how to decide where that inspection is worth the time.
Blast radius — the scope of impact
Eisele uses a refund service example: introduce an approval step so refunds above €100 require authorization, while exactly €100 does not. An agent implements the approval and adds tests, but also adds a retry after a timeout in the payment integration. That retry may cause duplicate refunds if the payment provider actually completed the refund before the response was lost. If the retry lands in a shared payment client, it can affect every refund request, including those below the approval threshold.
Counting changed lines won’t reveal that broader impact. Instead, establish which operations a change is allowed to affect and check whether the implementation stays within that boundary. Also consider how hard it would be to undo a mistake: redeploying previous code may not recover money already refunded twice.
Bidirectional traceability
Review should expose drift in both directions: verify that requested behavior exists in the code and examine additional behavior that could affect the system. For each important requirement, you should be able to find the implementation and the checks that support it; looking from the implementation back, you should be able to explain why a behavioral change belongs in this pull request.
This idea maps to established guidance — for example, NASA’s software engineering guidance describes tracing requirements through implementation and verification, including finding functionality that has no parent requirement. An agent can help by taking the agreed specification and the repository changes and flagging missing or unexplained behavior. Start from the changed files and follow calls into their callers, since a shared client change can alter the behavior of code that was not edited in the diff.
Tests can share the same mistake
Links between requirements, implementation and tests do not by themselves prove correctness. An agent might misinterpret a boundary: if "above €100" is read as "€100 and above," both implementation and tests will agree on the wrong behavior and CI will pass. Running tests in CI reproduces the agreement but won’t reveal that the expected result is incorrect. Reviewers still must check assertions against the agreed behavior, especially for boundary cases.
For critical rules, agree on boundary examples before implementation (e.g., €100 proceeds without approval; €100.01 requires it). Tests should observe what the service sends to the payment provider: checking only that an approval request was created is insufficient if the service can also send the payment immediately. For important assertions, you can go further: temporarily remove the approval check in a controlled test and confirm the relevant test fails — if it doesn’t, that test gives little protection.
Use a different agent to propose missed cases and to examine whether assertions match the requirement, but keep the concrete checks readable for human reviewers. A different model can make the same mistake; research supports that caution. A 2026 study of LLM requirement-conformance judgments found models rejecting correct implementations and accepting faulty ones, which implies we should not rely solely on a model’s confident explanation.
Make evidence easy to inspect
Require a short review record with each pull request that connects the intended behavior to the checks and surfaces open decisions. For the refund example, such a record could include:
- Agreed behavior: refunds above €100 wait for authorized approval; exactly €100 does not.
- Evidence: boundary tests check when the payment request is sent, with links to assertions and CI results for this revision.
- Additional behavior: payment client now retries after a timeout.
- Blast radius: if the retry applies to a shared client, all refund requests may be affected; review its callers.
- Open question: tests don’t cover a provider completing the refund before the timeout; safe retry behavior still needs to be established.
Start the review with this record. Check that approval assertions express the agreed rule and that test results support it. Then inspect the retry path where evidence and intended scope are incomplete. Require a test covering the uncertain provider response or remove the retry from this change. Link each claim to the specific checks supporting it; "tests passed" is too broad to help. Make sure the reviewer can see which tests ran against the revision being approved and refresh the evidence if the agent changes implementation after the test run.
Review changes to the checks
Compare tests and checks to the agreed baseline. If an earlier acceptance test expected a €100 refund to proceed but the agent updated it to expect approval, the new implementation and test will agree while the requirement has changed; comparing both to the agreed requirement exposes that change in meaning. Updating a test to match new behavior can be legitimate, but reviewers must decide whether the behavior change was intended and record that decision.
Set review depth by blast radius
Match review depth to potential impact and to the strength of evidence. Reports and agents can only expose the gaps they detect; tests can pass even when code relies on a wrong assumption. Require direct inspection of the payment path when errors can move money twice. Follow affected calls even if some are outside the diff.
For routine changes with limited effects and established checks, reviewers can spend less time reconstructing implementation if the affected behavior is understood and tests address likely failures. Where blast radius is unclear, investigate it before approving changes. Occasionally audit changes treated as routine; if those audits reveal missing assumptions, improve the checks before further reducing inspection. This lets teams test their review policy against the code they actually accept.
Make evidence part of the development cycle
Recommended process:
- Before generation, the developer and requirement owner agree on behavior and expected blast radius.
- The agent implements within that scope and prepares a short review record.
- CI runs checks against the proposed revision.
- The reviewer examines evidence and investigates deviations; perform direct inspection when consequences justify it.
- Release through controlled rollout and use production feedback to improve checks and specification.
Make the review record part of the definition of done. The submitting developer owns its accuracy even if an agent wrote the code; the reviewer owns the acceptance decision. Important claims lacking adequate evidence remain open. If implementation affects more operations than agreed, resolve scope changes before proceeding.
In the refund example, the approval feature can be merged once checks support the agreed behavior and the reviewer has examined the relevant payment path. The added retry needs its own justification: either remove it or review it explicitly and provide evidence that repeated requests will not issue duplicate refunds.
Keep blast radius contained
Keep the approval feature separate from a redesign of the shared payment client unless both must change together. Separate pull requests help reviewers assess each decision, but containment also depends on implementation: a one-line change in a shared client can affect every caller.
Use the same discipline with releases: when the system supports it, expose a change to a limited group (A/B) and observe behavior before widening the rollout. For refunds, that still requires adequate checks before any real payment. Start with a single service and make this the normal way changes reach review: require evidence, record expected blast radius, and keep unexplained behavior open until resolved. Reduce routine line-by-line inspection as checks earn trust, but keep direct inspection where mistakes have serious consequences. This is a concrete way to accept more agent-generated code while keeping each change’s effects understandable and contained.
Author: Markus Eisele
(Note: the original piece references a 2026 study on LLM requirement-conformance judgments.)
