Section 6Verify — review without reading every line

Agents produce more code than you can read. So don't review by reading — review by watching and by evidence. This is the single technique that makes the whole workflow scale.

Section 5 set this up deliberately. The blackbox behaviour tests you insisted on there — launch the real app, press the button, see the status change — aren't just the most refactor-proof kind of test. They're also the only kind of test a person without a programming background can watch. A unit test passing is a line of green text that means nothing to anyone outside the code; a behaviour test passing is the salon's booking page actually refusing to double-book a chair, on screen, in front of you. Choose behaviour tests in Build and you have already manufactured your review evidence for Verify — the two sections are one decision seen from both ends.

Hold on to Section 1's rule as you read: evidence over claims, always. Everything in this chapter is a kind of evidence — a recording of the feature working, a wall of green checks, a second agent's independent read of the changes, a regression suite that hasn't gone red. Your job in Verify isn't to redo the agent's work with your own eyes; it's to decide, the way a manager or an editor does, whether the evidence in front of you actually supports the claim "this is done." Most of the time that takes minutes. The skill is knowing which minutes.

The flipped testing pyramid

Classic advice: mostly fast unit tests, few slow end-to-end tests. Pocock flips it — a heavy base of blackbox behaviour tests. Those are historically expensive for humans to debug, but an agent has infinite patience: it reruns, instruments, and resolves failures at no cost to you.

That's worth slowing down for, because the pyramid was an economic argument — and the economics just changed. The expensive step was never running an end-to-end test; computers do that happily. It was a human diagnosing one when it failed. Hand that job to an agent and the cost collapses: it reruns the failing scenario twenty times, adds logging, narrows down the cause, and reports back, without consuming an hour of your attention. Meanwhile the end-to-end test keeps the advantage Section 5 already banked on: it checks what the user actually experiences, and it survives the constant refactoring agents do. When the costly option becomes cheap and was always the more valuable one, you buy more of it. Hence the flip. One honest caveat: the flip buys realism and pays for it in runtime and flake management — the maintenance rules in the regression section below are the bill.

Demo reels — watch the feature work

Configure the behaviour tests to record as they run — a screen recording for a web app, a terminal "cinema cast" for a CLI. Each test drives a real user scenario end to end. When the work is done, the agent opens a pull request (a "PR" — a proposal to merge its branch, where teammates and automated checks review the change), confirms all checks are green, and embeds the recording. Your review becomes watching a short clip to confirm the behaviour with your own eyes.

The tooling for this is standard, not exotic. Playwright — the same tool already driving the behaviour tests in the cards below — records video of its own test runs with a one-line setting (video: 'on', or 'retain-on-failure' to keep clips only when something breaks). For command-line tools, asciinema records the terminal session itself as a tiny text file you can replay or embed. Either way, the recording is a by-product of tests that were running anyway: nobody performs a demo, nobody edits a video. The reel is simply what the test suite saw.

Watch it the way the salon owner would use the app, with the ticket's "done" sentence from Section 4 open beside it: block a holiday week, watch a customer's booking attempt get refused politely, watch the confirmation arrive. You're not checking code — you're checking that the promise in the ticket is the behaviour on the screen. That's a judgment you're fully qualified to make with no programming background at all, which is precisely the point: the flipped pyramid moved the truth of the system somewhere a human can see it.

Match scrutiny to risk — where your minutes go

In the salon app the tiers are easy to name in advance. Bottom tier: wording changes, colours, layout tweaks — the demo reel alone is plenty. Middle tier: new behaviour like the holiday-blocking feature — watch the reel and skim the second agent's review, coming next. Top tier: anything touching payments, refunds, cancellation fees, login, or deleting customer data — here you watch the reel, read the review, and have the agent walk you through the actual changes line by line ("explain this diff to me as if I'm the salon owner"). The point isn't that top-tier changes are rare; it's that they're identifiable before the work starts, so your scarce close attention lands exactly where a mistake would cost real money or trust.

A second agent reads what you don't

Watching covers behaviour, but a reel can't show you everything. It won't reveal a hard-coded password, a wasteful database query, or a corner quietly cut inside the code. For that layer you still want a reader — just not you. The same principle as Section 5's "don't let the AI mark its own homework" applies to review: an agent that didn't write the code, starting with fresh context, has no memory of the shortcuts taken and no investment in the result looking good. It reads the change the way a sceptical colleague would — except it reads all of it, every time, and is exactly as thorough on the last file as on the first.

