Executive Summary
The governance gap is a prioritization problem
Enterprise AI development faces challenges when it comes to measurement. Organizations carefully track AI tool adoption, including seat counts, usage rates, and developer productivity scores. They have far less visibility into what those tools are producing, who is reviewing it, whether it follows established standards, and whether the review infrastructure in place was built for this kind of output at this volume.
The result is a governance gap that widens with every new tool deployed and every new role that starts generating code.
This paper examines how that gap shows up across three dimensions: design system drift as the most visible symptom of ungoverned AI development; review processes that were built for human authorship and now buckle under AI volume; and expanded authorship across product, design, and QA running through governance infrastructure that was designed for a single function. It then looks at what the organizations closing the gap are actually building.
Several findings are worth stating plainly up front.
Governance failure carries an opportunity cost that exceeds the downside risk. Teams with the highest AI productivity gains built governance infrastructure first.
The parallel development model breaks single-queue PR review. Distributing review across roles is a structural requirement at scale.
Design system enforcement cannot happen at review if the AI lacked access to the current design system as input. Governance requires accurate context first.
For regulated industries, the audit trail problem is more acute than most compliance teams have recognized. Organizations not thinking about this now will retrofit it under worse conditions.
Governance failure in AI development carries an opportunity cost that exceeds the downside risk for most organizations. The teams seeing the largest productivity gains from AI are the teams that built the infrastructure to trust what AI produces, which lets them run AI with less friction across more of the organization.
The parallel development model, where multiple agents run simultaneously on multiple branches, breaks single-queue PR review as a governance mechanism. Distributing review across roles, with designers validating visual output, QA validating correctness, and product validating requirements before a PR reaches engineering, becomes a structural requirement at scale.
Design system enforcement cannot happen at the review stage if the AI generating the code did not have access to the current design system in the first place. Governance requires accurate context as an input to generation, with careful review as an output.
For organizations in regulated industries, the audit trail problem is more acute than most legal and compliance teams have recognized. Current AI coding tools do not produce the generation records that changing control requirements may eventually demand. The organizations not thinking about this now will be retrofitting it later.
The governance gap is a prioritization problem. Most organizations have treated governance as cleanup work that follows adoption, when it should be a precondition for AI development that actually delivers what it promises. The infrastructure to close it exists and is in production at enterprises running AI development at scale.
THE PROBLEM
The gap nobody is measuring
Most engineering organizations can tell you exactly how many AI coding tools their developers use. They can cite adoption rates, seat counts, and the percentage of developers who run an AI assistant daily. They cannot tell you with any precision how much AI-generated code is in production right now, who reviewed it, whether it complied with their component standards, or what changed between the prompt and the merge.
That asymmetry is the governance gap. Adoption metrics are easy to track, and control is harder, so adoption metrics get reported to boards and CFOs as evidence that the AI strategy is working, while the harder question, whether the organization has the infrastructure to trust what AI is producing, gets deferred.
Deferral carries real costs, and those costs are accelerating as AI tool usage expands beyond individual developers to broader product teams. Closing the gap requires rethinking where governance fits in the development workflow and building it into the work itself, with control infrastructure shipping alongside the tools that generate code.
ROOT CAUSE
How AI adoption actually happened
The adoption pattern at most enterprises followed a predictable path. A handful of developers started using AI coding assistants in their local environments. Output quality was uneven in the early days, and the productivity gains were real enough that usage spread without formal approval. By the time IT or engineering leadership noticed, AI tools were already embedded in how a significant portion of the team worked.
Leadership response typically fell into one of two camps: retroactive endorsement, which meant buying enterprise licenses and adding the tools to the approved list, or retroactive restriction, which meant banning unapproved tools and issuing a usage policy. Neither response addressed the underlying question of what was actually being produced and merged.
The enterprise license response is more common and creates a false sense of resolution. The organization has visibility into seat usage, a contract with the vendor, and an AI tool on the approved list. The harder question, whether the code these tools generate meets organizational standards, follows the architecture, uses approved components, and undergoes meaningful review before it ships, remains open.
The restriction response fares no better. Developers route around it, use tools on personal machines, and the code still gets merged, with even less paper trail than the licensed alternative would have produced.
Both responses manage perception while the actual problem compounds beneath the surface.
Reviewers see what was generated. They do not see what was asked, what constraints the agent was given, whether it had access to the right design system context, or whether the output represents the first attempt or the fifth.
SYMPTOM
Three ways the gap shows up
The governance gap surfaces in three distinct ways across an enterprise, each requiring different infrastructure to close. Most organizations are dealing with all three simultaneously without recognizing them as related.
Design system drift
The most visible symptom of ungoverned AI development is design system drift, which manifests in two directions.
The first is outbound. AI tools that generate code without access to the organization's actual component library produce output that quietly diverges from the system the design team maintains. The output looks right on the surface. Generic implementations replace approved components. Hard-coded values appear where design tokens should be. New variants get created when an existing one would have worked. The code passes review because it works, renders correctly, and passes linting.
Over time, this divergence compounds. Each merged component that bypasses the design system creates a precedent. The reviewer who approved it set a bar, and the next engineer who reviews similar output has implicit permission to merge it the same way. The design system becomes less authoritative with each generation of AI-assisted work, and nobody made an explicit decision to abandon it. The tooling simply stopped enforcing it.
The second direction is inbound. The design system itself falls behind because its maintenance process has not changed. A designer updates a component in Figma, and the coded version in Storybook gets updated weeks later, if at all. AI tools that consume outdated component libraries produce output that meets yesterday's standards. The system drifts because the feedback loop between design intent and coded reality is too slow.
Both directions point to the same structural issue: AI tools consume whatever context they are given, and if that context does not reflect current standards, the output will not either. Governance has to start by ensuring that what the AI had access to was accurate in the first place.
2
Traditional code review assumes a human author. The reviewer evaluates reasoning, checks for errors, flags architectural concerns, and verifies that changes align with standards. The author is accountable, the context is documented in a ticket or PR description, and the review is proportionate to the change's scope.
AI-generated code disrupts each of those assumptions. The author is an agent with no stake in the outcome, no understanding of the codebase's history, and no institutional memory of why certain decisions were made. The context often lives in a prompt that nobody else saw. The scope can be large, including a complete component, a full-page layout, or a set of API integrations, all generated in seconds. That speed creates pressure to merge quickly because the perceived cost of the work is low.
Code review increasingly happens on output that arrives without the reasoning behind it. Reviewers see what was generated. The prompt itself, the constraints the agent was given, whether it had access to the right design system context, and whether the output represents the first attempt or the fifth, all stay invisible to the reviewer.
The volume problem compounds the reasoning problem. Single-agent AI development is manageable with existing review infrastructure: one developer runs one session on one branch, the PR lands in the review queue alongside everything else, and the governance holds together.
Multi-agent parallel development breaks this entirely. When a team is running ten agents in parallel, one per ticket and each on its own branch, the PR volume runs an order of magnitude higher than the review capacity. Engineering becomes the bottleneck because the throughput of AI generation has outpaced that of the review process, regardless of how fast the reviewers themselves work.
Traditional pull request review is a poor governance mechanism for AI-generated work because it was designed for a different kind of authorship operating at a different volume.
3
Expanded authorship, unchanged governance
For the first several years of AI coding tool adoption, the governance question was primarily an engineering question. Developers were using Cursor and Copilot to generate code, and the governance framework lived in the pull request review process and in the code quality bar that engineering teams maintained.
That framing is becoming less accurate by the quarter. Product managers are generating working prototypes in production codebases using tools that connect to real repositories. Designers are submitting PRs for UI changes made in visual editors, with AI handling the code translation. QA teams are generating fixes for bugs they found and routing them directly back to engineering for review. Marketing teams in organizations that have adopted platforms like Builder are building and publishing pages through systems that access the same component libraries engineers maintain.
This expansion is broadly positive and turns AI development into a company-wide workflow change. It also creates a governance surface that is much larger and more varied than the one enterprise security and engineering teams originally designed for.
The developers using Cursor went through an onboarding process. They know the codebase, and they understand when to follow conventions and when to escalate. The PM who generated a prototype in a production branch last week may not know that the component they used has a deprecated variant, that the API they are calling has a rate limit, or that the page layout they built conflicts with an accessibility requirement the design team added last quarter.
Traditional code review can catch some of this. It cannot catch all of it, especially as the volume of AI-generated work increases faster than the engineering bandwidth to review it, and especially as the people generating that work sit further from the review process that was supposed to govern them.
Risk and opportunity
The cost of getting it wrong
Organizations that address the governance gap often frame it as a risk-management issue. That framing captures part of the picture. Governance failure in enterprise AI development entails both downside and opportunity costs, and the opportunity costs tend to be larger.
The downside cost is the one most often discussed:
These are real costs. For most organizations, the downside has not yet materialized catastrophically, which is part of why the governance gap persists. The debt is accumulating quietly.
The opportunity cost is less visible and arguably larger. Teams that do not trust AI-generated output restrict its use. They require additional review cycles and limit which roles can generate code and what it can touch. These are rational responses to an absence of control infrastructure, and they cap the productivity gains that motivated AI adoption in the first place.
The organizations getting the most out of enterprise AI development are those that have built the infrastructure to trust what AI produces, which lets them run AI with less friction across more of the team and more of the codebase.
"The organizations getting the most out of enterprise AI development are those that built the infrastructure to trust what AI produces and can therefore let it run with less friction across more of the team and more of the codebase."
Framework
What governance actually requires
Governance in enterprise AI development is infrastructure built into the workflow, applied continuously throughout the work itself. It answers four questions on every change.
Each question requires tooling. Policy plays a supporting role, defining what the tooling enforces. Documenting that designers should review AI-generated UI before it merges is a policy. Building a workflow that requires designer review before a PR can be opened is governance.
"Documenting that designers should review AI-generated UI before it merges is a policy. Building a workflow that requires designer review before a PR can be opened is governance."
Market
Where the market is
The AI tooling market has optimized heavily for generation speed and individual developer experience. The tools that captured early market share are excellent at producing output quickly, and they were not built to answer the four questions above at enterprise scale.
Organizations typically discover this after deploying AI tools at scale and observing the design system drift, the review bottlenecks, and the trust deficit that follows. What they find is that generation infrastructure and governance infrastructure are separate problems requiring separate investment.
The generation problem is largely solved at this point. The tooling is good, and individual developers are genuinely faster. The governance problem remains open. Most organizations are managing it by increasing the review burden on engineering, which partially cancels out the productivity gains that motivated AI adoption, or by imposing usage restrictions that limit what AI can touch and cap the ceiling on what AI can deliver.
A third approach is emerging among organizations that have worked through this problem: building or adopting platforms that treat governance as a first-class feature. In these environments, the design system is indexed and enforced before generation happens. Review workflows are multi-role by default, with designers, PMs, and QA participating in validation before a PR reaches engineering. Each change runs in an isolated environment with a shareable preview that any stakeholder can inspect. Engineers receive work that has already been validated across multiple dimensions, so their review can focus on code quality and architectural alignment with the functional questions already settled upstream.
This model speeds up AI development by eliminating rework cycles caused by unreviewed AI output and by giving engineering the confidence to merge more quickly, since upstream review is already thorough.
Architecture
Distributing review at scale
Single-agent AI development is manageable with existing review infrastructure, even if imperfectly. Multi-agent parallel development breaks this entirely.
The volume problem introduced earlier has a structural solution. Well-navigated multi-agent development involves distributing reviews across the team, with each role validating the dimension closest to their expertise. Engineering stops being the single queue that every change has to pass through.
Designers validate visual output, PMs validate functional requirements, QA validates correctness, and engineering reviews code quality. By the time a change arrives in the engineering review queue, it has already passed multiple domain-specific checks, which makes the code review faster and more focused because the upstream work has already been completed.
This approach requires a platform that supports the distribution:
COMPLIANCE
For organizations in regulated industries, including financial services, healthcare, and government contracting, the governance gap is sharper. AI-generated code in production systems may need to meet documentation, audit-trail, or change-control requirements that the current AI tooling ecosystem does not support.
The typical workaround is to treat AI-generated code the same as human-authored code for documentation purposes: log it in the PR, attach it to the ticket, and close the change control record. This satisfies compliance theater without delivering actual auditability, because the PR record does not capture what the AI was given, what it considered and discarded, or why the output looks the way it does.
The enterprises most serious about this are beginning to require that AI tools used in production development contexts provide a record of generation, including the inputs, constraints, model version, and iteration history, that can be attached to the change control record. Most AI coding tools do not produce this kind of artifact today. The regulatory pressure is building, and organizations that are not thinking about audit trail requirements now will be retrofitting them later under worse conditions.
Closing the Gap
What closing the gap looks like
The governance gap is an organizational prioritization problem. Most organizations have treated governance as the last thing to figure out after adoption is underway: deploy tools, observe productivity gains, and address side effects.
The governance gap in enterprise AI development is an organizational prioritization problem. Most organizations have treated governance as the last thing to figure out after adoption is underway, deploying tools, observing productivity gains, and then addressing side effects. That sequence made sense when AI tools were used by a small number of individual developers in controlled environments, and it stops making sense when AI is generating production code across engineering, design, product, and QA simultaneously.
The organizations closing the gap are treating governance as part of the adoption decision. Before deploying AI development tools broadly, they ask:
THE SOLUTION
What to build toward
An enterprise AI development environment with built-in governance has five characteristics working together.
AI agents have access to the current design system, including components, tokens, and patterns, as a first-class input to generation. Output that does not meet those standards is caught before it reaches review.
Every agent run happens in an isolated environment with a preview link that any stakeholder can access from any device, so a designer can review visual output on their phone and a PM can validate functional requirements without opening a terminal.
Review workflows are multi-role by default. A PR cannot be opened until design has approved the visual output, QA has validated functional correctness, and product has confirmed scope. Engineering receives a PR that has already passed domain-specific review, and the engineering review focuses on code quality.
Generation provenance is recorded throughout. The inputs to the AI, the constraints it was given, the model version, and the iteration history are all attached to the PR record and available for audit.
Agent work is visible at the team level. A Kanban view of active branches, pending reviews, and blocked work gives the whole team visibility into what AI is doing and where human judgment is needed.
This is a description of how enterprises run AI development today. Organizations using this model are seeing the productivity gains that AI development promises while keeping the design system intact, moving review queues, and maintaining high enough team trust in AI output to actually use it.
The handoff model was already slow before AI arrived. AI-generated work moving through that same handoff model produces fast output upstream that creates slow rework downstream. The organizations that win are using AI to collapse the handoff chain itself, with every role working in parallel on shared, governed, production-grade output.
Design system as input
AI agents have access to the current design system, components, tokens, and patterns as first-class inputs. Output that does not meet those standards is rejected before it reaches review.
Builder's collaborative development platform connects to your real codebase and design system, enforces standards before generation happens, and gives every role the access they need to review and contribute, without creating a new governance gap in the process.