Vibe coding is not a passing trend. It represents a structural shift in how software gets built, already demonstrated by non-technical founders shipping production applications and generating real revenue. But the category has real limitations that marketing consistently understates, and conflating genuine utility with hype produces bad decisions. The question deserves a serious answer: what the evidence shows, where the ceiling sits, and what the next 18 months will determine about whether vibe coding's current momentum becomes category permanence.

Why the "trend or useful" question is worth asking seriously

Developer tools have a long history of arriving with large claims and departing without delivering on them. Low-code was going to eliminate enterprise software backlogs. Drag-and-drop app builders were going to replace developers. No-code was going to put product creation in the hands of anyone with a spreadsheet and an idea. Some of these claims were partially true. Most were significantly overstated. The people who learned to separate genuine capability shifts from marketing expansion are the ones who adopted the right tools at the right time and avoided rebuilding things that were never going to work.

Vibe coding has arrived with the same pattern: large claims, viral screenshots, breathless adoption curves. The question of whether it is a trend or a utility, therefore, deserves the same rigour applied to every previous "this changes everything" moment in developer tools. What does the evidence show, who is building what, and what are the documented failure modes?

What the hype cycle looks like and where vibe coding sits on it

The adoption metrics are real and unusually fast. Google searches for "vibe coding" rose roughly 6,700% in spring 2025. Stack Overflow's 2025 Developer Survey found that 84% of developers use or plan to use AI tools in their development process, up from 76% in 2024. A quarter of Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. These are not the adoption numbers of a niche productivity feature.

The commercial evidence is harder to dismiss. Lovable launched publicly in November 2024 and hit $1 million ARR within weeks, reaching $200 million ARR by late 2025. That is not the growth pattern of a tool people experiment with and abandon.

At the same time, the failure modes are documented and serious. A security assessment of five vibe coding tools in 2025–2026 found 69 total vulnerabilities across three test apps, many rated high or critical. The Moltbook breach in January 2026 is the case worth examining: a fully vibe-coded social platform exposed 1.5 million API authentication tokens, 35,000 email addresses, and private messages containing plaintext credentials. The root cause was a Supabase API key exposed in client-side JavaScript with Row Level Security not enabled. The founder had not written a single line of code. He also had no way to recognise what the AI had generated incorrectly.

The hype cycle framing suggests a peak of inflated expectations, a trough of disillusionment, and a plateau of productivity. Vibe coding in early 2026 looks like a category that has cleared the peak and is somewhere in the trough: genuine utility is documented, overclaiming is being corrected by failure cases, and the plateau location is still being determined.

The evidence that it's more than a trend: real products, real users, real revenue

The standard I apply to category legitimacy claims: can you point to specific, verifiable artefacts? Viral demos do not count. ARR does. Paying users do. Applications running under real traffic with real data persistence do.

By that standard, vibe coding passes. 44% of non-technical founders now build their initial prototypes using AI coding assistants rather than hiring developers. That is a change in how early-stage product development works, not a statistic about experimentation. One non-technical founder reached $456,000 ARR in 45 days using a vibe coding platform. Lovable's documented cases include Lumoo reaching €800,000 ARR in nine months and ShiftNex hitting €1 million ARR in five months.

The evidence also shows that the category has moved beyond purely frontend generation to genuinely full-stack output. Platforms like Mayson generate backend infrastructure as native code: the database schema, auth layer, and API routes arrive as part of the codebase, not connected to external managed services the founder does not control. Showcase applications, including Mandalove, Pitch Pulse, and Gupshup, were built this way: non-technical founders, production infrastructure, and real users. The architectural point is the one that matters: these applications did not need to be rebuilt when users arrived, because the infrastructure was production-grade from the first prompt. [PLACEHOLDER: verify Mandalove, Pitch Pulse, and Gupshup details and link to showcase page at mayson.app]

The category has also produced a different kind of evidence: the market correcting overconfident claims. The founders who succeeded with vibe coding used it for standard application patterns and treated the first output as a starting point. That is not a criticism of the category — it is the category working as designed.

The limitations that are still real and haven't been solved by marketing

A category argument that omits genuine limitations is not an argument. The limitations of vibe coding in early 2026 are well-documented enough to state precisely.

Security is the most serious current limitation, and Moltbook is not an outlier. 45% of AI-generated code contains security vulnerabilities, and 40% has exploitable bugs according to assessments from 2025–2026. AI systems generate code that follows standard security patterns for common scenarios. They do not catch edge cases, perform threat modelling, or audit their own output for the error category that led to the Moltbook breach. Any vibe-coded application handling sensitive data at scale needs a security review the generation process does not provide.

Complex state management is genuinely hard. Applications where many things are happening simultaneously across multiple users, where system state is intricate and must be managed precisely, stretch what AI agents currently handle well. The problem is not that AI cannot write state management code — it can. The problem is that the architectural decisions around state management in complex applications require engineering judgement that AI systems are not yet reliably able to provide.

