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'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.
>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.
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.
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.
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 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.
>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.
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.
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
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.
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