Team vibe-coding policy — per-tier rules with graduation criteria

Scorecard question: What’s the team policy for Lovable / Bolt / v0 / Replit Agent? Max-score answer (3 pts): Deliberate per-tier policy: vibe-coding for MVPs/lead-magnets, Cursor/Claude Code for production, clear graduation criteria.

Why this matters in 2026 (prototype speed vs prod risk)

Vibe-coding compresses the prototype-to-stakeholder loop from days to hours. A founder validating a positioning angle used to need a designer, a frontend engineer, and a sprint. By mid-2026, the same founder opens Lovable, types a paragraph, and walks into the 11 AM call with a working URL, real auth, and a Stripe link. That speed is not marginal — it’s a category change in how product, marketing, and engineering coordinate inside a small team.

But production deployment from these tools is its own risk class. Up to 45% of AI-generated code contains exploitable security vulnerabilities — insufficient input validation, default trust of user input, SQL injection surfaces, XSS, and auth flows that look fine but leak on the edges. Vibe-coding tools generate code from scratch using generic patterns, don’t know your component library exists, haven’t seen your design tokens, and don’t enforce your conventions. The output won’t merge cleanly with a real codebase. By Q1 2026, Replit’s CEO publicly called a production incident “unacceptable and should never be possible” — because, as one widely-shared thread put it, there is no way to enforce a code freeze in a vibe-coding app.

Q16 asks whether your team has internalized this — extraordinary at producing working software in hours, not yet trustworthy at running it for paying customers. The max-score answer is not “we let everyone use Lovable” and not “we banned it” — it’s “we have a per-tier policy with explicit graduation criteria, and every engineer can articulate it in fifteen seconds.” This is the team-scale counterpart to the individual vibe-coding-policy on the Developer Scorecard: the developer question asks whether you can route a task; the CTO question asks whether your team does — consistently, defensibly, without you in the room.

What “max score” actually looks like (per-tier policy doc + graduation gate)

A maxed-out team policy on Q16 has four visible artifacts. If any are missing, you’re not there.

A 1-page written policy in your engineering handbook naming which vibe-coding tools are sanctioned, which tiers each is preferred for, and who owns the graduation gate.
A three-tier classification: Tier 0 (vibe-coding territory — lead magnets, marketing pages, internal demos, throwaway prototypes), Tier 1 (mixed — MVPs that might become production), Tier 2 (production — real customer data, auth, payments, shared codebase). Every artifact gets a tier on day 1.
Explicit graduation criteria — a checklist of conditions under which a Tier 0 or Tier 1 artifact must migrate to a real codebase reviewed by Cursor or Claude Code: first paying customer, payment integration, customer PII storage, three-month lifetime, second engineer needs to touch it, compliance scope (SOC 2, GDPR, HIPAA).
A documented migration path — a 30-to-60 minute drill: extract components, drop into the production repo, run Claude Code with a prompt to align with design system / tests / conventions, review the diff, ship.

The self-test: ask three engineers “we have a lead magnet that just got its first paying customer — what do we do?” Three matching answers naming the graduation criterion and the migration drill = 3 points. Shrugs or three different answers = 1 or 2.

Current landscape (web-search-verified)

Lovable / Bolt / v0 / Replit Agent (current capability)

The market consolidated in 2026 around four tools, each with its own lane.

Lovable ships full-stack web apps with auth, database, and responsive design out of the box — locked to React + Supabase. Most polished one-click deploy, best non-developer UX in the category. Best fit: landing pages with auth, founder marketing demos, lead magnets needing a working login.
Bolt.new owns the fastest prompt-to-preview and a zero-setup in-browser experience built on StackBlitz’s WebContainers. Pick the framework — React, Vue, Svelte, Next.js — it spins up a full dev environment in a tab. Best fit: proof-of-concept artifacts, hackathon work, framework comparisons.
v0 by Vercel produces the cleanest output — a v0 component drops into a real Next.js repo with almost no rewriting. React + Tailwind, optimized for shadcn/ui, tight Vercel integration. Best fit: UI component generation, landing page sections, “vibe-code as starting point, then graduate”.
Replit Agent is the only tool that genuinely handles the full stack inside one workspace — frontend, backend, database, hosting, deploy. Replit also holds SOC 2 Type II certification as of early 2026, a posture neither Bolt nor Lovable has publicly matched. Best fit: end-to-end MVPs needing persistence and auth without detouring through Supabase, internal tools managing the data layer.

