Is vibe coding bad? Steelmanning the criticism

"Is vibe coding bad?" has become one of the fastest-growing questions people ask about AI app building — and most answers come from parties selling one side. We sell a vibe-coding platform, so the only credible move is to make the critics' case as strong as the evidence allows, then say what actually answers it. Here's that attempt.

The security case

This is the strongest criticism, and it's quantified. Veracode's GenAI Code Security Report (2025) ran 80 curated coding tasks across more than 100 models: AI-generated code introduced OWASP Top 10 vulnerabilities in 45% of cases, with Java failing around 72% of the time and cross-site scripting defenses failing in roughly 86% of relevant tasks. The uncomfortable part is the trend line — Veracode's Spring 2026 update found the secure-code rate still stuck near 55%. Newer models write more functional code, not more secure code.

It's no longer theoretical. A Cloud Security Alliance research note from April 2026 cites Georgia Tech's tracking of 35 CVEs in March 2026 alone — 74 cumulatively — attributed directly to AI coding tools, with the ecosystem-wide count estimated at 5 to 10 times higher. The same note reports that around 20% of AI-generated code references packages that don't exist, which attackers exploit by registering those names — "slopsquatting."

And there are two canonical incidents. In May 2025, a security review covered by Semafor found 170 of 1,645 sampled apps built on Lovable exposing personal data — names, emails, API keys — through misconfigured database access rules. In July 2025, Fortune reported that Replit's agent deleted a company's live production database during an explicit code freeze, then produced misleading output about it. Both companies responded and shipped guardrails; both incidents happened because generated code and agent actions went unreviewed.

The quality and maintainability case

CodeRabbit analyzed 470 pull requests in December 2025 and found AI co-authored code contained 1.7x more major issues and roughly 2.7x more security vulnerabilities than human-written code. At enterprise scale, Apiiro's September 2025 data from a Fortune 50 company showed AI-assisted developers committing 3-4x more code while monthly security findings rose from about 1,000 to over 10,000, with privilege-escalation paths up 322%. Volume without review multiplies debt — the discourse even has a name for the residue: "vibe slop."

The productivity case

The assumption that AI assistance is automatically faster took a documented hit. METR's randomized controlled trial (July 2025) had 16 experienced open-source developers work real issues with and without early-2025 AI tools: with the tools they took 19% longer — while estimating they'd been about 24% faster. The gap between felt speed and measured speed is the headline finding, and it explains a lot of credit-burn complaints across builder forums: iterating feels productive even when it isn't.

Developer sentiment matches: Stack Overflow's 2025 survey (~49,000 respondents) found 84% adoption alongside 46% active distrust of AI output accuracy — and among experienced developers, only 2.6% reporting high trust. Adoption with wariness is the accurate picture.

The labor anxiety

One more thread runs under the criticism: Stanford's Digital Economy Lab reported in 2025 that employment for software developers aged 22-25 had declined roughly 20% from its late-2022 peak, coinciding with generative-AI adoption. Whatever the causality, it colors how the practice is received.

So — is it bad?

Notice what every documented failure above has in common: code that nobody reviewed, shipped to a place where it could hurt someone. Andrej Karpathy's original February 2025 framing scoped vibe coding to "throwaway weekend projects" — the incidents happened when that scope was ignored.

So the honest verdict splits: vibe coding as drafting — prototypes, internal tools, validation, learning — is not just defensible but demonstrably valuable. Vibe coding as shipping unreviewed code that handles real user data is exactly as bad as the critics say, and the Veracode numbers put odds on it.

What a serious platform owes you

If the failure mode is "unreviewed code, silently broken, on rails you can't leave," then the mitigations are specifiable. We built opix around four of them — and any platform, ours included, should be judged against this list:

1. Gates, not vibes. Every generation should pass an automatic type-check and a runtime smoke test before a human ever sees it. Most defects are catchable mechanically; catching them shouldn't be the customer's job.
2. Real code ownership. The output should be a standard, exportable codebase — in our case Next.js on your own Postgres — so a professional can review, audit, and inherit it. Code behind glass can't be reviewed at all, which makes every criticism above worse.
3. Honest billing. If the model's failures cost you money, the vendor profits from the very loops the METR study describes. Failed builds should be free, costs should be visible before you spend, and caps should be settable.
4. Sane defaults for data. Auth and database access rules are where the Lovable-style incidents live; a platform should generate conservative defaults and make the rules inspectable.

And one admission, because this list would be dishonest without it: gates catch code that doesn't compile or crashes. They do not catch a flawed authorization rule or a business-logic hole. Before an app touches real user data, a human review — yours or a professional's — is still the standard, on every platform.

A checklist before you ship a vibe-coded app

A skeptic's checklist, usable on any tool:

1. Export the code and confirm it runs off-platform. If it can't, you don't own an app; you rent one.
2. Review every auth and data-access rule — this is where the documented breaches happened.
3. Confirm no secrets or API keys ship in client-side code.
4. Ask what a failed generation costs you, in writing, before subscribing.
5. Set a hard spend cap before a long agent session, not after.
6. Run a security scan or have a second model review the code — cheap, and it catches the embarrassing 45%.
7. Decide who maintains this in six months. "Nobody" is an answer — it just means the app is a prototype, and should be treated like one.

The critics are mostly right about the debt. The answer isn't abandoning the practice — it's process, and platforms engineered so the safe path is the default one. That's the standard we'd ask you to hold us to, comparison pages included.