3 ms·

Ok, I'm going to make a slightly controversial statement: Vibe coding is both A)potentially hugely important and transofrmative and B)massively good. Most of t

Ok, I'm going to make a slightly controversial statement: Vibe coding is both A)potentially hugely important and transofrmative and B)massively good. Most of the criticisms of vibe coding are coming from SWEs who work on large, complicated codebases whose products are used by lots of people and for whom security, edge cases, maintainability, etc. are extremely important considerations. In this context, vibe coding is obviously a horrible idea, and we are pretty far away from AI being able to do more than slightly assist around the edges. But small, bespoke scripts that will be used by exactly 1 person and are whose outputs are easily verified are actually _hugely_ important. Millions of things are probably done every single day where, if the person doing it had the skill to write up a small script, it would be massively sped up. But most people don't have that skill, and it's too expensive/there is too much friction to hire an actual programmer to solve it. AI can do these things. Each specific instance isn't a big deal, and won't make much productivity difference, but in aggregate, the potential gains are massive, and AI is already far more than good enough to be completely creating these kinds of scripts. It is just going to take people a while to shift their perspective and start asking about what small tasks they do every day that could be scripted. This is the true potential of "vibe coding". Someone who can't program, but knows what they need (and how to verify that it works), making something for their personal use.

candiddevmike 1y ago
I don't think that's a $3B market.
- MostlyStable 1y ago
  I actually literally think that these small scripts, if widely applied, are far, far more bigger than that. Even solely in the US, let alone globally. I'm also relatively certain that, if they weren't sinking money into research etc, subscriptions on inference are probably already profitable. These companies are burning money because they are investing in research, not because $10/month doesn't cover the average inference costs. Although I'd love to find a better source than the speculative ones I've seen about it.
- consumer451 1y ago
  I dislike the term, but eventually "vibe coding" should replace many existing no-code/low-code platforms, right? I see that as nearly guaranteed, for many use cases. > Low-code and no-code development platforms allow professional as well as citizen developers to quickly and efficiently create applications in a visual software development environment. The fact that little to no coding experience is required to build applications that may be used to resolve business issues underlines the value of the technology for organizations worldwide. Unsurprisingly, the global low-code platform market is forecast to amount to approximately 65 billion U.S. dollars by 2027. [0] We could argue about the exact no-code TAM, but if you have a decent chance to create the market leader for the no-code replacement, $3B seems fair, doesn't it? [0] https://www.statista.com/topics/8461/low-code-and-no-code-platforms/ https://www.statista.com/topics/8461/low-code-and-no-code-pl...
  - abxyz 1y ago
    I disagree, it's the opposite. Low code / no code is valuable because you're deferring responsibility to a system that is developed and maintained by experts. A task running once a day on Zapier is orders of magnitude better for a business than the same task being built by someone on the marketing team with vibe coding. Low code / no code platforms have a very bright future, because they can leverage LLMs to help people create tasks with ease that are also reliable. LLM-enabled Zapier or Make or n8n is the future, not everyone churning out Claude-written NextJS app after NextJS app.
    - consumer451 1y ago
      Yeah, I don't disagree with you at all. I almost wrote a longer and more nuanced comment to begin with. For one, low-code and no-code are actually two different very things. There are many use cases for low-code. The two major ones I've dealt with are MVPs where tools like Bubble are used, and the other is creating corporate internal tools, where MS Power Platform is common. Corporate IT departments are allergic to custom web apps, and have a much easier time getting a Power Platform project approved due to its easily understood security implications. That low-code use case is certainly going to be the last thing a tool like Windsurf conquers. However, even without that use case, in an AI-heavy investment environment, $3B doesn't seem all that bad to me. However, I have zero experience with M&A.
croes 1y ago
Here is my controversial statement: Vibe coding is coding like a customer hiring a programmer is coding. If all the code is written by AI it isn’t coding at all, it’s ordering.
theahura 1y ago
Strong plus one. This is more or less what my company is working on -- more and more ostensibly nontechnical people are able to contribute to codebases with seasoned engineers.
- pandemic_region 1y ago
  > ostensibly nontechnical people are able to contribute to codebases with seasoned engineers. Who is the contributor then? The AI or the prompt writer? I mean I'd be more at ease if they would just contribute their prompt instead. And then, what value does that actually have? So many mixed feelings here. At work I had a React dev merging Java code into a rather complex project. It was clearly heavily prompt assisted, and looked like the code the junior Java developer would have written. The difference is that the junior Java developer probably would have sweated a couple of days over that code, so she would know it inside out and could maintain it. The React dev would just write more prompts or ask the AI to do it. If we're confident that prompting creates good code and solid projects, well then we don't need expensive developers anymore do we?
