How many people a change reaches sets how many checks it needs. My own sites merge on a green build, a marketing site goes straight to main, and a product stacks six layers.
Last week my agents opened a PR for a typo on my portfolio the same way they opened one for Cal.com's sign-up page: same template, same merge once it's green. Then I read how Anthropic's Claude Code team reviews code now that agents write most of it, and looked at my pull requests again.
On my own repos, green meant almost nothing. No reviewer runs there. Green meant the site built.
The tempting fix is to review everything properly, with a person reading every line before it merges. It sounds like care. But what I need to know is what could break and which check catches it, and reading lines doesn't tell me that.
So I start with one question: who sees the change when it's wrong.
Only me. My portfolio and my studio. The build passes, I look at the preview on my phone, and it merges. If something slips, I'm the only one who trips on it, and one revert undoes it.
Visitors to a marketing site. The new cal.com site takes no pull requests at all. Commits go straight to main in batches. It's marketing, so a broken section costs a bad afternoon. It still reaches customers, so a batch only goes out once types check and the end-to-end suites pass, and a broken build gets fixed forward the same hour.
People booking a meeting. Here a mistake can cost someone their meeting, so the layers stack up. The author's agent verifies the change first. Required checks run. An AI reviewer reads the diff in rounds, and a separate pass looks for security holes. A risk label decides whether a person has to look, and only small, low-risk changes merge on their own. And if all of that misses, one step rolls it back.
None of those layers catches everything. Tests miss what nobody thought to test. AI reviewers miss things, and so do the people who wrote the code. Each layer is a slice of cheese with holes in it, and a mistake only reaches people when the holes line up in every slice.
So the fix is more kinds of check, each with its holes somewhere else. Reading more lines only thickens one slice. My own lane has two slices, the build and my look at the preview, and that's enough. In the figure one mistake slips through both, and the only person it reaches is me.
Slices cost something too. An agent fixes every comment a reviewer leaves, which means another commit, another round and more code. Anthropic's team watched one PR go more than fifty rounds overnight. My agents now stop after three and rethink the approach instead of patching again.
When I correct an agent, the fix can go in four places. Lauren Tan posted a drawing of them as an upside-down pyramid, with most of the effort at the top.
The top is the codebase: make the mistake impossible to write. Then static checks, which catch it on every commit for free. Then prose, a rule in the agent's instructions, which holds until a long session forgets it. Last comes a person, the scarcest check there is.
My own setup is the wrong way round, and I get away with it only because I'm the one standing at the end. Most of what I've taught my agents lives in prose, hundreds of lines of it. The rules a script could enforce belong in a script, one level up, and moving them is next.
The checks in the product lane catch broken code. A menu that opens a beat late still passes them, and so does a button that reads as decoration. Someone has to use it, and on the front end that's me with the preview in my hand.
Some paths need a specialist whatever the risk label says: sign-in, payments, the code that decides which slots are free. And reading every line is still right for the first PR of a new pattern, because the next twenty copy it.
Review is a budget of attention, and attention is the one thing agents haven't made cheaper. I spend it where the people are.