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?

If your mental picture of AI-assisted development is still “will it produce something that works,” you’re arguing about something that has already been settled. It can write the code, it has been able to for a while, and it gets noticeably better every few months.

The question that actually decides whether these tools help or hurt on software that has to last is a different one, and a much harder one. Once the AI has written something, how do you know you can trust it enough to keep it?

That sounds like a small distinction. It isn’t. It’s the whole game, and it gets a fraction of the attention, because it’s a lot less exciting than watching a feature appear out of a prompt.

Let me explain why it matters so much, and then what I’ve actually found that works.

Why trust is the bottleneck, not generation

Think about the difference between a weekend project and a system a lot of people depend on for a long time.

On the weekend project, what happens if the AI writes something subtly wrong? You find out fast, the blast radius is tiny, and fixing it costs you an afternoon. Trust barely matters, because being wrong is so cheap. You can just try things.

On a system that has to keep working (real users, real data, years of accumulated decisions) the math flips completely. A subtly wrong change can sit there quietly and surface months later as corrupted data, a security hole, or an architectural decision that makes everything after it a little harder. Being wrong stops costing an afternoon and starts costing something large, delayed, and often impossible to trace back to the moment it was introduced.

And here’s the trap: the AI is equally confident in both cases. The code comes back plausible, well-structured and confident-looking whether it’s right or catastrophically wrong, because the fluency is constant and the correctness is not. So on serious software the effort changes kind rather than owner — out of typing and into judgment. Out of “writing the code” and into “verifying I can trust the code,” which on a complex system was often the harder and more expensive half to begin with.

So the naive version of AI-assisted development (prompt, accept, ship, repeat) doesn’t scale to high-stakes work, not because the code is bad, but because it quietly transfers unverified risk into your system faster than you can check it. You end up with more to review, less context on each piece (you didn’t write it), and a tool that is cheerfully generating in whatever direction you pointed it — including off a cliff.

The teams that will use these tools well on software that matters aren’t the ones with the best prompts. They’re the ones who build an environment where the AI’s output can be trusted by construction and verified cheaply, so that going fast doesn’t mean flying blind.

Here’s what that has actually looked like for me: four things, none of which involve writing better prompts.

Make the channel narrow

The first is resisting the urge to let the AI touch everything freely, and instead making it work through a narrow, well-defined channel.

The wider and vaguer the surface you let it operate on, the more places it can be subtly, invisibly wrong. But what if you route its work through a constrained interface, a strict configuration schema, a defined contract, a small set of shapes the output is allowed to take? Then a whole class of mistakes becomes impossible rather than merely unlikely, and the constraint does some of the checking for you.

This is just good engineering, honestly, and we’ve always known that narrow interfaces contain the blast radius. AI raises the stakes, because now you have a fast, confident, tireless thing producing code, and the constraint is what keeps its confidence from becoming your problem. A narrow channel turns “I have to carefully review everything it could possibly have done” into “it can only do things of a shape I’ve already decided is safe.”

Make the changes cheap to review

The second is the one that has changed my workflow the most, and it’s less about the AI than about what surrounds it.

Why do people either white-knuckle every AI edit or, more often, quietly stop reviewing them? Not because they stopped believing in review. Reviewing is expensive and tedious, and under time pressure the review is the thing that silently gets skipped. And an unreviewed AI change on a serious system is exactly the unverified risk we’re trying to avoid.

So the highest-leverage thing I’ve done is make the review cheap and immediate. I let the AI edit fairly freely, and I can loosen the reins precisely because I see every change it made as a clean visual diff and can go through them quickly, hunk by hunk. Because the review is fast, I actually do it — not every line, but anywhere a mistake would be expensive. Which is the whole point: the goal was never to review less, it was to make reviewing cheap enough that I stop cutting corners. Pair that with frequent, small commits and you get a genuine balance — the speed of AI generation on one side, the review-and-verify discipline I actually want on the other, held together by the fact that checking its work costs me almost nothing.

