Verification must challenge both design and implementation

A model’s explanation is a claim. A passing test is evidence of a tested behaviour. Neither, on its own, proves the product is right.

The problem

AI makes writing code faster. It does not automatically make the result correct, appropriate or maintainable. Reviewing generated code only for plausibility is especially weak when the architecture and desired behaviour are implicit.

Independent verification means examining the result against evidence that does not depend on the implementing agent declaring it successful.

A layered assurance model

Different checks answer different questions:

• Product check: Does this capability address the user need? What feedback would disprove that?
• Design check: Does the proposed mechanism respect the agreed architecture and constraints?
• Contract check: Are the externally observable guarantees preserved, including failure behaviour?
• Implementation check: Do tests, static checks and inspection support the claimed behaviour?
• Operational check: Can the change be deployed, observed and reversed safely?

Passing code tests can support the fourth question, but not the first. Keep those forms of evidence separate.

Multi-model review as simulated peer review

A useful pattern is to give independent models the same agreed design, relevant contracts and implementation diff, then ask them to challenge different aspects: architectural boundaries, adversarial edge cases, or test completeness. Do not give all reviewers the implementing agent’s reassuring summary as their only context.

Reconcile review findings by reproducing them or disproving them with evidence. Models can agree on the same mistake, invent concerns or miss a defect. Their consensus is a signal for investigation, not a release criterion.

Illustrative example

An intake service passes a happy-path test. An independent reviewer asks what happens if the same event arrives twice with different payloads. A contract test establishes that this must be rejected, rather than silently modifying the original request. The reviewer contributed a question; the test and contract provide the durable protection.

What to retain

A concise verification record: claimed outcome, tests run, coverage boundaries, review findings, disposition, remaining risks and who accepted them. Prefer repeatable, mechanical checks over lengthy prose.

Limits

Review and tests have cost. Multiple models are not always valuable for a trivial change. Model independence is imperfect and automated checks cannot establish product-market fit. Match assurance effort to the impact and reversibility of the change.

See the worked example: verification plan, multi-model review, worked findings.