An Escape.tech scan of more than 1,400 vibe-coded production applications found that 65% contained security issues and 58% had at least one critical vulnerability. A broader scan of 5,600 production apps found 2,000 highly critical vulnerabilities, 400 exposed secrets, and 175 instances of personally identifiable information exposed in ways that should not have reached production. These are not edge cases from amateur developers — they are the results of AI-assisted coding deployed without an adequate governance layer.
The failure mode is predictable. Individual developers can use vibe coding tools effectively because they bring their own experience to the review process. They know when something looks wrong. They catch the security antipatterns, recognize the hallucinated dependency, spot the authentication flow that will fail under load. Enterprise teams cannot rely on that distributed intuition at scale. What works for a solo developer building a side project breaks down in an organization with fifty developers and inconsistent standards for what “good enough” means.
ishikawa
Enterprise vibe coding failures
Security
Secrets hardcoded in generated code
Hallucinated dependencies with vulnerabilities
Governance
No mandatory review for AI output
No policy on AI tool usage
Quality
Generated tests mock rather than verify
Inconsistent patterns across teams
Integration
AI unaware of actual API contracts
Generated code ignores existing architecture
The Trust Gap Is Hiding a Real Problem
Ninety-two percent of U.S. developers now use AI coding tools daily. Only 29% trust the code those tools produce. That gap between adoption and trust is not a signal that developers are being appropriately cautious — it is a signal that most organizations have not built the feedback loop that would let developers know whether their caution is calibrated correctly.
When a developer does not trust AI output, they review it more carefully. That is the right behavior. But careful individual review is not a scalable enterprise control. It depends on each developer applying consistent judgment across every commit, which does not happen in practice. Some developers over-review and slow down unnecessarily. Others under-review and let things through that should not have shipped. The gap between adoption and trust exists because there is no institutional mechanism for converting individual caution into team-level governance.
What a Governance Layer Actually Requires
Governance for AI-assisted coding is not complicated, but it requires deliberate design rather than assuming it will happen organically.
The minimum useful governance layer has four components.
Mandatory review for AI output. AI-generated code should never flow directly from model output to merged pull request without human review. This is not because AI output is bad — it is because the human review step is where the quality gate that an experienced developer applies intuitively gets made explicit and consistent.
Security scanning in the CI/CD pipeline. Automated scanning catches the most common AI-generated security issues — hardcoded credentials, known vulnerable dependency versions, common injection patterns — before they reach production. This is the most scalable control because it does not depend on developer attention.
AI policy documentation. A one-page document answering the questions that developers are currently resolving inconsistently: which tools are approved, what types of applications require additional review, what to do when the model produces output that references an external dependency not in the approved list, and what the escalation path is when something looks wrong but the developer is not certain.
Ownership. Someone has to own the AI coding policy the same way someone owns the security policy. Without clear ownership, governance documents become stale, edge cases accumulate as unofficial exceptions, and the policy drifts from what it says to what actually happens.
Karpathy’s Frame Is the Right One for Enterprise
Andrej Karpathy recently reframed “vibe coding” as a starting point rather than a destination, introducing “agentic engineering” as the more disciplined practice: coordinating AI agents while preserving correctness, security, and maintainability. His formulation — “vibe coding raises the floor, agentic engineering is about raising the ceiling” — describes the same evolution enterprise teams need to make.
The floor has already been raised. Developers across the organization are using AI tools, generating code faster, and delivering more than they could before. The ceiling is where the enterprise problem lives: the production security issues, the inconsistent patterns, the AI-generated code that works in development but creates problems when it interacts with other systems at scale.
At Carvana, I led a five-developer team building inventory and vehicle-data systems that processed millions of vehicle records daily through an event-driven architecture. Small team, high stakes, strict standards. The team’s output was exceptional not because the standards were relaxed — it was because the standards were clear, enforced, and understood by everyone on the team. Excellence in production code is not achieved by trusting the model. It is achieved by knowing exactly what standard the output needs to meet before it ships.
The enterprise vibe coding problem is not that AI-generated code is unacceptably bad. It is that the standard it needs to meet before production is not consistently defined, enforced, or measured. Governance fixes that. The tools are already in use — the question is whether the governance layer will be built proactively, before the production incident, or reactively, after it.
The Productive Path Forward
The organizations closing this gap are not banning AI coding tools. They are treating AI output as they would treat output from a capable but junior developer: useful, often correct, requiring review, and subject to the same quality gates as any other code.
That framing resolves the adoption-versus-trust tension. Trust is not a binary — it is calibrated to the review process. With a governance layer in place, developers can use AI tools more freely and with appropriate confidence, because the controls that catch the failure modes are in the pipeline rather than entirely in each developer’s head.
The investment in that governance layer is small relative to the risk it manages. One production security incident in a mid-market company costs more in remediation, regulatory exposure, and customer trust than the entire governance program. The stat from the Escape.tech scan — 65% of vibe-coded applications with security issues — should be the number that prompts that investment, not a post-incident retrospective.