Well, I'm sure we've all seen code produced by human developers that is 10x worse than what my Claude Code produces (certainly I have), so let's be real. And it's improving scary fast.
This seems like a lack of experience. The more I work with LLMs, the better I get at predicting what they’ll get wrong. I then shape my prompts to avoid the mistakes.
I think the bar has raised, for sure. There's code I work on from prior seniors that is worse than what our current juniors write, I'm assuming AI is assisting with that but as long as the PR looks good, it's no different to me.
I've noticed that generally OK design patterns and sticking to idiomatic code has increased while attention to small but critical details remains the same or maybe slightly decreased.
Hard disagree. Humans fail in ways I know, can predict, and know where to look for. ML coding assistants fail in all sorts of idiotic ways and thus every damn line needs to be scrutinized.
What actually scares me is the idea that with humans you can manage to follow their train of thought. But if LLM just rewrites everything each time, well that is impossible to follow and then there is same work to be done over and over again each review.
>If the resulting software is so poor you need to hire a human specialist software engineer to come in and rewrite the vibe coded software, it defeats the entire purpose.
I don't think this is entirely true. In a lot of cases vibe coding something can be a good way to prototype something and see how users respond. Obviously don't do it for something where security is a concern, but that vibe-coded skin cancer recognition quiz that was on the front page the other day is a good example.
Exactly… back in 1975 Fred Brooks was advising programmers to “plan to throw the first version away” (The Mythical Man-Month) and it’s still true today. Just the tools to build that rapid prototype that have changed. Once it was Ruby on Rails, once it was Visual Basic 6, very often it’s still Excel macros…
Wasn't part of throwing away the first version because of all the knowledge you gain while actually building it? So that you could build it much better the second time, with much better abstractions/design? If you had AI code it the first time, you don't gain that same knowledge.
You still do from operating the software.
You see what problems users have using it, which types of problems they tackle with it.
By the end of running the software for a month you will have typically learned a boat load.
But you and the parent are both ignoring that, in the real world, prototypes constantly (in fact, nearly always) get shipped straight to production and not updated or rewritten, precisely because they solve a pressing problem, and if they solve it well they get real users right away who start bringing up new feature requests and bugs before the prototype can ever be fixed.
This was a constant pattern in software engineering even before LLMs, but LLMs are making it much worse, and I think it's very head-in-the-sand behavior to ignore that. It's akin to going "well, you can't blame the Autopilot because the person should have been fully-attentive ready to react at any millisecond". That's not how humans work, and good engineering is supposed to take real-world human behavior into consideration
I've spent a good chunk of my career fixing or rewriting messes created by human developers. A majority of startups that succeed need this at some point, whether it's because of time and resource constraints during initial development, experience and competence issues, poor choices that got baked in, or whatever.
Right now, vibe coding just means there might be a lot more of this, assuming vibe coding succeeds well enough to compete with the situations I described.
In my experience, LLM-generated code is only as good (or as bad) as the software engineering skills of the “vibe coder.” A seasoned engineer will not only craft clear, detailed prompts that specify how something should be implemented, but will also review the AI’s output on the fly, correcting major derailments—things like: “Don’t create a new function for that; just modify X to add support for this case.” They’ll even do an initial review of the code before opening a PR.
The real problem arises when non-technical people use an LLM to generate a full project from scratch. The code may work, but it’s often unmaintainable. These people sometimes believe they’re geniuses and view software engineers as blockers, dismissing their concerns as mere technical “mumbo jumbo.”
I get two types of merge requests nowadays. The first is a traditional piece of code. Something simple like a bit of marketing text to a page or a new react component that adds another css effect to some content. The second type is a long complex merge request, for something more complex than a menu (not really though)…tabs, uses new dependencies, none of the old dependencies, is filled with emdashed code comments about personal dev choices (instead of logic flow or business context), and the core file convention is named after the implementers library choice: `react-tabs`. If I bring up any of these issues with the implementer they tell me “we can fix it later and they need to just get it out”.
The first type of merge request is one that should be generated by an LLM and the second is one that should be generated by a human.
Instead I get neither but I get efficiency so someone can deliver at the last minute. And so I can can go mop up the work later or my job is hell the next time “we just need to get this out the door”.
I tell my CS students who ask if there will be any junior positions for them when they graduate:
There will be an entire new industry of people who vibed 1000 lines of MVP and now are stuck with something they can’t debug. It’s not called a junior developer, but it’s called someone who actually knows programming.
Also, they will continue to deliver code that is full of security holes, because programming teachers are often not competent to teach those aspects, and IT security professionals who teach tend to be poor programmers or paper pushers.
Probably simultaneously, LLMs will perpetuate faulty MVPs that need fixing for the viber economy, while at the same time, all those AI engineering problems get solved, but only for those who know how to ask.
That is essentially how I survived the nuclear winter after the dot-com bubble burst (taking out most of the senior level tech workers across the vast majority of US domestic business --in those days, senior level meant formal training, 20+ years experience and over 40yo with kids in school, mortgages, etc..and when all the jobs go away in an industry for six years, you are forced to crack open your 401K and retire while you figure out something else...there was no coming back for them). The takeaway now is that the informally trained web people who came up without guidance beyond Google Search and forum contributions from Europe but gained control of the industry in the Crash's aftermath will live on as "vibe coders" forever and their "heavy lifting" partners at AWS, GCP and Azure will live on for a while hosting trillion+ parameter LLMs, even as the first wave of American CS graduates since the Crash are about to (finally!) hit their 20 year mark and gain control of tech across all industries (pulling the plug on the "heavy lifting cloud" that they don't need/want to budget for).
But unlike that six year gap during the tech nuclear winter (2000-2006) when you could literally follow those over-confident $10/hr kids around cleaning up one botched effort to port custom Windows apps to LAMP after another, this time it will be different. The LLMs are trained largely on the European-dominated code bases on Github and it's just enough to keep the "vibe coders" out of real bad trouble (like porting a financial application from Visual BASIC into PHP which has different precision floating point resolution between distributions/releases or de-normalizing structured customer data and storing it in KV pairs "because everybody is doing it so relational databases must be obsolete".) The work to cleanup their "vibe coded" mess will not be as intense (especially considering LLMs will help), but there will be a lot more of it this time around and re-hosting it more economically will be a Thing.
Sadly, American businesses will discover they don't need trillion parameter LLMs (due to MoE, quantization, agentic mini-models, etc.) and the supply of acceptable vector processing chips will catch up to demand (bringing prices down for "on prem" deployments) and that "AI snake oil factor" (non-deterministic behavior and hallucinations) will become more than a concern expressed over weekend C-suite golf games and yacht excursions (you know, where someone always gets fired to set an example of what happens when you don't make your numbers). AI had been dead so long that the top C-suites can't even remember the details of how/why it died anymore (hint: you could get fired for even saying "AI" up until the 2000 Crash giving rise to the synonym "ML" as a more laser focused application of AI), just that they don't trust it. The astonishing demonstrations at OpenAI, Anthropic, xAI, Google and Meta are enough to cause C-suites to write a few checks, causing a couple of ramps in the stock market, but those projects by and large are NOT working out due to the same 'ole same 'ole and I fear this entire paradigm will suffer the same fate as IBM Watson. The stock market may well crash again because of this horsepucky even though there IS true potential with this technology, just as with Web 1.0. (All it needs for that is a catalyst event --maybe not Bill Gates throwing a chair, maybe something in the dispute between Sammy and Elon.) Same as it ever was.
No; it doesn't care when it gives you incomplete garbage.
You have to tell it to validate its own work by adding to, refactoring, and running the tests before it replies.
Most junior developers do care and would never dump partial solutions on a prompter as though they're sufficient like LLMs.
Every time I remember to get `make test-coverage` working and have myself or the LLM focus on lines that aren't covered by tests.
Junior or Senior,
an employee wouldn't turn in such incomplete, not compiling assignments that % of the time; even given inadequate prompts as specifications.
I'd take tests over docs but that's a false dilemma.
What does the (Copilot) /tests command do, compared to a prompt like "Generate tests for #symbolname, run them, and modify the FUT function under test and run the tests in a loop until the tests pass"?
Documentation is probably key to the Django web framework's success, for example.
Well, I'm sure we've all seen code produced by human developers that is 10x worse than what my Claude Code produces (certainly I have), so let's be real. And it's improving scary fast.
I can understand how a mediocre SWE thinks and can anticipate what corners were cut, I have no idea what an LLM is thinking.
This seems like a lack of experience. The more I work with LLMs, the better I get at predicting what they’ll get wrong. I then shape my prompts to avoid the mistakes.
I think the bar has raised, for sure. There's code I work on from prior seniors that is worse than what our current juniors write, I'm assuming AI is assisting with that but as long as the PR looks good, it's no different to me.
I've noticed that generally OK design patterns and sticking to idiomatic code has increased while attention to small but critical details remains the same or maybe slightly decreased.
Try working with a bad dev using an LLM.
Hard disagree. Humans fail in ways I know, can predict, and know where to look for. ML coding assistants fail in all sorts of idiotic ways and thus every damn line needs to be scrutinized.
What actually scares me is the idea that with humans you can manage to follow their train of thought. But if LLM just rewrites everything each time, well that is impossible to follow and then there is same work to be done over and over again each review.
> Humans fail in ways I know, can predict, and know where to look for.
You clearly haven't worked with humans.
[dead]
>If the resulting software is so poor you need to hire a human specialist software engineer to come in and rewrite the vibe coded software, it defeats the entire purpose.
I don't think this is entirely true. In a lot of cases vibe coding something can be a good way to prototype something and see how users respond. Obviously don't do it for something where security is a concern, but that vibe-coded skin cancer recognition quiz that was on the front page the other day is a good example.
Exactly… back in 1975 Fred Brooks was advising programmers to “plan to throw the first version away” (The Mythical Man-Month) and it’s still true today. Just the tools to build that rapid prototype that have changed. Once it was Ruby on Rails, once it was Visual Basic 6, very often it’s still Excel macros…
Wasn't part of throwing away the first version because of all the knowledge you gain while actually building it? So that you could build it much better the second time, with much better abstractions/design? If you had AI code it the first time, you don't gain that same knowledge.
You still do from operating the software. You see what problems users have using it, which types of problems they tackle with it. By the end of running the software for a month you will have typically learned a boat load.
But you and the parent are both ignoring that, in the real world, prototypes constantly (in fact, nearly always) get shipped straight to production and not updated or rewritten, precisely because they solve a pressing problem, and if they solve it well they get real users right away who start bringing up new feature requests and bugs before the prototype can ever be fixed.
This was a constant pattern in software engineering even before LLMs, but LLMs are making it much worse, and I think it's very head-in-the-sand behavior to ignore that. It's akin to going "well, you can't blame the Autopilot because the person should have been fully-attentive ready to react at any millisecond". That's not how humans work, and good engineering is supposed to take real-world human behavior into consideration
I've spent a good chunk of my career fixing or rewriting messes created by human developers. A majority of startups that succeed need this at some point, whether it's because of time and resource constraints during initial development, experience and competence issues, poor choices that got baked in, or whatever.
Right now, vibe coding just means there might be a lot more of this, assuming vibe coding succeeds well enough to compete with the situations I described.
In my experience, LLM-generated code is only as good (or as bad) as the software engineering skills of the “vibe coder.” A seasoned engineer will not only craft clear, detailed prompts that specify how something should be implemented, but will also review the AI’s output on the fly, correcting major derailments—things like: “Don’t create a new function for that; just modify X to add support for this case.” They’ll even do an initial review of the code before opening a PR.
The real problem arises when non-technical people use an LLM to generate a full project from scratch. The code may work, but it’s often unmaintainable. These people sometimes believe they’re geniuses and view software engineers as blockers, dismissing their concerns as mere technical “mumbo jumbo.”
I get two types of merge requests nowadays. The first is a traditional piece of code. Something simple like a bit of marketing text to a page or a new react component that adds another css effect to some content. The second type is a long complex merge request, for something more complex than a menu (not really though)…tabs, uses new dependencies, none of the old dependencies, is filled with emdashed code comments about personal dev choices (instead of logic flow or business context), and the core file convention is named after the implementers library choice: `react-tabs`. If I bring up any of these issues with the implementer they tell me “we can fix it later and they need to just get it out”.
The first type of merge request is one that should be generated by an LLM and the second is one that should be generated by a human.
Instead I get neither but I get efficiency so someone can deliver at the last minute. And so I can can go mop up the work later or my job is hell the next time “we just need to get this out the door”.
THANK YOU LLMS
Clearly LLMs are not the ones to blame
Yes but are we using technology to enable our worst tendencies?
As the mythical man month says: never ship the prototype. Plan to write one and then throw it away.
I have literally never seen that happen in practice. The prototype code always evolves to become the product.
if you throw away a boat one piece at a time, have you thrown away the entire boat by the end?
Well… yes you have thrown away the entire boat. But I get where you were coming from.
Ah, the modern ship of Theseus
Like Red Teams for InfoSec, reliability teams meet developers. Not new, but keep pumping Gig Culture/the fad, I guess.
That’s a good comparison.
But at another scale.
I tell my CS students who ask if there will be any junior positions for them when they graduate:
There will be an entire new industry of people who vibed 1000 lines of MVP and now are stuck with something they can’t debug. It’s not called a junior developer, but it’s called someone who actually knows programming.
Also, they will continue to deliver code that is full of security holes, because programming teachers are often not competent to teach those aspects, and IT security professionals who teach tend to be poor programmers or paper pushers.
That will only be a temporary phase while LLMs still produce bugs that LLMs can't predict or fix themselves.
Untill GödeLLM comes along and proves this is a permanent phase after all
Probably simultaneously, LLMs will perpetuate faulty MVPs that need fixing for the viber economy, while at the same time, all those AI engineering problems get solved, but only for those who know how to ask.
https://archive.is/jX10p
From my relevant post last week:
> AI now lets anyone write software, but it has limits. People will call upon software practitioners to fix their AI-generated code.
https://www.slater.dev/about-that-gig-fixing-vibe-code-slop/
That is essentially how I survived the nuclear winter after the dot-com bubble burst (taking out most of the senior level tech workers across the vast majority of US domestic business --in those days, senior level meant formal training, 20+ years experience and over 40yo with kids in school, mortgages, etc..and when all the jobs go away in an industry for six years, you are forced to crack open your 401K and retire while you figure out something else...there was no coming back for them). The takeaway now is that the informally trained web people who came up without guidance beyond Google Search and forum contributions from Europe but gained control of the industry in the Crash's aftermath will live on as "vibe coders" forever and their "heavy lifting" partners at AWS, GCP and Azure will live on for a while hosting trillion+ parameter LLMs, even as the first wave of American CS graduates since the Crash are about to (finally!) hit their 20 year mark and gain control of tech across all industries (pulling the plug on the "heavy lifting cloud" that they don't need/want to budget for).
But unlike that six year gap during the tech nuclear winter (2000-2006) when you could literally follow those over-confident $10/hr kids around cleaning up one botched effort to port custom Windows apps to LAMP after another, this time it will be different. The LLMs are trained largely on the European-dominated code bases on Github and it's just enough to keep the "vibe coders" out of real bad trouble (like porting a financial application from Visual BASIC into PHP which has different precision floating point resolution between distributions/releases or de-normalizing structured customer data and storing it in KV pairs "because everybody is doing it so relational databases must be obsolete".) The work to cleanup their "vibe coded" mess will not be as intense (especially considering LLMs will help), but there will be a lot more of it this time around and re-hosting it more economically will be a Thing.
Sadly, American businesses will discover they don't need trillion parameter LLMs (due to MoE, quantization, agentic mini-models, etc.) and the supply of acceptable vector processing chips will catch up to demand (bringing prices down for "on prem" deployments) and that "AI snake oil factor" (non-deterministic behavior and hallucinations) will become more than a concern expressed over weekend C-suite golf games and yacht excursions (you know, where someone always gets fired to set an example of what happens when you don't make your numbers). AI had been dead so long that the top C-suites can't even remember the details of how/why it died anymore (hint: you could get fired for even saying "AI" up until the 2000 Crash giving rise to the synonym "ML" as a more laser focused application of AI), just that they don't trust it. The astonishing demonstrations at OpenAI, Anthropic, xAI, Google and Meta are enough to cause C-suites to write a few checks, causing a couple of ramps in the stock market, but those projects by and large are NOT working out due to the same 'ole same 'ole and I fear this entire paradigm will suffer the same fate as IBM Watson. The stock market may well crash again because of this horsepucky even though there IS true potential with this technology, just as with Web 1.0. (All it needs for that is a catalyst event --maybe not Bill Gates throwing a chair, maybe something in the dispute between Sammy and Elon.) Same as it ever was.
Typical coding LLM issues:
Hallucinations
Context limits
Lack of test coverage and testing-based workflow
Lack of actual docs
Lack of a spec
Great README; cool emoji
Sooo the LLM codes just like me ?
No; it doesn't care when it gives you incomplete garbage.
You have to tell it to validate its own work by adding to, refactoring, and running the tests before it replies.
Most junior developers do care and would never dump partial solutions on a prompter as though they're sufficient like LLMs.
Every time I remember to get `make test-coverage` working and have myself or the LLM focus on lines that aren't covered by tests.
Junior or Senior, an employee wouldn't turn in such incomplete, not compiling assignments that % of the time; even given inadequate prompts as specifications.
If you’re hiring someone remotely without any trust you could absolutely get random garbage that pretend to be real work from a human.
A human software developer doesn't code in the void, he interacts with others.
The same when you have an AI coder, you interact with it. It's not fire and forget.
well that's enough for "good-looking documentation-is-everything" kinda teams
I'd take tests over docs but that's a false dilemma.
What does the (Copilot) /tests command do, compared to a prompt like "Generate tests for #symbolname, run them, and modify the FUT function under test and run the tests in a loop until the tests pass"?
Documentation is probably key to the Django web framework's success, for example.
Resources useful for learning to write great docs: https://news.ycombinator.com/item?id=23945815
"Ask HN: Tools to generate coverage of user documentation for code" https://news.ycombinator.com/item?id=30758645
Context limits (regardless of hard limits) are a show stopper IMO, the models completely fail assignments with >= 30k LoC (or so) codebases.
You're better off feeding them a few files to work with, in isolation, if you can.