Most People Can't Vibe Code. Here's How We Fix That.
Building for consumers has been harder than for developers
| America | Tech | Opinion | Culture | Charts |
We’ve eagerly watched “vibe coding” take off as a new creative medium, but we have to admit that - at least so far - most people still can’t do it! Don’t stress about it if that’s you; help is on the way - but DO tell us about tools and approaches you find really helpful, we’d love to hear about them. -AD
Vibe coding promised to democratize software engineering. Instead, it’s created a new class of power users without touching everyday consumers.
We are living through a golden age of software. People are shipping insanely cool apps in an afternoon, automating their entire lives with agents, and prompting tools that would’ve taken a dev team months.
But the people drawn to vibe coding are largely developers, founders, designers, and PMs. They’re daily active users of X, fans of Karpathy’s YouTube videos, or regular listeners to Dwarkesh. They know what a terminal is.
That’s maybe 1% of the population.
Most people still think AI = ChatGPT. If they do see one of these vibe coding demos, it’s like a video of someone doing a backflip — cool to see, but not something they’re going to try at home.
The Gap Is Enormous
Try to put yourself in the mindset of someone who has never coded before. This is going to be difficult if you’re technical or even tech-adjacent – you’ve internalized so many things that the average person has never encountered.
I have zero engineering background, so I’m a good test case. I’d never interacted with either a CLI or an IDE before I started vibe coding. Now, my success rate is probably 50/50 on the projects I start. I spend a lot of time dragging screenshots and copying error messages into Cursor and asking for help.
Take OpenClaw (formerly ClawdBot). To run it, you need a separate machine (Mac Mini or VPS), terminal access, and the ability to configure your own security protocols. Did I get it up and running? Yes. Am I using it to its full potential? Absolutely not.
I’m not the only one who has struggled with vibe coding – in fact, we may be the silent majority. I came across a blog post from a writer that captures this perfectly. He was trying to vibecode an app to pull quotes from his newsletter (h/t @broderick). After getting off to a solid start, he quickly ran into problems.
He got further than most non-technical people ever would – but still ended up frustrated, and feeling unsuccessful. This is not the kind of experience that takes a product mainstream.
The Product Layer
Matt Rickard wrote years ago that every Unix command eventually becomes a startup. Technical people build powerful but arcane tools, then someone packages them for everyone else.
We’re in the Unix era of AI agents. The raw capabilities are incredible – but they’re buried under terminal commands, API keys, and YAML configs. Enter the product layer.
Companies like Poke (by Interaction Company) and Wabi get this. Poke built an AI assistant that lives in iMessage – no setup, and no terminal. You just text it. Wabi is building what CEO Eugenia Kuyda calls “YouTube for apps” – a platform where you can prompt an app into existence and share it with friends. No integrations, authentication, or API keys required.
These aren’t tools for developers. They’re products for people. Tools give you capabilities to build something yourself. Products give you the outcome you’re looking for.
Why This Is Hard
Building for consumers is harder than building for developers. Developers will work through complex problems and tolerate rough interfaces, while consumers will abandon a product if a page takes too long to load. You can ship tools to developers – but you need to ship products to consumers.
The setup problem. Developers will SSH into a server, configure environment variables, manage dependencies. Consumers need zero-setup: open browser, start building. Everything runs in the cloud, sandboxed and secure by default.
The security problem. Veracode’s 2025 report found that nearly half of all AI-generated code contains security vulnerabilities. Developers might catch these. Consumers won’t. As one researcher put it: applications built through vibe coding are “often built by inexperienced users, who either don’t configure the runtime environment at all, or configure it according to advice from the same AI.” Consumer products need guardrails baked in—not opt-in security that requires expertise.
The imagination problem. This one’s underrated. Developers often know what they want to do with a coding agent and have mental models for what software can do. Non-technical people can’t even imagine what they can create. The best consumer products will help people discover what’s possible—templates, use cases, or a feed of “what people like you built this week.”
The deployment problem. Many consumers struggle to understand how to deploy a product they’ve built (hence the “localhost” meme). Consumer tools need to collapse this complexity entirely—you hit “done” and your thing exists in the world.
The Opportunity
Almost everyone uses software. Very few people have ever built it. That’s starting to change with vibe coding—but so far, it’s only come for people who are already somewhat technical.
The startups that figure out vibe coding for consumers will do what Squarespace did for websites and Canva did for design: take something that requires expertise and make it accessible.
Right now, vibe coding is a spectator sport for most of America. Someone’s going to build the on-ramp. When they do, we won’t just have more developers—we’ll have millions of people building software who never thought they could.
If you’re building in this space, reach out. I’m at @venturetwins or jmoore@a16z.com.
This newsletter is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. Furthermore, this content is not investment advice, nor is it intended for use by any investors or prospective investors in any a16z funds. This newsletter may link to other websites or contain other information obtained from third-party sources - a16z has not independently verified nor makes any representations about the current or enduring accuracy of such information. If this content includes third-party advertisements, a16z has not reviewed such advertisements and does not endorse any advertising content or related companies contained therein. Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z; visit https://a16z.com/investment-list/ for a full list of investments. Other important information can be found at a16z.com/disclosures. You’re receiving this newsletter since you opted in earlier; if you would like to opt out of future newsletters you may unsubscribe immediately.
 | A guest post by
|
I have a masters in computer engineering. Started coding in the 70s.
I now run a retail bakery and do all the coding for the web site and our back end - i.e. payroll and accounting.
Here's the deal on using AI for coding from someone who has been coding since the start.
In the end, the basics have not really changed with AI. Its just the next level of abstraction that has been going on since I started coding. Coding started as assembler, went to basic, then C/C++, scripting like Awk/Python, web created HTML, PHP, Javascript, etc, DBs have SQL... You get the point. All those made it more efficient for me as the "programmer" to create an "app".
AI is a layer on top of all these. It can generate any of these. But here's the catch, you need to be very, very, very clear on what you are trying to build. You need to know how to state requirements in a way that the AI create the code that aligns with what you want. You need to be able to translate requirements into tests. That debugs both your requirements and the code generated by the AI. When it does not work, you need to be able to figure out where the problem is. AI can help but only if you give it information to help on.
Vibe coding certainly works for creating "toy" applications for your personal fun.
AI is not magical. It's just an abstraction layer on top of all the current coding languages.
Like all the AI chatbots, it comes down to how good you are at the prompts. Those prompts are the requirements. Also how good you are at checking the results - i.e.hallucinations - by both you (you really did not specify the prompt precisely) or by the AI.
Junior coders just implemented requirements. They ideally created test plans for the requirements. AI makes junior coders less relevant. For AI to work, the people who defined the requirements and the senior engineers that understand the whole system are the key.
Those people were once junior coders. The question is how does someone new to doing software get sufficient experience to define requirements and understand the system. Even more importantly, how to test and debug the requirements.
There is no magic in AI. Its just another abstraction compiler. A very costly one in this case. It's not clear that the cost of running and training the AI engine really is less than just having Junior programmers create code from requirements. The business case is not proven. Copilot and Claude are subsidized today by investors. If they were not subsidized, would they really be lower cost than just hiring a human junior programmer.
That remains to be seen.
For me and my business. Copilot has made it so I can do much more in my less time. But I don't even pay for Copilot. I can use a free version. I don't use the copilot embedded in Visual Studio really. Auto code line recommendations can be disruptive.
That's my take on doing this for a year now. Happy vibe coding out there.
So nice to see a16z sharing here. Some free guide on coding in the AI era
from the 🇧🇷 community ✨
https://ocoelhobranco.substack.com/p/o-coelho-branco-026-extra-mastering