Where they hit ceilings (auth, payments, complex backends)

All four tools share the same ceiling. Concrete failure modes documented across 2026 enterprise studies:

Code quality degrades sharply on complex features — enterprise success rates drop to roughly 31% on multi-step features beyond a 3–5 component MVP.
Production auth flows — happy path looks correct, edge cases leak: token refresh under load, multi-tab sessions, account takeover paths, CSRF between vibe-coded frontend and a separate backend.
Payment integration — Stripe webhook signature verification, idempotency keys, refund and dispute flows. Generated code regularly skips the security-critical parts and you don’t notice until the auditor does.
Custom backends — vibe-coding tools assume their own backend or Supabase. Anything calling your existing API, queue, or worker is loosely connected; the generated client lies about what your backend accepts.
Compliance scope — SOC 2, ISO 27001, EU AI Act, HIPAA, and GDPR controls are scoped to known systems. If a vibe-coded artifact touches customer data and your audit framework doesn’t know it exists, the next audit gets ugly fast.
Pattern drift inside one session — async/await in some files, promise chains in others, .then() callbacks in the rest — a maintainability headache that compounds.

The fix is not to stop using these tools. The fix is to know which lane they belong in, write the policy down, and gate the Tier 0–Tier 2 boundary with explicit graduation criteria.

Graduation criteria (when prototype becomes “needs to migrate”)

A vibe-coded artifact must graduate the day any one of these triggers fires:

First paying customer. Not first signup, not first demo — first dollar. The risk surface changes the instant money moves.
Payment integration goes live. Even one Stripe checkout in production. Webhooks and dispute flows are not vibe-coding territory.
Customer PII gets stored. Names, emails, payment data, anything regulated. SOC 2 and GDPR scope kicks in.
Three-month lifetime exceeded. The “I’ll throw this away” promise went unfulfilled. Pattern drift and dependency rot start to bite.
A second engineer needs to touch it. Two-person ownership without a real codebase is an onboarding nightmare and a knowledge silo.
Compliance scope triggers. SOC 2 audit window, HIPAA scope expansion, EU AI Act tier classification — anything in audit scope must be in a real codebase with a real review chain.
Performance ceiling hit. WebContainer or hosted-runtime limits on Bolt and Lovable; cold starts and quota throttling on Replit. When the artifact slows at scale, migration is overdue.

These are deliberately concrete. “When it feels production-ready” is not a criterion — it’s an excuse to never graduate.

Migration path (vibe-coding code → reviewed Cursor/Claude Code rewrite)

The graduation drill is what stops the policy from collapsing into “we vibe-code in prod now”. The shape that works in 2026:

Extract and audit. Pull the working output into a real git repo on day one. Read the code. Note what’s doing the work vs scaffolding.
Drop into the production codebase as a quarantine module. Don’t merge directly. Put it in a named directory (/quarantine/lead-magnet-X/) and isolate its dependencies.
Run Claude Code or Cursor against the quarantine module. Prompt: “align this directory with our design system, auth pattern, test conventions, TypeScript strictness, and ESLint config. Surface every conflict with our codebase patterns.” Review the diff.
Add tests at security-critical boundaries. Auth, payments, data validation, external API calls. Vibe-coded artifacts almost always ship without these; the migration is when they get added.
Code review with a senior IC. The gate. Senior IC’s job: find what the AI didn’t flag — implicit assumptions, missing input validation, hardcoded secrets, drift from the team’s threat model.
Promote, monitor two weeks, sunset the original URL. If the original Lovable / Bolt / Replit URL is still serving requests three months after migration, you have two production surfaces for the same feature. Pick one and kill the other.

First migration takes a full day. Third one takes 30 minutes. The drill makes graduation a routine activity, not a heroic refactor.

Step-by-step: writing your team policy