The insight underneath it: the speed of AI development is only safe if the speed of review keeps up. Invest in making the review effortless and you can safely let the generation run fast. Skip that, and speed just becomes unverified risk arriving faster.

Let evidence do the trusting, not your eyes

The third is verification you don’t have to perform by hand: tests, and increasingly, AI-run tests.

Eyeballing a diff catches a lot, but not everything. Does this change actually behave correctly? Human review of that question is both fallible and exhausting. The more of it you can turn into something automated, a check that passes or fails on its own, the more your trust is grounded in evidence rather than vigilance. Lately I’ve found real value in having the AI run tests directly against my local development environment as part of the loop: it makes a change, exercises it, and shows me whether it actually works, not just whether it looks right. That isn’t the only testing I do, and it doesn’t replace my own judgment, but semi-automating that verification layer means a whole class of “looks fine, is broken” problems gets caught by the process instead of by luck.

The principle: trust should be earned by evidence, not extended on the strength of confident-looking output. Every piece of verification you can automate is a piece of trust you no longer have to grant on faith.

Make suspicion a move, not a mood

The last is one I used to describe as a posture. I’ve come to think that’s exactly what’s wrong with it.

The instinct is right. When the AI produces something and it looks clean and the change seems small and everything appears to just work, that is the moment to get more careful, not less. Some of the worst problems hide behind output that looks too easy.

But look at what I argued two sections ago about review. People don’t stop reviewing because they stopped believing in it. They stop because it’s expensive, so under pressure it silently gets skipped. I don’t get to make that argument about review and then quietly exempt suspicion from it. Vigilance is a mood, and moods don’t survive a busy Thursday.

And it fails at the worst possible moment. The dangerous point isn’t when the AI hands back something obviously strange (you catch that). It’s when the change works. Once the thing you set out to do is done, the attention attached to checking it evaporates, because finishing is what tells your brain to stop. Success is what switches the suspicion off.

So what do you do with an instinct that’s right but can’t be relied on? What I actually practice is a move rather than a feeling. When a change comes back smaller or cleaner than I expected, I make the AI account for it: this is so minimal it’s almost concerning — walk me through why this actually works. Not because I think it’s wrong. Because I want the reasoning on the table where I can see it, and because I don’t trust myself to remember to want that at five o’clock on a Thursday.

It’s the ordinary discipline of anyone responsible for a system that matters, with one addition I’ve earned the hard way: the tool’s confidence is not evidence, and neither is my own sense that I’m being careful. Only the verification is.

What this actually is

Step back and notice what the narrow channel, the cheap review, the automated tests and the forced accounting have in common. None of them is about getting more out of the AI. They’re all about being able to trust what it gives you: preventing whole classes of errors, making verification so cheap you actually do it, grounding trust in evidence instead of appearances, and refusing to let confident output stand in for correct output.

That reframes the whole skill. The valuable thing isn’t prompting, which is easy and getting easier. The valuable thing is judgment about verification: knowing where the blast radius lives, what “correct” means for this system, which checks can be automated and which can’t, and which clean-looking answers deserve a second look. Where does that judgment come from? Not from the tool, but from having been responsible for software that had to keep working, and from paying attention to how it broke.

Which leads to the thing I keep coming back to:

As these tools get better at writing code, the scarce skill isn’t writing code, and it isn’t prompting either. It’s building the environment that lets you trust what they wrote — and being the person who can tell when the confident, clean-looking answer is quietly wrong.

So what would change my mind? The whole claim rests on one condition: that a human is still the one who ships. If verification itself ever becomes something you can hand off, a checker reliable enough to certify correctness rather than just flag suspects, then this is a skill with a shelf life like plenty of others. I don’t see that coming; the failure modes I run into today are the same ones as two years ago, produced faster and phrased more convincingly. But that’s the seam, and it’s where I’d look first if I’m wrong.

Until then, I don’t think that skill is going away, and if anything the better the tools get, the more it’s worth. But it’s a strange, hard-to-measure kind of value: the disasters you prevented, the risk you didn’t take on, the review you made cheap enough to actually do. Easy to feel. Hard to point at. Worth building anyway.

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.