Let me state the conclusion first. Code quickly built with AI (so-called vibe coding) works in the demo but breaks in production because AI can write "working code" but doesn't guarantee a "structure that doesn't break." Generative AI writes happy-path (when-it-goes-well) code astonishingly fast. But what production asks is the edge cases and adversarial conditions: what happens when the network drops, when malformed input arrives, when concurrent access occurs, when you're attacked. Ship to production with these missing, and it breaks.
This is not a "don't use AI" story. Building fast is itself correct. The problem is trusting AI's output as-is and shipping it to production. This article is a practical guide for businesses and developers holding an AI-built prototype to raise it (harden it) to production quality.
1. "Works" and "doesn't break" are different things
In recent years, "vibe coding" — quickly assembling apps with generative AI — has spread. Being able to turn an idea into a prototype in a few hours is truly revolutionary. On the other hand, trouble when putting it into production has also increased. Industry reports say a considerable proportion of AI-generated code required additional debugging after deployment, and many cases of AI-built products causing problems in production have been shared.
Why? AI writes code that achieves the "what you want to do" instructed by the prompt. But production-quality code needs more than that.
| What AI is good at | What's additionally needed in production |
|---|---|
| Writing working features fast | Boundary validation that rejects malformed input |
| Implementing the happy path | Error handling, timeouts, retries |
| Generating plausible UI | Authentication, authorization, data separation |
| Working on sample data | Handling concurrent access and race conditions |
| Implementing a single process | Whole-system consistency, idempotency, monitoring |
"Works" is a starting point, not the goal. There's a large gulf between working in a demo and withstanding production load, attacks, and failures.
2. The "fixed places" where AI-generated code breaks in production
Fortunately, there are strong patterns to where AI-generated code breaks. The five places I've reinforced repeatedly in the process of taking things to production are these.
① Missing input validation
AI tends to handle external input (forms, APIs, files) on the "correct premise." In production, unless you validate and sanitize all external input at the boundary, it breaks under malformed data or injection attacks. The standard play is to place type-safe validation (TypeScript + Zod, etc.) at the boundary.
② Missing error handling
It can write "when it goes well" code, but what to do on failure tends to be missing. When an external API goes down, when the DB is congested, when the network drops — unless you build in timeouts, retries with exponential backoff, and fallbacks, a failure in one spot stops the whole thing.
③ Security holes
AI tends to implement authentication/authorization at the level of "an if-statement in the screen." In production, unless authorization is enforced on the server/DB side, it's broken through by calling the API directly. Hardcoded secrets, lax CORS settings, SQL injection — these are holes often found in AI-generated code.
④ State races (concurrency)
Invisible in a single-user demo, but in production multiple processes run simultaneously. A "read → compute → write back" process causes races and corrupts data. For payments, it directly leads to double charges or balance inconsistencies. You need to prevent it structurally with idempotency and atomic operations.
⑤ Absent tests
AI will write tests if you say "write tests too," but whether they poke at meaningful boundaries and abnormal cases is a separate matter. Without tests, every change breaks something else, and it becomes "pickled code" no one dares to touch.
3. What production needs is not a "rewrite" but "hardening"
You might think "so it's a full rewrite, then," but in most cases that's not necessary. Keeping the skeleton built by AI while hardening the breaking spots after the fact is the fastest and cheapest approach.
AIで作ったプロトタイプ（骨格は活かす）
│
├─ 境界に型安全な検証を足す（Zod等で外部入力を parse）
├─ エラー処理・タイムアウト・リトライ・フォールバックを追加
├─ 認可をサーバ/DB側に移し、秘密情報を環境変数/秘密管理へ
├─ 競合する処理を冪等・原子的に作り直す（決済・在庫・予約など）
├─ 意味のあるテストとCI（型チェック・静的解析・セキュリティスキャン）を整備
└─ 構造化ログ・アラートで可観測にする
↓
本番運用に耐える品質へ
The AI video-localization platform I worked on was built with exactly this philosophy. To raise heavy, unstable AI/GPU processing to "withstands production operations" quality, I made backend test coverage of 100% mandatory (CI fails the build if unmet), kept type checking (mypy strict) and static analysis at zero errors, and made an idempotent design that can resume processing even if a spot GPU is forcibly stopped. "Build fast" and "doesn't break in production" can be reconciled via verification gates.
4. Verification-first — the mechanism that makes "fast" "safe"
This is the core of how I develop with one-person × generative AI. Generative AI makes implementation overwhelmingly fast, but by passing it through a multi-layered mechanism that doesn't trust its output as-is, you reach production quality while keeping the speed.
| Verification gate | What it prevents |
|---|---|
| Type-safe boundary validation (Zod / TypeScript) | Malformed input, unexpected data shapes |
| Automated tests (unit, integration, E2E) | Regression from changes, missed abnormal cases |
| Static analysis / Lint (type checking, unused detection) | Latent bugs, type escape hatches via any |
| Security scanning (dependencies, secrets, vulnerabilities) | Known vulnerabilities, leaked secrets |
| Enforcement via CI/CD | Structurally eliminates "humans forget to review" |
| Third-party security audit | Holes found only from the attacker's perspective |
This is not abstraction. In the B2B SaaS for lumber distribution, through four rounds of security audits including a third-party penetration test across 15 real roles, I demonstrated 0 missing-authorization findings across all 221 endpoints. Not "AI wrote it fast," but "because it's hardened by verification, it doesn't break in production even when built fast" — this is the basis of quality buyers should confirm in AI-era development.
5. A checklist for buyers
You want to take an AI-built prototype to production, or commission AI-leveraged development — here are questions to discern your counterpart.
A checklist for commissioning the productionizing of AI-generated code
- Can they talk about "safely hardening" and not just "building fast"? — can they concretely explain the verification gates (type safety, tests, security).
- Do they know where production breaks? — can they cite the five places: input validation, error handling, authorization, races, tests.
- Can they correctly judge rewrite vs hardening? — do they avoid immediately answering "full rewrite" and discern what can be kept.
- Do they have a mechanism to verify AI's output? — not "AI wrote it so it's OK," but do they protect quality mechanically in CI.
- Do they avoid bolting on security? — do they build authorization, secrets, and PII handling into the design.
My position: I build fast with generative AI and then harden it to production quality with the verification gates of "type safety, tests, security audit, idempotency." Taking an AI-built MVP to production, rebuilding a codebase whose quality is uncertain, improving security and performance — I've handled many such rebuilds at the stage of "it works, but I'm anxious about shipping it to production as-is."
FAQ
Q. Can an AI-built prototype be used in production as-is?
In most cases it's dangerous as-is. AI writes happy-path (when-it-goes-well) code fast, but tends to miss the "parts asked in production" — validation of malformed input, error handling, authorization, concurrency races, and tests. Keep the skeleton while hardening these after the fact, and you can raise it to production quality without a rewrite.
Q. Does AI-built code ultimately all need rewriting?
In most cases, no. Keeping the skeleton built by AI and reinforcing the breaking spots (input validation, error handling, authorization, races, tests) — this "hardening" is the fastest and cheapest approach. A full rewrite is limited to cases where the design is fundamentally broken.
Q. Why does AI-generated code work in the demo but break in production?
Because "works" and "doesn't break" are different things. AI quickly implements the instructed features, but what production asks is edge cases and adversarial conditions like network drops, malformed input, concurrent access, and attacks. A demo holds with sample data and a single user, but production load, failures, and attacks need additional engineering (verification gates).
Q. Can "building fast" and "quality" be reconciled?
They can. The key is to not trust AI's output as-is and to pass it through a multi-layered set of verification gates: type-safe boundary validation, automated tests, static analysis, and security scanning. This reaches production quality while keeping generative AI's speed. There's actually a case of running an AI/GPU pipeline in production while maintaining 100% test coverage.
Q. I'm anxious about whether my vendor uses AI. What should I confirm?
Using AI itself isn't a problem — rather, it's the source of speed. What to confirm is "how do they verify AI's output." If your counterpart can explain verification gates like type-safe boundary validation, automated tests, CI/CD, and security audits, they can ensure production quality even using AI. A counterpart who can only say "AI wrote it so it's fine" warrants caution.
Summary: the source of speed is AI, the source of safety is verification
To ship AI-built code to production with peace of mind, here's what to grasp.
- "Works" and "doesn't break" are different things — AI writes working code but doesn't guarantee a structure that doesn't break.
- The breaking spots are fixed — the five places: input validation, error handling, security, races, tests.
- Building fast is itself correct — the problem is trusting AI's output as-is. Pass it through verification gates.
- Productionizing is hardening, not a rewrite — keep the skeleton and reinforce the breaking spots after the fact.
- Commission by "can they safely harden what was built fast," not "can they build fast."
"I tried building with AI but I'm anxious about shipping to production" / "It works, but I'm not confident in quality or security" — that rebuild is exactly what I'm best at. Verification-first, I take it on one-stop to production quality that reconciles speed and safety.