Audit the last twenty artifacts your team shipped. Landing pages, lead magnets, MVPs, internal tools, production features. For each, write down (a) audience (internal demo / marketing visitor / paying customer), (b) lifetime (week / month / year+), (c) risk (payments, auth, customer data, or none). Most teams discover 12–15 of 20 are objectively low-risk, short-lifetime, marketing-facing — exactly where vibe-coding wins.
Define the three tiers with concrete examples from your product. “Tier 0 = comparison page lead magnets, dev community CTA pages, Friday demo links. Tier 1 = the onboarding wizard rebuild, the customer-portal pilot. Tier 2 = billing, API gateway, anything in /apps/api.” Examples beat definitions; engineers route correctly because they pattern-match.
Write the graduation criteria as a triggered checklist. Use the seven triggers above. Customize: add “EU customer first signup” if you have GDPR exposure, “appears in pricing page” if you have a sales motion. The team should answer “should this graduate now?” without escalating to you.
Pick one vibe-coding tool per lane. Don’t sanction all four. Default for 2026: Lovable for lead magnets with auth, v0 for UI generation ported to a Next.js codebase, Bolt for fastest prototyping outside React, Replit Agent for full-stack MVPs in one workspace. A second tool per lane can come later.
Build the migration drill once and document it. First migration is a learning exercise — have your senior IC do it visibly, ideally recorded, then write the 30-minute version as a runbook. The single highest-leverage artifact on the whole policy.
Stand up the graduation gate. Name one owner — engineering lead or staff IC — who reviews graduation candidates. SLA: 5 business days from trigger to “approved / rejected with reason / scheduled”. The gate doesn’t have to be slow; it has to be visible.
Publish and run a 30-minute Q&A. Post the doc in the engineering handbook and #engineering. Field “but I want to keep using Lovable for our admin tool” live — most of those surface Tier 1 artifacts the team didn’t recognize.
Quarterly review: kill, graduate, or extend. Every 90 days, walk the list of vibe-coded artifacts and decide for each: kill (job done, take it down), graduate (trigger fired, run the drill), extend (audience and lifetime still match Tier 0). Without this, throwaways turn into long-tail liabilities.

Common pitfalls

Vibe code deployed to prod with no review. The most expensive Q16 failure mode. Artifact ships, lands a paying customer, six weeks later there’s a SQL injection in a Supabase RLS policy nobody can find. The migration drill is cheap; the post-incident rewrite is not.
No graduation gate at all. “We have a policy” plus “nobody owns the migration decision” equals no policy. Name one owner with a 5-day SLA.
Banning vibe-coding because of one bad incident. Six months later marketing ships one lead magnet per quarter instead of one per week. Don’t ban the tool — gate the boundary.
Sanctioning all four tools because “engineers can choose”. Same as the seven-tool tooling-policy failure. Pick one tool per lane; everything else by exception (see Q2 · Tooling policy).
No migration drill written down. First migration may take a day. Second must be a runbook. Third is 30 minutes. Without the runbook the team stops graduating and starts shipping vibe-code to production.
Treating “MVP” as one category. “MVP” sometimes means “internal demo”, sometimes “first version a paying customer will use”. Use the three-tier classification, not the word “MVP”.
Vibe-coded artifacts outside version control. Lovable and Bolt make it easy to keep code inside the tool’s workspace and never push to GitHub. With a paying customer or 3+ month lifetime, “code not in git” is a single-point-of-failure. Push an export to a private repo on day one.
Forgetting the security audit on graduation. The drill is when input validation, auth tests, and the secrets audit get added. If the drill ports code as-is, you’ve promoted a 45%-vulnerable artifact with the team’s name on it.

How to verify you’re there

A 1-page written policy exists in your engineering handbook, with named tier examples and explicit graduation criteria.
A new engineer can articulate the three-tier classification and at least three graduation triggers in under 30 seconds.
One named owner is on the graduation gate with a 5-business-day SLA.
A migration drill runbook exists; the most recent migration took under 60 minutes.
Every vibe-coded artifact in production has a tier, an owner, and a documented graduation status (graduated / waiting on trigger / explicit Tier 0).
All vibe-coded code lives in a real git repo, not just inside the tool’s workspace.
A quarterly “kill, graduate, or extend” review actually happens; you can produce the last two review notes on request.
The team graduated at least one artifact in the last quarter, or has a defensible explanation for why no triggers fired.