From AI Prototype to Production: The Bridge Nobody Shows You
From AI Prototype to Production: The Bridge Nobody Shows You
Honesty note: this is the engineering side of my own AI-assisted workflow — I’ve built prototypes with AI (why) and I live the 5 AI-workflow rules I wrote about. This post is about what happens between the prototype and the version you’d actually publish.
TL;DR
- A prototype is a proof, not a foundation. It answers “is this fun?” — it doesn’t need to be well-structured, and treating it as production is the mistake. The bridge is a conscious decision: rewrite, refactor, or rebuild.
- The rewrite decision is the key call. Rewrite when the prototype is a single tangled file, when state is implicit, or when AI produced code you don’t fully understand. Keep-and-refactor only when structure is already clean (my project structure).
- Technical debt from AI loops is the hidden cost. AI fixes break adjacent features; without version control checkpoints you lose working states — that’s exactly why rule 2 (backups) is non-negotiable. Every AI edit should be a commit you can return to.
- The production checklist is boring and essential: typed data (no magic strings for events/keys), a single state/event flow, assets loaded through one pipeline, and dead code deleted. A game you can’t read is a game you can’t ship (the 60fps reality).
The three paths
| Path | When | What you keep |
|---|---|---|
| Rewrite | Prototype is one tangled file; state implicit; you don’t understand parts of the AI code | Ideas, tuned values, assets — not code |
| Refactor | Structure already clean; changes are mostly renaming/decoupling | Most code, with discipline |
| Rebuild (hybrid) | Core loop is good but the edges are AI-spaghetti | Core loop rewritten cleanly; reuse proven subsystems |
The honest rule: when in doubt, rewrite. A prototype’s value is its ideas and tuned values — those survive a rewrite; its code rarely does. The cost of carrying unreadable code is paid every day after; the cost of rewriting is paid once.
What AI prototypes do that production can’t tolerate
- Single-file everything — scene logic, input, assets, all in one script. Fine for a demo, fatal for a game with 10 scenes (my scene structure).
- Magic strings — event names, texture keys, localStorage keys written inline. Production wants them in one constants module (the save-system pattern).
- Implicit state — flags toggled in place with no owner. Production wants a single state flow (architecture in Phaser).
- Asset loading scattered — sprites loaded mid-scene, no manifest. Production wants one pipeline (asset pipeline).
- Unedited AI text — prompts embedded as comments, TODOs everywhere, half-used imports. Production wants clean, readable code — the thing the 5 rules protect.
The production checklist (when the bridge is done)
- One entry flow — boot → loading → menu → scenes, each with a clear owner.
- Typed constants — events, keys, and localStorage keys in one module; no magic strings.
- Asset manifest — every asset loaded through one pipeline, sizes audited (asset size guide).
- State is owned — one place decides game state; scenes read it, don’t improvise it.
- Dead code deleted — AI iterations leave abandoned functions;
git grepfor them and cut. - Checkpointed — every significant change is a commit; you can return to any working state (rule 2).
The workflow that makes the bridge cheap
From my own practice (the 5 rules): prototype with AI → stop and plan the rewrite before production coding (rule 5: feasibility + design before coding) → rewrite the core loop with typed structure → feed the AI small, single-task edits into the new structure (rule 1: one change at a time) → verify each against a checkpoint. The bridge isn’t a scary migration — it’s a planned rewrite with version control underneath.
Pitfalls
- “It works, just ship it” — a working prototype that’s unreadable becomes an unshippable game the first time a bug needs a fix you can’t find.
- Refactoring the tangled file forever — sometimes the honest path is deleting it and rewriting 300 lines in an hour with structure.
- Letting AI patch a broken structure — AI is great at fitting new code into existing structure and terrible at deciding the structure is wrong; that decision is yours (rule 3: you aid the AI).
- No checkpoints during the bridge — the rewrite itself needs commits; an uncommitted rewrite is one bad edit from losing everything.
- Skipping the plan — the bridge fails when it’s “start coding and see”; it works when it’s “here’s the structure, now fill it” (rule 5).
Bottom line
The AI prototype is the cheapest way to learn what your game is — and the worst foundation to build on. The bridge is a conscious decision: rewrite by default, refactor only clean code, keep the ideas not the spaghetti, and checkpoint everything. My own path is prototype-with-AI → planned rewrite → small AI edits inside clean structure — the discipline that turns a fun demo into a game you can actually publish.