Review-First Programming
Art Criticism by H.Daumier
Summary
A food critic can't necessarily plate at Michelin level, and it doesn't matter. Knowing a dish is wrong is its own thing, same as an editor fixing a novel she couldn't have written herself. That skill is the one LLMs keep pushing forward.
They make the cost split visible. Coming up with what to say is the heavy lift, and review gets to skip it, since the work is already on the screen for you to poke at.
Old news, really. "Real Programmers Don't Use Pascal" (1983) mocked structured programming as "quiche eating," and every abstraction after it caught the same flak from people who liked the layer below.
I've quit reading review-first work as a slide into softness. Looks like specialization from where I sit. The people getting ahead are the ones who can look at a working feature and still say we don't need this one.
Same confession keeps coming up from developers working with LLMs, so I'll make it too. I review code better than I write it. Out loud that sounds like a soft-hands admission. It isn't one. Reviewing and writing were separate skills long before any of this.
Two Different Jobs
Writing from scratch means keeping syntax, design patterns, edge cases, and architecture all live in your head, like four conversations at one party. Review folds all of that into a single question. Does this solve the problem?
Working out what to say costs more than saying it. Review gets a discount, because the plan already exists on the screen, and all you owe it is a verdict.
The empty file is what makes writing expensive. Twenty-year veterans still paste in their own old code as scaffolding rather than face a blank one. LLMs hand you infinite scaffolding. So the energy that used to go into wrestling anything at all onto the screen now goes into logic and the calls you have to make. A lot of people hear their own skills going quiet and assume decline. I think the work just changed addresses.
Code Review as Archaeology
Reviewing LLM output feels like archaeology. Artifacts everywhere, no note from the author, so you piece intent together off the page and reason it out from scratch. And you have to keep the architecture of code you never wrote steady in your head, which can ask more of you than typing something fresh.
We've done this dance before. In 1983 Ed Post ran 'Real Programmers Don't Use Pascal' in Datamation, mocking the 'quiche eaters' who reached for structured languages over assembly and FORTRAN. Every layer of abstraction after that took the same shots. The complainers had a point, actually. Something really was being abstracted away each time. The good ones just went and learned the layer underneath.
The developers in for the roughest ride are the ones who've wrapped their identity around typing the code. Shame, that. A good editor reads a story's machinery cold, red pen in hand, without ever having drafted a word of it.
One Reviewer, Many Machines
There's a scaling perk on top. Review and direct instead of typing, and you stop having to back a single horse. Point three LLMs at one problem and see what each drags back. Tools for orchestrating multiple coding LLMs already run this way, handing different languages and problem types to whichever model does them best.
An LLM will gladly write you spotless syntax for a distributed system when one process would've been fine. Gorgeous abstractions that rot into maintenance nightmares by sprint three? Those too. Code is nearly free to generate now, so the costly thing is the nerve to read all that flawless output and say no, not this one. That nerve is in short supply.