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.
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.
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.
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!
I guess in the long run it could become worthwhile, but it’ll be a long road to get there
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.
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"?
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?
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.
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.
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.
> 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-pl...
LLM-enabled Zapier or Make or n8n is the future, not everyone churning out Claude-written NextJS app after NextJS app.
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.
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.
Like even in a cold capitalist analysis, the benefits to developer velocity, ease of new feature development, incident response, stability, customer trust, etc.
It doesn’t always; there are certainly areas of tech debt that bother me personally but I know aren’t worth the ROI to clean up. These become weekend projects if I want a fun win in my life, but nothing terrible happens if there’s a little friction.
Sometimes it’s because there are regular bugs and on-call becomes a drag on velocity.
Sometimes making code changes is difficult and there’s only one person who knows what going on, so you either have a bus factor risk or it limits flexibility on assigning projects / code review.
Sometimes the system’s performance is, or will be in the short–medium term, going to start causing incidents.
Sometimes incident recovery takes a long time. We had a pipeline that would take six–ten hours to run and couldn’t be restarted midway if it failed. Recovering from downtime was crazy!
Sometimes there’s a host of features whose development timelines would be sped up by more than it would take to burn down the tech debt to unlock them.
Sometimes a refactor would improve system performance enough to meaningfully affect the customer or reduce infra costs.
And then…
Sometimes you have career-driven managers and engineers who don’t want to or can’t make difficult long-term trade-offs, which is sometimes the way it is and you should consider switching teams or companies.
So I guess my question to you is: why should you burn this down?
Also what tech debt? If you have good engineers doing the vibe coding they are just way faster. And also faster at squashing bugs.
I was one-shotting whole features into our Rust code base with 2.5 last week. Absolutely perfect code, better than I could have written it in places.
Then later that week o3 solved a hard bug 2 different MLEs failed to solve as well as myself.
I have no idea why people think this stuff is bad, it’s utterly baffling to me
If I’m not learning something every day this profession holds very little for me.
This seems like a bold statement.
We’ll see if Gemini 2.5 Flash is good enough, but it definitely doesn’t feel like Google is selling for a huge loss post-training.
Yes the training is a huge investment but are they really not going to do it? Doesn’t seem optional
For some projects (e.g. your internal-facing CRUD app), cheap code is acceptable. For a high scale consumer product, the cost of premium engineering resources is a rounding error on your profits, and even small marginal improvements can generate high value in absolute dollar terms.
I’m sure vibe coding will eat the lowest end of software development. It will also allow the creation of software that wouldn’t have been economically viable before. But I don’t see it notably denting the high end without something close to AGI.
I don't see how peak vibe coding in a few months follows that. Check revenue and growth figures for products like Lovable ($10m+ ARR) or Bolt.new ($30m+ ARR). This doesn't show costs (they might in fact be deep in red) but with story like that I don't see it crashing in 3-4 months.
On the user experience/expectation side, I can see how the overhyped claims of "build complete apps" hit a peak, but that will still leave the tools positioned strong for "quick prototyping and experimentation". IMHO, that alone is enough to prevent a cliff drop.
Even allowing for the peak in tool usage for coding specifically, I don't see how that causes "AI winter", since LLMs are now used in a wide variety of cases and that use is strongly growing (and uncorrelated to the whole "AI coding" market).
Finally, "costs will go up for all sorts of reasons" claim is dubious, since the costs per token are dropping even while the models are getting better (for a quick example, cost of GPT-4.1 is roughly 50% of GPT-4o while being an improvement).
For these reasons, if I could bet against your prediction, I'd immediately take that bet.
Oh, please. Even if every cent of VC funding dries up tomorrow we'd still have years of discovering how to use LLMs and "generative models" in general to do cool, useful stuff. And by "we" I mean everyone, at every level. The proverbial bearded dude in his mom's basement, the young college grad, phd researcher, big tech researcher, and everyone in the middle. The cat is out of the bag, and this tech is here to stay.
The various AI winters came because of many reasons, none that are present today. Todays tech is cool! It's also immediately useful (oAI, anthropic, goog are already selling billions of $ worth of tokens!). And it's highly transformative. The amount of innovation in the past 2 years is bonkers. And, for the first time, it's also accessible to "home users". Alpaca was to llama what the home computer was to computers. It showed that anyone can take any of the open models and train them on their downstream tasks for cheap. And guess what, everyone is doing it. From horny teens to business analysts, they're all using this, today.
Also, as opposed to the last time (which also coincided with the .com bubble), this time the tech is supported and mainly financed by the top tech firms. VCs are not alone in this one. Between MS, goog, AMZ, Meta and even AAPL, they're all pouring billions into this. They'll want to earn their money back, so like it or not, this thing is here to stay. (hell, even IBM! is doing gen ai =)) )
So no, AI winter is not coming.
Could you please elaborate? Is this how management (at least in your company) looks at code—as a ratio of how fast it's done over how many tests it passes?
"Vibe" coding is here to stay and it's only devs who don't know how to adapt that are wishfully hoping for otherwise.
You might not be good at estimating, but professional software teams at the most successful tech companies in the world generally are.
If you read the blog post, they were able to manually migrate 3% of the tests in 1 week. Extrapolating that gives you an estimate of less than half of the 1.5 year estimate.
I’d also say there’s a pretty good chance that the 3% of tests the automated process couldn’t handle were more complicated than average and the devs would have gotten faster at doing these migrations after the first week.
It’s very unclear what was actually being compared. A team did a POC in 2023 and then some work in 2024 and then spent 6 weeks tweaking the pipeline and a final week manually migrating the tests that the automated process couldn’t handle.
But they don’t specify how many people worked on this or how many people were going to work on the original project. It could have been 1 guy on the team.
As for looking at what the actual work was, it was migrating from one test framework to another one. I’d be surprised if a team couldn’t have written a compiler to do something similar in a similar amount of time.
Color me unimpressed - it converted some test files. It didn't design any architecture, create any databases, handle any security concerns or any of the other things programmers have to do/worry about on a daily basis. It basically did source to source translation, which has been around for 30+ years.
and we don't know what is the quality of end code, it is possible that tech debt created by migration is well higher than 1.5 eng/y.
I’ve done something similar to this type of work with an llm. It produces code that is often too idiomatic, in that it introduces conventional approaches that are overkill for the task at hand. But this is almost an ideal scenario, because if the previous tests run clean, the newly converted tests can only fail by being wrong.
They can also silently reduce the tested scenarios, but that’s what code reviews are for.
> They can also silently reduce the tested scenarios, but that’s what code reviews are for.
code review of complicated scenarios is about as resource demanding as actually writing code, so shrinking time spent from 1.5y to 6 weeks totally can produce lower quality.
Seriously, the wishful thinking around this stuff is embarassing.
But given your comment history, backing up your arguments doesn't seem to be your strong suit...
I doubt that error free code is outnumbering code with errors in the training data.
1. Nobody cares. It's still worth the insane productivity improvements.
2. There is no proof that it's going to lead to long-term issues, because why would it?