Topics / Engineering practice
Who checks the code when an agent wrote it?
Assign responsibility for intent, implementation, verification and acceptance. “Another AI reviewed it” does not answer all four questions.
Separate the responsibilities.
| Responsibility | Question to answer |
|---|---|
| Product authority | Who decides what behavior is intended? |
| Implementation | Who proposes and explains the change? |
| Verification | Who or what produces inspectable evidence? |
| Acceptance | Which person or policy may accept this revision? |
One person can perform several roles where policy permits. What matters is that the implementation cannot silently rewrite its own success criteria. Higher-consequence work may need independent review defined by the applicable assurance plan.
Challenge the claim with a different kind of evidence.
Illustrative example
The reviewer agrees with the wrong assumption.
An agent implements “ignore duplicate callbacks,” and a reviewer praises the code. Both assume the callback has a stable identifier. A recorded API contract says the identifier can change after a retry. A test using that condition reveals the gap their agreement missed.
Ask reviewers to look for counterexamples and weakened protection. Then distinguish their reasoning from observed executions and formal results. Preserve disagreements that could change the acceptance decision.
Name the owner and the handoff
For the duplicate-callback example, assign these responsibilities before the implementation starts. This is a suggested review arrangement; your assurance plan may require different independence.
| Responsibility | Concrete handoff | Decision it does not grant |
|---|---|---|
| Contract owner | Confirm which identifier stays stable across delivery retries, using the provider contract and domain knowledge. | Does not establish that the patch implements that rule. |
| Implementation author | Propose the deduplication change and identify the behavior it must preserve. | Cannot silently redefine a duplicate to make the patch pass. |
| Verifier | Run a replay with a changed delivery identifier and the same logical event; inspect the resulting side effects. | A scoped pass does not authorize every release or prove all retry cases. |
| Acceptance authority | Assess the current results, remaining gaps and any requested exception under the project policy. | Does not grant merge or deployment permissions unless those are separately delegated. |
A specialist review is most useful when it brings a different basis for the expected behavior or tests a consequential failure mode the author missed. Two models repeating the same assumption still leave the same gap.
Keep accountability attached to the record.
Proof connects the governing requirements, code, hazards and evidence so review can start with the agreement rather than reconstructing it. The team still needs to establish authority, define permitted agent actions and choose sufficient checks.
For an initial audit, agree on a bounded component and an evidence-backed deliverable. Ask to see reproductions, revisions and unresolved limitations. A large list of unverified allegations is a poor substitute.
Try it on your software
Choose one change you would not delegate today.
Use it to identify which decisions need a person and which evidence collection can be repeated by an agent.