VIBE CODING TO PRODUCTION
AI can draft a product in a weekend. Production still needs ownership, tests, and a ruthless definition of done. Here is the operator split.
← Guides All Custom Software & Architecture guides
What vibe coding is good for
Vibe coding means steering an AI coding agent with intent and taste more than with a formal spec: Cursor, Claude Code, Copilot, Windsurf, and friends. It is excellent for spikes, internal tools, migrations with a clear before and after, UI scaffolding, and boring glue code you would rather not type.
It is also how a lot of founders now start products. That is fine. The failure mode is treating a green local demo as a production system. Users, payments, auth, SEO, accessibility, and on-call reality do not care that the agent felt fast.
Key takeaway: Use vibe coding to explore and accelerate. Do not confuse velocity of generation with readiness to serve customers.
Where it breaks in production
The patterns I see when AI-built apps meet real traffic:
No ownership of architecture
The agent will happily create a third pattern for data fetching because the prompt did not forbid it. Six weeks later nobody knows which pattern is canonical.
Happy-path auth and payments
Login works on the demo account. Edge cases, session expiry, webhook retries, and permission checks are fiction until a human writes them down and tests them.
Invisible performance and SEO debt
Client-rendered shells, unbounded images, and missing metadata ship because the agent optimised for "it looks right in Chrome".
Secret and env sprawl
Keys in chat logs.env examples that are real, and preview deployments that talk to production databases.
Key takeaway: Production failures after vibe coding are usually ownership and edge cases, not model IQ.
The guardrails that make it shippable
| Guardrail | Why it matters | Minimum bar |
|---|---|---|
| Written definition of done | Stops demo theatre | Auth, payments, empty states, error states listed |
| Thin vertical slice first | Proves the risky path | One real user journey in staging with real data shape |
| Human review on critical paths | Agents miss incentives | Auth, billing, migrations, public SEO routes |
| Automated checks | Catches regressions agents reintroduce | Typecheck, lint, smoke tests, CWV on key templates |
| Observability | You cannot fix what you cannot see | Error tracking + basic product analytics before launch |
| Rollback plan | Fast generation needs fast undo | Migrations reversible, feature flags for risky UI |
Inside Seahawk we treat agents as aggressive juniors with infinite typing speed. They draft. Humans still own architecture, security, and the release decision. For the longer workflow we use when building with Claude on purpose, see the Claude spec-driven workflow guide and the custom software pillar.
Key takeaway: Write the done list before you open the agent. Review the scary paths yourself.
A practical loop we use
1. State the user job in one paragraph. 2. List non-negotiables (auth provider, CMS, hosting, accessibility, SEO). 3. Let the agent scaffold against that list. 4. Run the app on the unhappy paths the same day. 5. Delete clever abstractions the agent invented that you did not ask for. 6. Add tests only where breakage is expensive. 7. Ship a narrow slice. 8. Only then widen scope.
If step 4 fails twice in a row, stop prompting and write a short spec. Vibe coding without a tightening loop becomes prompt churn.
Key takeaway: Alternate generation with adversarial use. If you only ever vibe forward, you only ever demo.
When not to vibe code the core
Do not let the agent freestyle the billing ledger, permission model, or data migrations for a system that already has customers. Do not vibe-code a redesign of production information architecture without a map. Do not outsource threat modelling to a chat window.
Do vibe-code the admin screen CRUD, the script that renames a folder of assets, the first version of an internal dashboard, and the migration PR once a human has specified the schema change.
Key takeaway: Keep agents away from irreversible money, permissions, and data shape until a human has set the rules.
The bottom line
Vibe coding is a leverage tool, not a delivery methodology. The teams that win in 2026 use agents daily and still sound boring in standup: definition of done, review on critical paths, field performance, and a rollback plan.
If you want help turning an AI-speed prototype into something you can put customers on, that is normal agency work now. Bring the repo and the done list. Leave the demo confidence at the door.
Key takeaway: Ship the slice you can operate, not the demo that impressed you on Friday night.
How this differs from spec-driven Claude work
Spec-driven work starts with a written contract: entities, routes, acceptance checks, then the agent fills the gaps. Vibe coding starts with taste and a prompt and tightens into a contract only when reality pushes back. Both are valid. The mistake is using vibe coding on a surface that already needed a contract.
Rule of thumb: greenfield spike or internal tool, vibe first. Multi-tenant product, payments, or a public SEO surface with existing traffic, spec first. Our Claude spec-driven workflow guide covers the second path in detail. This guide is the first path with production brakes.
Key takeaway: Vibe to discover. Spec to harden. Do not skip the handoff.
WHEN YOU ARE READY TO TALK
If you are mid-build on something this guide touches and want a second pair of eyes, the fastest path is a 30-minute call.
BOOK YOUR 30-MIN CALL