If you're using llms to shit out large swathes of unreviewed code you're doing it wrong and your project is indeed doomed to become unmaintainable the minute it goes down a wrong path architecturally, or you get a bug with complex causes or whatever.
Where llms excel is in situations like:
* I have <special snowflake pile of existing data structures> that I want to apply <well known algorithm> to - bam, half a days work done in 2 minutes.
* I want to set up test data and the bones of unit tests for <complicated thing with lots of dependencies> - bam, half a days work done in 2 minutes (note I said to use the llms for a starting point - don't generate your actual test cases with it, at least not without very careful review - I've seen a lot of really dumb ai generated unit tests).
* I want a visual web editor for <special snowflake pile of existing data structures> that saves to an sqlite db and has a separate backend api, bam 3 days work done in 2 minutes.
* I want to apply some repetitive change across a large codebase that's just too complicated for a clever regex, bam work you literally would have never bothered to do before done in 2 minutes.
You don't need to solve hard problems to massively increase your productivity with llms, you just need to shave yaks. Even when it's not a time save, it still lets you focus mental effort on interesting problems rather than burning out on endless chores.
johnfn · 47m ago
The article throws out a lot of potential issues with AI generated code, but doesn't stop for a moment to consider if solutions currently exist or might exist to these problems.
- Before LLMs, provided that your team did some of their due diligence, you could always expect to have some help when tackling new code-bases.
Has the author never worked on legacy code before?
- (oh, and it has forgotten everything about the initial writing process by then).
Does the author not think this can ever be solved?
- Because of the situation of a Bus Factor of zero that it creates, vibe coding is fundamentally flawed. That is, only until there is an AI that can generate 100% accurate code 100% of the time, and it is fed 100% accurate prompts.
Why does it require 100% accuracy 100% of the time? Humans are not 100% accurate 100% of the time and we seem to trust them with our code.
AntwaneB · 25m ago
Hello, author here. Thanks for your comment.
I agree with your first point, maybe AI will close some of those gaps with future advances, but I think a large part of the damage will have been done by then.
Regarding the memory of reasoning from LLMs, I think the issue is that even if you can solve it in the future, you already have code for which you've lost the artifacts associated with the original generation. Overall I find there's a lot of talks (especially in the mainstream media) about AI "always learning" when they don't actually learn new anything until a new model is released.
> Why does it require 100% accuracy 100% of the time? Humans are not 100% accurate 100% of the time and we seem to trust them with our code.
Correct, but humans writing code don't lead to a Bus Factor of 0, so it's easier to go back, understand what is wrong and address it.
If the other gaps mentioned above are addressed, then I agree that this also partially goes away.
No comments yet
ndneighbor · 44m ago
Yea, I found the article to be overly reductive. I work on a shared ownership codebase, which at times, I am not going to be able to pull the original author at all times when I work on my branch.
At least having a partner explain some aspects is a huge unlock for me. Maybe the OP shadowboxing a world with no humans, but no humans is already a status quo issue that my team and I face sometimes.
lovich · 24m ago
He’ll, have they never had to maintain applications where the source code was lost? I haven’t had to do it too often, and I wouldn’t claim I’m very good at it, but on more than a handful of occasions I have had to decompile binaries to figure out what the fuck it was doing before I could write a wrapper around it to try and mitigate its unfixeable issues
sfink · 16m ago
The author was just saying that this will become the norm, not the exception. Ok, not this bad -- we can at least expect to have access to the AI-generated code for at least a little while longer. (I can imagine a future where AI programming gets just robust enough that some early adopter types will take their whiteboard sketches and prompts and prose test case descriptions, generate the code, compile it to a binary, then throw out the code. It's more agile! You can tweak the spec slightly and just turn the crank again!)
raincole · 29m ago
> Why does it require 100% accuracy 100% of the time?
I've said this before, but I'd say it again: anti-AI people, instead of AI users, are usually those who expect AI to be magical panacea.
The vibe reminds me of some people who are against static typing because "it can't catch logical error anyway."
bgwalter · 22m ago
No, we treat it as a bureaucratic, distracting and infantile way of software engineering that does not work.
juancn · 37m ago
I think the article underestimates how much intent can be grasped from code alone. Even without comments.
Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.
We tend to tackle the same problems the same way. So how something is solved, tells you a lot about why, who and when it was solved.
Still, it's a valid point that much of the knowledge is now obscured, but that could be said too of a high employee churn organization.
sfink · 8m ago
> I think the article underestimates how much intent can be grasped from code alone. Even without comments.
I agree, the human thought process always ends up getting embedded in a which of several possible ways any one thing might be done. But it's still a process, and a vastly inferior one to having a knowledgeable person on hand. Reverse-engineering has up until now been reserved to times when it is necessary. (I mean, we all still do it, especially on legacy codebases, but it's not good for productivity at all.)
> Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.
I disagree with the parenthetical. That's what stands out to me the most about LLM code: there are definitely intentions embedded in the code, but they're a hodgepodge of different intentions all tangled up together. You can't infer much of anything from a small snippet, because the intention behind that snippet was likely relevant to a completely different origin codebase that was piled up into a compost heap to grow an LLM out of. It's actually harder to make sense of an LLM codebase because the intentions distract and confuse the reader -- just as with text, we implicitly assume that a generated artifact means the same thing as if a human wrote it, and it doesn't.
bigiain · 19m ago
> I think the article underestimates how much intent can be grasped from code alone.
That's very scale related.
I rarely have any trouble reading and understanding Arduino code. But that's got a hard upper limit (at least on the common/original Arduinos) of 32kB of (compiled) code.
It's many weeks or months worth of effort, or possibly impossible, for me to read and understand a platform with a hundred or so interdependent microservices written in several languages. _Perhaps_ there was a very skilled and experienced architect for all of that, who demanded comprehensive API styles and docs? But if all that was vibe coded and then dropped on me to be responsible? I'd just quit.
krrishd · 5m ago
Related premise / HN discussion from a bit ago - “AI code is legacy code from day one”:
It's potentially the opposite. If you instrument a codebase with documentation and configuration for AI agents to work well in it, then in a year, that agent will be able to do that same work just as well (or better with model progress) at adding new features.
This assumes your adding documentation, tests, instructions, and other scaffolding along the way, of course.
bigiain · 14m ago
I wonder how soon (or if it's already happening) that AI coding tools will behave like early career developers who claim all the existing code written by others is crap and go on to convince management that a ground up rewrite is required.
(And now I'm wondering how soon the standard AI-first response to bug reports will be a complete rewrite by AI using the previous prompts plus the new bug report? Are people already working on CI/CD systems that replace the CI part with whole-project AI rewrites?)
getnormality · 10m ago
This guy thinks bus factors of zero started with ChatGPT. Hahahahahaha. Adorable.
How many of you have asked about a process and been told that nobody knows how it works because the person who developed it left the company?
There was a blog post at the top of HN about this, like, yesterday.
I hate the current AI hype hothouse and everything it seems to be doing to the industry... but I couldn't help but laugh.
No comments yet
schlowmo · 38m ago
At least we also have LLMs to generate our status updates during outages of our SaaS products while groping around in the dark.
bigiain · 11m ago
This is why it's important to be experienced in a range of different SaaS and AI tools.
So that when one of your employers has a SaaS related outage, you can just switch to one of your other employers and keep working.
All hail the 100x AI assisted developers doing 10x jobs at 5 different companies at the same time!
danjl · 4m ago
The folks that think they can now suddenly program without any experience, and not need understand how their product works, are suffering from Dunning-Kruger syndrome. Actually, it is a much broader segment and includes product managers, executives, VCs and the general public.
fzeroracer · 38m ago
Unfortunately the corporate machine has been converging on a bus factor of 0. I've been part of multiple teams now where I was the only one holding knowledge over critical subsystems and whenever I attempted to train people on it, it was futile. Mainly because they would get laid off doing 'cost-savings measures'.
There were times where I was close to getting fed up and just quitting during some of the high profile ops I had to deal with which would've left the entire system inoperable for an extended period of time. And frankly from talking to a lot of other engineers, it sounds like a lot of companies operate in this manner.
I fully expect a lot of these issues to come home to roost as AI compounds loss of institutional knowledge and leads to rapid system decay.
bigiain · 5m ago
My guess? The AI companies will keep the free and $20/month plans to entice developers and their managers. They will have $200/month plans with bigger context windows to allow effective work on larger that toy codebases. But sooner or later companies with large scale projects are going to need a much larger context window, that _that_ will suddenly become a $200k/year/developer subscription. There's a lot of correlation between "institutional knowledge" and context window I think.
oompydoompy74 · 38m ago
By that same logic, if a project is documented so thoroughly that an agent could handle all the work, then the bus factor effectively becomes infinite.
jonny_eh · 42m ago
Everything you interact with on a daily basis is either natural, or designed by a human. Until now.
Where llms excel is in situations like:
* I have <special snowflake pile of existing data structures> that I want to apply <well known algorithm> to - bam, half a days work done in 2 minutes.
* I want to set up test data and the bones of unit tests for <complicated thing with lots of dependencies> - bam, half a days work done in 2 minutes (note I said to use the llms for a starting point - don't generate your actual test cases with it, at least not without very careful review - I've seen a lot of really dumb ai generated unit tests).
* I want a visual web editor for <special snowflake pile of existing data structures> that saves to an sqlite db and has a separate backend api, bam 3 days work done in 2 minutes.
* I want to apply some repetitive change across a large codebase that's just too complicated for a clever regex, bam work you literally would have never bothered to do before done in 2 minutes.
You don't need to solve hard problems to massively increase your productivity with llms, you just need to shave yaks. Even when it's not a time save, it still lets you focus mental effort on interesting problems rather than burning out on endless chores.
- Before LLMs, provided that your team did some of their due diligence, you could always expect to have some help when tackling new code-bases.
Has the author never worked on legacy code before?
- (oh, and it has forgotten everything about the initial writing process by then).
Does the author not think this can ever be solved?
- Because of the situation of a Bus Factor of zero that it creates, vibe coding is fundamentally flawed. That is, only until there is an AI that can generate 100% accurate code 100% of the time, and it is fed 100% accurate prompts.
Why does it require 100% accuracy 100% of the time? Humans are not 100% accurate 100% of the time and we seem to trust them with our code.
I agree with your first point, maybe AI will close some of those gaps with future advances, but I think a large part of the damage will have been done by then.
Regarding the memory of reasoning from LLMs, I think the issue is that even if you can solve it in the future, you already have code for which you've lost the artifacts associated with the original generation. Overall I find there's a lot of talks (especially in the mainstream media) about AI "always learning" when they don't actually learn new anything until a new model is released.
> Why does it require 100% accuracy 100% of the time? Humans are not 100% accurate 100% of the time and we seem to trust them with our code.
Correct, but humans writing code don't lead to a Bus Factor of 0, so it's easier to go back, understand what is wrong and address it.
If the other gaps mentioned above are addressed, then I agree that this also partially goes away.
No comments yet
At least having a partner explain some aspects is a huge unlock for me. Maybe the OP shadowboxing a world with no humans, but no humans is already a status quo issue that my team and I face sometimes.
I've said this before, but I'd say it again: anti-AI people, instead of AI users, are usually those who expect AI to be magical panacea.
The vibe reminds me of some people who are against static typing because "it can't catch logical error anyway."
Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.
We tend to tackle the same problems the same way. So how something is solved, tells you a lot about why, who and when it was solved.
Still, it's a valid point that much of the knowledge is now obscured, but that could be said too of a high employee churn organization.
I agree, the human thought process always ends up getting embedded in a which of several possible ways any one thing might be done. But it's still a process, and a vastly inferior one to having a knowledgeable person on hand. Reverse-engineering has up until now been reserved to times when it is necessary. (I mean, we all still do it, especially on legacy codebases, but it's not good for productivity at all.)
> Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.
I disagree with the parenthetical. That's what stands out to me the most about LLM code: there are definitely intentions embedded in the code, but they're a hodgepodge of different intentions all tangled up together. You can't infer much of anything from a small snippet, because the intention behind that snippet was likely relevant to a completely different origin codebase that was piled up into a compost heap to grow an LLM out of. It's actually harder to make sense of an LLM codebase because the intentions distract and confuse the reader -- just as with text, we implicitly assume that a generated artifact means the same thing as if a human wrote it, and it doesn't.
That's very scale related.
I rarely have any trouble reading and understanding Arduino code. But that's got a hard upper limit (at least on the common/original Arduinos) of 32kB of (compiled) code.
It's many weeks or months worth of effort, or possibly impossible, for me to read and understand a platform with a hundred or so interdependent microservices written in several languages. _Perhaps_ there was a very skilled and experienced architect for all of that, who demanded comprehensive API styles and docs? But if all that was vibe coded and then dropped on me to be responsible? I'd just quit.
https://news.ycombinator.com/item?id=43888225
This assumes your adding documentation, tests, instructions, and other scaffolding along the way, of course.
(And now I'm wondering how soon the standard AI-first response to bug reports will be a complete rewrite by AI using the previous prompts plus the new bug report? Are people already working on CI/CD systems that replace the CI part with whole-project AI rewrites?)
How many of you have asked about a process and been told that nobody knows how it works because the person who developed it left the company?
There was a blog post at the top of HN about this, like, yesterday.
I hate the current AI hype hothouse and everything it seems to be doing to the industry... but I couldn't help but laugh.
No comments yet
So that when one of your employers has a SaaS related outage, you can just switch to one of your other employers and keep working.
All hail the 100x AI assisted developers doing 10x jobs at 5 different companies at the same time!
There were times where I was close to getting fed up and just quitting during some of the high profile ops I had to deal with which would've left the entire system inoperable for an extended period of time. And frankly from talking to a lot of other engineers, it sounds like a lot of companies operate in this manner.
I fully expect a lot of these issues to come home to roost as AI compounds loss of institutional knowledge and leads to rapid system decay.