Let me give the conclusion first. vibe coding is "a way of building where you hand the code to an AI and move on vibes without reading each diff," and you'll never be lost choosing between Cursor, Claude Code, v0, Lovable, and Bolt if you sort them into three categories — editor-type / agent-type / builder-type. But no matter which tool you build with, "it runs" does not mean "it's safe, it won't break." The key to turning generation speed into production quality is inserting a mechanical verification gate before you ship.
This article is for developers who build with their own hands. The buyer's perspective — "how do I evaluate the ordering and acceptance of an AI-built app" — is collected in a separate article (productionization & hardening). The audience is different, so don't conflate them. Here, on the premise that I have built — solo × generative AI (Claude Code) — a B2B SaaS that won the Minister of Economy, Trade and Industry (METI) Award and a payments platform with zero production double-charges, I write how to choose tools and the minimum bar for shipping to production, from a builder's point of view.
1. What is vibe coding — back to Karpathy's definition
"vibe coding" is a term Andrej Karpathy coined on February 2, 2025 (the original post). His definition goes like this — a new way of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He continues: "I always 'Accept All,' and I don't read the diffs anymore."
There's a line that often gets overlooked. Karpathy himself qualified it as "not too bad for throwaway weekend projects." In other words, vibe coding in its original sense is a technique for rapidly building toys that don't matter if they break.
The problem is that the term was later stretched to mean "AI-led coding in general," and people started shipping even production SaaS in the same spirit. Apply the original "don't read the diffs" to a production app that handles payments or personal data — that's an incident. So this article's stance is: welcome the "vibe" of generation. But come back to your senses with mechanical verification only right before you ship.
2. Three categories of tools — editor-type / agent-type / builder-type
AI coding tools are proliferating, but view them along two axes — "abstraction" and "control granularity" — and they split cleanly into three. Understand this and the choice is settled in one shot.
| Category | Representative tools | Your role | Abstraction | Unit of output |
|---|---|---|---|---|
| Editor-type | Cursor, GitHub Copilot, Windsurf | You drive; the AI completes and suggests | Low (line to file) | Diffs / completions |
| Agent-type | Claude Code, Codex, Cursor Agent | Delegate tasks in words; the AI executes autonomously | Medium (feature / multiple files) | Commits / PRs |
| Builder-type | v0, Lovable, Bolt | Generate a whole app from a prompt | High (entire app) | A running app + backend |
Editor-type — you hold the reins
Cursor and Copilot are powerful completion embedded in your editor. You drive one line — or one function — at a time, and the AI suggests the next move. Its strength is that control granularity is the finest and the output is always right in front of you. It suits surgical changes to existing code, delicate refactors, and "I just want to fix this one spot." The closest thing to vibe coding in its original sense is Cursor's Composer — and that's exactly what Karpathy cited as his example.
Agent-type — delegate the task
Claude Code and Codex autonomously execute task-level instructions across multiple files — things like "write tests for the auth module, run them, and fix whatever fails." They read files, edit them, run commands, and even create commits and PRs. The abstraction goes up a notch, and you move into the reviewer's seat. This is the workhorse for adding features, fixing bugs, and large refactors in an existing codebase. It's the center of gravity when I build production products.
Builder-type — generate an app from a prompt
v0, Lovable, and Bolt generate a running app — UI and backend included — from a single line like "build me an app that does X." The abstraction is the highest and it's the fastest. They have overwhelming force for standing something up from zero, a design starting point, or a prototype for an internal tool. On the other hand, this is also the category where the insides of what's generated — especially the database and authorization — are the furthest from your field of view. This is what leads into the heart of Section 4.
3. The criteria for choosing — pick by "what you're building"
Bringing the three categories down to an actual decision looks like this. My rule is simple: choose by "how tightly a human wants to hold the reins" = the level of risk.
ゼロから立ち上げ・UIの叩き台・使い捨てプロト
└─→ ビルダー型（v0 / Lovable / Bolt）で一気に形にする
既存コードベースへの機能追加・リファクタ・テスト整備
└─→ エージェント型（Claude Code / Codex）にタスクを委譲する
決済・認可・データ整合性など「間違えたら事故る」中核ロジック
└─→ エディタ型（Cursor / Copilot）で1行ずつ運転し、diffを必ず読む
The important thing is that these three are not mutually exclusive — you switch between them phase by phase within a single project. I mix them: put out the skeleton with builder-type, stack features with agent-type, and drop down to editor-type to check the diff line by line only where money and permissions are touched. The higher you raise the abstraction the faster it goes, but the higher you raise it the less you can see of "what is actually happening." Tuning that invisibility to the risk is where a builder earns their keep.
4. "It runs" ≠ "it's safe, it won't break" — the higher the abstraction, the more the risk hides
This is the one line I most want to land in this article. No matter which category of tool you build with, "the demo runs" and "it doesn't leak and doesn't break in production" are separate things. Generative AI writes happy-path code astonishingly fast, but what production asks is how it behaves against malformed input, concurrent access, and — above all — "a well-formed request that points at someone else's ID."
And the higher the abstraction, the less visible this hole becomes.
- Editor-type: the output is right in front of you, so you can still notice.
- Agent-type: it spans multiple files, so it slips through if you neglect review.
- Builder-type: it auto-provisions the backend. When v0 / Lovable / Bolt spin up Supabase behind the scenes, the RLS (Row Level Security) and authorization design become production-grade without you ever laying eyes on them.
This is not a hypothetical worry. A case where missing RLS in an AI-builder-made app let an unauthenticated attacker read and write other people's data is registered as CVE-2025-48757 (CVSS 9.3 CRITICAL). And Supabase's service_role key runs with PostgreSQL's BYPASSRLS and ignores RLS entirely — that the defense boundary moves to "where you keep the key" is something the generated code never tells you.
Furthermore, because the attack is a well-formed, correctly authenticated request, there are holes that WAFs and headers can't stop. Object-level authorization flaws (IDOR/BOLA) have been #1 in the OWASP API Security Top 10 ever since 2019 — the most frequent risk of all.
How often does it happen? In primary research on the OSS "Aegis" I'm involved with — a primary survey of 1,000 public Supabase apps found that roughly 9.2% of the apps that had RLS carried a policy that "authenticates but doesn't scope rows to the owner" (a lower bound, since the sample is public repositories; non-owner-scoped ≠ immediately vulnerable — it needs checking) (the survey's details and methodology). "Lets the login through but returns someone else's rows" — this structure of "authenticates but doesn't authorize" is the trap vibe coding steps on most easily.
Exactly which vulnerabilities AI-generated code mass-produces (missing authorization, missing input validation, hardcoded secrets, slopsquatting, and so on) is explored in depth, with before-and-after code, in Vulnerability assessment of AI-generated code. I won't repeat it here.
5. The minimum gates for shipping to production — insert one verification step into the vibe loop
So what do you do to reach production quality without killing generation speed? The answer is "don't change how you generate; just pass through four mechanical gates right before you ship." This is the final "verify" part of the explore → plan → implement → verify loop I use consistently.
| Gate | What it stops | How |
|---|---|---|
| ① Typed boundaries | Malformed input / unexpected data shapes | Zod parse external input at the boundary. Eliminate direct process.env references with types |
| ② Invariant tests | Skipped or regressed authorization | Pin down "you can't see someone else's data with someone else's ID" as a test |
| ③ CI quality gate | "A human forgets to review" | Enforce type checking, static analysis, and dependency/secret scanning on every PR |
| ④ Security scan | Common injection / RLS & authorization traps | Static analysis with npx @aegiskit/cli scan |
The design philosophy behind ①②③ — dropping acceptance criteria into tests and mechanically upholding them in CI — is collected in Quality gates for AI-driven development. And as the polar opposite of "don't read the diffs," the approach of fixing what you'll build as a spec first and letting the AI handle only "the implementation that satisfies that spec" is covered in The spec-driven development workflow. Generate fast on vibes, but keep the entrance (the spec) and the exit (verification) in human hands — that's the key to having both.
Where ④ fits — make the current state visible with free OSS
Even before you've set up ② and ③, you can diagnose the code you have with a single command. The MIT-licensed OSS Aegis runs static analysis with no install via npx @aegiskit/cli scan, and it automates filling the gaps in the "horizontal controls" — headers/CSP, rate limiting, input validation, CSRF, secret hygiene — while it detects and warns on the "vertical risks" a library can't fix (authorization/IDOR, Supabase RLS design mistakes). Code exported from v0 / Lovable / Bolt can be fed in as-is.
But — Aegis does not claim to "protect you completely." A tool that advertises otherwise is, if anything, dangerous (the complacency of "I installed it, so I'm fine" produces the worst outcomes). The authorization, business logic, and tenant isolation raised in Section 4 are "vertical risks," and neither an AI nor a scanner can guarantee them by nature. That's because they depend on the meaning of your business rules — "who owns what, and which operations they're allowed." What a scanner can do is inspect "form," not guarantee "meaning." So keep closing the vertical risks as a human job — design and review — to the very end; don't let go of it.
6. Going deeper from here — how to walk the productionization cluster
From this pillar article, reading the following by your goal is the shortest path.
- Want to know what AI tends to bake in, by vulnerability class → Vulnerability assessment of AI-generated code (four-layer assessment, slopsquatting, top 5)
- Want to harden "it runs but production worries me" without rebuilding → Productionizing & hardening AI-generated code (buyer / business perspective)
- Want to graduate from "don't read the diffs" development → The spec-driven development workflow
- Want to keep upholding quality mechanically in CI → Quality gates for AI-driven development
- Want to cure Supabase RLS's "authentication ≠ authorization" at the root → Crush "authenticates but doesn't authorize"
Summary — welcome the vibes; come back to your senses only right before shipping
- vibe coding's original meaning is "throwaway weekend projects" (Karpathy). If you bring it to production, add the verification gates that the original meaning never had.
- Tools come in three categories — editor-type (Cursor/Copilot) / agent-type (Claude Code/Codex) / builder-type (v0/Lovable/Bolt). Choose by abstraction and risk.
- The higher the abstraction, the more the risk hides. Builder-type in particular goes production-grade with RLS and authorization unseen (a measured lower bound of 9.2%, CVE-2025-48757).
- The minimum production gates are four — typed boundaries → invariant tests → a CI quality gate →
npx @aegiskit/cli scan. - Authorization, business logic, and tenant isolation are the human domain. Don't let go of spec decisions and design review.
I myself, staying solo × generative AI with this approach, have built a B2B SaaS that proved zero missing-authentication findings across all 221 endpoints through four rounds of audits, including third-party penetration testing across 15 real roles and a payments platform with zero production double-charges. The source of speed is AI; the source of safety is verification — with that design in place, vibe coding becomes the strongest weapon you have. Start by making the current state of your code visible with the free Aegis.