Enterprise companies watching their developers adopt AI coding tools have two reasonable concerns: they want the velocity gains, and they do not want the governance failures. Those two goals are compatible — but only if the governance work happens before the vibe coding does, not after.
The Pragmatic Engineer’s deep-dive into Anthropic’s engineering practices found that 70 to 90 percent of internal code is now AI-generated, product requirement documents have been replaced by working prototypes, and code review is increasingly AI-driven. If that describes one of the most technically sophisticated organizations in the industry, it describes the direction enterprise software development is heading. It does not describe where most enterprises are today — and the gap between Anthropic’s context and a thirty-developer team maintaining a production system processing billions in transactions annually is significant.
flowchart TD
Q{Is this codebase<br/>production-critical?}
Q -->|No: internal tool or prototype| V[Vibe coding with<br/>basic review checkpoints]
Q -->|Yes| Q2{Does it handle<br/>regulated data?}
Q2 -->|No| Q3{Team size?}
Q2 -->|Yes: PII, HIPAA, PCI| G[Full architecture review<br/>and compliance scan at every PR]
Q3 -->|Fewer than 5 developers| V2[Vibe coding with<br/>pair review]
Q3 -->|5 or more developers| V3[Vibe coding with documented<br/>patterns and weekly arch review]
class V good
class V2 good
class V3 good
class G warn
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;
What Goes Wrong Without Governance
The failure mode I see most often in enterprise teams adopting AI coding tools is not adoption failure — it is adoption without structure. Developers start using AI assistants individually. Velocity goes up. Quality feedback loops go away. Six months later, the codebase has grown by 30 percent, the architecture has drifted from what anyone documented, and the senior engineers who understood the original system design are spending their time fixing AI-generated inconsistencies rather than building new features.
I saw a version of this dynamic at LERETA, the second-largest property tax processor in the United States, during a major modernization effort. Mid-way through the project, LERETA acquired a company from Texas that provided similar technology, with the intention of retrofitting that technology to fit the flagship product rebuild. The data structures differed slightly. The way they handled information was fundamentally different. The acquisition’s technology was built under different assumptions, without knowledge of the constraints that shaped the LERETA codebase, and integrating it required months of rework that a clean-start approach would have avoided.
The same dynamic plays out in enterprise vibe coding when AI-generated code is accepted without governance. The AI does not know the architectural decisions made six months ago. It does not know which components are performance-critical. It does not know that the naming convention in the recent files is an experiment that was not ratified by the team. Without governance, it generates against whatever context it has — and that context is always incomplete.
What Enterprise Vibe Coding Governance Actually Covers
Governance in this context is not bureaucracy. It is the set of structures that allow AI-assisted development to produce consistent, maintainable, reviewable code at enterprise scale.
Architecture documentation that stays current. AI agents reference context they can read. If the architecture documentation is current and accurate, the AI generates code that aligns with the existing architecture. If documentation is stale or absent, the AI generates against whatever patterns it infers from recent files — which means it infers from whatever was last committed, not from the intentional design. Keeping the architecture documentation current is a precondition for enterprise vibe coding working well.
Review checkpoints tied to criticality. Not all code carries the same risk. An internal analytics dashboard built by one developer does not require the same review process as a payment processing integration. Enterprise governance tiers the review requirement to the code’s criticality: production-critical paths require human review of AI output; internal tools and prototypes can move faster. The key is that the tiers are defined and enforced before the AI coding begins, not negotiated case-by-case.
Compliance and security scanning at the PR level. AI-generated code can introduce security vulnerabilities in the same ways human-written code does — insecure dependencies, improper input validation, data exposure patterns — and in some cases faster. Automated security scanning at the pull request level is not optional for enterprise vibe coding; it is the primary control that makes velocity compatible with compliance obligations.
Explicit patterns, not implicit conventions. When a team documents the patterns it uses — how data access works, how errors are handled, how authentication is wired — those patterns become part of the context an AI agent works from. When patterns are implicit, the AI generates against examples rather than documented decisions, and examples in a large codebase vary more than anyone remembers.
The Team-Size Inflection Point
Governance requirements scale with team size, not just codebase size.
A single developer using AI coding tools operates as their own reviewer — they catch inconsistencies because they wrote the surrounding code and remember the decisions behind it. The context lives in their head.
At two to four developers, pair review of AI-generated output keeps the context shared. This is the range where most early vibe coding success stories occur: small teams, fast velocity, built-in informal review.
At five or more developers, the informal review structure breaks down. No one person holds the full context. Architecture drift begins. Documentation that was optional becomes mandatory. This is the inflection point where governance transitions from nice-to-have to operational requirement.
At fifteen or more developers — where LERETA’s modernization teams were operating — architecture review meetings, documented patterns, compliance scanning, and regular codebase audits are not governance overhead. They are the coordination mechanism that makes velocity possible at all.
Getting the Order Right
The enterprise teams that make vibe coding work are the ones that build the governance layer before they scale AI adoption, not after. The teams that build the governance layer after are the ones debugging architecture drift and inconsistency in a codebase that is now 40 percent larger than it was six months ago.
The sequence matters: document the architecture, define the review tiers, set up the scanning, write the explicit patterns — then start generating at scale.
