The Vibe Coding Debate, Explained: Believers, Critics, and What Is Actually True

By mid-2026, "vibe coding" has become one of those terms in software that splits a room in half before anyone has finished defining it. One camp treats it as the most important shift in how products get built since the cloud. The other treats it as the polite name for shipping AI-generated junk and calling it craftsmanship.

This piece is a fair-minded read on what each side is actually arguing, which claims hold up to scrutiny, and how working builders can keep the upside without buying the downside.

A note before we start: a bilingual tracker page on myvibe.so does a useful job aggregating arguments from both camps. Several of the eye-catching statistics circulating online (92 percent adoption, "0.02 percent" of vibe-coded apps reaching traction, app releases doubling) trace back to that tracker. We were not able to verify the underlying primary sources for those figures, and the writer of this piece could not retrieve the tracker page itself at the time of writing. So this article describes positions and arguments rather than treating the contested numbers as fact. Where we cite a statistic, we say where it came from.

Where the term came from

Andrej Karpathy, the former Tesla AI lead and OpenAI founding member, used the phrase "vibe coding" in a post on X in early 2025. The shape of his description: hand the model a goal, accept the diffs without reading them all, watch what happens, and steer with follow-up prompts. He was not making a normative argument about whether anyone should code that way. He was describing how he had been coding lately.

The line landed harder than the post probably deserved. Within weeks, "vibe coding" had become both a self-applied identifier (indie hackers, designers learning to ship, product managers cutting out their first contractor) and a slur ("vibe slop" for the resulting codebases). The debate that followed is less about Karpathy's original post and more about what people now mean when they use the term.

The believer case

Strip the believer case down to its load-bearing claims:

Shipping speed is real. Builders using Cursor, Claude Code, and similar tools report finishing in hours what used to take days. This is not a marketing claim from the tool vendors. It shows up in independent reports from working developers, in YouTube build logs, and in the steady volume of small businesses appearing online whose entire stack was AI-generated.

Access widens. Designers, founders, and product managers who never learned to set up a build pipeline can now ship working software. The argument is not that they will produce code as good as a senior engineer would. The argument is that they will produce some code where previously they produced none.

Learning accelerates for those who pay attention. When you can ask a model to write something, then ask it why, then break it on purpose and ask it to fix it, you compress a lot of feedback loops. Builders who treat AI output as a teacher rather than a substitute report learning faster than they did from documentation alone.

Distribution and adoption are happening. This is the part where the contested statistics live. The myvibe.so tracker reports a 92 percent daily-use figure among US developers and roughly doubled worldwide app releases attributed to AI-assisted development. We have not verified the primary sources for those specific numbers. What is verifiable is that AI coding tools are widely adopted: independent surveys from major dev-tooling vendors and industry analysts consistently show the majority of professional developers using some AI assistant in their workflow, even if specific percentages vary. The believer case does not require the most aggressive number to be true to hold.

Indie outcomes exist. The "$26,000 a month indie hacker" archetype is real in the sense that several public-build creators have posted MRR receipts at that level or higher. The same tracker reports a single creator with 5,800 deployments in a year. We cannot confirm the specific creator or the headcount. What we can say is that the genre of "I built it with AI, here is the dashboard" is no longer rare.

The critic case

The critic case is less about whether the tools work and more about what they do to the people using them.

Robert "Uncle Bob" Martin and the discipline argument. Martin, author of Clean Code and a long-running voice for craftsmanship in software, has consistently argued that skipping the discipline of reading and understanding your own code creates a long-term debt the project cannot pay. He is not anti-AI. He is anti-shipping-code-you-cannot-defend. This is a real position, and it shows up across his blog and conference talks well before "vibe coding" became a term of art.

The illusion of understanding. This is the sharpest version of the critic case: a builder who has shipped fifty AI-generated features can describe what their product does, but cannot explain how any one piece of it works. When something breaks, they prompt the model to fix it, and either the model can or it cannot. There is no third option, because there is no person in the loop who can reason from first principles about the failure.

