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.
> * 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 would naively think that, as did I, but I've tested it against several big name models and they are all eventually "lazy", sometimes make unrelated changes, and worse as the context fills up.
On a small toy example they will do it flawlessly, but as you scale up to more and more code that requires repetitive changes the errors compound.
Agentic loops help the situation, but now you aren't getting it done in 2 minutes because you have to review to find out it wasn't done and then tell it to do it again N times until it's done.
Having the LLM write a program to make the changes is much more reliable.
> Having the LLM write a program to make the changes is much more reliable.
I ended up doing this when switching our 50k-LOC codebase to pnpm workspaces, and it was such a good experience. It still took me a day or two of moulding that script to get it to handle the dozens of edge cases, but it would have taken me far longer to split things up by hand.
I still feel like I am under-using the ability of LLMs to spit out custom scripts to handle one-off use-cases.
Yeah was thinking about this recently. A semantic patch is more reliable, but prompting an ai might be easier. So why not prompt the ai to wrote the semantic patch.
I like the spirit of these, but there are waaaay more. Like you only mentioned the ones for professional and skilled coders who have another option. What about all the sub-examples for people all the way from "technically unskilled" to "baby-step coders". There's a bunch of things they can now just do and get in front of ppl without us.
Going from "thing in my head that I need to pay someone $100/h to try" to "thing a user can literally use in 3 minutes that will make that hypothetical-but-nonexistent $100/h person cry"... like there is way more texture of roles in that territory than your punchy comment gives credit. No one cares is it's maintainable if they now know what's possible, and that matters 1000x more than future maintenance concerns. People spend years working up to this step that someone can now simply jank out* in 3 minutes.
* to jank out. verb. 1. to crank out via vibe-coding, in the sense of productive output.
The fact that people could make excel monstrosities has never really been a real threat to the job security of programmers. IMO it increased it. LLMs are the new excel
Agreed. Video game idea that’s been in my head for years, but not sure if it’s actually fun? Too lazy to sit down for a few days and make it. Went back and forth with an llm for 30 mins and I had more of a game than was even in my head.
I agree with your comment but I wanted to share something that gave me a good chuckle the other day. I had asked claude to write some unit tests that, after reviewing, were sound and actually uncovered a bug in the code-under-test that I had written. When I pointed this out, claude had decided that to make the unit test pass, it would not patch the bug but it would simply not exercise the failing unit test LOL! Good times.
But yeah, LLM are not good at defining requirements, architectures, or writing a spec to the requirements. They are good a contained, bite sized asks that don't have much implications outside the code it writes.
There's also a middle ground, where you have the AI generate PR reviews and then review them manually. So that 2 minutes of code you spat out (really more like 5-10 using CC) takes another hour or three to review, and maybe 5 to 10 more commits before it's merged in.
I've done this successfully on multiple projects in the 10-20k LOC, ~100 file area - fully LLM generated w/ tons of my personal feedback - and it works just fine. 4/5 features I implement it gets pretty close to nailing from the spec I provide and the work is largely refactoring. But the times it doesn't get it right, it is a slog that could eat the better part of a day. On the whole though it probably is a 3-5x speedup.
I'm a little less confident about doing this on projects that are much bigger... then breaking things up into modules begins to look more attractive.
It's definitely a middle ground, but PR reviews, are not perfect. So it's easy to miss a lot of things and to have a lot of extra baggage. From reviewing code it's not always easy to tell exactly what's necessary or duplicate. So I agree, this is a middle ground of using LLMs to be more productive. Removing one bad line of code is worth adding a hundred good lines of code.
Scaffolding is another area where LLM's work great.
I want to create a new project using framework XYZ. I already know how to do it, but I don't remember how to set up it since I only do that once, or I don't know how to set up a class that inherits from the framework because I usually just copy the other from another class in the same project. I can simply tell the bot to write the starting code and take it from there.
The sad thing is for a LOT of use cases an LLM is completely unnecessary. Like why do I even need an LLM for something like this? Why can't I just download a database of code examples, plug it into a search engine that apppears in the sidebar, and then just type "new project XYZ" or "new class XYZ.foo" to find the necessary snippet? A lot of NPM frameworks have a set up script to get you started with a new project, but after that you are practically forced to use Google.
It's crazy that a problem that could be solved so easily with a local file search has been ignored for so long and the only solution has been something impossibly inefficient for the problem it's supposed to solve.
As long as the LLM is up to date, or you really know the framework / tech well or you will be in a fair amount of pain with little understanding of how to reconcile what it’s got wrong.
> If you're using llms to shit out large swathes of unreviewed code you're doing it wrong
> bam, x days work done in 2 minutes
This is a bit of a misrepresentation, since those two minutes don’t account for the reviewing time needed (nor prorperly, which vastly exceeds that time. Otherwise you end up in the situation of “doing it wrong” described in your first paragraph.
The implication with that example was it's some editor thing for use during the dev process separate from the actual product, so it doesn't matter if it's disposable and unmaintainable as long as it does the thing you needed it for. If the tool becomes an integral part of your workflow later on you stop and do it properly the second time around.
It’s not a misrepresentation, they’re saying the time it would take to write the code has been reduced to two minutes, not the reviewing and everything else (which still takes just as long)
Still fleshing out this idea, but it feels recently like LLMs are helping me "throw the first one away". Get the initial starting momentum on something with the LLM, continue to iterate until it mostly works, and then go in and ruthlessly strip out the weird LLMisms. Especially for tedium work where nothing is being designed, it's just transformations or boilerplate.
It's like artificial intelligence isn't intelligent at all but rather semi-useful for tedious, repetitive and non creative tasks. Who would have thought.
What's interesting is that I wouldn't really call any of the things you list software development. With the exception of the "testing starting point", they're mostly about translating from one programming language/API to another. Useful for sure, but not quite "the future of programming". Also, they all sound like the kind of thing that most "basic" models would do well, which means that the "thinking" models are a waste of money.
Finally, the productivity boost is significant from the perspective of the programmer, but I don't know how big it is from the perspective of the employer. Does this significantly shorten time-to-market?
> work you literally would have never bothered to do before done in 2 minutes.
That has been a nice outcome I didn't expect. Some of the trivial "nice to haves" I can get done by Claude, stuff I just don't have time for.
To your other points I agree as well, I think what's important isn't so much stuffing the context with data, but providing the context with the key insights to the problem you have in your head.
In your first example, perhaps the insight is knowing that you have a special snowflake data structure that needs to be explained first. Or another example is properly explaining historical context of a complex bug. Just saying "hey here's all the code please fix this error" yields less good results, if the problem space is particularly complex.
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.
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.
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
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.
> 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.
But this already exists! At work, our code is full of code where the original reasoning for the code is lost. Sometimes someone has forgotten, sometimes the person who wrote it is no longer at the company any more, and so on.
> 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.
But there are plenty of instances where I work with code that has a bus factor of 0.
The conclusion of your article is that vibe coding is "fundamentally flawed". But every aspect you've described about vibe coding has an analog in normal software engineering, and I don't think you would claim that is "fundamentally flawed".
Document. Whenever a member of the team leaves, you should always make them document what is in their head and not already documented (or even better, make documenting a required part of normal development).
The thing to understand is that every (new) AI chat session is effectively a member entering and leaving your team. So to make that work well you need great onboarding (provide documentation) and great offboarding (require documentation).
No, it's not a wish nor an expectation for a magical panacea, but logic.
The only code you do not have to maintain is code that is fully perfect (100% accurate, 100% of the time). Bus factor zero is a problem for code that needs to be maintained. If AI is short of the 100%, then it is generating code that needs to be maintained. Ergo, a bus factor zero will be a problem for AI generated code (until such time as that code is perfect).
I recently joined a team with a very messy codebase. The devs were long gone, and even the ones maintaining it didn’t really understand large parts of the code. The bus factor was effectively zero.
What surprised me was how useful AI was. It helped me not only understand the code but also infer the probable intent behind it, which made debugging much faster. I started generating documentation directly from the code itself.
For me, this was a big win. Code is the source of truth. Developer documentation and even shared knowledge are often full of bias, selective memory, or the “Chinese whispers” problem where the story shifts every time it’s retold and never documented. Code doesn’t lie, it just needs interpretation. Using AI to cut through the noise and let the code explain itself felt like a net positive.
As a manager, I am considering to enforce a rule on my team that -- no README in any repo should ever go stale ever again --> it should be near-trivial for every dev to ask Claude Code to read the existing README, read/interpret the code as it practically currently stands, read what's changed in the PR, then update the README as necessary. This does not mean Claude will be perfect or that engineers don't need to check that its summaries make sense (they do, and the human is always accountable for the changes at the end of the day); but this does mean that, the typical amount of laziness that we are all guilty of often, should not be eliminated as a reason as to why READMEs go stale.
Why have such a rule if at any moment of time the LLM could update the readme ad hoc? Btw, your ingested readmes will affect your LLM's code generation and I made the observation that more often than not it is better to exclude the readmes from the context window.
The Bus Factor was an issue long before LLM-generated code. Very few companies structure work to allow a pool of >1 individuals to understand/contribute to it. What I found is -- when companies are well structured with multiple smart individuals per area, the output expectation just ends up creeping up until again there is too much to really know. You can only get away from this with really good engineering management that specifically tries to move people around the codebase and trade-off speed in the process. I have tried to do this, but sometimes pressure from the stakeholders for speed is just too great to do it perfectly.
Shameful plug, i've been writing a book on this with my retrospective as a CTO building like this. I just updated it so you can choose your price (even $0) to make this a less shameful plug on HN: https://ctoretrospective.gumroad.com/l/own-your-system
I dont think anyone has the perfect answer, yet, but LLM-built systems arent that different from having the system built by 10 diff people on eLance/Upwork/Fiverr...so the principles are the same.
The Bus Factor was indeed an issue before LLMs, and in fact it's a jargon term that has been in use since forever.
What TFA is arguing is that never before we had a trend towards Bus Factor zero. Before, the worst was often 1 (occasionally zero, of course, but now TFA argues we're aiming for zero whether we're aware or not).
True, but when the bus factor is 1, it might as well be zero -- soon you end up with employees (or contractors) who legitimately want more compensation realizing their critical nature. I totally sympathize from the employee's perspective, esp if the 1-factor means they cannot take holiday. Really, it is the company's job to control the bus factor (LLM or human) -- it is good for both the employee and company in the long run.
Yes, its very much a goldfish problem, where work needed grows to fill what is possible, not what is advisable or good.
The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process, and generally it just makes everyone lazy and deliver stuff at the last second anyway, not use the additional time to make something polished.
>> The only way I have seen people "solve" this is by putting a bunch of speed bumps in a process
I solve this by sufficient compartmentalization with good inter-component interfaces. Worst case, you excise part of your system and rebuild. Possibly you can take the schema and docs and rebuild with an LLM :-)
I talk about this in my upcoming book on the topic (link above.) Most good systems are rebuilt 3 or 4 times anyway.
The problem is that our brains really don't like expending calories on information we don't repeatedly use so the further you get from something, the less you understand it or remember it.
So even if you aren't even vibe coding and are trying to review every change, your skills are atrophying. We see this all the time as engineers enter management, they become super competent at the new skills the role requires but quickly become pretty useless at solving technical problems.
It's similar to why it's so hard to go from level2 to level5 in driving automation. We're not really designed to be partially involved in a process - we quickly loose attention, become lazy, and blindly trust the machine. Which is maybe fine if the machine is 100% reliable but we know that isn't the case.
There is a really important point here, and it's critical to be aware of it, but we're really just at the beginning of these tools and workflows and these issues can be solved, IMO, possibly better than with humans.
I've been trying to use LLMs to help code more to mixed success, honestly, but it's clear that they're very good at some things, and pretty bad at others. One of the things they good at obviously is producing lots of text, two important others are that they can be very persistent and thorough.
Producing a lot of code can be a liability, but an LLM won't get annoyed at you if you ask it for thorough comments and updates to docs, READMEs, and ADRs. It'll "happily" document what it just did and "why" - to the degree of accuracy that they're able, of course.
So it's conceivable to me at least, that with the right guidance and structure an LLM-generated codebase might be easier to come into cold years later, for both humans and future LLMs, because it could have excellent documentation.
There is a really important point here, and it's critical to be aware of it, but we're really at the end of these tools and workflows and these issues can't be solved.
> 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.
> 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.
No disrespect for your ability to read Arduino code, but no amount of experience will tell you why the code was written a certain way. Did the programmer not know of any alternatives? Did they specifically choose this one method because it was superior to the alternatives? Did they just run out of time? Is it due to regulatory requirements? The list goes on. To expand further:
FTA:
> but ultimately reading code remains much more complex than writing it no matter what.
I disagree. If reading code is complex, it's because that code was not documented well. If you've written a complex algorithm, that presumably took you hours or days to develop, the proper documentation should allow somebody to understand it (or at least grasp the major points) in a few minutes.
If you're not documenting your code to that level, i.e. to allow future devs to take less time to read and understand than it took you to write--let alone add additional information went into why you made the decisions you did--then you're doing something wrong.
I agree with the premise and the conclusion, but over almost 20 years of writing, adapting and delivering software I've more than once been in exactly the same situation. Noone to ask, the only person even vaguely familiar with software development left half a year ago. Half of the processes have changed since the software was written, and the people who owned them have left, too.
So while I agree that LLMs will accelerate this process, in my opinion it's not a new flavor, just more of an existing problem. Glad to see this kind of thinking though.
The author though neglects what a bus factor of 0 means in real terms and how it gets there, aside from the description of the definition upfront where all knowledge lost.
A company acceptable with a bus factor of zero is a company that is not willing to pay the economic advantage to the expertise required to do the work.
The economic demand, of humanity competing with AI is zero because AI does things its good at with an order of magnitude difference in cost, and the deception and lies surrounding the marketing coupled with communications channel jamming lead to predictable outcomes. What happens when that demand and thus economic benefit go to zero? Any investment in the knowledge in the first place has no return. No one goes into it, no one learns, and that's quite dangerous in economies based in money-printing.
So while there may not be a problem right now, there will no doubt be problems in the next proverbial quarter. Career development pipelines are years in the making. They are sequential pipelines. Zero into a sequential pipeline is zero out with the time-lag between the two (which is years).
~2 years without economic incentive is when you lose your best and brightest. From there is a slow march to a 10 year deadline after which catastrophic losses occur.
I had a chance to have a interesting discussion with a local community college Dean. Apparently they have had to lower the number of Computer Science related program sections because of lack of demand. In intro courses, for 18 sections there were 13 people who had declared for the major, most students when asked citing AI concerns and lack of career development pipeline.
What happens when you have no expertise that you can pay at any price to fix the processes involved because you put them all out of business using what amounts to a semi-thinking non-sentient slave.
Without supply, there can be no demand. Where supply becomes infinite because of external parties, there can be no demand. There can be need, but demand is not need.
So this all started in 2022. Best and brightest are re-skilling. There's a glut of lower competency talent too. Bad things happen when you mess with the foundations of economics, and they happen on a time lag, where you can't react fast enough after-the-fact.
What will it take? At some point there will be a crisis where they will have to treat it as triage on the battlefield. The people in charge didn't want to hear about this when it could have made a difference.
As programmers, the bus factor is something to be noted and avoided, but in medicine, it goes the other direction. Private practice is one doctor, and a whole support staff for that single individual. Why are we so eager to be replaceable?
Readit News
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.
You would naively think that, as did I, but I've tested it against several big name models and they are all eventually "lazy", sometimes make unrelated changes, and worse as the context fills up.
On a small toy example they will do it flawlessly, but as you scale up to more and more code that requires repetitive changes the errors compound.
Agentic loops help the situation, but now you aren't getting it done in 2 minutes because you have to review to find out it wasn't done and then tell it to do it again N times until it's done.
Having the LLM write a program to make the changes is much more reliable.
I ended up doing this when switching our 50k-LOC codebase to pnpm workspaces, and it was such a good experience. It still took me a day or two of moulding that script to get it to handle the dozens of edge cases, but it would have taken me far longer to split things up by hand.
I still feel like I am under-using the ability of LLMs to spit out custom scripts to handle one-off use-cases.
And I would never want to use a piece of software written by you ever.
If you think that writing the code was the hard part, your code was probably always shite.
Going from "thing in my head that I need to pay someone $100/h to try" to "thing a user can literally use in 3 minutes that will make that hypothetical-but-nonexistent $100/h person cry"... like there is way more texture of roles in that territory than your punchy comment gives credit. No one cares is it's maintainable if they now know what's possible, and that matters 1000x more than future maintenance concerns. People spend years working up to this step that someone can now simply jank out* in 3 minutes.
* to jank out. verb. 1. to crank out via vibe-coding, in the sense of productive output.
But yeah, LLM are not good at defining requirements, architectures, or writing a spec to the requirements. They are good a contained, bite sized asks that don't have much implications outside the code it writes.
Dead Comment
I've done this successfully on multiple projects in the 10-20k LOC, ~100 file area - fully LLM generated w/ tons of my personal feedback - and it works just fine. 4/5 features I implement it gets pretty close to nailing from the spec I provide and the work is largely refactoring. But the times it doesn't get it right, it is a slog that could eat the better part of a day. On the whole though it probably is a 3-5x speedup.
I'm a little less confident about doing this on projects that are much bigger... then breaking things up into modules begins to look more attractive.
I want to create a new project using framework XYZ. I already know how to do it, but I don't remember how to set up it since I only do that once, or I don't know how to set up a class that inherits from the framework because I usually just copy the other from another class in the same project. I can simply tell the bot to write the starting code and take it from there.
The sad thing is for a LOT of use cases an LLM is completely unnecessary. Like why do I even need an LLM for something like this? Why can't I just download a database of code examples, plug it into a search engine that apppears in the sidebar, and then just type "new project XYZ" or "new class XYZ.foo" to find the necessary snippet? A lot of NPM frameworks have a set up script to get you started with a new project, but after that you are practically forced to use Google.
It's crazy that a problem that could be solved so easily with a local file search has been ignored for so long and the only solution has been something impossibly inefficient for the problem it's supposed to solve.
> bam, x days work done in 2 minutes
This is a bit of a misrepresentation, since those two minutes don’t account for the reviewing time needed (nor prorperly, which vastly exceeds that time. Otherwise you end up in the situation of “doing it wrong” described in your first paragraph.
If you have an LLM transform a big pile of structs, you plug them into your program and it will either compile or it won't.
All programmers write countless one-off throwaway scripts. I can't tell you how many times I've written scripts to generate boring boilerplate code.
How many hours do you spend reviewing such tools and their output? I'll bet anything it's just about zero.
Finally, the productivity boost is significant from the perspective of the programmer, but I don't know how big it is from the perspective of the employer. Does this significantly shorten time-to-market?
That has been a nice outcome I didn't expect. Some of the trivial "nice to haves" I can get done by Claude, stuff I just don't have time for.
To your other points I agree as well, I think what's important isn't so much stuffing the context with data, but providing the context with the key insights to the problem you have in your head.
In your first example, perhaps the insight is knowing that you have a special snowflake data structure that needs to be explained first. Or another example is properly explaining historical context of a complex bug. Just saying "hey here's all the code please fix this error" yields less good results, if the problem space is particularly complex.
- 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.
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 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.
But this already exists! At work, our code is full of code where the original reasoning for the code is lost. Sometimes someone has forgotten, sometimes the person who wrote it is no longer at the company any more, and so on.
> 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.
But there are plenty of instances where I work with code that has a bus factor of 0.
The conclusion of your article is that vibe coding is "fundamentally flawed". But every aspect you've described about vibe coding has an analog in normal software engineering, and I don't think you would claim that is "fundamentally flawed".
Document. Whenever a member of the team leaves, you should always make them document what is in their head and not already documented (or even better, make documenting a required part of normal development).
The thing to understand is that every (new) AI chat session is effectively a member entering and leaving your team. So to make that work well you need great onboarding (provide documentation) and great offboarding (require documentation).
Dead Comment
"Just ask the author of that perl file".
Sure, it was last edited in -97 and the author is the regional manager now, should I just book a meeting or...?
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."
The only code you do not have to maintain is code that is fully perfect (100% accurate, 100% of the time). Bus factor zero is a problem for code that needs to be maintained. If AI is short of the 100%, then it is generating code that needs to be maintained. Ergo, a bus factor zero will be a problem for AI generated code (until such time as that code is perfect).
What surprised me was how useful AI was. It helped me not only understand the code but also infer the probable intent behind it, which made debugging much faster. I started generating documentation directly from the code itself.
For me, this was a big win. Code is the source of truth. Developer documentation and even shared knowledge are often full of bias, selective memory, or the “Chinese whispers” problem where the story shifts every time it’s retold and never documented. Code doesn’t lie, it just needs interpretation. Using AI to cut through the noise and let the code explain itself felt like a net positive.
Shameful plug, i've been writing a book on this with my retrospective as a CTO building like this. I just updated it so you can choose your price (even $0) to make this a less shameful plug on HN: https://ctoretrospective.gumroad.com/l/own-your-system
I dont think anyone has the perfect answer, yet, but LLM-built systems arent that different from having the system built by 10 diff people on eLance/Upwork/Fiverr...so the principles are the same.
What TFA is arguing is that never before we had a trend towards Bus Factor zero. Before, the worst was often 1 (occasionally zero, of course, but now TFA argues we're aiming for zero whether we're aware or not).
I solve this by sufficient compartmentalization with good inter-component interfaces. Worst case, you excise part of your system and rebuild. Possibly you can take the schema and docs and rebuild with an LLM :-)
I talk about this in my upcoming book on the topic (link above.) Most good systems are rebuilt 3 or 4 times anyway.
So even if you aren't even vibe coding and are trying to review every change, your skills are atrophying. We see this all the time as engineers enter management, they become super competent at the new skills the role requires but quickly become pretty useless at solving technical problems.
It's similar to why it's so hard to go from level2 to level5 in driving automation. We're not really designed to be partially involved in a process - we quickly loose attention, become lazy, and blindly trust the machine. Which is maybe fine if the machine is 100% reliable but we know that isn't the case.
Deleted Comment
I've been trying to use LLMs to help code more to mixed success, honestly, but it's clear that they're very good at some things, and pretty bad at others. One of the things they good at obviously is producing lots of text, two important others are that they can be very persistent and thorough.
Producing a lot of code can be a liability, but an LLM won't get annoyed at you if you ask it for thorough comments and updates to docs, READMEs, and ADRs. It'll "happily" document what it just did and "why" - to the degree of accuracy that they're able, of course.
So it's conceivable to me at least, that with the right guidance and structure an LLM-generated codebase might be easier to come into cold years later, for both humans and future LLMs, because it could have excellent documentation.
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.
FTA:
> but ultimately reading code remains much more complex than writing it no matter what.
I disagree. If reading code is complex, it's because that code was not documented well. If you've written a complex algorithm, that presumably took you hours or days to develop, the proper documentation should allow somebody to understand it (or at least grasp the major points) in a few minutes.
If you're not documenting your code to that level, i.e. to allow future devs to take less time to read and understand than it took you to write--let alone add additional information went into why you made the decisions you did--then you're doing something wrong.
A company acceptable with a bus factor of zero is a company that is not willing to pay the economic advantage to the expertise required to do the work.
The economic demand, of humanity competing with AI is zero because AI does things its good at with an order of magnitude difference in cost, and the deception and lies surrounding the marketing coupled with communications channel jamming lead to predictable outcomes. What happens when that demand and thus economic benefit go to zero? Any investment in the knowledge in the first place has no return. No one goes into it, no one learns, and that's quite dangerous in economies based in money-printing.
So while there may not be a problem right now, there will no doubt be problems in the next proverbial quarter. Career development pipelines are years in the making. They are sequential pipelines. Zero into a sequential pipeline is zero out with the time-lag between the two (which is years).
~2 years without economic incentive is when you lose your best and brightest. From there is a slow march to a 10 year deadline after which catastrophic losses occur.
I had a chance to have a interesting discussion with a local community college Dean. Apparently they have had to lower the number of Computer Science related program sections because of lack of demand. In intro courses, for 18 sections there were 13 people who had declared for the major, most students when asked citing AI concerns and lack of career development pipeline.
What happens when you have no expertise that you can pay at any price to fix the processes involved because you put them all out of business using what amounts to a semi-thinking non-sentient slave.
Without supply, there can be no demand. Where supply becomes infinite because of external parties, there can be no demand. There can be need, but demand is not need.
So this all started in 2022. Best and brightest are re-skilling. There's a glut of lower competency talent too. Bad things happen when you mess with the foundations of economics, and they happen on a time lag, where you can't react fast enough after-the-fact.
What will it take? At some point there will be a crisis where they will have to treat it as triage on the battlefield. The people in charge didn't want to hear about this when it could have made a difference.