Code review is a taste problem

Code review is quietly becoming the place where software teams make real decisions. The old story was simple: read the diff, catch bugs, merge the rest. But that model was built for a world where humans wrote the code at human speed. AI has changed the pace so much that the review step is starting to matter less as a line-by-line inspection and more as a place where teams decide whether they even want the change at all.

That shift explains why debates about reviewing AI-written code keep talking past one another. People are treating code review as if it has one job. It doesn’t. It is where teams collaborate on what belongs in the product, where they build shared understanding about the code base and the business behind it, and where they verify whether the code is correct and safe enough to ship. Those jobs don’t disappear when AI writes the first draft. If anything, they get heavier because there’s more code and fewer humans who can realistically read all of it.

The bigger change is that planning and review are starting to blur together. Work that used to live in PRDs or architecture docs can collapse into the review process itself, because writing code is cheaper and easier to revise. Instead of front-loading every decision before implementation, teams can shape the real artifact together. The article even imagines a future with many more pull requests that never merge. That sounds chaotic, but it may be closer to how software gets built once trying things becomes cheap.

There’s also a different way to move the process left: capture intent before the code is even submitted. If the engineer has already made decisions while talking to an LLM, those decisions can be preserved and reviewed as intent, not just as a 600-line diff. In that setup, the reviewer is not asking whether the code “looks right.” They’re checking whether the team is solving the right problem with the right constraints. That is a better use of senior engineering time than staring at every line like a suspicious customs officer.

The piece’s sharper point is that the most mechanical part of review may be the easiest to automate. A senior engineer spots the same anti-pattern again and again. Pull enough review comments from a code base, sort them into deterministic, execution-testable, and genuine judgment, and a lot of that feedback can be turned into rules. The article calls this an “AI slop register,” which is a rude name for a very old software idea: encode the lessons, so the same mistake doesn’t keep coming back. Code review isn’t dying. It’s just moving away from the diff and toward the place where judgment lives.