The Elephant in the Vibe Coding Room

I woke up yesterday to a post from Andrea Bosoni, who has become one of my favorite people to follow on Twitter. Andrea’s a marketer who knows his stuff and has a penchant for telling it like it is—and as I read his post, I smiled.

Andrea just said the quiet part out loud. Again.

Before you write me off——this post is pro-vibe coding (keep reading). But Andrea’s comments aren’t wrong—there’s a chasm that still needs to be crossed. And in order to cross it, we have to first have to understand why it’s there.

The undeniable truths of vibe coding

I think it’s fair to say opinions on vibe-coding right now are extremely bifurcated. 

Some people genuinely believe we’ve ushered in an era where “anyone can build anything,” whereas other people see it as little more than a recipe for creating the Chef Boyardee of spaghetti code. 

Regardless of where you fall, let’s establish some common ground—I think these points are generally agreed upon.

• Vibe-coding platforms—right now—introduce all sorts of problems. 
• Vibe coding platforms will only get better—this is the worst they’ll ever be.
• There are vibe-coding platforms that target developers (Cursor, Claude) and there are vibe coding platforms that target non-technical customers (Loveable, Bolt)—and these are very different target markets.
• More people being able to build digital products is a good thing!

If we can agree on these four things, then we’re doing ourselves a disservice if we don’t take the time to really evaluate Andrea’s comments and consider how we can bridge this gap. 

This post is about how we can do just that.

People are quiet-quitting vibe coding in droves

Behind the insane revenue charts, the valuations, the funding rounds, the hackathons, the concerts, the cease-and-desist letters, and the flashy demos let’s address the elephant in the room—people are quiet-quitting vibe coding in droves.

I know because Andrea did. 

I know because I did. 

And I know because all of a sudden 80% of the software projects that I’m seeing in our support queue that are a total disaster are vibe coded. For a non-technical user, vibe coding is messy and frustrating. Perhaps worst of all, this became apparent to me fast—yet I waited to churn.

This is the future of building digital products, right? Surely I can’t cancel my subscription to that.

So I waited—two or three months before I quit. And all you have to do is read the comments on Andrea’s tweet to know that many others are doing the same.

It’s not to say that there’s no utility in these tools—for super simple sites or in the hands of the technically skilled, these platforms provide fantastic utility already. But for a truly non-technical person they simply are not the best solution right now for much more than landing pages or sites with very basic functionality. As soon as a project takes on even a reasonable amount of technical complexity, the wheels start to fall off. 

Jason Lemkin is one of the few that’s documented this well. While Jason is “non-technical” he’s built successful software companies before and knows lightyears more than the average person about what it takes. Yet his experience of building with Replit is about the furthest thing from a sales pitch you could ever hope to read. He had tons of money, tons of patience, tons of knowledge, and a level of commitment to making it work far beyond what a normal person would have. And the experience still sucked.

Which leads me to my next point…

Developers are benefitting most from vibe coding tools today

I think it’s incredibly important to call out that vibe coding tools are delivering huge returns today for one group—developers! While I think the idea that vibe coding tools are “one-shotting” features is mostly nonsense, competent developers are certainly 80%-ing relatively simple features with vibe coding tools already. There are significant productivity gains to be had. But I think it’s pretty clear the playing field has not been “leveled” in any meaningful way—developers are that much more capable now, whereas non-technical users are increasingly thrown into scenarios from which they have no way of escaping.

There’s a sliding scale when it comes to technical ability—everything from “Dial-up Granny” to “Tien Ehx” represented by the illustration below.

Tien Ehx is a "10x" software engineer working at a hot Silicon Valley start-up, where he's using AI tools to pump out 10,000+ lines of code per day. Vibe coding tools are already serving Tien and his team well, but as we slide towards “Dial-up Granny” the tools simply aren’t good enough…yet. 

The different shades of non-technical builders 

As we consider the “non-technical” user of vibe coding tools, we can be talking about very, very different people. On the extreme end we have “Dial-up Granny”—this person has almost no fluency in computers. They probably check their email from time to time, but if you asked them what a URL is they probably have no clue. 

Then you have the advanced no-coders. While these people aren’t software engineers, they’re fluent and extremely comfortable working with technology. They work with APIs, send webhooks, store data in a database, and may have swapped a JWT access token or two. They even say things like “context area” in every conversation they have, so you know they belong.

In short, these people are the ones who have become the loudest advocates for vibe-coding in the world of the non-technical builder—and that makes sense, as they’re closest to Tien Ehx. These are also the people who hear about Andrea quitting and say, “You just need to stick with it, then it will click.” 

And that’s of course not wrong! Persistence is key when you’re learning anything. But something I’ve also witnessed is the advanced no-coders all too often seem to hoist trophies based on the complexity of what they’ve been able to build, rather than its commercial success. Exhausting countless credits and hours of frustration in the name of learning is awesome—but building something more “advanced” almost never improves your chances of building a more successful business. Across all of the products that I’ve seen built by non-technical founders, the simple ones almost always outperform the complex ones. 

I seriously question if vibe-coding platforms will ever be a great solution as you go to the extreme end of the non-technical spectrum. Squarespace continues to dwarf all of these platforms in size because there’s a real market and a real need for something far less technical—something where the idea that you’re writing code is obfuscated altogether.

For reasons that remain beyond me, people in the tech industry generally hate to acknowledge this.

Analyzing Andrea’s problem statement

