Look, I use these tools all day. I’m not here to tell you they don’t work. They do, and they’re only going to get better. But after leaning on AI for real work for a while now, I’ve noticed something that doesn’t show up in the demos, doesn’t show up in my commit history, and honestly doesn’t show up anywhere except in my own head at the end of a long day.
The most valuable thing AI has done for me isn’t the code it wrote. It’s the code it helped me not write.
That took me a while to see, so let me try to explain.
A few years ago I wrote a post about a restaurant-industry concept called Full In, Full Out — the idea that a good waiter never walks with an empty hand, clearing plates on the way in and carrying food on the way out. It was a post about proactivity, but there’s a section in it I keep coming back to that wasn’t really about waiters at all. It was about design:
When something is designed really well, the final design can often end up feeling obvious to the uninitiated. I’ve started to feel a little bad for designers, as when they are successful, the result of that good work is that it can cause others to think that their work is less necessary: “Well that doesn’t look so hard. Just 2 colors, a few lines here and there, and a bunch of white space. I could have done that, piece of cake!”.
And then the line I think matters most:
The final product may be both simple and efficient, but neither of those things were inevitable and come only from hard work that goes largely unseen.
I wrote that about design. It turns out to be the truest thing I know about software engineering, too. And I think it’s the key to what AI is actually doing for the people who are good at using it.
Here’s the thing that a lot of people, including a lot of developers, never fully internalize: in a system that has to last, the code is the liability, and the working system is the asset. Every line you write is a line someone has to understand later, maintain later, debug later, work around later. The best engineers I know aren’t known for how much they produced. They’re known for the mess they didn’t make: the feature they talked someone out of, the abstraction they collapsed into something simpler, the clever solution they passed on because a boring one would age better.
Which brings me to the uncomfortable part.
If the highest-value work in software is subtractive — less code, less complexity, the bug caught before it ships — then look at everything we’ve built around these AI tools. All of it points the other way.
The marketing is about generating: ships features 10x faster. The demos are always something appearing on the screen, never something wisely left off it. The metrics your organization can actually see (commits, pull requests, lines, velocity) all count production. And the interface itself, that little cursor waiting for you to type “build me X,” quietly nudges you toward making the thing rather than asking whether the thing should exist at all.
So we have a technology that’s genuinely capable of the subtractive, high-value work. I know it is, because it does it for me every day. And it’s wrapped in a commercial layer pointed almost exactly the opposite direction.
If you want the purest example of this, look at design. Good design is the ultimate subtractive act: the elements removed, the step taken out of the flow, the screen that ends up looking so obvious you assume it was easy. And it’s exactly because it looks easy that it gets undervalued. The better the work, the more invisible it becomes. Code and design turn out to have the same secret. The best of both is defined by what isn’t there, and neither shows up on a dashboard.
And it gets worse, in a quiet way.
Using AI subtractively is harder than letting it generate. To make the small change instead of the big one, you have to understand the system deeply enough to know which small change is the right one. To catch the thing that’s about to go wrong, you have to be paying real attention. To decide not to build something, you have to hold the whole picture in your head and take responsibility for the call. That’s the tiring work. Accepting the generated output is the easy work. The tool’s path of least resistance runs downhill toward volume, and the valuable thing is uphill. So even the person best positioned to use it well has to spend energy fighting the current, and gets, for the trouble, nothing anyone can see.
I keep thinking about another line from that same old post:
When you took the time to solve a problem very few people knew about and saved yourself and others around you countless hours, they may never know to thank you as you made the problem go away before it became a problem for them as well.
I wrote that in 2019, about being proactive. I could republish it today, unchanged, about what it feels like to use AI well.
Here’s what worries me, and I want to be careful here, because I don’t think it’s obvious in either direction. What if all of this rewards the wrong thing without anyone being foolish or lazy?
Picture two teams. The first uses AI to spray out an enormous volume of plausible code. It ships constantly, looks tremendously productive on every dashboard, and quietly piles weight onto the foundations of its system until, a couple of years later, everything is slow and brittle and no one can quite say why. The second team uses AI with restraint. It ships less. It keeps the system clean and comprehensible and easy to change. And by every available metric, it looks like it’s getting less out of the same expensive tool.
Which team gets praised this quarter? Which one gets the budget next year?
The signal isn’t just missing. It might be backwards.
I don’t have a clean answer to this, and I’m suspicious of anyone who says they do. Maybe the value surfaces eventually. The sprayed-out system does bog down, the clean one does keep moving, and over a long enough horizon the truth comes out. I hope that’s how it goes. But I’ve spent enough years inside real organizations to know that the distance between true and recognized can be enormous, and that the story a company tells itself about why it slowed down is rarely the honest one.
So I’ll leave you where I usually do: with a piece of advice and a question, and no tidy conclusion.
The advice: the best thing you do with these tools may be the thing no one thanks you for, the same way it’s always been. If you find yourself using AI to build less, you’re very likely doing the most valuable work available to you: keeping things simple, catching what’s coming, making the change small. Know that it will probably be invisible. Value it anyway. You may be the only person who ever really knows what it took.
And the question, worth asking of yourself and of whatever metric is currently telling you how well you’re doing:
Are we measuring how much got built — or whether the right thing got built?
I’m increasingly convinced those aren’t the same question. And I think the whole story of AI and software is going to turn on which one we decide to care about.