Something genuinely changed in the last couple of years, and it’s worth saying plainly before I complain about it. You can point an agent at a problem, describe what you want, and come back to running code. A small team can now produce, in a weekend, what used to take a department a quarter. Work that once required hiring, a budget, and a roadmap argument now takes an afternoon and a good prompt. I don’t want to be glib about that – it’s one of the most significant shifts in how software gets built that I’ve seen.

But every capability arrives with a bill, and this one’s doesn’t show up where you’re looking for it.

The cost doesn’t show up on the invoice Link to heading

When people tally the cost of AI in engineering, they look at the tooling line – the licenses, the per-seat cost of the assistant. That number is real and almost beside the point. The expensive costs arrive somewhere else.

Start with the one nobody sees coming: the tokens. Agentic development burns them at a rate with no intuitive relationship to the work being done – an agent can quietly run through $60,000 of tokens in a week, and you often have no idea that’s the figure until it’s spent. In the old world, cost was legible and arrived before the decision. “Two engineers, six months” is a number you can weigh and decline – and we declined things all the time on exactly that basis. AI inverts the order: the cost lands after the work, in a unit – tokens – almost impossible to attribute back to any particular thing you built. You used to kill an expensive feature on sight; now you find the expense in the rear-view mirror, stapled to something that may have delivered nothing. The price tag that used to be a gate is now a receipt.

The second cost is the understanding gap. Classic technical debt is code someone understood and chose to compromise – a person somewhere holds the context. What teams are shipping now is different: code that works, that passed review in the loose way generated code tends to get reviewed, and that no one fully understands. The mental model was never built, because the tool skipped the step where a human would have had to build one. John Gall noted that a complex system that works is invariably found to have evolved from a simple system that worked – and that a complex system designed from scratch never really works and can’t be patched into working. AI is exceptionally good at generating complex systems from scratch. The faster you generate, the wider the gap between what exists and what anyone understands.

The third cost doesn’t look like a cost at all. When building was slow, the expense was a filter: the friction forced a conversation about whether the thing was worth it. Remove the friction and you remove the conversation, and you end up carrying a sprawl of services and half-features nobody asked for, each of which still has to be understood, secured, and kept alive by someone. You didn’t decide to build all of it. You just never had to decide not to.

The question worth keeping on your desk Link to heading

Here’s the test I keep coming back to. The thing you just built with AI in an afternoon – if it had required you to hire twenty engineers, would you have done it?

If the answer is no – if you’d never have signed off on the headcount, the payroll, the two-year commitment – then why is it yes because the tool made the first version cheap? Producing it is the cheap part now; owning it is not. AI collapsed the cost of writing the code and did almost nothing to the cost of understanding it, maintaining it, operating it, and being accountable for it. We’re making twenty-engineer decisions with the deliberation we’d give a coffee order, because the part that used to hurt stopped hurting.

An old idea wearing new clothes Link to heading

All of this is one old problem in new clothes. I first came across Simon Sinek’s Start With Why in 2020, and I’ve returned to it more than almost any other idea in my working life. The premise is nearly too simple to respect on first hearing: most organizations can tell you what they do and how they do it, but very few can clearly say why – and the why is what should drive every decision beneath it.

It sounded a little neat at the time. It has aged into something urgent, because what these tools have handed every team is the most powerful how the industry has ever produced – and a powerful how is exactly what makes an absent why dangerous. When building was slow, a weak why got caught eventually; the cost surfaced it. When building is instant, a weak why ships before anyone thinks to ask the question.

Engineering has failed this way before Link to heading

None of the people who warned about this were talking about AI. They were describing the same failure, over and over, for forty years.

In 1986, Fred Brooks wrote No Silver Bullet, arguing that no single advance would deliver even a tenfold improvement in software within a decade. He split accidental complexity – the difficulty of expressing a solution – from essential complexity, the irreducible difficulty of the problem itself, and showed that every breakthrough only ever attacks the accidental kind. AI is the most impressive accidental-complexity solvent the field has produced: it writes the code, scaffolds the system, clears the boilerplate. What it cannot do is the essential part – decide what is worth building, and why. That difficulty hasn’t moved an inch. It’s still yours.

