Cheap Code Considered Harmful
For decades, the cost of building software acted as a forcing function. If you wanted a feature, you had to justify it — to your team, your stakeholders, your budget. That friction wasn’t a bug. It was a feature.
Now, with LLMs and coding agents capable of scaffolding entire applications in hours, that constraint is disappearing. Things that used to cost $100,000 to build now cost less than a nice dinner. The tech industry is celebrating. But I can’t help wondering whether we really got what we were wishing for.
The budget was doing your product thinking for you
The cost of building something forced a moment of healthy reflection. Teams had to articulate why a feature mattered, who it was for, and what problem it actually solved. A feature that couldn’t survive a cost-benefit conversation probably wasn’t worth building. That process filtered out an enormous amount of noise. Remove the filter, and you might just end up building the noise.
We know, intellectually, that more features doesn’t mean better software — that every addition is a maintenance burden, a new edge case, a new source of confusion. We’ve lived through the post-mortems. We’ve written the “less is more” posts. And yet, give a team a coding agent that can crank out features overnight, and suddenly every idea that was previously “not worth the effort” is back on the table. The backlog stops being a prioritization tool and becomes a to-do list.
Constraint is a creative force
There’s a counterintuitive truth engineers have long understood: limits make you smarter. Early console programmers invented entirely new rendering techniques not because they were curious, but because the hardware forced cleverness. Tight memory budgets led to elegant data structures. Slow networks led to efficient protocols.
Cost worked the same way. If building something was expensive, you thought harder about how to build it well — because throwing more code at a problem wasn’t free. That pressure produced care and architecture that someone had actually thought through.
Cheap code dissolves that pressure. Why design a clean, minimal solution when you can generate more? Why refactor when the agent can add another layer? And codebases built that way tend to accumulate complexity quietly, until one day they don’t.
Abundance changes behavior
This pattern isn’t new. When storage got cheap, we stopped deleting files. When bandwidth got cheap, websites got bloated. When compute got cheap, applications got lazy. In each case, breaking the constraint was followed by a period of excess — and eventually a reckoning.
The early phase of cheap code looks like productivity. That’s real, and it’s good. But the second-order effect is already visible: software assembled from AI-generated parts that no single person fully understands, features that exist because they could be built rather than because anyone seriously asked whether they should be.
The discipline has to come from somewhere
Good software has always been about deciding what not to build. Cost was one of the mechanisms that enforced those decisions — not always the right one, but on balance it created discipline.
Now that it’s gone, the discipline has to come from taste, from product thinking, from someone asking the uncomfortable question: do we actually need this? The problem is that “we can build it basically for free” is a very persuasive answer. Even when it’s the wrong one.
The questions worth asking haven’t changed — they’ve just become harder to justify asking:
- Should this feature exist at all?
- What does adding this cost the user in complexity and cognitive load?
- What are we not building because we’re building this?
- Who is actually asking for this, and have we talked to them?
Cheap code doesn’t make those questions irrelevant. It makes them more important than ever.
The title of Edsger Dijkstra’s famous 1968 letter was “Go To Statement Considered Harmful”. His point wasn’t that goto could never do anything useful. It was that the ease of reaching for it was itself the problem — it let programmers avoid thinking carefully about control flow.
Cheap code might turn out to be this generation’s goto. Not harmful in itself. But harmful when it becomes a substitute for thinking.