Vibe-coding policy — Lovable/Bolt/v0 for MVPs, Cursor/Claude for production
Scorecard question: How do you use vibe-coding tools like Lovable / Bolt / v0 / Replit Agent? Max-score answer (3 pts): I deliberately choose per-task: vibe-coding for MVP/lead-magnets, Cursor/Claude Code for production.
Why this matters in 2026
Section titled “Why this matters in 2026”Vibe-coding tools are the breakout software category of 2025–2026. Lovable, Bolt.new, v0, Replit Agent, Base44, Figma Make, Magic Patterns — the prompt-to-app surface is everywhere, and for the right task it is genuinely an order of magnitude faster than hand-coding in a terminal agent. The trap is that the same tools that turn a Friday-afternoon idea into a deployed landing page in twenty minutes also produce code that 45% of the time contains security vulnerabilities, generates a different async pattern every conversation, and ignores your team’s design tokens. The 2026 max-score answer to Q19 isn’t “I use vibe-coding tools” and it isn’t “I refuse to touch them” — it is “I have a per-task policy that routes work to the right tier.” That policy separates founders who ship five lead magnets a month from founders who either ship slowly with a real codebase or fast with a debt-laden mess. Q19 is, in effect, asking whether you’ve internalised the tiering — the same way Q1 asks about terminal agents and Q3 asks about model routing. The answer the scorecard wants is “yes, I know when each tier is right, and I can defend the call for any given task.”
What “max score” actually looks like (a per-task decision tree)
Section titled “What “max score” actually looks like (a per-task decision tree)”A max-score Q19 setup is a written decision rule you can articulate in fifteen seconds. The shape is a short decision tree: audience, lifetime, risk. Use vibe-coding tools (Lovable / Bolt / v0 / Replit Agent) when the artifact is a marketing site, lead magnet, internal demo, one-shot prototype, landing page for an experiment you’ll kill in three weeks, or a UI mock you’ll throw at users on Discord on Friday. Use terminal agents (Claude Code / Codex CLI / Cursor Agents) when the artifact carries real user data, has a maintenance horizon over three months, integrates with billing or auth in your existing platform, must conform to a shared codebase, or sits anywhere on the path from “first paying customer” to “production.” Use both, in sequence, when the vibe output is a starting point you’ll port into the real codebase — generate the UI in v0, copy components into the production repo, then have Claude Code refit them against your design system, tests, and conventions. Compare that to lower tiers: vibe-coding for everything (1 pt — ships UIs and tech debt at the same speed), refusing to touch vibe tools (1 pt — leaves a 5–10x speed-up on the table for the lead magnets they’re objectively best at), or using them indiscriminately (2 pts — sometimes right, sometimes wrong, never confidently right). The tell of a max-score user is that when a teammate asks “should I use Lovable for this?”, they don’t say “yes” or “no” — they ask three questions about audience, lifetime, and risk, then answer.
Current landscape (web-search-verified)
Section titled “Current landscape (web-search-verified)”The 2026 vibe-coding market has consolidated around four tools that each own a lane: Lovable for non-developer full-stack apps, Bolt.new for in-browser zero-setup prototyping, v0 for React + Tailwind components in a Vercel workflow, and Replit Agent for end-to-end full-stack. Most serious users pair one of these with a Tier 1 terminal agent — the same “two tools” pattern as Q1, but cross-tier.
Lovable (full-stack web apps)
Section titled “Lovable (full-stack web apps)”Lovable produces genuinely deployable apps with authentication, database integration, and responsive design out of the box, locked to a React + Supabase stack. Strengths: polished one-click deploy, the best UX for non-developers on the market, and outputs that look like a real product rather than a prototype. Weaknesses: the React + Supabase lock-in means you can’t take the code into a Next.js + Postgres + Drizzle stack without rewriting, and the abstractions hide enough plumbing that debugging production issues inside Lovable is harder than debugging code your own agent wrote. Best fit: landing pages with auth, founder-shipped marketing demos, lead magnets with a working login, and the “I need a working SaaS-shaped thing by tonight” class of artifact.
Bolt.new (StackBlitz-based, in-browser)
Section titled “Bolt.new (StackBlitz-based, in-browser)”Bolt rounds out the trio with the fastest prompt-to-preview speed and a zero-setup browser experience perfect for rapid prototyping. Built on StackBlitz’s WebContainers (the entire dev environment runs in your browser tab), Bolt lets you choose the framework — React, Vue, Svelte, Next.js — and is partially open source. Strengths: fastest first preview in the category, no install step, framework freedom, and the cleanest “share a URL with a working app” experience. Weaknesses: heavier features (custom backends, persistent storage, long-running jobs) hit the WebContainer ceiling, and long sessions feel slower than Lovable or v0 once the project grows past a few dozen files. Best fit: proof-of-concept work, hackathon artifacts, framework comparisons, and any time the answer is “I just need to show someone what this would look like.”
v0 by Vercel (React + Tailwind components)
Section titled “v0 by Vercel (React + Tailwind components)”v0 has the smoothest publishing and deployment flow of any of these tools because it sits inside the Vercel ecosystem and ships straight to a preview URL. Output is React + Tailwind by default, optimised for shadcn/ui patterns, and aimed at developers who already write React and want the UI scaffolding done for them. Strengths: the cleanest output code of any vibe tool (drop a v0 component into a real Next.js repo with almost no rewrite), tight Vercel integration, and the best fit when the goal is “generate the UI, then take it into the codebase.” Weaknesses: weaker on full-stack and backend than Lovable or Replit, less suitable for non-developers who want one-click deploy, and you’ll outgrow it quickly if you need anything beyond a polished component. Best fit: component generation, design exploration, landing-page sections, and the “vibe-coding as starting point” workflow where the output gets ported.
Replit Agent
Section titled “Replit Agent”Where Lovable and Bolt are primarily frontend tools, Replit is full-stack — tell it “build me a login system” and it sets up frontend, backend, and database in one go, no separate services to connect. Strengths: the only tool in the category that genuinely owns the whole stack inside one workspace, hosting and deployment included; best fit for end-to-end MVPs that need persistence and auth without a Supabase detour; and the strongest “I can keep working on this for weeks” story because the workspace is a real dev environment with terminals and package management. Weaknesses: heavier workspace metaphor than the prompt-then-deploy pattern of Lovable or Bolt, slower first-app experience for non-developers, and pricing scales faster on long-running projects. Best fit: full-stack MVPs, internal tools where you own the data layer, and side projects that might survive past the demo.
Where they top out (production code, complex auth, custom backends)
Section titled “Where they top out (production code, complex auth, custom backends)”All four tools share the same ceiling, and the ceiling is where Q19’s policy earns its keep. Up to 45% of AI-generated code contains security vulnerabilities — insufficient input validation, trust-by-default of user input, SQL injection, XSS, and auth flows that look fine but leak edge cases. Vibe tools generate code from generic patterns and don’t know your component library exists, haven’t seen your design tokens, and don’t enforce your team’s conventions — so the output is loosely coupled to nothing in particular and won’t merge cleanly. They prioritise speed over thoughtful system design, and generate different patterns for similar problems even within the same conversation (async/await one day, promise chains the next). Where they genuinely top out: production auth with real session/token handling, custom backends hooked into existing services, anything load-bearing on real user data, anything that needs to merge into a shared codebase, and anything with a maintenance horizon long enough that the inconsistencies will catch up to you. The fix isn’t to stop using them — it’s to know exactly which lane they belong in and write the policy down.
Step-by-step: writing your per-task policy
Section titled “Step-by-step: writing your per-task policy”- Audit your last ten artifacts. For each side project, landing page, lead magnet, MVP, and production feature, write down (a) audience — internal demo, marketing visitor, paying user, (b) lifetime — one week, one month, one year+, (c) risk — does it touch payments, auth, customer data. Most people are surprised that 6–8 out of 10 are objectively low-risk, short-lifetime, marketing-facing — exactly where vibe tools are unmatched.
- Write your three-question rule. Audience (internal/marketing/demo vs. paying customer or shared codebase), Lifetime (≤3 months vs. >3 months), Risk (no payments/auth/customer data vs. any of those). If any answer points to “production”, route to a terminal agent. If all three point to “throwaway”, route to a vibe tool. Pin the rule somewhere —
CLAUDE.md, a Notion page, a sticky note. It doesn’t work if it’s not written down. - Pick one vibe tool per lane. Don’t try to use all four. Default: Lovable for lead magnets and marketing artifacts with auth, v0 for UI you’ll port into a Next.js codebase, Bolt for the fastest browser prototype, Replit Agent for one workspace per MVP. Add a second later; starting with one tool per lane is what makes the policy executable.
- Build the “vibe-to-prod” porting drill. For artifacts that graduate to production, write a 30-minute checklist: extract components, drop them into the real repo, run Claude Code with the prompt “refit these to our design system, conventions, and tests”, review the diff, ship. The first port takes two hours; by the third time it’s the 30 minutes you budgeted. This drill turns vibe-coding into “fast prototype with a path to production” instead of “throwaway with no graduation”.
- Add a test on the way out. Any vibe artifact that goes near a real customer gets at least one test before it ships — Playwright happy-path on the deployed URL, Vitest unit test on the critical helper, or a clean-browser smoke test. The point isn’t full coverage; it’s to defeat the 45%-vulnerabilities statistic with a single deliberate check. Without it, you’re back at 1 pt — fast and broken.
- Set a quarterly “kill or graduate” review. Vibe artifacts have a half-life. Every quarter, decide for each: kill (lead magnet served its purpose), graduate (port to the real codebase via step 4’s drill), or extend (keep it on vibe-tool hosting because the audience and lifetime haven’t changed). Without this review, throwaways turn into long-tail liabilities because nobody revisits the original lifetime assumption.
- Document the policy and share it. Solo: a paragraph in
CLAUDE.md. With a team: a paragraph in your engineering handbook plus a Slack thread answering “when do we use Lovable vs. Claude Code?”. The policy delivers max-score Q19 only when others can apply it without you in the room. The artifact is the written rule, not the verbal one. - Defend the call at least once a week. Watch for two failure modes: a teammate routes a production feature to Lovable “because it’s faster” (re-route to Claude Code, explain maintenance cost), or hand-codes a lead-magnet page for two days “because vibe tools are sloppy” (re-route to Lovable, explain lifetime). After about six weeks the defending stops, because the team has internalised the call.
Common pitfalls
Section titled “Common pitfalls”- Deploying vibe-coded output straight to production without a port. The most expensive Q19 mistake. The artifact ships, gets a paying user, the founder forgets it was vibe-coded, then six weeks later there’s an SQL injection in a Supabase row policy nobody can find. If it carries real user data, port it to the real codebase before the first non-internal user touches it.
- No test coverage on the deployed artifact. The “I’ll add tests later” promise that became “we never add tests” the moment the artifact got traction. Even one Playwright happy-path test on the live URL catches the worst regressions. Without it, you’re back at the 45%-vulnerabilities statistic, shipping it to customers.
- Vibe code outside version control. Lovable and Bolt make it easy to keep code inside the tool’s workspace and never push it to GitHub. Fine for a true throwaway, but the moment the artifact has a paying user, “code not in git” is single-point-of-failure — vendor outage, account loss, accidental delete, and the code is gone. Push the export to a private GitHub repo on day one.
- Using vibe tools for production “because we’re moving fast.” The fastest path to production in 2026 is not vibe-coding the whole stack. It’s vibe-coding the UI, porting it into a real codebase with a terminal agent, and shipping in a day. The “move fast” instinct that bypasses the port is the same instinct that ships the SQL injection.
- Refusing to touch vibe tools because “real engineers don’t.” The mirror failure mode. A founder spends two days hand-coding a lead-magnet landing page that Lovable would have shipped in twenty minutes, then doesn’t ship the next four because per-magnet cost is too high. The engineer-coded artifact is no more virtuous when the audience never sees the code.
- Treating “MVP” as the only category. “MVP” does a lot of work — sometimes it means “internal demo”, sometimes “first version a paying customer will use.” The first stays on the vibe artifact for months; the second graduates the day it gets traffic. Use the three-question rule, not the word “MVP”, to decide.
How to verify you’re there
Section titled “How to verify you’re there”- You can articulate your three-question decision rule (audience / lifetime / risk) in fifteen seconds without checking notes.
- The policy is written down somewhere your team can find —
CLAUDE.md, engineering handbook, or a pinned Slack message. - You have one vibe-coding tool you own per lane (e.g. Lovable for lead magnets, v0 for UI generation) — not four open tabs.
- You have a “vibe-to-prod” porting drill that takes ≤30 minutes for a typical artifact.
- Every vibe-coded artifact that’s customer-facing has at least one automated test on the deployed URL.
- All vibe-coded code lives in a real git repo, not just inside the tool’s workspace.
- You run a quarterly “kill or graduate” review on shipped vibe artifacts.
- You’ve defended the routing call at least once recently — talked a teammate out of using Lovable for production, or talked one into using it for a lead magnet.