Most things that people who don't know how to code want to build are not actually dead simple, and they often won't be able to articulate what they need very well.
Ironically, an experienced coder that needs a specific and simple tool quick will have a better time.
> Most things that people who don't know how to code want to build are not actually dead simple, and they often won't be able to articulate what they need very well.
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.
>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.
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.
As someone who vibes codes web apps that are being used by people, they take way way longer than initially expected. The prototype can take one shot, and the full prod implementation can take weeks to months. If you aren’t able to stick it out it will die but if you are willing to learn how to prompt to integrate Auth, email, security, performance than you can create truly incredible apps with no coding experience. But it’s basically a new skill in and of itself. Claude Code already gets the prototype to final product gap down a lot because it’s so good and getting better but it still makes mistakes and needs lots and lots and lots of nudging and directing and reminders and writing docs and getting other agents to check work based on docs ect.
When you say with no coding experience, what does that mean to you? I can get near miraculous results from vibe coding, but it often gets stuck in weird “bug loops” where it goes back and forth between broken states, and I have to understand either like bracket formatting, or be able to research library failures and conflicts. I suppose with no coding experience I could maybe muddle through, but itw would require hours of patience and probably learning some coding fundamentals to do something I can identify in sometimes seconds.
> I can get near miraculous results from vibe coding, but it often gets stuck in weird “bug loops” where it goes back and forth between broken states, and I have to understand either like bracket formatting, or be able to research library failures and conflicts.
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.
Literally could only do basic html css before. Now I can build solid Sveltekit web apps from scratch. It’s still hard and frustrating. I’ve spent all day trying to get OTP auth working it’s very frustrating it misses things. But other times you can one shot whole features. Supabase MCP has been an absolute game changer. Database fluidity in development is really key. Trying to push migrations and generate types manually beforehand add so much time.
This has been my experience as well. I've gotten really good results from Claude Code, but sometimes I have to press esc when I see it doing something stupid and course correct. It really seems to struggle with recursive solutions to problems or deeply nested constructs. Because I have a programming background, I know better when to interrupt and provide different directions or know when to abandon contexts better than someone without "coding experience" ever could. Just the years and years of debugging experience on your own projects will position you infinitely better than someone who has never really had to dig into complex problems and figure out what's going wrong. Sometimes you have to tell the agent specifically which logs to look into or which likely problem spaces it's encountering and knowing what sort of logs exist on a system is important for that.
Tradition is circular, it's only done based on tradition. I would prefer to call it classical coding because it's still useful in modern frameworks and a wonderful base skill set that can enhance current practice. Take for example, Bogo sort, a "trad" algorithm. No one uses it and the only reason people would use it is to continue some kind of tradition. Merge sort is one of the classics. Asking an LLM to sort a list might be a modern approach, but sometimes the classics are there for a reason.
This guy keeps writing negative articles trying to wish into existence his bad call on the usefulness of LLMs. He really isn’t an expert, as he claims. Instead he cherry picks anecdotes to feed his confirmation bias.
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.
Most things that people who don't know how to code want to build are not actually dead simple, and they often won't be able to articulate what they need very well.
Ironically, an experienced coder that needs a specific and simple tool quick will have a better time.
> Most things that people who don't know how to code want to build are not actually dead simple, and they often won't be able to articulate what they need very well.
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.
>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.
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.
As someone who vibes codes web apps that are being used by people, they take way way longer than initially expected. The prototype can take one shot, and the full prod implementation can take weeks to months. If you aren’t able to stick it out it will die but if you are willing to learn how to prompt to integrate Auth, email, security, performance than you can create truly incredible apps with no coding experience. But it’s basically a new skill in and of itself. Claude Code already gets the prototype to final product gap down a lot because it’s so good and getting better but it still makes mistakes and needs lots and lots and lots of nudging and directing and reminders and writing docs and getting other agents to check work based on docs ect.
When you say with no coding experience, what does that mean to you? I can get near miraculous results from vibe coding, but it often gets stuck in weird “bug loops” where it goes back and forth between broken states, and I have to understand either like bracket formatting, or be able to research library failures and conflicts. I suppose with no coding experience I could maybe muddle through, but itw would require hours of patience and probably learning some coding fundamentals to do something I can identify in sometimes seconds.
> I can get near miraculous results from vibe coding, but it often gets stuck in weird “bug loops” where it goes back and forth between broken states, and I have to understand either like bracket formatting, or be able to research library failures and conflicts.
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.
So vibe coders need to know how to write tests? I doubt that lowers the effective barrier of entry to coding very much.
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...
Literally could only do basic html css before. Now I can build solid Sveltekit web apps from scratch. It’s still hard and frustrating. I’ve spent all day trying to get OTP auth working it’s very frustrating it misses things. But other times you can one shot whole features. Supabase MCP has been an absolute game changer. Database fluidity in development is really key. Trying to push migrations and generate types manually beforehand add so much time.
This has been my experience as well. I've gotten really good results from Claude Code, but sometimes I have to press esc when I see it doing something stupid and course correct. It really seems to struggle with recursive solutions to problems or deeply nested constructs. Because I have a programming background, I know better when to interrupt and provide different directions or know when to abandon contexts better than someone without "coding experience" ever could. Just the years and years of debugging experience on your own projects will position you infinitely better than someone who has never really had to dig into complex problems and figure out what's going wrong. Sometimes you have to tell the agent specifically which logs to look into or which likely problem spaces it's encountering and knowing what sort of logs exist on a system is important for that.
Yeah, well... I'm gonna go vibe code my own Substack, with zoomable webpages and zoomable pictures. In fact, forget Substack!
It’s just “coding” now apparently. Time to coin the term “trad coding” or “trad engineering”
In my mind, Donald Knuth is the trad programmer. Though I hear he sometimes uses a computer.
Legacy development
Tradition is circular, it's only done based on tradition. I would prefer to call it classical coding because it's still useful in modern frameworks and a wonderful base skill set that can enhance current practice. Take for example, Bogo sort, a "trad" algorithm. No one uses it and the only reason people would use it is to continue some kind of tradition. Merge sort is one of the classics. Asking an LLM to sort a list might be a modern approach, but sometimes the classics are there for a reason.
God I hope so.
This guy keeps writing negative articles trying to wish into existence his bad call on the usefulness of LLMs. He really isn’t an expert, as he claims. Instead he cherry picks anecdotes to feed his confirmation bias.
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.
Vibe coding will simply be the new "no-code".
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.
> Vibe coding will simply be the new "no-code".
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.
Just be careful not to correlate graphs and make assumptions about the data.
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.