The Vibe Coding Economy: When 'Make This' Is the Spec

Three sentences and a working app

In February 2026 a 16-year-old in Tirupati shipped a study-group scheduling app to her school's WhatsApp community. Two thousand users in the first week. The technical history of that app is: she spent forty minutes describing what she wanted to a chat interface, accepted most of what came back, fixed two layout glitches she didn't like, and deployed.

She doesn't know JavaScript. She doesn't know what a database is. She would not pass a junior developer interview. She built and shipped a working product. This is the thing the term "vibe coding" was trying to name, before the joke calcified.

The economics nobody priced in

The original argument against vibe coding was correctness: that the code would be subtly broken, that nobody would understand it, that maintenance would collapse on itself in six months. All of these criticisms are partly right and entirely beside the point.

The thing the early skeptics missed is that most software doesn't need to last six months. A scheduling tool for one school. A pricing calculator for one consultant's spreadsheet. A landing page for a one-week event. An internal dashboard a five-person team will replace next quarter anyway. Software in this category — call it disposable software — has always existed. It used to live in Excel and Airtable because nothing else was cheap enough to write.

Vibe coding made the cost of a bespoke app drop below the cost of an Excel hack. That's the entire economic shift. It's not that AI writes better code; it's that AI lowered the floor of who could write any code at all.

Who's actually doing it

The vibe coding cohort that's shipped real products in 2026 is not who the early jokes suggested. It's not "PMs who can't code." The actual demographic is more like:

Domain experts who happen not to be developers. Lawyers building case-management tools. Teachers building grading workflows. Nurses building patient-tracking spreadsheets-that-aren't-spreadsheets. The thing they all share is they know exactly what the tool needs to do because they're the user. The translation step from "what I need" to "working software" used to require a developer. Now it doesn't.

Solo operators in non-technical businesses. A freelance graphic designer building her own client portal. A bakery owner building inventory tracking. The audience is small, the requirements are specific, and hiring a developer was never going to make sense. These tools used to live in the gap between "doable in Google Sheets" and "worth paying $15K to build properly." That gap is gone.

Senior developers using it for prototyping. Quietly. Not the demographic that makes the meme, but the largest one by token volume. A 20-year veteran engineer using Cursor's agent mode to bash out a working prototype in 90 minutes that they'll then rewrite by hand for production. The prose-driven first draft has become the norm.

What still breaks

The criticisms aren't wrong, they're just narrower than originally argued. Vibe coding produces software that genuinely struggles in three places:

At scale. The schoolgirl's scheduling app works for 2,000 users. At 200,000 it would melt. None of the AI-generated code accounts for query patterns, indexing, caching, rate limits, or any of the boring infrastructure that turns a working demo into a working product. If you need scale, you need a developer.

At security. AI-generated code passes auth checks for happy paths and forgets the unhappy ones. Authorization bugs, injection vulnerabilities, secret leaks — the failure modes that don't trip in casual testing. The schoolgirl's app probably has at least one. So does most of the vibe-coded landscape.

At change over time. A vibe-coded app is fine until you need to change it in a way the original prompt didn't anticipate. The "code" exists, but no one understands the structure, including the tool that wrote it. Re-prompting works for small changes; for big ones, the whole thing gets thrown out and rebuilt. That's not a bug — it's the operating model. Disposable software is supposed to be disposable.

What the next layer looks like

The category that will matter in 2027 isn't vibe coding itself, it's what runs on top of it. Tools that take a vibe-coded prototype and add the boring infrastructure (auth, billing, scaling, monitoring) without making the user write any of it. Some of this exists already (Lovable, v0, Bolt, Replit Agent). Most of it is still half-built.

The bet underneath this is that most software doesn't need a software engineer. It needs a domain expert with a tool good enough to do the translation. The bet is mostly correct.

The remaining 30% — the software that genuinely needs an engineer — pays better than ever, because there's less competition for it.