luckylion 1y ago
> But small, bespoke scripts that will be used by exactly 1 person and are whose outputs are easily verified are actually _hugely_ important. Are they easily verified though? I have a bunch of people who are "vibe coding" in non-dev departments. It's amazing that it allows them to do things they otherwise couldn't, but I don't think it's accurate to say it's easily verified, unless we're talking about the most trivial tasks ("count the words in this text"). As soon as it gets a bit more complex (but far from "complex"), it's no longer verifiable for them except "the output looks kinda like what I expected". Might still be useful for things, but how much weight do you want to put on your sales-analysis if you've verified its accuracy by "looks intuitively correct"?
kjellsbells 1y ago
> This is the true potential of "vibe coding". Someone who can't program, but knows what they need I would argue that the real money, and the gap right now, is in vibe tasking, not vibe coding. There are millions of knowledge workers for whom the ability to synthesize and manipulate office artifacts (excel sheets, salesforce objects, emails, tableau reports, etc) is critical. There are also lots of employees who recognise that a lot of these tasks are "bullshit jobs", and a lot of employers that would like nothing more than to automate them away. Companies like Appian try to convince CEOs that digital process automation can solve this problem, but the difficult reality is that these tasks also require a bit of flexible thinking ("what do I put in my report if the TPS data from Gary doesnt show up in time?"). This is a far bigger and more lucrative market than the one made of people who need quick and dirty apps or scripts. It's also one that has had several attempts over the years to solve it. Somewhere between "keyboard automation" (macro recording, AutoHotKey type stuff) and "citizen programming" (VB type tools, power automate) and "application oriented LLM" (copilot for excel, etc) there is a killer product and a vast market waiting to escape. Amusingly, in my own experience, the major corps in the IT domain (msft, salesforce, etc etc) all seem to be determined to silo the experience, so that the conversational LLM interface only works inside their universe. Which perhaps is the reason why vibe tasking hasnt succeeded yet. Perhaps MCP or an MCP marketplace will force a degree of openness, but it's too early to say.
abxyz 1y ago
I am very much in favor of anything that makes software engineering more accessible. I have no principled objection to vibe coding. The problem I have with vibe coding is practical: it's producing more low quality code rather than allowing people to achieve more than they previously could. Almost everything I've seen achieved with vibe coding so far has been long since achievable with low / no code platforms. There is a great deal of value in the freedom that vibe coding gives (and for that reason, I am in favor of it) but the missing piece of this criticism of the criticism is that vibe coding is not the only way to write these simple scripts and it is the least reliable way. Vibe coding as the future is an uninspired vision of the future. The future is less code, not more.
- gerad 1y ago
  After watching a sales person and a PM vibe code I’ll say that existing developers are not the initial for vibe coding. Vibe coding absolutely allows non-devs to achieve more than they previously could.
  - abxyz 1y ago
    The issue is one of education, not possibility. There is so much hype around vibe coding that it has penetrated non-technical circles and given non-technical people the confidence to try and make things. The same people could use Zapier or Airtable or Tally or Retool or Bubble or n8n to achieve their goals but they didn't have the confidence to do so, or knowledge of the tooling.
- sebastiennight 1y ago
  > Almost everything I've seen achieved with vibe coding so far has been long since achievable with low / no code platforms. I tried showing someone Bubble as a solution to a fairly simple workflow (one form input, a few LLM calls, an output) that they should have been able to build in minutes. It was a horrific experience, as Bubble can't find the right balance between being "no-code" (simple) and "powerful enough" with customizations. The end result is that in my experience a non-technical person just can't get workflows to work in Bubble without investing a massive number of hours. In comparison, getting this done with either vanilla Claude.ai or Lovable is a *single* prompt. Just one! I think you are deeply underestimating the difference for true non-technical users. Or even bored/overwhelmed technical users who need something done that's non-mission-critical and would just never get done if it took hours of messing with a no-code GUI, vs. dictating it through whisper and letting the AI agent go at it.
