The Rise of Wasteful Resources

We used to be proud of making things small.

Smaller binaries. Faster queries. Fewer allocations. A page that loaded in under a second on a bad connection. We measured it, argued about it in code review, and bragged about it afterwards.

Somewhere in the last two years that pride quietly disappeared.

Today the default answer to almost any problem is to throw more at it. More tokens. More context. More agents running in parallel. More regenerated files. More compute that nobody sees and nobody counts.

And almost nobody seems to care. Call it what it is: AI waste.

We used to brag about bytes

The Apollo Guidance Computer flew people to the Moon with roughly 4 KB of erasable memory and about 72 KB of read-only rope memory. Every word of it was argued over.

The demoscene built an entire culture around constraints. People wrote complete audiovisual productions that fit in 64 KB, then in 4 KB, just to prove it could be done.

Game developers squeezed whole worlds onto cartridges. Database people spent days shaving milliseconds off a query because it ran a million times a day. Frontend engineers fought over every kilobyte of JavaScript because they knew someone on a slow phone was paying for it.

None of that was vanity. Optimization was respect. Respect for the machine, for the user, for the person paying the bill, and for the engineer who would maintain the code next year.

Doing more with less was the craft.

Now the answer is “throw more at it”

Look at how a lot of work gets done now.

• An agent rewrites an entire file to change one line.
• A whole repository gets pulled into context to fix a typo.
• Five agents attempt the same task in parallel, four results get thrown away.
• A language model is called to format a date, parse JSON or check whether a string is empty.
• Tests fail, so the model tries again. And again. Until something is green.
• A 300-line abstraction appears where a ten-line function would have done the job.

Each of these is small. Each is easy to justify in the moment. Together they describe an engineering culture that has stopped asking the most basic question we used to ask about everything: what is the least this actually needs?

I wrote before about 200,000 lines of AI code that disappeared without anything breaking. That was the waste you can see. The waste you cannot see is bigger.

Why nobody cares about AI waste

It is not that engineers got lazy overnight. The incentives changed.

The cost is hidden. A flat monthly subscription makes every extra token feel free. The bill for the compute lands somewhere else, in someone else’s data center, on someone else’s balance sheet. You never see it, so you never optimize it.

We reward output, not efficiency. Teams celebrate how much got shipped, how many pull requests were opened, how many lines were generated. I have argued that lines of code is the wrong way to measure AI productivity. Measuring volume quietly rewards waste.

“It is cheaper than my time.” Sometimes that is true. Burning a few cents of compute to save an hour of a senior engineer is a good trade. But it has become a reflex instead of a decision. Nobody checks whether it is still true at a thousand requests a minute.

The abundance feels permanent. When something has always been available, nobody builds the habit of measuring it.

The bill always arrives

Waste does not disappear because you cannot see it. It moves.

It shows up as latency, when the feature that called a model three times in a row feels sluggish to users. It shows up as cost, the moment a prototype becomes a product and the usage curve goes up. I have seen how much changes when you treat model calls as a budget instead of a reflex, which is why something as simple as caching embeddings can save real money.

It shows up as complexity. Generated code that nobody fully understands is code somebody will have to understand later. Complexity is never eliminated, it is only relocated, and waste is one of the places it hides.

It shows up outside the codebase too. Every unnecessary call runs on real hardware that needs real electricity and real cooling. At the scale the whole industry now operates, that stops being an abstraction. And the economic side of this shift is bigger than any one team, as I explored in Is AI quietly contracting the world economy?

The most expensive cost is the quietest one. A generation of engineers is growing up without ever learning to measure. They have never profiled a slow endpoint, never counted queries on a page, never asked what a feature costs to run. That skill does not come back the day you need it.

How to cut AI waste: what optimization looks like now

I am not arguing for hand-tuning assembly or refusing to use AI. The tools are genuinely useful. The point is to use them deliberately.

• Deterministic problems get deterministic code. If a regular expression, a SQL query or a ten-line function solves it, do not call a model.
• Right-size the model. The biggest model is not the default. Most tasks do not need it.
• Edit, do not regenerate. Small diffs instead of rewritten files. Narrow context instead of the whole repository.
• Cache what repeats. Embeddings, summaries, classifications. If you computed it once, keep it.
• Measure it like we measured queries. Tokens per feature, calls per request, cost per user. Put it on the dashboard next to latency.
• Ask the old question. Would I write it this way by hand? If not, why is it acceptable when a model does it?

None of this is new. It is the same judgment that always separated good engineering from merely working code. It just moved to a different layer, the one I called the middle loop, where engineers decide what the machine should do and check what it actually did.

Efficiency is still a craft

Constraints made us better engineers. They forced us to understand the problem before we threw resources at it.

Abundance does the opposite. It lets us skip the understanding.

The best engineers I know still ask the question nobody seems to ask anymore: what is the least this needs? Not because compute is scarce, but because the answer tells you whether you actually understand what you are building.

Waste used to be a sign of a junior engineer. Now it is a default setting.

It does not have to be.

Have you noticed this shift in your team? What is the most wasteful AI pattern you have seen this month?