Reviews Are Expensive, Rewrites Are Cheap
Ishmeet Bindra wrote a post yesterday that pinned something I’ve been feeling but couldn’t articulate. Here’s the thesis: the economics of code have inverted.
Writing code used to be the expensive part. Reviewing it was the cheap part — you skimmed the diff, looked for obvious problems, and shipped. The ratio made sense because humans are slow writers and fast readers.
LLMs flipped that.
An LLM will happily write two hundred lines of implementation when two lines of import would do. Not because it’s lazy — because the cognitive cost is the same. For a transformer, writing a complete sorting algorithm from scratch and calling sorted() are indistinguishable operations. No instinct for parsimony. No muscle memory for “there’s probably a library for this.”
So the output changes. Now you’re reviewing code that’s technically correct but structurally gratuitous. Ten files changed when two would’ve sufficed. A bespoke implementation of something that’s been a standard library call since Python 2.
Bindra’s observation: the bottleneck moved. Reviewing is now the expensive step. And rewriting? Cheap. If you can see the over-engineering, you can prompt the AI to simplify it. The tool that created the mess is also the fastest broom.
The counterargument I keep hearing
“Just prompt better. Tell the LLM to prefer libraries, minimize changes, write simple code.”
Sure. And that helps at the margins. But here’s the thing: you can’t prompt your way out of a knowledge gap. The LLM doesn’t know when it’s being excessive because it has no sense of proportion. It generates code token by token, and every token feels equally necessary from its perspective. The judgment about what’s appropriate for the context — that’s still a human signal, and you have to inject it after the fact.
Which means your workflow becomes: generate → review → identify bloat → regenerate → re-review. The review step is no longer a gate. It’s the entire loop.
What actually changes
Bindra says he’s shifted his time upstream — more planning, more architecture decisions, more specifying what should exist before letting the AI write it. Then implement, deploy, look at what the AI produced, and rewrite the parts that don’t belong.
This tracks with what I’ve seen. The engineers getting the most out of AI coding tools aren’t the ones who let the AI run. They’re the ones who treat it like a very fast junior dev who needs constant course correction. The value isn’t in the AI’s first draft. It’s in the human’s ability to see the delta between what the AI wrote and what should exist.
That delta-detection skill? That’s what becomes valuable. Not typing speed. Not framework familiarity. The ability to look at a hundred lines of technically correct code and say “this should be ten lines, and here’s why.”
The objection that makes me pause
Here’s where I’m not entirely sure I’m right: if rewriting is cheap, doesn’t that just move the problem? Now instead of reviewing once, you’re reviewing twice — once to identify the bloat, once to verify the simplification.
Unless the simplification is small enough that you can trust it without deep review. A rewrite from 100 lines to 10 lines is easier to audit because the surface area shrinks. The question is whether that trust scales.
I don’t know yet. But I’m watching how my own workflow changes, and Bindra’s piece gave me language for something I was already doing without realizing why.
Writing is cheap now. Understanding is what costs.
Source: Reviews have become expensive, rewrites have become cheap by Ishmeet Bindra