Ironically, an experienced coder that needs a specific and simple tool quick will have a better time.
I think it's wrong to frame vibe coding as something that's done by people who don't know how to code. Those who I see effectively vibe coding things tend to be staff- and senior-level engineers, who use it to speed up implementations while focusing on architecture.
What I see as the main obstacle to vibecoding at the moment is that vibecoding is mainly effective at greenfield development projects with little to no prior contrext, and that small-scope work over reasonably sized projects ends up being iterative, time-consuming, and with mixed results.
One of the factors I've noticed is that legacy projects gravitate towards messy, unstructured, poorly maintained projects. When these projects carry huge contexts that tend to be unstructured and inconsistent, coding agents have a hard time outputting anything that is worthy of the term "improvement".
Another issue with legacy projects is that maintainers often don't have the full picture of what the codebase does and is expected to do. They at best gain enough context to do tactical changes whose scope is minimized. Coding agents don't show the same concern, and often propose sweeping changes that can and often do introduce regressions. That's frowned upon tactical-minded programmers, who don't want the risk or the work of testing and verifying their changes.
You moved the goalposts by adding the "effectively" qualifier.
I think without it, it's quite right "to frame vibe coding as something that's done by people who don't know how to code". As those are most who do it: students, junior engineers, etc.
Worse, over-reliance on it ensures they'll never really learn how to code.
In my experience this is mainly caused by a lack of investment in tests.
Vibe-coding excels when paired with test-driven development, because TDD approaches serve as validators and problem constrains. Often coding agents get stuck on but loops because they have neither context nor feedback on what represents a broken state. Tests fix both problems, and if you stop to add one then your bug loops quickly vanish.
I assume you can't trust the LLM to write these tests, since you are writing tests so the LLM will stop it's bug loop...
Inasmuch as they need to know how to write code.
For all we know the right side of the graph is actually representing something else like accelerating layoffs in the tech industry.
If I’m unemployed I’m perhaps not doing AI code completion like I do at work.
Even if “vibe coding” is dying, there is a very real boost to the productivity of people writing software from AI based tools. That’s here to stay, even if there is a human element in working with those tools. Vibe coding is not dying, unless you reductively try to define it in very limited ways.
A tool for non technical people to build things within reason.
I don't know how you're trying to define vibe coding, but I would definitely put it as more of a pejorative/negative term.
I have 20+ years of coding experience, I use coding agents well, and I'm not a vibe coder.
I would also bet that vibe coding will never become good enough to replace me because the models will never have enough context window for an entire repo of a complex app. LLMs can output code for you, but coding is only part of the job.
Not really. Vibecoding is the new code-completion, where every single developer uses extensively but is so mundane that no one bothers to blog about it. You don't see blog posts on how intellisense I'd a kin to magic, or how project starter templates speed up prototyping. No, people just use them and it's so mundane they don't think twice.
vips7L•3mo ago