>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…
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.
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 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 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.
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.
>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…
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.
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 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.
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
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/
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
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