Vibe to Production
A two-phase framework for turning AI-generated prototypes into production software — and a task-graph engine I built to author the entire course that teaches it.
The problem
AI prototyping tools like Lovable can turn a plain-English description into a clickable app in minutes. That’s genuinely useful for getting real feedback from stakeholders fast. The problem is what happens next: teams either keep “refining” requirements in documents forever and never ship, or they take the AI-generated prototype, start bolting features onto it, and six months later they’re stuck maintaining a codebase full of hardcoded values, no tests, and a database (usually Supabase) that was never meant to be a permanent backend. Nobody made a deliberate decision to ship the prototype — it just became the product by default.
This isn’t a solo-developer problem. Any engineering org that has adopted an AI app builder for discovery — Lovable, v0, Bolt, or an internal equivalent — hits the same wall: prototypes that were fast to build turn into technical debt that’s expensive to unwind, and requirements end up rewritten three or four times as they move from a product doc, to a prompt for the AI builder, to Jira tickets, to actual test cases, with drift creeping in at every handoff.
The approach
The core of the project is the Vibe-to-Prod framework itself: a documented method for running two distinct phases on purpose instead of by accident. Phase one is discovery — requirements get written as “Requirement Cards” (a structured format with a story header, context, Given/When/Then acceptance criteria, an explicit out-of-scope list, and open questions that have to be resolved before the card counts as ready), and each card drives a Lovable prototype that stakeholders can actually click through. Phase two is extraction — the prototype is treated as scaffolding, not code, and gets replaced: tests generated straight from the requirement cards before anything is refactored, the frontend rebuilt with Claude Code, the backend redesigned API-first with an OpenAPI contract, and Supabase migrated out to a real Postgres instance and a proper auth provider. Lovable is retired at that point. Everything after that runs as an Acceptance Driven Development loop in Claude Code — new requirement, failing test, implementation, passing test, deploy, repeat. The framework also specifies a multi-agent version of that loop for teams working at higher throughput: an orchestrator plus specialist agents for requirements, schema, tests, implementation, review, and observability, each with a narrow context window instead of one agent trying to hold the whole codebase in its head.
The second half of the project is an engine I built to actually produce the Udemy course that teaches this framework, and it’s arguably the more interesting artifact. It’s a task-graph content pipeline, not a chat session: a scaffold phase reads the course design docs (outline, production plan, brand palette, design transcript) and computes a full dependency graph — 37 modules across 8 parts, 164 individual deliverables (slide decks, narratives, hands-on guides, lab briefs, quizzes), each one a discrete task with declared inputs, an exact output path, and a token budget. Tasks are split into three layers with different models assigned per layer — Opus for the planning layer that has to reason about dependencies, Sonnet for the technical-asset and delivery layers that mostly need to execute cleanly against a spec — and an external scheduler dispatches each task to the Claude CLI, which writes its own files and logs a completion signal. Groups that exceed a token ceiling get automatically split into a slide-deck pass and a text pass with an enforced dependency between them. The course itself teaches the framework hands-on by having students build four progressively harder apps — a requirements manager, a Jira-like ticket tracker, a prompt-versioning tool, and a document-redaction tool as the capstone — walking through the exact discovery-to-production journey the framework describes.
What I learned
The thing that makes the framework actually work is that the Requirement Card is designed to survive translation. The same card drives the Lovable prototype, becomes Gherkin acceptance criteria with essentially no rewriting, and is the exact input Claude Code needs to generate a failing test and then the implementation. Most teams lose fidelity at every handoff between product spec, prototype, ticket, and test — writing the card once, in a format precise enough for all four uses, removes that translation tax entirely.
Building the course-production engine taught me a related lesson from the other side: the same “structured task with explicit dependencies, single owner, and a hard completion signal” pattern that makes AI coding agents reliable also makes AI content generation reliable. Treating course production as a dependency-checked DAG — with cycle detection before a single deliverable gets generated — caught the kind of planning mistakes (missing a prerequisite, releasing a code ZIP before the module that needs it) that would otherwise only surface after tokens and effort had already been spent.
Where this could go
The requirement-card-as-single-source-of-truth idea generalizes well beyond one course: any org standardizing on AI-assisted development could adopt it as a company-wide artifact format, with a shared business-rules register instead of rules re-explained informally in every ticket. The multi-agent orchestration design in the framework — locking shared resources across parallel feature work, an observability agent that traces which agent received what context and why an implementation looped — is essentially a blueprint for running several development teams’ AI agents against the same codebase without them stepping on each other, which is exactly the coordination problem larger engineering orgs run into once more than one team is using agentic coding tools at once.
The course-production engine is its own generalizable pattern, separate from this specific course: a layered, dependency-graphed content pipeline with per-layer model assignment and hard output contracts could produce any large structured deliverable set — internal documentation, a certification curriculum, a compliance-training library — not just this one curriculum. The scaffold/schedule/dispatch split is the reusable part; swapping in a different outline and production plan is what would make it produce something else entirely.
Text summarized and optimized using Anthropic’s models and reviewed by a human.