# What is vibe coding? Choosing between Cursor, Claude Code, v0, Lovable, and Bolt — and taking it to production > What is vibe coding? From Karpathy's original definition, to the criteria for choosing between Cursor, Claude Code, v0, Lovable, and Bolt across three categories — editor-type / agent-type / builder-type — to the minimum production gates that close the gap between 'it runs' and 'it's safe.' A start-to-finish guide for developers who build things themselves. - Published: 2026-07-07 - Author: 友田 陽大 - Tags: バイブコーディング, AI駆動開発, 技術選定, セキュリティ, Next.js - URL: https://tomodahinata.com/en/blog/vibe-coding-what-is-tools-risks-production-guide - Category: Vibe coding: shipping AI-generated code safely ## Key points - vibe coding is a term Karpathy coined in 2025; its original meaning — 'forget the code even exists and build on vibes' — was for throwaway weekend projects. Production use is outside that original scope, and that gap is where many incidents begin. - See AI coding tools in three categories and the choice settles itself: editor-type (Cursor/Copilot = you drive), agent-type (Claude Code/Codex = you delegate tasks), builder-type (v0/Lovable/Bolt = generate a whole app from a prompt). - The higher the abstraction, the less you see of 'what was actually generated.' Builder-type tools in particular auto-provision backends like Supabase, so gaps in RLS and authorization can reach production entirely unseen. - The minimum gates for shipping to production are four: typed boundaries (Zod) → invariant tests → a CI quality gate → npx @aegiskit/cli scan. Generation speed only becomes production quality once these gates offset the debt it creates. - Authorization, business logic, and tenant isolation are 'vertical risks' that neither an AI nor a scanner can guarantee by nature. Keep these as the human domain of spec decisions and design review — don't let go of them. --- 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)](/blog/vibe-coding-ai-generated-code-production-hardening-guide). 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](https://x.com/karpathy/status/1886192184808149383)). 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](https://code.claude.com/docs/en/overview), 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](https://code.claude.com/docs/en/overview) 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.** ```text ゼロから立ち上げ・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)](https://nvd.nist.gov/vuln/detail/CVE-2025-48757). And [Supabase's service_role key runs with PostgreSQL's BYPASSRLS and ignores RLS entirely](https://supabase.com/docs/guides/database/postgres/row-level-security) — 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](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) — 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](/blog/supabase-rls-security-field-study)). "Lets the login through but returns someone else's rows" — this [structure of "authenticates but doesn't authorize"](/blog/supabase-rls-authenticated-vs-authorized-owner-scope-guide) 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](/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-guide). 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](/blog/ai-driven-development-quality-gates-ci-type-safety-test-security). 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](/blog/spec-driven-development-claude-code-ai-agent-production-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](/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](/blog/ai-generated-code-vulnerability-assessment-vibe-coding-security-guide) (four-layer assessment, slopsquatting, top 5) - **Want to harden "it runs but production worries me" without rebuilding** → [Productionizing & hardening AI-generated code](/blog/vibe-coding-ai-generated-code-production-hardening-guide) (buyer / business perspective) - **Want to graduate from "don't read the diffs" development** → [The spec-driven development workflow](/blog/spec-driven-development-claude-code-ai-agent-production-workflow) - **Want to keep upholding quality mechanically in CI** → [Quality gates for AI-driven development](/blog/ai-driven-development-quality-gates-ci-type-safety-test-security) - **Want to cure Supabase RLS's "authentication ≠ authorization" at the root** → [Crush "authenticates but doesn't authorize"](/blog/supabase-rls-authenticated-vs-authorized-owner-scope-guide) --- ## Summary — welcome the vibes; come back to your senses only right before shipping 1. **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. 2. **Tools come in three categories** — editor-type (Cursor/Copilot) / agent-type (Claude Code/Codex) / builder-type (v0/Lovable/Bolt). Choose by abstraction and risk. 3. **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). 4. **The minimum production gates are four** — typed boundaries → invariant tests → a CI quality gate → `npx @aegiskit/cli scan`. 5. **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](/case-studies/lumber-industry-dx) 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](/aegis).