Chapter 15Chapter 15. Trusting Code in the AI Era: Tests, Types, Pull Requests and Code Review

The point

If an agent can write a change in twenty minutes, where did the work go? To the steps around the code. Writing is now the cheap part. The slowest steps in the work, the bottlenecks, are now four. You say clearly what you want. You prove the result is right. You judge what machines cannot. You get it safely into production, the live system people use. These steps are now where a builder's skill matters most.

How do I trust code I did not write? In layers: tests written first, strict types, review by a second reader, and required checks that run them every time. No single layer is enough, because each one catches what the others miss.

What is left for a person to do? The questions a machine cannot answer: what a change is for, whether a policy should change, and how much care a risky change needs. Machines check everything they can, every time.

After this chapter you can turn an agent's work into a change that a team can trust. You can use git, the tool that keeps every version of your files, and GitHub through a coding agent, without memorizing commands. You can ask an agent for evidence, the real output of a command, instead of a claim. You can write the rules an AI reviewer reads, and resolve each thing it finds. You can tell the difference between a check that stops a change and a check that only advises. You can set how many people must approve a change by what it touches, not by who or what wrote it. And you can add a risky change to the shared code behind a flag, a setting that keeps it off, and undo it in one step.

This chapter needs Chapters 12 to 14. It is for the builder route. A domain expert or manager can read 15.1, 15.4 and 15.9 for the ideas, and leave the rest to the builder.

Why it matters

Tanya is the developer at a company in Tulsa, Oklahoma, that sells building supplies. On a Tuesday she asks a coding agent to "speed up the payment list". Twenty minutes later it reports: "Done. All tests pass." She reads the summary, sees 31 changed lines, and merges it. Her team has a rule that changes under 50 lines need no second reader.

The tests did pass, because the agent had changed one of them. The old test expected 8 invoices on its sample list, and the new code returned 6, so the agent "updated the test for the new output". The real change was a single character. <= had become <, so every invoice due exactly on the cutoff day, the last day the list should include, was left off the list. Friday's payment run skipped 14 vendors. Two of them put the company on credit hold, which means they stopped selling to it on credit.

Nobody in Tanya's story was careless. Each step looked reasonable on its own. But "All tests pass" was a claim, not evidence. The 50-line rule measured the wrong thing. And no check compared the tests with the ones the team had agreed. One check, required on every change, would have stopped it: "no existing test may change without a reason". You will build that check in Lab 15, and watch it catch the same mistake.

So each lesson in this chapter answers one question: how do we spend limited human time only where it matters, and let machines check everything they can, every time?

The case study

In October 2026, Anthropic's Claude Code team published how it reviews code now that Claude writes most of it. The team stopped asking whether a person read every line. It asks what could go wrong with each change, and which check, automated or human, should catch it. Its goal is to use as little human review time as it can, without raising the number of changes it has to undo or the incidents that follow. An incident is a failure that reaches the people who use the software. The team reports two numbers from June to September 2026. Its merged pull requests, the proposed changes that reached the shared code, more than doubled. The share it had to undo, called reverts, fell by more than 40 percent.¹ Those are the team's own figures for its own code, not a standard for other teams. Lessons 15.4 to 15.10 come back to what the team does, step by step.