Review-First Programming
Art Criticism by H.Daumier
Summary
Food critics who can't cook at Michelin level. Editors who don't write novels. Casting directors who can't act.
Different skills, not lesser skills?
LLMs are revealing something we usually sweep under the rug: generation and evaluation are cognitively asymmetric. Research on utterance planning shows construction is harder than execution. Starting with nothing costs more cognitive load than refining something that already exists.
This phenomenon isn't new. "Real Programmers Don't Use Pascal" (1983) mocked structured programming as "quiche eating." Every abstraction faced resistance from people who valued control over leverage.
Review-first programming isn't a decline. It's specialization. And the developers adapting fastest aren't the ones who generate the most code. They're the ones who know what not to build.
I keep hearing the same confession from developers working with LLMs, and I'll make it myself: I'm better at reviewing code than writing it. Out loud that sounds like admitting you've gone soft. I don't buy it. Reviewing and writing were never the same skill to begin with.
Two Different Jobs
Writing code from scratch means holding syntax, design patterns, edge cases, and architecture in your head all at once, like trying to carry on four conversations at the same party. Reviewing collapses the whole mess into one question. Does this solve the problem?
Planning what to say costs more brainpower than saying it, and code review gets to skip the expensive part: the plan already exists on the screen, and your only job is to judge it.
The blank canvas makes writing even pricier. Developers with twenty years of experience still paste in their own old code as scaffolding rather than face an empty file. LLMs are infinite scaffolding. All the energy that used to go into getting something, anything, onto the screen now goes into the logic and the judgment calls. Some developers worry that leaning on review means their skills are rotting. I think the skills are relocating.
Code Review as Archaeology
Reviewing LLM output is archaeology. The author left artifacts and no forwarding address, so you reconstruct intent from what's on the page and reason from first principles. You also have to hold the architecture of code you never wrote steady in your head, which might take more knowledge than typing fresh code ever did.
We've been through this before. In 1983, Ed Post published 'Real Programmers Don't Use Pascal' in Datamation, sneering at the 'quiche eaters' who preferred structured languages to assembly and FORTRAN. Every abstraction layer since has drawn the same fire. And each generation of grumblers was right about one thing: something really was being abstracted away. The best programmers just learned to work with the layer below anyway.
The developers who will have the roughest time with this shift are the ones whose identity lives in typing the code themselves. Which is a shame, because a good editor often understands a story's machinery better than the writer does. The editor just shows it with a red pen instead of a draft.
One Reviewer, Many Machines
There's a scalability bonus too: a developer who reviews and directs instead of typing doesn't have to pick one horse. Run three LLMs against the same problem and compare what comes back. Tools for orchestrating multiple coding LLMs already lean into this, routing different languages and problem types to whichever model handles them best.
An LLM will happily hand you flawless syntax for a distributed system when a single process would have done fine. Elegant abstractions that curdle into maintenance nightmares by the third sprint? Also on the menu. Generating code is now nearly free, which makes the judgment to look at all that perfect output and say no, we're not building this, the scarcest resource in the room.