orbital-decay 1y ago
Malleable software. This all reminds me of personal computing in 80's with BASIC in every machine, and environments like Emacs that are built for that. I think LLMs have a much better chance at this kind of software than Emacs or BASIC, but I also doubt it has any future: once AI is capable enough, you can just hide the programmatic layer entirely and tell the computer what to do.
aerhardt 1y ago
I work in Enterprise IT, I'm the CTO of a small business. People executing small scripts all over the place sounds to me like the stuff of nightmares. Especially locally, but even if it's run online in a safer environment, as long as it causes side effects in other systems, the risk is massive. And if it doesn't cause side effects, well, chances are the program is worthless. Also, I've already seen this story play out with low-code. The pitch was the same, nearly line by line: "citizen developers will be able to solve so many problems by themselves at the edges of enterprise". It didn't take. Most users could not learn the technologies, but much more importantly: they did not even know how to verbalize their requirements. Take my word for it, most people do not want to design solutions, and of those that are willing, only a small subset is able.
- rfoo 1y ago
  > I've already seen this story play out with low-code. The pitch was the same That's the point. Unlike low-code or no-code bullshit, this somehow worked. People "magically" want to design solutions, and are able to, now. > People executing small scripts all over the place sounds to me like the stuff of nightmares. Me too. However, watching how eager people want to (and they indeed can!) make progress with these LLM generated horror, I believe it's time to give up and start designing secure systems despite the existence of massive slightly broken scripts.
  - aerhardt 1y ago
    > People "magically" want to design solutions, and are able to, now. I agree that LLMs lower the barrier significantly compared to low-code/no-code, but most people are not able to design solutions because they lack the business analysis skills and are not detailed-oriented enough to follow through with the specification of requirements. Let's not even talk about the discipline to carry out maintenance over a working project in the face of changing requirements. Even if we agree that LLMs move a lot of the work up the stack towards business analysis / product ownership / solution design, my experience in Enterprise IT in companies ranging from small to gigantic is that users do not magically become BAs / POs / PMs. There's a reason those are professionalized and specialized roles. I wouldn't mind being proven wrong, it's not like I feel personally threatened or anything. I feel it's the integrity of the systems I oversee that would be threatened. > I believe it's time to give up and start designing secure systems OK, well I'm not going to bear that responsibility for that, I have enough on my plate as it is. I'm not allowing an arbitrary sales rep to interact with our production Salesforce instance by automated means, period. Even if they have the proper permission levels configured to a tee in Salesforce, I can think of a thousand ways they could badly mess up their own slice of data. Interacting with the local machine: also potentially a supermassive black hole of vulnerabilities. Some of them possibly more serious than data loss, such as the syphoning of data to malicious actors. If someone can think of secure ways for citizen devs to interact with critical enterprise systems via scripting, then fine. I'll sit here waiting!

candiddevmike 1y ago

I don't think that's a $3B market.

MostlyStable 1y ago
I actually literally think that these small scripts, if widely applied, are far, far more bigger than that. Even solely in the US, let alone globally. I'm also relatively certain that, if they weren't sinking money into research etc, subscriptions on inference are probably already profitable. These companies are burning money because they are investing in research, not because $10/month doesn't cover the average inference costs. Although I'd love to find a better source than the speculative ones I've seen about it.
consumer451 1y ago
I dislike the term, but eventually "vibe coding" should replace many existing no-code/low-code platforms, right? I see that as nearly guaranteed, for many use cases. > Low-code and no-code development platforms allow professional as well as citizen developers to quickly and efficiently create applications in a visual software development environment. The fact that little to no coding experience is required to build applications that may be used to resolve business issues underlines the value of the technology for organizations worldwide. Unsurprisingly, the global low-code platform market is forecast to amount to approximately 65 billion U.S. dollars by 2027. [0] We could argue about the exact no-code TAM, but if you have a decent chance to create the market leader for the no-code replacement, $3B seems fair, doesn't it? [0] https://www.statista.com/topics/8461/low-code-and-no-code-platforms/ https://www.statista.com/topics/8461/low-code-and-no-code-pl...
- abxyz 1y ago
  I disagree, it's the opposite. Low code / no code is valuable because you're deferring responsibility to a system that is developed and maintained by experts. A task running once a day on Zapier is orders of magnitude better for a business than the same task being built by someone on the marketing team with vibe coding. Low code / no code platforms have a very bright future, because they can leverage LLMs to help people create tasks with ease that are also reliable. LLM-enabled Zapier or Make or n8n is the future, not everyone churning out Claude-written NextJS app after NextJS app.
  - consumer451 1y ago
    Yeah, I don't disagree with you at all. I almost wrote a longer and more nuanced comment to begin with. For one, low-code and no-code are actually two different very things. There are many use cases for low-code. The two major ones I've dealt with are MVPs where tools like Bubble are used, and the other is creating corporate internal tools, where MS Power Platform is common. Corporate IT departments are allergic to custom web apps, and have a much easier time getting a Power Platform project approved due to its easily understood security implications. That low-code use case is certainly going to be the last thing a tool like Windsurf conquers. However, even without that use case, in an AI-heavy investment environment, $3B doesn't seem all that bad to me. However, I have zero experience with M&A.