Peter Drucker put it more bluntly, decades earlier: there is nothing so useless as doing efficiently that which should not be done at all. He drew a sharp line between efficiency – doing things right – and effectiveness – doing the right things. AI is an efficiency engine of startling power, and efficiency aimed at the wrong target is just faster waste – now manufacturable at a volume Drucker never had to imagine.

The measurement trap has its own literature. Melissa Perri calls it the build trap: measuring success by outputs, the features you ship, rather than outcomes, the value they create. John Cutler named the symptom the “feature factory”; Joshua Seiden wrote a book arguing for outcomes over output. The lineage predates this moment; AI just pours accelerant on it, because output has never been this cheap. Eric Ries gave the antidote a name – validated learning, progress measured by what you’ve learned about whether to build a thing, not by how much you’ve built – and warned about achieving failure: flawlessly executing a plan to deliver something nobody wanted. AI makes prototypes effortless, which is genuinely useful, because a prototype is a cheap way to ask a question. The trap is that the AI prototype already looks like production, so it ships by default – not because anyone decided it was ready, but because deciding felt unnecessary. A prototype is supposed to be a question. AI is unnervingly good at making questions look like finished answers.

The big bet you can’t measure Link to heading

There’s a specific version of this that worries me most, because AI makes it newly tempting: the big-bang rewrite.

Joel Spolsky called rewriting from scratch “the single worst strategic mistake” a software company can make, pointing at Netscape, which burned three years rebuilding its browser and handed the market to Microsoft. Martin Fowler’s answer was the strangler fig: replace a system piece by piece, never in one big bang, precisely because the big bang delivers no value until it’s all done and stakes everything on a single cutover. For twenty years, the main reason teams resisted the big rewrite was that it was obviously, painfully expensive. AI removes the pain – and with it, the deterrent. The rewrite that was insane to attempt by hand is now a quarter’s work for an agent, which puts the worst idea in software back on the table, dressed as innovation.

And a big-bang rewrite is nearly impossible to judge. Ship small, incremental changes and you can attribute impact – this change moved that number. Replace everything at once and you’ve changed every variable simultaneously; you can no longer tell what helped, what hurt, or whether it paid for itself. You’ve traded a system you could reason about for one you can only hope about.

So sit with this before you green-light the rebuild: if AI could rewrite your entire platform in six months, and the most honest answer to “what will a user actually notice?” was “pages load 200 milliseconds faster” – would you do it? And if you did, how would you ever prove it was worth it?

What “success” was allowed to mean Link to heading

We’ve just watched a version of this play out in public. In May 2026, the team behind Bun – the JavaScript runtime, originally written in Zig – used AI agents to rewrite close to a million lines of it into Rust: roughly 6,700 commits in about six days. When it merged, 99.8% of the existing test suite passed and the binary got smaller. As a demonstration of raw capability it is staggering – nobody is hand-porting a million lines of systems code in a week – and it’s been widely held up as a triumph.

But Bun is not a product anyone buys. It’s a free, open-source runtime – there’s venture money and commercial ambition behind it, but the runtime itself is given away, and rewriting it carried no profit-and-loss line. That’s the only reason it gets to be called a success on the terms it’s being judged by. The benefits were almost entirely under the hood: a smaller binary, some leaks fixed, a codebase more people can contribute to. Real engineering wins – and exactly the kind a user will never notice or pay for. When the thing you ship isn’t sold, “the tests pass and the internals are nicer” is a fine definition of success, because there’s no customer for it to answer to.

Now change one variable. Suppose Bun were a commercial product with profit targets. Would anyone have signed off on that spend – and an AI rewrite at this scale is real money in tokens – to chase improvements most customers would never feel? Almost certainly not; someone would have asked what the money bought, heard “a tidier codebase our users can’t see,” and spent it where a customer would notice. Which is why “AI rewrote Bun in six days” is not the evidence it looks like that an AI rewrite of your revenue-generating system would succeed. There, success means something else entirely – not “the tests pass,” but “revenue moved, or cost fell, or a customer is better off, by more than this cost us.” Bun never had to clear that bar. You do.

