Matt Pocock argues that AI agents have turned the PR review queue into a firehose, and the fix is three layered "brakes": cheap deterministic checks, an automated reviewer running in its own sub-agent, and a much lighter human review. His core unintuitive advice is to keep coding standards out of the implementer agent (which is already overloaded with exploring, editing, and debugging) and put them in a coding-standards.md file that only a review agent reads, and to have that reviewer commit fixes rather than leave comments for humans. He also introduces new skills: a PR skill that labels every PR as a one-way or two-way door with a blast radius, and a "retro" skill that mines past sessions and reviews to generate new checks and standards so each cycle compounds.

• AI-initiated work (bug reports classified into fixes, slow-query reports from tools like PlanetScale triggering jobs) accelerates the "software factory," so you need brakes or you get a "slop cannon" of unreviewable PRs.
• Three layers stack on top of each other: deterministic automated checks, automated agent review, then human review — the first two exist mainly as lie detectors for the ones below them.
• Automated checks are cheap (CPU cycles, not tokens or human attention), so you should layer on far more of them than you currently do, but a green CI does not mean ready to merge.
• Agents produce specific failure modes: tautological tests that just reassert a constant, tests that read a module's source text to assert UI ordering, and over-mocked tests that literally cannot fail.
• Designing deep modules — large implementations behind small interfaces, per John Ousterhout — reduces structure-sensitive tests because agents are forced to test at the interface.
• Don't put coding standards in the implementer agent: implementation is already overloaded with exploration, editing, and debugging, while a review sub-agent is underloaded and has spare budget for standards.
• The automated reviewer should commit fixes, not post verbose comments, otherwise it just creates more work for the human reviewer.
• Don't outsource automated review to generic third-party bots — too general gives false positives, too specific locks you to one language; build and share your own standards instead.
• Classify PRs as one-way or two-way doors with a stated blast radius so humans spend scrutiny only where reversal is hard (migrations, data loss, mass emails).
• Human review should also review the system that produced the code; the retro skill turns sessions and past PRs into new automated checks, coding-standard updates, navigation pointers, tool-economy fixes, and de-bloated steering files.

Agents write tests that can't fail 5:24–6:30

A concrete, recognizable example of how agent-written tests give false confidence by binding to code structure instead of behavior.

It said expect X post character limit to be 280. So the implementation looked like that and the test essentially reasserted the implementation. That is a tautological test.

Why coding standards belong in the reviewer, not the implementer 11:35–13:41

This is the talk's central counterintuitive recommendation, with a clear mental model of context-window budgets to justify it.

While implementation is overloaded, review is actually underloaded... I think of this as the two-part process for writing good code, which is implement, you make it work, and then code review, you actually make it good.

If you just have permanent acceleration pushing stuff through your factory, you're going to end up with a slop cannon.

Code is the environment your agent operates in, and if you have bad code in your code base, that is going to beget more bad code.

The reviewer should commit. It should make fixes... then when the human comes around, you're reviewing a really nice artifact.

When you do a human review, you're not just reviewing the code, you're reviewing the system that creates it.