A change that reaches production has to be shown to be right by something other than the thing that produced it. This chapter treats that showing, D4 Prove: code review, testing strategy, static analysis and the places where formal methods earn their cost, and what each of them can and cannot establish when AI wrote the diff, drafted the tests or wrote the review comment. It touches D3 Build, because the volume of what is built sets the load on what must be proved, and D5 Steward, because proof that nobody can act on has no owner. Chapter 8 defined the mandate under which a coding agent produces a change. This chapter defines what the change has to pass before a named developer can accept it, and Chapter 10 takes the security-specific checks and the toolchain as an attack surface.
The chapter makes one argument. Generation became cheap and verification did not, so the checks that show a change to be right carry more weight and are more exposed to correlated failure. A check counts as proof only when its failure modes are shown not to be those of the thing it checks. That is the independence principle of AI Purple, Chapter 15 (169, Nordqvist, 2026), and the observer principle of AI Operations, Chapter 17 (170, Nordqvist, 2026), applied to code. In this book it appears as the corollary of the stewardship principle defined in Chapter 4: the test oracle must be independent of the generator. A test oracle is the mechanism that decides whether the observed behaviour of the software is correct, whether a human reading the output, an expected value in a test, a stated property or a reference implementation.
Code review is the oldest check in the chain and the one that has been given the most unexamined trust. Its purposes are more varied than its name suggests, and the evidence on them predates generative AI, which matters because it describes what review was already good at before the volume problem arrived.
Primary topics explored
- What review is for
- Testing strategy
- The independent test oracle
- The volume problem
- AI as reviewer
- A verification plan and a review record
About AI Developer
AI Developer is Book 12 of The Transformed Architecture. It takes the developer as its subject and asks what happens when AI is used broadly in software development: the five developer functions (frame, design, build, prove, steward), the delegation ladder and the Level 4 prohibitions, the stewardship principle (name, understand, revert), verification as the scarce skill, the junior pipeline, adoption and productivity as claims that need evidence, regulation (the AI Act, the Cyber Resilience Act, the Product Liability Directive, NIS 2, DORA, the GDPR), ethics, intellectual property and sovereignty in the toolchain, and the developer as a person, for European enterprises and public authorities.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple, AI Operations and AI Leader.
developers at every level, tech leads and engineering managers, architects, platform engineers, site reliability engineers and testers, product owners and designers, leaders who decide on developer tooling, heads of public-sector IT and procurement, works councils and unions, educators, and supervisors and auditors.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 9: Prove: Review, Tests and Verification in AI Developer gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “The Craft of Developing” and is one of 37 drawn from the manuscript.