croes 1y ago

Here is my controversial statement: Vibe coding is coding like a customer hiring a programmer is coding. If all the code is written by AI it isn’t coding at all, it’s ordering.

theahura 1y ago

Strong plus one. This is more or less what my company is working on -- more and more ostensibly nontechnical people are able to contribute to codebases with seasoned engineers.

pandemic_region 1y ago
> ostensibly nontechnical people are able to contribute to codebases with seasoned engineers. Who is the contributor then? The AI or the prompt writer? I mean I'd be more at ease if they would just contribute their prompt instead. And then, what value does that actually have? So many mixed feelings here. At work I had a React dev merging Java code into a rather complex project. It was clearly heavily prompt assisted, and looked like the code the junior Java developer would have written. The difference is that the junior Java developer probably would have sweated a couple of days over that code, so she would know it inside out and could maintain it. The React dev would just write more prompts or ask the AI to do it. If we're confident that prompting creates good code and solid projects, well then we don't need expensive developers anymore do we?

luckylion 1y ago

> But small, bespoke scripts that will be used by exactly 1 person and are whose outputs are easily verified are actually _hugely_ important. Are they easily verified though? I have a bunch of people who are "vibe coding" in non-dev departments. It's amazing that it allows them to do things they otherwise couldn't, but I don't think it's accurate to say it's easily verified, unless we're talking about the most trivial tasks ("count the words in this text"). As soon as it gets a bit more complex (but far from "complex"), it's no longer verifiable for them except "the output looks kinda like what I expected". Might still be useful for things, but how much weight do you want to put on your sales-analysis if you've verified its accuracy by "looks intuitively correct"?

kjellsbells 1y ago

> This is the true potential of "vibe coding". Someone who can't program, but knows what they need I would argue that the real money, and the gap right now, is in vibe tasking, not vibe coding. There are millions of knowledge workers for whom the ability to synthesize and manipulate office artifacts (excel sheets, salesforce objects, emails, tableau reports, etc) is critical. There are also lots of employees who recognise that a lot of these tasks are "bullshit jobs", and a lot of employers that would like nothing more than to automate them away. Companies like Appian try to convince CEOs that digital process automation can solve this problem, but the difficult reality is that these tasks also require a bit of flexible thinking ("what do I put in my report if the TPS data from Gary doesnt show up in time?"). This is a far bigger and more lucrative market than the one made of people who need quick and dirty apps or scripts. It's also one that has had several attempts over the years to solve it. Somewhere between "keyboard automation" (macro recording, AutoHotKey type stuff) and "citizen programming" (VB type tools, power automate) and "application oriented LLM" (copilot for excel, etc) there is a killer product and a vast market waiting to escape. Amusingly, in my own experience, the major corps in the IT domain (msft, salesforce, etc etc) all seem to be determined to silo the experience, so that the conversational LLM interface only works inside their universe. Which perhaps is the reason why vibe tasking hasnt succeeded yet. Perhaps MCP or an MCP marketplace will force a degree of openness, but it's too early to say.

abxyz 1y ago

I am very much in favor of anything that makes software engineering more accessible. I have no principled objection to vibe coding. The problem I have with vibe coding is practical: it's producing more low quality code rather than allowing people to achieve more than they previously could. Almost everything I've seen achieved with vibe coding so far has been long since achievable with low / no code platforms. There is a great deal of value in the freedom that vibe coding gives (and for that reason, I am in favor of it) but the missing piece of this criticism of the criticism is that vibe coding is not the only way to write these simple scripts and it is the least reliable way. Vibe coding as the future is an uninspired vision of the future. The future is less code, not more.