And even on its own technical terms, “success” is working hard: the Rust port shipped with north of thirteen thousand unsafe blocks, in a language whose entire point is memory safety. The tests pass; the understanding gap is enormous – something that looks finished, measured against the one bar it could clear, quietly carrying a debt no one yet holds the model for.

Discipline doesn’t get a holiday Link to heading

Product teams that were, until recently, ruthless about exactly this – that demanded evidence before building, killed features that couldn’t justify themselves, treated “no” as a complete sentence – sometimes abandon all of it the moment “AI” is attached to the proposal. The rigor doesn’t fail so much as get suspended, as though the old questions are rude to ask of something this exciting. But the discipline you had before AI is precisely the discipline AI demands. Prioritization, evidence, measuring outcomes over output – I’ve argued before that activity is not output – none of it became optional. It became load-bearing.

There’s a version of this that comes dressed as good practice. Product spent a decade learning to build small, ship fast, and test – run the experiment, read the data, iterate. AI looks like that ethos with the friction stripped out, so it gets waved through under the same banner: it’s cheap, let’s just build it and find out. But what made the old experiment safe was that you knew its cost before you ran it. A two-week spike was two weeks. With AI, the cost of the build often isn’t knowable until the build is done – the tokens are spent in the act of finding out. “Cheap to try” quietly became “unknowable until tried,” and a team running on the old reflexes will burn a budget answering a question nobody decided was worth the price.

The product leaders who genuinely understand AI – and the best of them are getting there fast – don’t answer this by slowing down. They move the discipline back in front of the build, where it used to live, instead of discovering it afterward. Before a single token is spent, they insist on three things. A cost ceiling: the most we’ll spend to answer the question, and the number at which we stop. A value hypothesis: the outcome that would make it worth doing and how we’ll know – written down before the build, so “it works” can’t pass itself off as success. And a decision waiting at the end: what we’ll actually do with the result, including the nerve to throw the prototype away, so the experiment stays an experiment instead of shipping by default. None of that is a brake. It’s the difference between a product organization that uses AI on purpose and one that’s quietly used by it – and the leaders who get this right will outbuild the ones who mistook motion for progress.

Boards are often part of the pressure rather than the check on it. The fear of being left behind travels downward as a corrosive instruction – what’s our AI strategy? – which, by the time it reaches a team, has mutated into build something with AI so we can be seen building something with AI: the exact weak-why initiative this whole piece is about, manufactured on demand by the people whose job is to prevent it. The board’s role is not to demand motion; it’s to ask the uncomfortable question and sit through the silence after it. “We looked seriously at it and chose not to, and here’s why” is a mark of a healthy board, not a timid one.

Sensible usage, which is mostly unglamorous Link to heading

None of this is an argument against AI. I use it. My teams use it. The capability is real, it isn’t going away, and the organizations that refuse to touch it will lose to the ones that use it well. Using it well turns out to demand the same discipline good engineering leadership always did, just under more pressure.

Own what you generate. If you’re not willing to own the understanding, the maintenance, and the accountability for a piece of code, you’re not ready to ship it – however fast it appeared.

Apply your hiring bar to your building. The twenty-engineer test: if the value wouldn’t justify the people, the cheap start hasn’t changed the math, just hidden it.

Keep changes small enough to measure. Prefer incremental over big-bang even when AI makes the big bang feel free, because you can’t manage what you can’t attribute.

Make someone own the why. Every initiative should have one person who can say, in a sentence and without using the word “AI,” what it’s actually for.

AI has made producing software feel nearly free – the cost didn’t vanish, it just moved out of sight and arrives late. What it hasn’t done is make it free to be wrong, and it has quietly removed the friction that used to catch us being wrong before it got expensive. The constraint was never how fast we could build; it was whether we’d stop to ask why we were building it. That question just got easier to skip and more costly to skip at the same time. Ask it anyway.