Code review at AI pace: Earning the right to read less

Part 1 sorted every change into three tiers, so human attention goes where the risk is. This part answers the question that follows: what makes it safe for humans to read less? Two things do: evidence that proves a change works, and deployments that make a missed bug cheap. Then come the limits: the case for not reading code at all, what regulators require, and the signals that keep the system honest.

Evidence, not assertion

Every pull request carries a machine-generated proof pack, so the reviewer checks outcomes instead of rebuilding the author’s work in their head.

A reviewer who must check out a branch and click through a flow spends twenty minutes before forming an opinion. One who sees before-and-after screenshots, a green test report and a live preview needs two. For agent-written code, the proof pack is how the agent earns trust rather than asking for it.

Playwright has become the natural backbone. Its test agents, a planner that explores the app, a generator that writes the tests and a healer that repairs broken ones, let the author produce evidence alongside the change. ARIA snapshots assert structure against the accessibility tree; screenshots catch what only eyes notice:

test('checkout summary', async ({ page }) => {
  await page.goto('/checkout/summary?fixture=standard-basket');
  await expect(page.getByRole('main')).toMatchAriaSnapshot();
  await expect(page).toHaveScreenshot('checkout-summary.png', {
    mask: [page.getByTestId('timestamp')],
  });
});

CI posts the images inline on the pull request, and a preview environment per pull request lets the reviewer open the real thing in one click when a picture is not enough.

Trust in the pack comes from the details: seeded data, frozen clocks and masked timestamps, so a diff always means something; evidence scoped to what the change touches; failures shown at the top, never collapsed. One caution from experience: a self-healing test that rewrites an assertion can hide a real regression, so healer changes outside Tier 1 get human eyes.

Make a missed bug cheap

No review catches everything, so every change should ship in a way that limits who a defect can reach and how long it lives.

This safety net is what makes lighter review responsible. When a change can be switched off in seconds and first reaches only a small slice of traffic, a missed bug becomes an incident note, not a crisis.

The depth scales with the tier, exactly like review. Tier 1 ships through continuous deployment with automatic rollback on failed health checks. Tier 2 ships behind a flag, through a canary. Tier 3 combines flags and rings and, when a critical component is being replaced, a shadow period first, with the rollback rehearsed before go-live. Open standards make this cheaper than it used to be: OpenFeature gives flags a vendor-neutral API, and tools such as Argo Rollouts or Flagger automate canary analysis on Kubernetes.

Three cautions. Shadow traffic must never replay side effects: stub the payment provider, the email sender and anything that writes outside the service. Flags are debt, so each gets an owner and an expiry date and disappears once the rollout completes. And on critical paths, flipping a flag is a production change in its own right, audited and owned by whoever is on call.

Should anyone still read the code?

Stop reading code where the harness can prove what matters, and keep reading it where it cannot. Not reading code does not remove the bottleneck; it moves it.

In July 2026, Robert C. Martin, the author of Clean Code, said he no longer reads the code his agents write: “That’s the only way I can take advantage of their productivity. What I do instead is to surround the agents with extreme constraints.” His gauntlet: unit and acceptance tests, mutation testing, coverage, limits on complexity and module size, dependency analysis. Grady Booch replied that he still reads all of it, because metrics show whether code works, not whether it opened a vulnerability or buried a poor design.

Both are right, about different code. Martin’s position is where Part 1’s Tier 1 and the proof packs above lead: once the checks are strong enough, reading every line adds little and is the slowest step in the loop. But someone still writes the acceptance criteria, decides what the evals measure and keeps the harness honest. That is review by another name, done once for many changes instead of once per change.

Three limits stop it from applying everywhere:

• A harness only finds what it was built to look for. Mutation testing proves the tests catch the bugs someone imagined. A missing authorisation check, an injection path or a rounding rule nobody specified passes a green suite, and those are exactly Tier 3’s risks.
• The harness becomes the most critical code you own. A weakened assertion, a skipped test or a loosened threshold silently widens what ships unread. Changes to tests, evals and gates deserve more scrutiny, not less, for the same reason the risk map is a Tier 3 file.
• A personal practice is not a control. Martin’s rule works for his own projects. In a regulated firm, someone independent of the author approves the change, as the next section shows.

The practical answer is a gradient: read the guardrails before the code.

As the harness matures, more changes can move up this table, from read to unread. Each move should be earned through the post-merge sample and incident reviews, never by declaration.

What regulators actually require

Regulators ask for maker-checker, an approver independent of the author, not a human on every pull request. The tiers meet that bar, as long as the approval path is itself governed.

For EU financial entities, DORA’s ICT risk management standard, Delegated Regulation (EU) 2024/1774, sets two relevant rules. Article 16 requires source code reviews covering static and dynamic testing, with findings tracked through an action plan. Article 17 requires change procedures with “mechanisms to ensure the independence of the functions that approve changes”, safeguards for emergency changes and their approval after the fact.

Card payments are more literal. Under PCI DSS v4.0.1 requirement 6.2.3.1, a manual code review is done by someone other than the author, and management approves the change before release.

Two points need care:

• First, Tier 1 auto-merge has no human approving the individual change, so independence moves up a level: the risk map, the gate configuration and the AI reviewer’s instructions are approved as Tier 3 changes, the same logic as a pre-approved “standard change”. Write that down, and agree it with your compliance function and auditors before applying it to in-scope systems such as a cardholder data environment.

• Second, when an agent writes the code, the maker is the person who drove the agent. They cannot also be the checker, and an AI reviewer never counts as the independent approver in Tiers 2 and 3: its output is evidence, not a signature.

The EU AI Act’s human oversight rule is often cited here, but it governs high-risk AI systems in use, such as credit scoring, not the assistants that write your code.

Keeping the system honest

A handful of signals catch the usual failure modes early.

The last signal teaches the most. Every incident review asks one extra question: which tier did the originating change go through, and should it have been higher? The answer updates the risk map, and that is how the system learns.

What changes

Code review at AI pace is not about reviewing less; it is about spending human judgment where it changes the outcome.

How to start on Monday : Start small

Write down your three tiers and the paths that make a change critical. Add Playwright screenshots to one team’s pipeline and post them on every pull request. Turn on an AI reviewer for Tier 1 and read its digest for a month.

Then listen to your reviews. You should hear fewer questions about what, and far better ones about why. That is the sound of a team that trusts its evidence, and has time again for the conversations that make everyone better.