The pitch for vibe coding is that it compresses the distance from idea to working software. That compression is often real. What it doesn’t compress is the distance from working software to software that handles production traffic, edge cases, malicious inputs, unexpected failures, and the requirements that weren’t specified in the original prompt.
That gap is larger than most vibe-coded projects account for, and the specific things missing are predictable — they correspond directly to what AI tools are and aren’t good at generating.
flowchart TD
Q{Is this vibe-coded app<br/>ready for production?}
Q --> SEC[Does it validate<br/>all user input?]
SEC -->|No| BAD1[Injection vulnerability<br/>— stop here]
SEC -->|Yes| ERR[Does it handle<br/>failures gracefully?]
ERR -->|No| BAD2[Silent failures in prod<br/>— stop here]
ERR -->|Yes| OBS[Is there logging<br/>and monitoring?]
OBS -->|No| WARN[Flying blind at scale<br/>— address before launch]
OBS -->|Yes| LOAD[Tested under<br/>realistic load?]
LOAD -->|No| WARN2[Load test first]
LOAD -->|Yes| GOOD[Production-ready]
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
class GOOD good
class BAD1 bad
class BAD2 bad
class WARN warn
class WARN2 warn
What AI tools are good at — and what they aren’t
AI coding tools are good at: generating code that satisfies the prompt, following the pattern of whatever is already in the file, and implementing functionality with clear precedent in training data.
AI coding tools are not reliably good at: generating robust error handling for failure scenarios the prompt didn’t mention, implementing security controls that depend on a context-specific threat model, adding observability instrumentation that reflects what you actually need to know about this system, or producing code optimized for the load profile of a specific application.
This is not a criticism of AI tools. It is a description of how they work. The tool generates what was asked for, in the style of whatever was already there. If the prompt said “build a login form,” the AI built a login form. Whether that login form properly validates input, rate-limits authentication attempts, or logs suspicious patterns is a separate question — one that requires a separate prompt or a separate human decision.
At CloudVirga, where I served as a solution architect on a production mortgage loan origination platform, one of the first things I escalated was the development environment setup. Developers were working inside virtual machines with response latency of several seconds per interaction. I pushed to replace them with physical hardware, which happened — and team morale and output quality both improved immediately. The lesson was about fidelity: a development environment that doesn’t reflect production conditions produces code that doesn’t account for production realities. That principle extends directly to vibe coding.
The five things that routinely fail to make it into vibe-coded production code
Input validation. The AI builds the happy path reliably. Edge cases — malformed inputs, unexpected character sets, missing required fields, inputs designed to break the parser — get less attention. In a test environment, you provide well-formed test data. In production, users provide whatever they type. SQL injection, XSS, and path traversal vulnerabilities commonly appear in vibe-coded code that wasn’t specifically prompted for security.
Error handling. AI-generated code tends toward optimistic execution: the path where the database responds, the API is available, and the file exists. Production code fails constantly — networks time out, services return errors, dependencies are unavailable. The difference between a codebase that surfaces failures cleanly and one that silently discards them or crashes is almost always whether error handling was explicitly asked for or written manually.
Observability. A vibe-coded app typically has whatever logging the starter template provided — usually not enough to diagnose a production issue. When something goes wrong in production, the first question is “what does the log show?” If the log shows nothing useful, the investigation starts from zero.
Performance under realistic load. AI-generated code works correctly for the number of requests in the development environment, which is typically one. Whether it works for 100 concurrent users is a different question that requires testing, profiling, and often significant changes to data access patterns and connection management.
Environment parity. Development environment assumptions baked into the code — hardcoded localhost URLs, local file paths, assumed environment variables — fail in production in ways that weren’t visible during development. Environment-specific configuration has to be externalized before a vibe-coded app is production-ready.
The production checklist
Six categories need explicit human review before a vibe-coded application goes to production:
- Input validation: does the application reject malformed, oversized, or malicious inputs at every entry point?
- Authentication and authorization: are access controls implemented correctly, and are they tested for bypass?
- Error handling: does every failure path produce an appropriate response, not a 500 error with a stack trace?
- Logging and monitoring: does the application produce logs that would be actionable during an incident?
- Load characteristics: has the application been tested under realistic concurrent load, not just sequential development requests?
- Environment configuration: is environment-specific configuration externalized, not hardcoded?
This review is not a full security audit. It’s a targeted pass against the categories that AI tools most commonly miss. For most vibe-coded applications, a competent engineer can run through it in one to two days. The cost of doing it is trivial compared to the cost of a security incident or a production outage caused by something on this list.
What this means for teams moving fast
Most vibe-coded projects are built by small teams with short timelines. The checklist above can feel like overhead that slows the shipping pace. It doesn’t — it prevents the kind of production incident that costs more time to remediate than the entire checklist would have taken.
The practical approach: build the checklist into the definition of done. Before any feature or application is called complete, these six categories pass. Treat it as part of the development process, not a gate applied at the last minute. The fastest teams are the ones where this check is automatic, not the ones where it’s optional.