Custom business logic that does not map to common patterns is where generation becomes unreliable. AI builders are trained on patterns; when an application requires novel logic, the AI guesses. Sometimes correctly, often not — and diagnosing the failure requires understanding the code in a way that vibe-coding-first founders typically do not have.

Regulated industries are a specific category of concern. Applications in financial services, healthcare, and legal domains have compliance requirements that go beyond functional correctness. Generated code is not compliant by default, and the work required to make it compliant typically exceeds the savings from generating it in the first place.

How vibe coding compares to previous "this changes everything" moments in developer tools

I have covered this category since Bubble was a curiosity and Webflow was a Hacker News thread. The pattern of "this changes everything" announcements in developer tools is consistent enough to be a framework.

No-code's first wave (roughly 2012–2019) delivered on a specific, bounded promise: non-technical people could build visual applications, marketing sites, and simple internal tools without hiring engineers. It did not deliver on the broader promise of replacing software development. The ceiling was real and architectural, and the founders who discovered it mid-product ended up rebuilding on conventional infrastructure at high cost.

The low-code enterprise wave (2018–2022) was largely a rebranding of visual development for enterprise procurement budgets. It delivered real productivity gains for IT departments building internal tools against well-understood patterns. It did not transform enterprise software development in the ways its marketing described.

Replit's early era (2019–2022) introduced the browser-based development environment and genuinely lowered the barrier to getting code running. It did not solve the capability gap for non-technical builders — you still needed to be a developer to use it effectively.

What distinguishes vibe coding from these predecessors is the output. No-code produced platform configurations. Low-code produced partial code exports and workflow definitions. Vibe coding produces real, executable, portable code. The ceiling is not set by a component library — it is set by the complexity of the application being described and the quality of the description.

The second distinguishing factor is adoption velocity. No-code grew steadily over a decade. Vibe coding reached mainstream developer adoption within two years of becoming reliably possible. Categories that are primarily novelty do not sustain 84% developer engagement in annual surveys.

Who it's genuinely useful for right now (and who should wait)

Vibe coding is well-suited to: non-technical founders building MVPs with standard application patterns (auth, database, CRUD operations, common integrations). Internal tools that solve operational problems where function matters more than design. Early-stage products where the goal is user feedback rather than scale. Applications where the founder intends to bring in a developer later and needs a real, portable codebase to hand over.

It is poorly suited to applications that require a security review. Systems with complex state management across many simultaneous users. Products in regulated industries where compliance requirements are non-trivial. Consumer applications where the interaction design is the primary differentiator. And any project where the founder's plan is to hand off a vibe-coded application to a developer who will discover structural problems that cost more to fix than to rebuild.

The practical test: if you can describe your application specifically — its users, its data, its core workflows — and it follows standard patterns that software developers build frequently, vibe coding will likely get you to a working first version faster than any alternative. If your application requires logic or architecture that a developer would consider genuinely novel, or if it will handle sensitive data at scale, the speed advantage does not outweigh the risk.

What the next 18 months will determine about the category's staying power

Three questions will determine whether vibe coding becomes a permanent infrastructure for non-technical product development or plateaus at a narrower use case than the current moment suggests.

The first is security tooling. The Moltbook breach demonstrated a failure mode that is not idiosyncratic — it is systemic to AI code generation. If platforms develop reliable automated security review as part of the generation pipeline, the ceiling for safe vibe-coded applications rises significantly. If they do not, the category will be constrained to low-stakes applications by reputational risk.

The second is whether the evidence of genuine scaling holds. The early revenue numbers from vibe-coded applications are real but early. Whether those applications sustain growth past the initial product-market fit stage without needing to rebuild on conventional infrastructure will determine whether the category's claim to production-grade output is vindicated over a longer time horizon.

The third is the convergence of no-code and AI generation. Several no-code platforms are adding AI generation capabilities. Several AI builders are adding visual editing interfaces. The category definitions are blurring faster than most observers expected. Whether vibe coding remains a distinct category or gets absorbed into a broader "build without coding" umbrella will affect how founders evaluate tools and how platforms position themselves.

My read, for what a technology writer's read is worth: the category is real, the capability is genuine, and the limitations are correctable. Vibe coding in 2026 is roughly where no-code was in 2016 — past the novelty phase, proven for a defined range of use cases, not yet at the ceiling of what it will eventually do. The founders who treat it as a real tool with real constraints will build real products. The ones who treat marketing as accurate will have a harder eighteen months ahead.

Frequently asked questions

Shashi has covered developer tools and the no-code/low-code space from Delhi for eight years, across enough "this changes everything" announcements to have developed a calibrated scepticism about all of them. She is, cautiously, more convinced by vibe coding than by most of the previous ones.