Security. The "we will fix security later" pattern is old. It gets worse when "later" has to confront a codebase nobody on the team wrote. The contested 0.02 percent success-rate figure for vibe-coded apps is impossible to verify without methodology, but the underlying worry, that most prompt-first applications never get a security pass and most never need one because nobody uses them, is taken seriously even by AI-tool optimists. For builders shipping anything that touches money, identity, or other people's data, this is the part of the critic case that should land.

Maintainability. Code that gets written one prompt at a time tends to be inconsistent. Different sections were generated by different models on different days with different framings. A new contributor faces a codebase with no shared style, no consistent abstractions, and no clear ownership. The cleanup-cost case is real, even if its dollar figure is hard to pin down.

What is actually verifiable

After sorting through the louder claims, here is what holds up:

• The term comes from Karpathy. The post is in the public record on X.
• Adoption of AI coding tools among professional developers is high in 2026. The exact percentage varies by survey methodology.
• Both indie success stories and indie failure stories exist in large numbers. The selection bias on both sides is severe.
• The "skip the discipline, regret it later" position predates vibe coding. It is the same argument the craftsmanship movement has been making since the 1990s, now applied to a new substrate.
• The "illusion of understanding" concern is genuine and worth taking seriously, especially for builders shipping anything they would not personally bet their reputation on.
• Many of the loudest critics use the tools themselves. This is not hypocrisy. It is the normal pattern of new technology adoption: the people closest to a tool are usually the first to articulate its risks.

A productive read

The unproductive framing is "vibe coding versus engineering discipline." The productive framing is "vibe coding plus engineering discipline, applied at the right moments."

Vibe coding earns its place at the front of the workflow:

• Sketching ideas you do not yet know are worth building
• Learning new languages, frameworks, or domains by asking the model to walk you through them
• Throwaway tools that solve one problem one time
• Internal scripts that nobody but you will ever run
• Early-stage prototypes meant to test whether a thing is worth doing at all

Engineering discipline earns its place at the back:

• Anything that handles user data, payments, or credentials
• Production systems with real uptime expectations
• Code that other humans will read, extend, or maintain
• Anything you would be embarrassed to defend in a post-mortem

The mistake either side makes is treating its preferred mode as universal. The vibe-only builder ships a payment integration that never got a security review. The discipline-only builder spends three weeks scaffolding a CLI tool a prompt would have produced in twenty minutes. Both pay a cost neither needed to pay.

For a practical walkthrough of the "vibe for ideation, discipline for production" pattern, see our guides on how to vibe code an app responsibly and the common vibe coding mistakes worth avoiding.

Where to land

The debate is real, the stakes are real, and the loudest claims on both sides are usually the least reliable. Karpathy did not invent a movement. He named a workflow that was already happening. The critics did not invent the maintainability argument. They restated it for a generation that had been allowed to forget it.

Builders who win in 2026 are not the ones who picked a side. They are the ones who learned which side is right for which kind of work, and who have the judgment to switch modes without ego.

If you want to evaluate the tools in this debate for yourself, the vibe coding tools directory catalogs the editors, agents, and builders that have shaped the conversation, with pricing and positioning for each.

FAQ

Is vibe coding actually bad? No. It is a speed-and-access tradeoff. The risks the critics name are real for production systems and overstated for prototyping. Use the right tool for the right phase.

Did Andrej Karpathy mean for "vibe coding" to be a movement? The original post reads as a description of his personal workflow, not a manifesto. The movement is something the internet built on top of the phrase.

Who is Uncle Bob and why does he keep coming up? Robert C. Martin, author of Clean Code and a long-running advocate for engineering discipline. He has been making the underlying argument (read your own code, take responsibility for what you ship) for decades. The vibe coding debate is the latest place that argument is being applied.

Are the "92 percent" and "0.02 percent" numbers real? We cannot independently verify either figure. Both trace back to a single user-contributed tracker page (myvibe.so/xiaoliang-2/vibe-coding-debate) that we could not retrieve at the time of writing. Treat them as claims, not facts.

Should I be worried about AI-generated code in production? You should be exactly as worried as you would be about any code in production that nobody on the team wrote, reviewed, or fully understands. The right response is process (review, tests, security pass), not avoidance.

What is the smartest position to hold in this debate? That both sides are partially right and partially overcommitted. Use the speed where speed pays off. Use the discipline where the cost of getting it wrong is high. Stop confusing taste for tribe.