Chapter 15. Trusting Code in the AI Era: Tests, Types, Pull Requests and Code Review
In this section
- Chapter 15. Trusting Code in the AI Era: Tests, Types, Pull Requests and Code ReviewHow trust in code you did not write is earned in layers, and how to propose, prove and accept an agent's changes.
- 15.1 The change is the unit of workWhen an agent writes the lines, your work moves from files to the proposed change: its purpose, its behavior, and the evidence for it.
- 15.2 Git through the agentRepositories, commits, branches, diffs and history from the beginning, with the agent typing the git commands and you reading each one.
- 15.3 GitHub and the pull requestA remote copy of the repository, pushing and pulling, forks, and the parts of a pull request, opened and read through the agent.
- 15.4 Layers of trust: tests, types and reviewTrust in agent-written code comes in layers, and the question that replaces "did someone read it?" is which check should catch each kind of problem.
- 15.5 Before the pull request: evidence, not "done"Ask for output you can run again, a fresh-context review of the diff, and a short change brief scaled to the risk.
- 15.6 Rules the reviewer readsA short project rules file, and a review rules file that says what failure means in this repository, read from main so a change cannot rewrite the rules it is judged by.
- 15.7 AI review on every pull requestAn AI reviewer reads the whole change against the repository and reports findings by severity, and every finding is fixed or resolved with a reason.
- 15.8 Checks that blockA check that fails the merge against a check that only advises, and how required checks, branch protection and a pull request template make the right checks block.
- 15.9 Human approval, scaled by riskLow, medium and high tiers set by what a change touches, not by who wrote it, with code owners for sensitive paths and an approval that covers one commit.
- 15.10 After the mergeA merge queue, feature flags, staged rollouts and a rehearsed revert make mistakes small after the merge, and the person who lands a change owns it.
- 15.11 How today's tools realize itShort practice for each lesson of this chapter, with tabs where Claude Code, Codex and OpenCode differ, and what each one can and cannot block, as their own pages said on October 31, 2026.
- Lab 15: a reviewed pull requestPut Brightline on GitHub through the agent, set required checks, review rules, code owners and risk tiers, review the weekend rule, catch an agent's bad change, merge behind a flag, rehearse a revert, and port the review to Codex or OpenCode.
- Check yourselfRecall and practice for the whole chapter: the flashcards, and a final quiz round from all eleven lessons.