Returning to Andrea’s tweet, the problem that sent him over the edge was trying to implement a “Mark as complete” button within his project. For context, this is most likely a course that he was building and after completing a lesson he wanted the user to click a button to mark that they’d completed the lesson. This is typically used to track course progress, so that when you log back into your course platform you can pick up where you left off.

In a land before vibe-coding—which I fondly recall as B.V.C.—non-technical builders were using “no-code” tools to bring similar creations to life.

In fact, I helped dozens of such people implement the exact functionality that Andrea is referring to. We ended up creating a Webflow course template and incredibly specific documentation to help non-technical users through this—it was still a struggle for many, but doable for most.

The problem that nearly everyone seems to be missing right now when it comes to vibe-coding I believe to be a simple one—there are simply tons of different ways to build any given feature, and a lot of different considerations to factor into your decision making. 

This is what software engineers do—they weigh those decisions. The vide-coding world seems very comfortable trivializing the importance of such decisions.

Non-technical users don’t even know what they should be considering—they just have a relatively rudimentary sense of what they want any given feature to do.

As an example—if you ask a non-technical user to prompt their way to an authentication system they’ll likely write a prompt like “Add a login form to my site.” If you ask a developer the same question, they’ll spend time considering whether they build authentication that uses session based storage, versus local storage, versus a cookie to store the authenticated status or the user. This sort of decision has reprecussions for the entire project. 

Screaming “You just need better prompts!” at a non-technical user is pointless—they don’t even know that they should be considering these things. 

Which leads me to one of the most important conclusions in this article—non-technical users need less choice. 

The path to better serving the non-technical builder

Alright—so let’s say vibe coding tools have won over the advanced no-coders as early adopters and Dial-up Granny is never going to be a good fit. How do these platforms win over the Andreas of the world?

This is where the size of the vibe-coding opportunity truly explodes—this is why Accel invested $200M in Lovable.

This is where I’ve learned the most based on helping non-technical people build web apps over the last 8 years—this is the version of the future that I think can and will play out.

Vibe coding platforms need to embrace being opinionated

This one is tough because it comes in direct conflict with what the advanced no-coders love about vibe-coding—they’re intoxicated by their newfound ability to write code without the shackles that templates and no-code tools once put on them.

But man-oh-man let me tell you—what the non-technical need is less choice, not more.

“Here’s how to add authentication to your site” works far, far better than “Here are three options to consider in terms of how you add authentication to your site.”

Non-technical builders become paralyzed by choices that they are not well informed enough to make.

I’ve seen this play out over-and-over-and-over.

Vibe coding platforms need to embrace templates as a starting point

"Templates" is something of a dirty word to many—especially the technically or creatively capable. But if we can move beyond our personal baggage that we’ve attached to the term, we typically use a templated approach to anything that we learn.

• We first learn to ride a bike with training wheels
• We first learn to hit a baseball off of a tee

A template is a way of setting someone up for success, with built in best practices. If Andrea had started with a vibe coding course template that had built in “Mark as complete” functionality, he probably wouldn’t have quit vibe coding.

Vibe coding platforms need to provide pre-written prompts

As I’ve played with vibe coding tools more and more, there’s no denying that seeing specific examples of well written prompts is super helpful in learning. And this is another area where the vibe coding platforms can learn from their “no-code” predecessors.

For example, Outseta today provides all sorts of prewritten javascript snippets that our customers can drop into the header of their sites that bring more advanced functionality to their site. Many of our customers generally have no idea how these scripts work from a technical perspective, but we’ve given them the functionality in a format they can handle—a script that just needs to be dropped into the header of a web page. Many of our customers have even told us that they’ve learned a bit about coding through the use of these scripts—and pre-written prompts represent the same opportunity.

I think you’ll see all of the vibe-coding platforms build out libraries of pre-written prompts over time.

Vibing coding delivers big value in small ways

I know that many people will scoff at the points I’ve made above—vibe coding is supposed to get us away from templated, boilerplate type of functionality—right?!?! 

I think that’s wrong—everyone who learns to ride a bike starts out with training wheels. We’re also underselling the drastic leap forward that vibe-coding still represents. There’s no shame in starting with a course template if you can then simply prompt to make it your own. 

I think that looks like:

• “I just uploaded a new color palette—update the site to use this.”
• “Increase the price of my subscription plan by $20 per month—but allow all of my existing customers to continue paying the same price.”
• “When this form on my site is submitted, forward the lead to my email and also send it to Jenny.”
• “The size of the video player looks too small to me on desktop—make it slightly larger.”

If you think these sorts of changes don’t open a whole new world of possibilities for a non-technical audience… you’re wrong. These are the sorts of things non-technical builders often lose hours trying to figure out.

This shouldn’t be controversial—it’s a pattern that’s played out with consistency

While this take may not be the awe-inspiring take that the VCs want you to buy into, I think it’s hard to argue that a more no-code-ish, templated, Squarespacey approach to vibe-coding is exactly what it’s going to take to inch closer to mass adoption by non-technical builders.

Frankly this audience isn’t awed by the idea that they’re writing code—they’re indifferent.

The opportunity lies in making it easy to make products that function well—that’s the magic, no matter what you call it.

And if you can get a non-technical user 80% of the way there and give them some new vibey powers—uploading a new color palette is a massive improvement over figuring out how to create a class or write CSS.

And the truly sophisticated products will always be best created by developers.

‍