In mid-2026, the data on AI-assisted coding is no longer ambiguous. Surveys from across the developer community converge on the same picture: roughly 92% of US developers use AI coding tools as part of their daily work, and roughly 29% report that they trust the output of those tools. The gap between those two numbers, 63 percentage points, is the governance gap, and it is the most consequential unsolved problem in enterprise software engineering today.
The teams whose codebases will compound over the next three years and the teams whose codebases will degrade are being separated right now, and the separating factor is not which AI tools they chose. It is whether they put governance around those tools before the volume of AI-generated code outran the organization’s ability to review it.
flowchart TD
A[AI coding tool adopted] --> Q{Governance<br/>defined?}
Q -->|No| N1[Implicit decisions by<br/>individual developers]
N1 --> N2[Inconsistent review depth]
N2 --> N3[No attribution or audit trail]
N3 --> N4[Debt compounds at AI speed]
Q -->|Yes| P1[Policy]
P1 --> P2[Review discipline]
P2 --> P3[Attribution and audit trail]
P3 --> P4[Security gates]
P4 --> P5[Accountability]
P5 --> P6[Training]
P6 --> G[Codebase compounds<br/>under deliberate oversight]
class N4 bad
class G good
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;
Vibe Coding Without Governance Compounds Technical Debt at AI Speed
The pattern is consistent across the engineering organizations I have looked at this year. AI coding tools are adopted across a team. Productivity gains show up quickly, often within weeks. The code review process is not adjusted, because the existing process feels like it is working. Six to nine months in, somebody on the team notices that the codebase has started to look strange. Different sections follow different conventions. Patterns the team had explicitly decided against are showing up in new code. Dependencies appear in package files that nobody on the team can clearly justify. The on-call rotation starts surfacing incidents in code that the developer named in the commit history does not feel ownership of.
By the time those signals become visible, there is usually a year of AI-generated code accumulated in the system. Remediating it costs more than the original productivity gain ever delivered.
This is not a tooling failure. The tools are doing what they were designed to do. It is a governance failure. The organization adopted a powerful production capability without defining the rules under which that capability would be used, and the absence of rules became the rules.
The Six Pillars of Vibe Coding Governance
Governance for AI-assisted coding has the same shape governance for any consequential engineering activity has. It rests on six pillars, and the absence of any one of them weakens the others.
Policy. Policy defines what the team is allowed to use AI coding tools for, what is banned, and what requires explicit approval. Most teams have an implicit policy of “anything goes,” which is a policy in the same way that having no traffic laws is a policy. A useful written policy addresses categories: greenfield code in a sandboxed module versus changes to production-critical paths, low-stakes utility versus security-sensitive logic, internal tools versus customer-facing systems. It needs to be specific enough that a developer asking “can I use AI for this” has a clear answer.
Review discipline. AI-generated pull requests need to be reviewed at least as rigorously as human-written ones, and in practice they need to be reviewed more rigorously, because the cost of accepting them is low and the volume is high. A useful review discipline identifies AI-generated code in the pull request, evaluates not just correctness but fit with the existing codebase, and ensures reviewers spend proportionate time rather than rubber-stamping plausible-looking diffs. Teams that adopt AI coding tools without adjusting review practices find their review process atrophies under the cognitive load of high-volume output.
Attribution and audit trail. Every AI-generated change should be identifiable as such, tagged with which tool produced it, and associated with the prompt or context that drove the generation. Without attribution, you cannot answer the question “how much of our codebase was AI-generated, and where.” Without that answer, you cannot prioritize review intensity, security scanning, or remediation. The teams that will have a viable response when an auditor or a security incident demands provenance are the teams that built attribution in from the beginning.
Security gates. AI-generated code introduces specific risks conventional review does not catch reliably. Dependency hallucination, where the AI invents a package name or pulls in a typosquatted package, is well-documented. Secret leakage, where AI tools embed credentials they saw in a context file, is recurring. Subtle injection vulnerabilities, where AI handles user input in ways that look reasonable but bypass the team’s sanitization patterns, slip through review when reviewers do not know to look for them. Security gates need automated dependency verification, secret scanning on every AI-generated commit, and a reviewer checklist that calls out the AI-specific failure modes.
Accountability and ownership. When AI-generated code fails in production, who responds. The developer named in the commit history may have accepted hundreds of lines of AI output without deeply understanding all of it. Collective ownership dissolves under pressure. A useful accountability model assigns clear ownership to a named person, treats acceptance of AI output as a positive act of authorship rather than passive endorsement, and ensures on-call response has the context it needs.
Training. Working productively and safely with AI coding tools is a real skill, distinct from the skill of writing code. Recognizing when output is plausible but wrong, designing prompts that produce code consistent with project conventions, predicting failure modes before they reach production: all of this is learnable, and it is rarely learned without deliberate training. Teams that treat AI tool adoption as self-serve onboarding leave the most consequential variable unmanaged.
The LERETA Analog: What Governance at Scale Actually Looks Like
The pattern is not new. The velocity is.
From 2020 to 2024 I served as senior enterprise architect at LERETA, the second-largest property-tax processor in the United States, leading more than thirty developers through a roughly $20 million, multi-year modernization of two flagship products. The work replaced significant portions of legacy mainframe technology on a critical path the board of directors needed visibility into.
What made that engagement deliverable was governance. Wall-sized enterprise architecture diagrams gave the CTO and the board a visual representation of the modernization critical path. A review cadence ensured no significant architectural decision happened in isolation. There was clear attribution of which team owned which component, and clear accountability for outcomes. The security and compliance posture matched a system handling roughly $18 billion in annual processing. There were policies about what could be retrofitted from an acquired company’s codebase and what needed to be rebuilt, and we learned, sometimes painfully, when one of those decisions was made under the wrong assumption. The work delivered because the governance held.
AI coding governance has the same shape, compressed. Every AI-assisted pull request is, in miniature, a modernization decision. The codebase is being changed by an outside system. The change needs review, attribution, security verification, accountability, and a trained team. The cycle time is hours instead of months. Teams that already know how to run modernization governance have a useful pattern to draw on. Teams that have never run it are learning under live conditions.
Starting Is Not Buying a Tool
The most common mistake I see right now is engineering leaders treating governance as a tooling procurement question. There are a growing number of vendors selling AI code review tools, AI security scanning tools, AI attribution and audit tools. Some of them are useful. None of them substitute for the underlying decisions an engineering leader has to make.
Starting on vibe coding governance means answering four questions in writing.
What is the team allowed to use AI coding tools for, and what is explicitly off-limits. The answer does not need to be restrictive. It needs to exist.
How is AI-generated code reviewed, and by whom. Is it called out in the pull request. Does it go through a different reviewer pool. Does it get held to a different standard, and if so, which one.
What is logged about AI-generated code so the provenance is reconstructable. Which tool was used. What prompt or context produced the output. Which lines were AI-generated versus human-written.
Who is accountable when AI-generated code fails. The default of “the developer who committed it” is one answer. It is not the only answer. Whatever the answer is needs to be explicit, and the team needs to understand it before the incident, not during it.
A leader with the authority to decide can answer those four questions in a day. The first version does not need to be perfect. It needs to exist in a form the team can follow. Iteration on governance after it is in place is much easier than retrofitting governance onto a codebase where a year of AI-generated code is already accumulated.
The Mistakes Most Teams Make
Three patterns recur in organizations that adopted AI coding tools without governance.
Treating it as a tooling problem. The instinct is to evaluate Copilot versus Cursor versus Claude Code, pick a winner, and consider the question handled. The tooling choice matters but is not the governance answer. An organization with no governance and the best tool available will produce a worse codebase outcome than one with disciplined governance and a mid-tier tool.
Reviewing AI-generated pull requests less rigorously than human-written ones. This is the inverse of what the situation requires, and the most consistent failure mode I see. The reasoning is usually some combination of “the diff looks reasonable,” “I trust the developer who submitted it,” and the implicit time pressure of high AI volume. Six months of that pattern and the codebase has changed in ways that cannot be reversed by re-reviewing.
Not knowing who wrote what. This is the attribution failure, and it closes off the other recovery options. If you do not know which code was AI-generated, you cannot scope remediation, prioritize security review, or adjust governance based on what is actually in the codebase. The teams in the worst position right now are the ones that adopted AI coding tools enthusiastically a year ago and now cannot answer how much of their production code came from those tools.
Recovery is possible. It is more expensive than putting governance in place from the beginning.
A fractional CTO engagement is one of the more direct ways to put vibe coding governance in place, because the work benefits from someone who has run governance over consequential engineering programs before and can apply the pattern under compressed cycle times. If your engineering team has adopted AI coding tools and you are not sure what the governance posture actually is, that is worth a direct conversation.