You can also run /review to spawn adversarial reviewer agents that check the diff (the exact lines added and removed) against the spec and your standards — a second opinion before you even watch the reel. Claude Code's GitHub Actions integration can run this same review automatically on every pull request with no manual trigger, and headless mode (claude -p, with --output-format json) is what lets any of this run unattended inside CI at all. Anthropic's own dedicated code-review agents, run internally on Anthropic's own pull requests, raised the share of PRs getting a substantive review comment from 16% to 54%, with under 1% of findings marked wrong by the engineers who checked them — real evidence that agent-driven review, built properly, isn't just theoretically thorough.

Put together, the pull request page is the one screen where all of this evidence lands. Here's a compact mock of what you'll see there, part by part:

Block out holiday weeks on the staff calendar  #214    ← title: the ticket's promise
───────────────────────────────────────────────────────
✓ Behaviour tests (Playwright)     passed · 4m 12s     ← the row of checks —
✓ Type-check (strict)              passed                all green before you
✓ Linter                           passed                spend a single minute
✓ Reviewer agent                   no blocking findings
───────────────────────────────────────────────────────
▶ demo-reel.webm · 0:48                                 ← the embedded demo reel,
  recorded by the behaviour tests themselves              the promise on screen
───────────────────────────────────────────────────────
src/booking/availability.ts · line 87                   ← a review comment anchored
  reviewer agent: "This availability check runs           to one line — the second
  after the write; two simultaneous requests              agent's fresh-eyes read
  could both pass it. Unique constraint instead?"
  you: "Agree — fix it and re-run the suite."

Read it top to bottom in that order — title against the ticket, checks green, reel watched, review skimmed — and you've done a full review without opening the diff once.

Regression testing — proving new work didn't break old work

Every test that turned green in Section 5 stays in the suite forever, and that permanence is the point: from now on, every future change has to keep every old promise. When the agent builds gift vouchers in March, the February tests for holiday-blocking still run — and if the voucher work accidentally breaks holiday-blocking, a test you'd forgotten existed goes red before the mistake reaches a customer. Breaking something that used to work is called a regression, and it's the characteristic failure of fast-moving agents: they change a lot of code quickly, and their blind spot is everything they weren't currently thinking about. The C-compiler story above is this failure at scale, and its lesson applies at yours: the automated gate is the regression protection.

A growing test suite is a liability the moment it's slow enough that people skip it or flaky enough that a red result gets ignored. Treat the suite as something to actively maintain, not something you write once during Build and forget.

• Quarantine flaky tests, don't tolerate them. A test that fails intermittently comes out of the required-merge gate immediately, but keeps running and reporting — with an owner and a deadline to fix or delete it. A healthy suite runs under roughly 5% flaky. Silently re-running a red test until it turns green trains everyone to stop trusting red.
• Run only what the change could have broken. Once the suite is large, gate each pull request on the tests whose dependency graph actually touches the diff, with a full run on a schedule as a backstop — build-graph tools like Nx, Bazel or Turborepo do this automatically. Teams report this cutting CI from tens of minutes to a few.
• Let production keep testing after you ship. Canary rollout, synthetic monitoring (scripted checks hitting your critical paths continuously), and — for higher-traffic products — shadow traffic (mirroring real requests to a new version without it affecting real users) catch what your test suite didn't think to write. Pre-merge checks and post-release monitoring are one continuous loop, not a choice between them.

Test tooling, by what it actually catches

No single test type catches everything. Pick tools by what they're for:

Don't try to install all six on day one. The salon app starts with the first two rows — unit tests for the fiddly logic, behaviour tests as the base of the pyramid — plus the accessibility check, because retrofitting that later is miserable. The other rows earn their place when the product creates the failure they catch: contract testing when the app splits into separate services, load testing before the first marketing push, visual regression once the interface is polished enough that a broken layout costs trust. And what's worth remembering isn't the tool names — the agent will happily set any of them up when asked — but the failure modes: each card names a way software breaks that none of the other rows would notice.

Verified is not the same as ready

Everything in this chapter answers one question: does the change do what the ticket said, without breaking what already worked? That's necessary — and nowhere near sufficient. A feature can pass every behaviour test, look perfect in its reel, and survive two agent reviews, and still fall over with ten thousand users, still be unusable with a keyboard, still greet a network failure with a raw error dump. Those aren't verification failures; they're things nobody asked the tests to check. Section 7 closes that gap with a definition of done — a checklist of quality gates, enforced in CI, that a change must clear before "verified" is allowed to mean "ready."