- Generation is nearly free now, so the scarce skill is no longer producing more — it's knowing what should never have been produced.
- Over-engineering isn't a technical flaw. It's a failure to decide what the problem actually required — and it shows up in code, decks, roadmaps, and org charts alike.
- The expensive part was never generating the thing. It was maintaining it, explaining it, and eventually undoing it — and AI left that cost exactly where it was.
- The edge this decade belongs to whoever has the nerve to make the cut early, while it's still cheap to make.
Andrew Powers, who runs a company called PageLines, compared Anthropic's and OpenAI's coding models on LinkedIn recently. His conclusion wasn't about speed or accuracy. It was about taste — whether the thing a model builds you is something you'd actually want to maintain.
His specific complaint about Claude: it over-engineers. Extra abstractions, extra files, extra layers nobody asked for. His line that resonated with me was: increasing entropy is probably the cardinal sin of AI. Doing more is no longer the hard part. Cutting is.
I think he named something that reaches well past coding.
The scarcity moved
When generation is nearly free, the only thing still scarce — and therefore still valuable — is the judgment to say no.
For most of business history, output was the constraint. You had a finite number of engineer-hours, writer-hours, analyst-hours, so the winning move was almost always to produce more.
That constraint is going. A model can generate a hundred variations of a campaign, a codebase, or a strategy deck in the time it used to take a person to draft one. Which means the scarce resource is no longer the ability to make things. It's the ability to know, before you make them, which ones deserve to exist.
The entrepreneur of the coming era will not be the one who creates the most. It will be the one who knows what should not be created.
Over-engineering is a decision, not a bug
Over-engineering isn't too much ambition — it's a failure to decide what the problem actually required.
A model trained to be helpful keeps helping past the point of usefulness, because stopping requires a judgment call the training rarely rewards. Add a config option in case someone needs it. Add a fallback for an edge case that never occurs. Each addition is individually defensible. Together they're sediment — the system gets heavier and harder to change, which is the opposite of what all that flexibility was for.
The same pattern runs through work that has nothing to do with code. A forty-slide deck when the decision needed three numbers. A roadmap that hedges every bet by keeping twelve initiatives alive instead of three. A pricing page with nine tiers because removing any one of them felt like a loss. None of it comes from malice. It comes from an unwillingness to make the cut.
The expensive part was never generating the thing. It was maintaining it, explaining it, and eventually undoing it.
Where this leaves the operator
The edge stops being speed of production and becomes precision of exclusion — knowing, in advance, what doesn't get built.
Saying no to something that's now cheap to make feels almost irresponsible. Why not spin up the extra variant, the extra tier, the extra layer, when the marginal cost rounds to zero? Because the marginal cost was never the generation. AI made that first cost disappear and left the second one — maintenance, explanation, eventual untangling — exactly where it was. The second cost is now the whole game.
Powers was talking about a coding model when he called entropy the cardinal sin. The advantage this decade doesn't belong to whoever creates the most. It belongs to whoever has the discipline, and the nerve, to know what should never have been created — and to cut it before anyone notices it was ever there.
