yeah, i think the siren song of reducing developer cost and accelerating delivery is irresistible to boards, execs, managers, non-senior devs (all essentially semi-technical, even the nonexpert devs) but it is a mirage. The startups that over raised in the extended bubble are all drowning in tech debt and the game is to exit or get profitable faster than the tech debt compounds, it leads to a divergence in outcomes where you either build a google and buy your way out of the hole (“ revenue solves all problems”) or you don’t quite get there and your delivery ability crests and decays as the tech debt compounds above the threshold line that the company cash flow can service.
Vibe coding is going to exacerbate this - the growth can come faster, but the collapse point is accelerated correspondingly. If you plot this complexity out like we were taught in CS 101, lines of code will grow linearly, proportionate to the number of agents/devs, but the interconnectedness and therefore state space will explode polynomially without applying encapsulation and local reasoning techniques like functional programming. But we’ve aligned the models to use imperative languages (TS, Python, Java), essentially constraining the code models to specifically prevent the best code scaling techniques! And guaranteeing the emergent “spooky action at a distance” that is inherent to the computational structure of imperative languages.
And note that most companies don’t take flight like Google, instead they seek acquisition, and a lot of those acquisitions fail to integrate and get swimming, they are perhaps underwhelming compared to the sales pitch, to the extent that many start to look like a form of securities fraud? Tech debt is real, it’s just invisible to the balance sheet and therefore to boards and buyers. If it were properly accounted for, the entire IT sector would be revealed as completely underwater.
klabb3 · 1d ago
> but the interconnectedness and therefore state space will explode polynomially without applying encapsulation and local reasoning
I wish the complexity demon was this gentle. It's exponential generally – a single boolean flag can double the test/state space.
The only thing that really matters long term is taming complexity. Humans fail at this and that’s why large companies need to hire armies of big fixers and QA to play whack-a-mole with the symptoms rather than the causes.
LLMs make both tasks faster, but it also changes the balance between them. I would be wary of replacing a company of 5 wizards, 20 seniors and 100 juniors with 10000 juniors overnight.
dustingetz · 21h ago
do you think it’s really exponential in practice? i don’t know if i see that, and polynomial (growth in bugs per LOC) is enough to explain why all sufficiently large projects grind to a halt
dist-epoch · 1d ago
By the time the tech debt of the vibe code hits, new models will appear which can still handle it. And we are close to being able to point the model at the repo and ask it to "reduce the tech debt". Then it becomes a money problem - put the agents on a 24/7 reduce the code debt mission.
maaaaattttt · 1d ago
I think that's the bet many investors are making at the moment. And if it pays off, it will do so big times as it will be almost impossible to maintain a codebase without an LLM. Therefore making them indispensable for the company using/working on said codebase. If they continue to perform linearly from the point we are now, though, then the only option is to continue making better LLMs capable of comprehending the relative mess the previous one made. Which at the limit means betting on AGI.
If for some reason the progress doesn't come fast enough and too many people are making that bet, then developpers (the ones left) can expect even higher salaries than before...
dustingetz · 1d ago
The investors may be right, and yet, this is a collapse vector in “The Collapse of Complex Societies”, in one sentence, “societies collapse when they reach a point of rapidly declining marginal returns on their investments in problem solving capacity.” So we’d expect an outcome somewhere between “market dynamics will resolve this” and “war and/or violent revolution”
dgb23 · 1d ago
Why is producing all that waste and complexity necessary in the first place?
We often get distracted by benefits and forget to look at the costs. And we often overdo things to a degree where previous wisdom has to be re-discovered again and again.
Having experienced a couple of hype cycles, I learned that the sensible thing is to narrow down what the new thing is useful for specifically.
And all that's assuming that the prediction holds. I don't see any clear signs of whether the usefulness and precision is primarily a quantitative or qualitative issue.
dustingetz · 1d ago
If the cost per unit delivery (say LOC) grows something like polynomial due to interconnectedness, surely it is superlinear for even a state of art formal reasoning system let alone imperative langs, it will outstrip our ability to build energy infrastructure. If the cost growth is exponential due to state space explosion, it will outstrip the energy in the Sun.
How does HN think these factors will balance?
dist-epoch · 1d ago
Yet humans can handle and untangle spaghetti code without requiring fusion power plants. There is no fundamental reason why LLM would fail to do it too. And as they improve the code they produce is better architected. So the situation is improving at both ends.
dustingetz · 1d ago
humans cannot in any sufficiently large project, for example government contracts and the entire banking sector.
dist-epoch · 1d ago
They can. They are not allowed due to "reasons".
cadamsdotcom · 1d ago
It’s rational - the risk of breaking things by changing them outweighs the ongoing costs of keeping them the same - including developer sanity, unfortunately.
danielbln · 1d ago
An often overlooked point in these LLM vs human debates: the majority of humans are extremely fallible.
mrbald · 1d ago
I myself almost exclusively use LLMs as a scoping/pathfinding tool, an extremely powerful version of search engine and a ultimately knowledgeable sparring partner if you will, did not even dare tasking it to write production code (so o4-mini, not Claude)
cadamsdotcom · 1d ago
> The insight that reading code is harder than writing leads naturally to the insight that every line of code is tech debt.
> Lowering the cost of writing code was the thing that no engineering leader asked for, but it’s the thing we got.
Code review is even more crucial with LLMs writing code. Don’t merge until you fully understand the PR and what it’s doing.
Kamshak · 1d ago
In 2-3 years once this begins to matter for a new project you can probably just put the codebase into context and the "make it DRY" prompt will work. Already works with 2-3 files.
fhd2 · 1d ago
The usual "the models will improve a lot" narrative that I've seen in the majority of companies calling themselves an "AI company".
Could be true of course, fair bet to make.
Could also not be true, and I think as far as tech due diligence goes, an acquiring company or investor might want to play it safe.
But like I said, it's a fair bet to make - companies are essentially bets, and so are investments. As long as it's conscious and you like your odds, why not.
dustingetz · 1d ago
1/ this requires AGI not stochastic parrot - as the training dataset does not contain any successful instances of obtaining actual DRY at scale, so the agent will need to contribute novel research and essentially solve software engineering. It’s not 2-3 years out. And why should any result be aligned to how things work today, why not start over from the qbits and work our way up?
2/ The worst instances of coupling are between foreign systems where one is not in your control to change, or too high risk (such as banking) and prohibitively difficult to test all but the most incremental changes. So at some point you need to decide what error rate is acceptable in any tool assisted rewrite, where error rate is measured in death count and lawsuit liability.
spacebanana7 · 1d ago
I've used that kind of prompt successfully using codex with 04-mini.
mathieuh · 1d ago
Doesn't really work for me at the moment with 3.7 Sonnet.
If I point out redundancies it will fix them but just giving it an open-ended kind of directive hasn't been very successful in my experience.
fzeroracer · 1d ago
But what's the financial incentive to make it DRY? The LLM services your company pays for are incentivized to ensure the output is as long and verbose as possible because they can charge more. And from an engineers perspective it does not matter because no one is reading said code, or they're just asking the same LLM to tell you what the code does. And obviously more lines of code looks better to your execs.
There are a bunch of anti-patterns both in how these services are used and sold to you.
ivanche · 1d ago
> The LLM services your company pays for are incentivized to ensure the output is as long and verbose as possible because they can charge more.
At least for now you can make the ouput quite short, with 95+% code. I use this prompt for Claude Sonnet:
Communicate with direct, expert-level technical precision. Prioritize immediate, actionable solutions with minimal overhead. Provide concise, thorough responses that anticipate technical needs and demonstrate deep understanding. Avoid unnecessary explanations or formalities.
Key Communication Guidelines:
- Terse, no-nonsense language
- Assume high technical competence
- Immediate solution-first approach
- Speculative ideas welcome if flagged
- Prioritize practical implementation
- Technical accuracy over diplomatic language
- Minimal context, maximum information
The user has included the following content examples. Consider these when generating a response, but adapt based on the specific task or conversation:
<userExamples>
[Technical Query Response]
Quick solution for async race condition in Python:
```python
from threading import Lock
class SafeCounter:
def __init__(self):
self._lock = Lock()
self._value = 0
def increment(self):
with self._lock:
self._value += 1
```
[Problem-Solving Approach]
Unexpected edge case in data processing? Consider implementing a robust error handling strategy with dynamic fallback mechanisms and comprehensive logging.
</userExamples>
dist-epoch · 1d ago
> The LLM services your company pays for are incentivized to ensure the output is as long and verbose
The incentive is to avoid you moving to a competing LLM provider which has short and concise output.
See how a large numbers of devs switched from Claude to Gemini 2.5 because the generated code was "better".
Providing a bad service is not a competitive advantage.
fzeroracer · 1d ago
You seem to have missed a core point. I, as a developer, do not have the ability to make that change for whatever company I work for. Otherwise I would've canned shit like JIRA and Confluence instantly.
The 'competing' LLM providers does not matter. Companies will sign on with the big players.
ramon156 · 1d ago
Zed agents in Ask mode are amazing. Ask it a question and it can guide you to at least the right direction. It helps keep the motivation going
naiv · 1d ago
So the costs for Github actions cpu power should now be a limitation for test coverage?
Vibe coding is going to exacerbate this - the growth can come faster, but the collapse point is accelerated correspondingly. If you plot this complexity out like we were taught in CS 101, lines of code will grow linearly, proportionate to the number of agents/devs, but the interconnectedness and therefore state space will explode polynomially without applying encapsulation and local reasoning techniques like functional programming. But we’ve aligned the models to use imperative languages (TS, Python, Java), essentially constraining the code models to specifically prevent the best code scaling techniques! And guaranteeing the emergent “spooky action at a distance” that is inherent to the computational structure of imperative languages.
And note that most companies don’t take flight like Google, instead they seek acquisition, and a lot of those acquisitions fail to integrate and get swimming, they are perhaps underwhelming compared to the sales pitch, to the extent that many start to look like a form of securities fraud? Tech debt is real, it’s just invisible to the balance sheet and therefore to boards and buyers. If it were properly accounted for, the entire IT sector would be revealed as completely underwater.
I wish the complexity demon was this gentle. It's exponential generally – a single boolean flag can double the test/state space.
The only thing that really matters long term is taming complexity. Humans fail at this and that’s why large companies need to hire armies of big fixers and QA to play whack-a-mole with the symptoms rather than the causes.
LLMs make both tasks faster, but it also changes the balance between them. I would be wary of replacing a company of 5 wizards, 20 seniors and 100 juniors with 10000 juniors overnight.
We often get distracted by benefits and forget to look at the costs. And we often overdo things to a degree where previous wisdom has to be re-discovered again and again.
Having experienced a couple of hype cycles, I learned that the sensible thing is to narrow down what the new thing is useful for specifically.
And all that's assuming that the prediction holds. I don't see any clear signs of whether the usefulness and precision is primarily a quantitative or qualitative issue.
How does HN think these factors will balance?
> Lowering the cost of writing code was the thing that no engineering leader asked for, but it’s the thing we got.
Code review is even more crucial with LLMs writing code. Don’t merge until you fully understand the PR and what it’s doing.
Could be true of course, fair bet to make.
Could also not be true, and I think as far as tech due diligence goes, an acquiring company or investor might want to play it safe.
But like I said, it's a fair bet to make - companies are essentially bets, and so are investments. As long as it's conscious and you like your odds, why not.
2/ The worst instances of coupling are between foreign systems where one is not in your control to change, or too high risk (such as banking) and prohibitively difficult to test all but the most incremental changes. So at some point you need to decide what error rate is acceptable in any tool assisted rewrite, where error rate is measured in death count and lawsuit liability.
If I point out redundancies it will fix them but just giving it an open-ended kind of directive hasn't been very successful in my experience.
There are a bunch of anti-patterns both in how these services are used and sold to you.
At least for now you can make the ouput quite short, with 95+% code. I use this prompt for Claude Sonnet:
Communicate with direct, expert-level technical precision. Prioritize immediate, actionable solutions with minimal overhead. Provide concise, thorough responses that anticipate technical needs and demonstrate deep understanding. Avoid unnecessary explanations or formalities.
Key Communication Guidelines: - Terse, no-nonsense language - Assume high technical competence - Immediate solution-first approach - Speculative ideas welcome if flagged - Prioritize practical implementation - Technical accuracy over diplomatic language - Minimal context, maximum information
The user has included the following content examples. Consider these when generating a response, but adapt based on the specific task or conversation:
<userExamples> [Technical Query Response] Quick solution for async race condition in Python:
```python from threading import Lock
class SafeCounter: def __init__(self): self._lock = Lock() self._value = 0
```[Problem-Solving Approach] Unexpected edge case in data processing? Consider implementing a robust error handling strategy with dynamic fallback mechanisms and comprehensive logging. </userExamples>
The incentive is to avoid you moving to a competing LLM provider which has short and concise output.
See how a large numbers of devs switched from Claude to Gemini 2.5 because the generated code was "better".
Providing a bad service is not a competitive advantage.
The 'competing' LLM providers does not matter. Companies will sign on with the big players.