You ask for a small change. What comes back is the change, plus three helper functions you didn’t ask for, plus error handling for a state the system can’t actually reach, plus a configuration option nobody will ever set.
None of it is wrong, exactly. All reasonable. Defensible. The kind of thing you’d nod at in a review and move on.
And you keep most of it — not because you decided to, but because it’s already written, and it looks fine, and deleting things that look fine requires a reason you have to go find.
That last part is what I’ve been chewing on.
A while back I wrote that maybe the best thing AI does for software is help you write less code. That in a mature system the code is the liability and the working system is the asset, so the highest-value contribution is often subtractive: the feature refused, the abstraction that didn’t need to exist, the bug caught before it shipped.
I still think that’s right. But I framed it as an opportunity, and I’ve come to think I was too cheerful about it, because if subtraction is so obviously valuable, the honest question is why almost nobody does it.
The answer I’ve landed on is less flattering than I’d like.
We were never practicing restraint. We were just constrained.
Think about what actually kept a codebase from sprawling, historically. It wasn’t our judgment. It was typing. Every unnecessary abstraction cost somebody an afternoon. Every speculative feature had to be argued for, scheduled, and then physically typed by a person who would rather have been doing almost anything else. Every “we might need this later” ran straight into the wall of somebody having to build it now.
The friction was doing the work of discipline for us. And it was quietly letting us take the credit.
Ed Catmull noticed the same thing from the other side of it, at Pixar, where the scarce resource was compute rather than keystrokes. “I found early on that an abundance of resources leads to sloppiness,” he told David Epstein for Inside the Box: How Constraints Make Us Better. Not that abundance is bad. That abundance removes the thing that was forcing you to choose.
That’s the shape of what AI has done to software. AI hasn’t made us less disciplined. What it removed was the mechanism standing in for our discipline, and the discipline itself is now exposed for the first time.
Which is a problem, because subtraction has always been the harder sell anyway. Leidy Klotz’s research on why people add rather than remove keeps arriving at the same place: it’s much easier to demonstrate competence by adding. Adding leaves evidence. You can point at it. Subtraction leaves an absence, and nobody has ever been promoted for an absence. So the one contribution that just became most valuable is also the one that is structurally hardest to show anybody.
Here’s the frame that’s helped me most, and it isn’t from software at all.
In Born to Run, there’s a trail runner called Caballo Blanco who coaches by way of a four-word sequence: “Easy, Light, Smooth, and Fast.” You start with easy. Then you work on light. Then, once light has become so habitual you’ve forgotten you’re working on it, you work on smooth.
And then — this is the part that stopped me — he tells you not to work on the fourth one. You don’t have to. Get the first three and fast arrives on its own.
I’ve read a lot of engineering advice and I’m not sure I’ve read a better description of an ordering. Not a list of virtues. A sequence, in which the final term is explicitly not something you pursue. You get it.
Now look at what we actually do with these tools.
We start at Fast.
Fast is the whole pitch. Fast is what the demos show, what the pricing is built on, what the interface defaults to. Nobody’s tooling opens by asking whether the thing should exist. And so the sequence gets run backwards: generate first, and discover afterward what you’ve committed to.
Bill Gates said the sharpest version of this decades before any of this existed, about business processes rather than code: automation applied to an efficient operation magnifies the efficiency, and “automation applied to an inefficient operation will magnify the inefficiency.” Point a code generator at a system whose requirements you never questioned and you don’t get a better system. You get more of the same system, faster, with the mess now load-bearing.
Which suggests the ordering isn’t optional, and it isn’t new. We just used to get the first three steps for free, enforced by friction, and now we don’t.
Ask whether it should exist. Delete what shouldn’t. Simplify what’s left. Then let the machine run.
I want to be careful here, because there’s a cheap version of this argument that I don’t mean.
The cheap version is “write less code,” as though brevity were the point and terseness a virtue. Neither is true. Deleting the wrong thing is worse than adding the wrong thing, because at least the addition is visible. Jobs had the better formulation: “To be truly simple, you have to go really deep.” Simplicity that comes from conquering complexity, not from ignoring it. The five hundred lines that genuinely needed to be five hundred lines are not a failure of restraint.
So: not a call for less. A call for the order.
And the honest difficulty is that the first three steps are all judgment, all unmeasurable, and all slower than the fourth. Questioning a requirement takes a conversation. Deleting something takes a defense. Simplifying takes understanding the thing well enough to know what’s load-bearing — which is the most expensive knowledge there is and the least visible once you have it. Meanwhile the fourth step takes a prompt and produces something you can screenshot.
I don’t think that asymmetry resolves. I think it’s the permanent condition now, and the practical question is just whether you can build something small and mechanical that forces the order — ask first, generate second — because relying on remembering to be disciplined is, as I’ve argued elsewhere, relying on a mood.
The closest thing I have is a rule for deciding what to automate rather than what to delete: only automate what you can imagine never needing a person for again. Partial automation is the dangerous kind, because it strands the knowledge while still requiring the person. Not the same problem. But it has the right shape: you answer it before the thing exists, and that is the cheapest place there has ever been to remove something.
What I keep returning to is that none of this is a complaint about the tools. I use them every day and they’ve changed how I work more than anything else in a decade. The generation is genuinely extraordinary.
They didn’t only remove effort. They also, accidentally, removed a governor. And governors are easy to miss, because a governor’s entire job is to be the reason something didn’t happen.
Which leaves a question I don’t have a settled answer to, and I’d rather put it to you than pretend otherwise.
For twenty years, the cost of building things badly was the main reason we didn’t. That cost is gone, and it isn’t coming back. So what are you going to put in its place?