Vibe coding creates a bus factor of zero
mindflash.org
mindflash.org
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'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.
> 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.
My job right now depending on the week is to either lead large projects dealing with code I don’t write or smaller “full stack” POCs- design, cloud infrastructure (IAC), database, backend code and ETL jobs and rarely front end code. Even before LLMs if I had to look at a project I did it took me time to ramp up.
Yes, and water is wet, but that's not exactly relevant. If you have an LLM generate slop at you that you have to review and adjust, you need to compare the time this whole process took you rather than just the "generating slop" step to the time needed to write the code by yourself.
It may still save you time, but it won't be anywhere close to 2 minutes anymore for anything but the most trivial stuff.
The only refactoring I ended up doing on my current project is extracting functions from a script and creating a library that I reused across other functionality.
Even then I just pasted the library into a new ChatGPT session and told it the requirements of my next piece of functionality and told it to use the library.
I don’t trust an LLM to write more than 200 lines of code at the time. But I hardly ever write more than 200-300 lines at a time.
I can tell you that my latest project has around 1000 lines of Node CDK code between multiple apps (https://aws.amazon.com/cdk/) and around 1000 lines of Python code and I didn’t write a single line of any of it by hand and from reviewing it, it didn’t make any choices that I wouldn’t make and I found some of the techniques it used for the CDK code were things I wouldn’t have thought about.
The SQL code it generated for one of the functions was based on my just giving it the inbound JSON and the create table statements and it didn’t idiomatic MySQL, with parameters (ie no sql injection risk) and no unsafe code.
This was a 3 week project that I would have at least needed one if not two junior/mid level devs to do without Gen AI. Since I also had to be in customer meetings, write documentation and help sells on another project coming up.
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.
I've also spent countless hours debugging throwaway scripts I wrote myself and which don't work exactly like I intended when I try them on test data.
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.
I run LLMs against a 500k LoC poker engine and they do well because the engine is modularized into many small parts with a focus on good naming schemes and DRY.
If it doesn't require a lot of context for an LLM to figure out how to direct effort then the codebase size is irrelevant -- what becomes relevant in those scenarios is module size and the amount of modules implicated with any change or problem-solving. The LLM codebase 'navigation' becomes near-free with good naming and structure. If you code in a style that allows an LLM to navigate the codebase via just an `ls` output it can handle things deftly.
The LLMification of things has definitely made me embrace the concept of program-as-plugin-loader more-so than ever before.
> The LLM codebase 'navigation' becomes near-free with good naming and structure
I have not found this to be true. They seem to break badly if you have a lot of files with similar-ish names even if they're descriptive.
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.
I'm sure there's a lot of poorly tested code I use, that doesn't mean I want to use it. :)
In fact, I see a lot of broken things in the wild, frequently.
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.
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.
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?
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.
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'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).
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".
I added the "remotely-mission-critical" qualifier to capture additional nuance. Tolerance for a low bus factor should be inversely correlated with a project's importance. That wasn't explicitly stated in the article, but it seems uncontroversial, and I suspect the author would agree with me.
> But there are plenty of instances where I work with code that has a bus factor of 0.
Do you think this is a problem?
As per my other replies, if all of these instances are in completely unimportant projects, then I could see you answering "no" (but I'd be concerned if you're spending a lot of time on unimportant things). If they are important, isn't the fact that knowledge about them has been lost indicative of a flaw in how your team/company operates?
1. If a process necessarily results in bus factors of zero, that process is flawed.
2. The nature of vibe coding is such that it always produces code with a bus factor of zero (i.e. this is a "fundamental" fact of vibe coding).
I definitely agree with the first point, and I think agree with the second as well (at least if "vibe coding" carries its original implication that you don't even look at/care about the code produced by the LLM).
Did you have a different interpretation? Or do you disagree with one of these points?
I think I would disagree a bit with both.
It doesn't seem a priori evident that producing a bus factor of zero is bad. For instance, using a library which is not maintained has a bus factor of zero. That doesn't seem "flawed" to me. I think the problem I find with the author's, and your, statements is absolutism. Few things in engineering are ever truly 100% right or 100% wrong choices. Using a library with no maintainers is decision with tradeoffs, but in some contexts those tradeoffs would be worth it. Similarly, vibe coding code that has a bus factor of zero is also a decision with tradeoffs, and sometimes tradeoffs are worth it.
As for the second point - is it really so. hard to read the code that an LLM produces? I am continuously reading output from LLMs for any code which is even remotely important. Again, this is another decision with tradeoffs. Sometimes I vibe-code a 500 loc script, but I can manually verify the output of the script, and therefore there is no reason to read every line. Sometimes I am working on more important code that must be right; I typically inspect it line by line, like a code review.
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).
"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...?
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.
They will when you run /init, but after that they won't look at it unless directed to do so.
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.
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.
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).
Spot on. 1 might as well be zero. Totally unfair to the worker also, who now cannot take time off.
I considered it a success when I realized a company doesn’t need me anymore and I can move on and talk about what I did at my next interview in STAR format.
This is precisely why the term "Bus Factor" was invented: to point out when it's 1, because it's both high risk to the company and unfair to the dev that cannot go on vacation or extended time off.
A Bus Factor of 0, especially as an implicit goal, seems doubly worrisome! Now it's a goal rather than a warning sign.
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.
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.
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.
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.
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.
What's more the same would be if they were practicing healthcare on a species that they had invented, and no one knew anything about it, and the species was crucial to a company's survival.
Aka, why we should ask vendors for their source code in case they go under.
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.
If you show it bad code and ask it to add features on top, it will produce more bad code... It might work (kind of) but more likely to be buggy and have security holes. When the context you give to the LLM includes unnecessary complexity, it will assume that you want unnecessary complexity and it will generate more of it for you.
I tried Claude Code with both a bad codebase and a good codebase; the difference is stark. The first thing I notice is that, with the good code base without unnecessary complexity, it generates a lot LESS code for any given feature/prompt. It's really easy to review its output and it's very reliable.
With a bad, overengineered codebase, Claude Code will produce complex code that's hard to review... Even for similar size features. Also it will often get it wrong and the code won't work. Many times it adds code which does literally nothing at all. It says "I changed this so that ..., this should resolve the issue ..." - But then I test and the issue is still there.
Some bad coders may be tempted to keep asking Claude to do more to fix the issue and Claude keeps adding more mess on top. It becomes a giant buggy hack and eventually you have to ask it to rewrite a whole bunch of stuff because it becomes way too complicated and even Claude can't understand its own code... That's how you get to bus factor of 0. Claude will happily keep churning out code even if it doesn't know what it's doing. It will never tell you that your code is unmaintainable and unextendable. Show it the worst codebase in the world and it will adapt itself to become the worst coder in the world.
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?)
On the other hand, if the agent is just as capable of fixing bugs in legacy code as rewriting it, and humans are no longer in the loop, who cares if it's legacy code?
But I can see it "working". At least for the values of "working" that would be "good enough" for a large portion of the production code I've written or overseen in my 30+ year career.
Some code pretty much outlasts all expectations because it just works. I had a Perl script I wrote in around 1995-1998 that ran from cron and sent email to my personal account. I quit that job, but the server running it got migrated to virtual machines and didn't stop sending me email until about 2017 - at least three sales or corporate takeovers later (It was _probably_ running on CentOS4 when I last touched it in around 2005, I'd love to know if it was just turned into a VM and running as part of critical infrastructure on CentOS4 12 years later).
But most code only lasts as long as the idea or the money or the people behind the idea last - all the website and differently skinned CRUD apps I built or managed rarely lasted 5 years without being either shut down or rewritten from the ground up by new developers or leadership in whatever the Resume Driven Development language or framework was at the time - toss out the Perl and rewrite it in Python, toss out the Python and rewrite it in Ruby On Rails, then decide we need Enterprise Java to post about on LinkedIn, then rewrite that in Nodejs, now toss out the Node and use Go or Rust. I'm reasonably sure this year's or perhaps next years LLM coding tools can do a better job of those rewrites than the people who actually did them...
Absolutely not.
In the short term it will, while OpenAI/Anthropic/Anysphere destroy software development as a career. But they're just running the Uber playbook - right now they're giving away VC money by funding the datacenters that're training and running the LLMs. As soon as they've put enough developers out of jobs and ensured there's no new pipeline of developers capable of writing code and building platforms without AI assistance, they will stop burning VC cash and start charging at rates that not only break even but also return the 100x the investors demand.
> This assumes your adding documentation, tests, instructions, and other scaffolding along the way, of course.
It's not just about knowledge in someone's brain, just about knowledge persistence.
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!
But in the long term, when experienced developers actually feel comfortable letting LLMs write large swats of code, or when the machine no longer needs to generate human readable code, then we will start forgetting how it works.
A good dev can dive into a completely unknown codebase with or without tools like a debugger and figure it out. AI makes this far easier.
Some great devs/reverse-engineering experts can do the same without even the compiled source code. Again AI tools can now do this faster than any human.
Security researchers have figured out the intricacies of a system with no more than a single string as input and an error code as output.
I don't miss that phase of the evolution of software development practice at all.
So maybe that is a test, or something to strive for. If you can get a new developer to make a moderate change to your code base on their first day successfully, then your code is fine. If not you have work to do.
To expand a little on this thought, any one developer's experience is probably not significant but if you hire say 10 new devs and 6-8 are making changes on their first day or in the first few days, your code base is likely fine.
I recomend that a new dev should first make the most trivial change possible but see it through all the way to release, to expose them to process. Following that, a moderate change to expose them to paradigm. All on the first day or in the first few days. If only say 3 of 10 new hires can accomplish the above, the problem is in your code base (or hiring practices).
> Testing string prefixes or file extensions is bound to fail at some point on some edge case. I'd like to see more robust discovery of formats than this. This reeks of script-kiddie code, not professional-quality code.
It's true more often than I'd like that the quality of code I see generated is script-kiddie level. If I prompt carefully beforehand or review harshly after, it generally improves, but I have to keep my guard up.
Ive been trying to resolve this with things like “make a notebook that walks through this modules functions”, etc, to make it easier for me to review.
In the spirit of literate riding though, why but have these agents spend more time (tokens…money) walking you through what they made.
Likewise, if dev A vibe codes something and leaves it to dev B to maintain, we should think about what AI workflows can get B up to speed fast. “Give me a tour of the code”
You want this factor to be +Inf, not 1/+Inf. Just in case it wasn't beyond abundantly clear to all...
This just sounds like every other story I hear about working on ossified code bases as it is. At least AI can ingest large amounts of code quickly, even if as of today it can't be trusted to actually decipher it all.
A co-worker spent the same amount of time having a LLM do the same thing, and produce documentation that now lives in a wiki.
It would have taken me another 30-60min to produce the same documentation.
The difference is that I, as a person/team member, understand it.
If the model is effectively a team member and is included in all the same conversations ("hey, what about...") then I think it could be roughly equivalent.
LLMs are bad for bad programmers. LLMs will make a bad programmer worse and make a layperson think they're a prodigy.
Meanwhile, the truly skilled programmers are using LLMs to great success. You can get a huge amount of value and productivity from an LLM if and only if you have the skill to do it yourself in the first place.
LLMs are not a tool that magically makes anyone a good programmer. Expecting that to be the case is exactly why they don't work for you. You must already be a good programmer to use these tools effectively.
I have no idea what this will do to the rising generation of programmers and engineers. Frankly I'm terrified for them.
I've used a variety of LLMs to ask questions about probably dozens of unfamiliar code bases many of which are very complicated technically.
At this point I think LLMs are indispensable to understanding unfamiliar code bases. Nearly always much better than documentation and search engines combined.
In a way, I have been thinking about it [1] as the difference between writing a book and a writing a blog post - the production qualities expected in both are wildly different. And that's expected, almost as a feature!
I think as “writing” and distributing new software keeps getting easier - as easy as writing a new blog post - the way we consume software is going to change.
[1]: https://world.hey.com/akumar/software-s-blog-era-2812c56c
I love the conclusion. When no human holds the knowledge it is like the bus already struck everybody at the company.
I have worked in teams that share knowledge often and extensively. Anybody can go on a vacation with little disruption as other's can take the tasks. Everybody is happier and projects work better.
(If your first tough is that you can be replaced easily and you will be fired. Then you live in a dystopian class-warfare country where the owner-class will fire you because they enjoy making the working-class suffer. I am sorry for you, but have hope. That can be changed with good laws and employee protections.)
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.
The post is great. Bus factor of zero is a great coinage.
I've seen from beautiful to crazy legacy systems in various domains. But when I encounter something off, there appears to always be a story. Not so much with LLMs.
It got hit by a bus before it was born.