One of the most common claims about LLMs and AI agents is that they'll dramatically reduce the cost of software development. Instead of hiring more engineers, you can simply assign a task to a model and have it completed in minutes.
I think there's a lot of truth to that.
But there's one important caveat.
How technical debt used to scale
For years, the growth pattern of many large software projects looked something like this:
Technical debt → slower development → larger engineering teams → more communication overhead → more regressions → even more technical debt.
As systems became more complex, companies hired more engineers. But every additional team increased coordination costs, introduced more communication paths, and gradually slowed development.
Technical debt never disappeared.
Companies simply paid for it with more people.
What changed with LLMs
LLMs don't eliminate the problem.
They change the price of one of the resources.
Instead of hiring five more engineers, a company can now "hire" thousands of times more compute.
When a model struggles, we increase the context window, add more agent loops, switch to a larger model, or simply regenerate the solution multiple times.
This can preserve development velocity – for a while.
But the underlying problem remains.
LLMs don't reduce system complexity.
I'd put it this way:
We used to pay technical debt with people. Now we can pay for it with tokens. The debt hasn't gone away – it has simply changed currency.
Why development still gets more expensive
Several factors push us toward the same outcome.
Context becomes increasingly expensive
As projects grow, models need more files, dependencies, business rules, and historical context to make correct changes.
Eventually, the cost of solving a task isn't driven by the task itself.
It's driven by the cost of understanding the system.
Understanding becomes harder
LLMs perform remarkably well in clean, well-structured codebases. But do many enterprise systems really meet these standards?
When a project is full of massive services, circular dependencies, hidden side effects, and years of architectural compromises, the model has to spend far more computation simply figuring out what's happening.
At the same time, the probability of mistakes increases.
Verification becomes the bottleneck
Even if code is generated in seconds, it still has to be reviewed, tested, and safely integrated. If the architecture is poor, the cost of verification starts growing faster than the speed of generation.
That's why generating code faster doesn't automatically mean shipping software faster.
Regressions don't disappear
If a system lacks modularity and strong test coverage, AI can introduce regressions even faster than humans.
The reason is simple. It produces much more code per unit of time.
The more changes you make to a complex system, the greater the chance that something breaks.
Why the problem is harder to notice
This is where the AI era differs from previous generations.
Before, companies were constrained by hiring budgets and the number of available engineers.
Today, the constraint is less visible.
Instead of expanding the team, organizations gradually increase spending on inference, larger context windows, agent loops, repeated generations, automated testing, and additional validation.
From the outside, productivity appears to remain high. In reality, the cost of each additional feature quietly increases.
The problem hasn't disappeared. It's simply better disguised.
The real scarcity in the AI era
The most interesting conclusion has little to do with token costs.
The real scarce resource isn't code generation.
It's architectural entropy.
LLMs scale code production incredibly well.
They do very little to reduce the complexity of the system itself.
And once a system becomes too complex for humans to understand, it gradually becomes too complex for AI as well.
That's when the cost of every new change starts growing – not linearly, but exponentially.
At that point, it doesn't matter whether you're measuring costs in developer salaries or millions of burned tokens.
A possible law of the AI era
I'd summarize it like this:
Any technical debt that once required linear growth in engineering headcount will now first require linear growth in token consumption – and eventually lead to the same outcome: an exponential increase in the cost of change. The only difference is that the limiting factor shifts from the number of engineers to the amount of compute required to understand the system.
If this hypothesis is correct, then the biggest competitive advantage in the AI era won't be generating code faster.
It will be maintaining an architecture that remains simple enough for both humans and AI to understand.
That, for MHO more than raw coding speed, may become the true bottleneck of software development over the next decade.
Top comments (1)
This matches something I've felt but never put into words, messy code used to cost you in engineer-hours, now it costs you in tokens, since the AI has to re-read the mess every time, same tax, different currency and it's easier to ignore now. A messy codebase used to mean "we need to hire" - visible, budgeted. Now it's just a bigger API bill, and nobody connects it back to the architecture.
Have you noticed this directly, some messy part of your codebase that's clearly more expensive to work in with AI than the clean parts?