gerad 1y ago
After watching a sales person and a PM vibe code I’ll say that existing developers are not the initial for vibe coding. Vibe coding absolutely allows non-devs to achieve more than they previously could.
- abxyz 1y ago
  The issue is one of education, not possibility. There is so much hype around vibe coding that it has penetrated non-technical circles and given non-technical people the confidence to try and make things. The same people could use Zapier or Airtable or Tally or Retool or Bubble or n8n to achieve their goals but they didn't have the confidence to do so, or knowledge of the tooling.
sebastiennight 1y ago
> Almost everything I've seen achieved with vibe coding so far has been long since achievable with low / no code platforms. I tried showing someone Bubble as a solution to a fairly simple workflow (one form input, a few LLM calls, an output) that they should have been able to build in minutes. It was a horrific experience, as Bubble can't find the right balance between being "no-code" (simple) and "powerful enough" with customizations. The end result is that in my experience a non-technical person just can't get workflows to work in Bubble without investing a massive number of hours. In comparison, getting this done with either vanilla Claude.ai or Lovable is a *single* prompt. Just one! I think you are deeply underestimating the difference for true non-technical users. Or even bored/overwhelmed technical users who need something done that's non-mission-critical and would just never get done if it took hours of messing with a no-code GUI, vs. dictating it through whisper and letting the AI agent go at it.

orbital-decay 1y ago

Malleable software. This all reminds me of personal computing in 80's with BASIC in every machine, and environments like Emacs that are built for that. I think LLMs have a much better chance at this kind of software than Emacs or BASIC, but I also doubt it has any future: once AI is capable enough, you can just hide the programmatic layer entirely and tell the computer what to do.

aerhardt 1y ago

I work in Enterprise IT, I'm the CTO of a small business. People executing small scripts all over the place sounds to me like the stuff of nightmares. Especially locally, but even if it's run online in a safer environment, as long as it causes side effects in other systems, the risk is massive. And if it doesn't cause side effects, well, chances are the program is worthless. Also, I've already seen this story play out with low-code. The pitch was the same, nearly line by line: "citizen developers will be able to solve so many problems by themselves at the edges of enterprise". It didn't take. Most users could not learn the technologies, but much more importantly: they did not even know how to verbalize their requirements. Take my word for it, most people do not want to design solutions, and of those that are willing, only a small subset is able.

rfoo 1y ago
> I've already seen this story play out with low-code. The pitch was the same That's the point. Unlike low-code or no-code bullshit, this somehow worked. People "magically" want to design solutions, and are able to, now. > People executing small scripts all over the place sounds to me like the stuff of nightmares. Me too. However, watching how eager people want to (and they indeed can!) make progress with these LLM generated horror, I believe it's time to give up and start designing secure systems despite the existence of massive slightly broken scripts.
- aerhardt 1y ago
  > People "magically" want to design solutions, and are able to, now. I agree that LLMs lower the barrier significantly compared to low-code/no-code, but most people are not able to design solutions because they lack the business analysis skills and are not detailed-oriented enough to follow through with the specification of requirements. Let's not even talk about the discipline to carry out maintenance over a working project in the face of changing requirements. Even if we agree that LLMs move a lot of the work up the stack towards business analysis / product ownership / solution design, my experience in Enterprise IT in companies ranging from small to gigantic is that users do not magically become BAs / POs / PMs. There's a reason those are professionalized and specialized roles. I wouldn't mind being proven wrong, it's not like I feel personally threatened or anything. I feel it's the integrity of the systems I oversee that would be threatened. > I believe it's time to give up and start designing secure systems OK, well I'm not going to bear that responsibility for that, I have enough on my plate as it is. I'm not allowing an arbitrary sales rep to interact with our production Salesforce instance by automated means, period. Even if they have the proper permission levels configured to a tee in Salesforce, I can think of a thousand ways they could badly mess up their own slice of data. Interacting with the local machine: also potentially a supermassive black hole of vulnerabilities. Some of them possibly more serious than data loss, such as the syphoning of data to malicious actors. If someone can think of secure ways for citizen devs to interact with critical enterprise systems via scripting, then fine. I'll sit here waiting!