Your Employees Are Coding 10x Faster With AI. Your Pipeline Is Breaking.

You manage AI-generated internal tools the same way you manage any other production software: by putting them on a governed platform with centralized security, an inventory that tracks what exists and who owns it, and tiered approval that scales with how much damage a tool could do. Policy documents and per-app reviews don't hold up at the volume AI coding tools now produce.

That's the short answer. The longer answer is why almost nobody is doing it yet.

The bottleneck moved from building to reviewing

For twenty years, the constraint on enterprise software was engineering capacity. If you wanted a dashboard, an automation, or an internal tool, you filed a ticket and waited for IT to have room on the roadmap. That constraint is gone. Claude Code and its peers let a customer success manager or a sales ops lead describe what they want and get a working prototype in an afternoon.

CIOs are leaning into this on purpose. At EnFi, Skillsoft, and ZenBusiness, leadership is deliberately extending AI coding tools past engineering into HR, customer success, sales, and marketing.¹ As EnFi's CTO Scott Weller put it, "What started as an engineering productivity initiative has become a company-wide capability, where anyone from the CEO to a customer success manager can turn an idea into a working prototype in hours, not weeks."¹ The catch, in his framing, is that "every branch, regardless of who initiates coding projects, passes through the same automated quality gates, architectural checks, and human code review before anything reaches production."¹

That second sentence is the whole ballgame. The building constraint disappeared. The reviewing constraint didn't. Most companies have gates built for the volume of a professional engineering team, not for the volume of every employee with a Claude account.

What are employees actually building with AI?

This isn't a hypothetical about rogue engineers. Sixty percent of builders across seniority levels have built software, workflows, or automations outside of IT oversight in the past year, and a quarter do it frequently.² The reasons are practical, not rebellious: 31% say they can build faster than IT, and 18% say IT's process is too slow.²

Thirty-five percent of organizations have already replaced at least one SaaS tool with a custom AI-assisted build, and 78% expect to build more custom tools in 2026, with workflow automation and internal admin tools the categories most likely to get replaced.² For a rundown of the tools employees are actually reaching for, see the shadow AI tech stack employees are running.

Worth noting: most of this isn't full-blown "describe an app, get an app" vibe coding. Only 31% of builders who ship working software are prompting their way to a complete application. Most, 72%, use AI to write discrete snippets they integrate into larger projects.² The stereotype of an untrained employee prompting a whole finance system into existence overstates the average case. It doesn't change the governance math, because even measured, snippet-by-snippet building adds up to real software running in production, unaccounted for.

The productivity number everyone cites, and the number that should worry you more

Apiiro's analysis of Fortune 50 codebases found AI-assisted developers shipping 3 to 4x more code, and generating 10x more security findings along with it:³

• Privilege escalation paths up 322%, architectural design flaws up 153%, and over 10,000 new security findings per month by June 2025 in Apiiro's monitored repositories, a tenfold increase in six months.³
• Trivial syntax errors down 76%.³

The AI isn't sloppy in the way people expect. It's clean on the surface and structurally reckless underneath.

Veracode's testing across more than 100 models found AI-generated code introduces a known security vulnerability in roughly 45% of tasks, a number that has barely moved across report updates.⁴ A Stanford study found something worse than a bug rate: participants using an AI coding assistant wrote less secure code on four of five tasks, and were simultaneously more confident their code was secure.⁵ The tools don't just introduce risk. They suppress the instinct to check for it.

And the productivity claim itself deserves an asterisk. METR's randomized controlled trial of experienced open-source developers found AI coding tools made them 19% slower on real tasks, even though those same developers estimated AI had sped them up by 20%.⁶ The gap between felt speed and actual speed is exactly the kind of thing that makes "ship it, we're moving fast" a bad governance strategy.

Why review can't keep up

Traditional code review, security scanning, and IT approval were built around a few reasonable assumptions: a limited number of trained authors, small incremental changes, and a review queue sized to that trickle. AI-generated internal tools break every one of those assumptions at once.

• Volume outpaces reviewers. When one person can generate what used to take a team a week, the number of things needing review multiplies faster than headcount ever will.
• The failure mode shifted. Reviewers are trained to catch syntax errors and obvious bugs. The new problems are architectural, privilege escalation paths and design flaws buried in code that looks clean.³
• Confidence is inflated on both sides. Builders believe their AI-assisted code is secure.⁵ Reviewers, pressed for time, are more likely to trust code that passes a quick scan and looks well-structured.
• There's no single door it walks through. A dashboard built in Retool, a script run through a terminal, and an agent stitched together in a no-code tool don't hit the same review process, if they hit one at all.

For the mechanics of closing that gap, see the step-by-step framework for securing AI-generated code.

The governance gap, by the numbers

Retool's 2026 governance survey puts the mismatch in blunt terms:

• 93% of senior technology and security leaders are at least somewhat concerned about vibe-coded internal tools running in production, and 38% rank it among their top operational risks right now.⁷
• Only 8% describe their internal tool governance as strong.⁷
• 22% report at least one production incident caused by an AI-generated internal tool in the past year, and 51% say they can't be certain whether one has occurred.⁷

That last number matters most: most companies don't have an incident count because they don't have visibility, not because nothing went wrong.

Gartner projects that by 2030, more than 40% of enterprises will experience a security or compliance incident linked specifically to unauthorized shadow AI.⁸ Gartner also estimates that citizen developers will outnumber professional developers roughly 4 to 1 at large enterprises, a shift AI coding tools are accelerating fast by removing the skill barrier to build.⁹ More builders, less oversight, and a widening confidence-competence gap. For a broader framework on treating this as an organizational problem rather than a tooling one, see the step-by-step shadow AI governance framework.

How much does a shadow AI breach cost?

IBM's 2025 Cost of a Data Breach Report has the number: breaches involving shadow AI cost an average of $4.63 million, about $670,000 more than the global average.¹⁰ Ninety-seven percent of the organizations breached lacked proper AI access controls.¹⁰ The exposure isn't abstract. Recent scans of live vibe-coded apps found:

• A Red Access scan of more than 380,000 public web assets built on vibe-coding platforms found roughly 5,000 built for corporate purposes, and 40% of those contained sensitive data deployed with no authentication, access controls, or audit trail.¹¹ Among the exposed: a live financial dashboard at one of Latin America's largest banks, and strategic documents from a $200 billion company.¹¹
• A similar scan of apps on Lovable, Bolt.new, and Base44 turned up 2,000 critical vulnerabilities, 400 exposed secrets, and 175 instances of exposed personal data.¹²

These weren't sophisticated attacks. They were unguarded doors that nobody knew were open.

How to manage AI-generated internal tools: the paved-path model

Banning the tools doesn't work; 60% of builders are already routing around IT, and the incentive to keep doing it (speed) isn't going anywhere.² The fix leaders themselves point to is structural, not punitive. Fifty-five percent of technical C-suite leaders say security and access controls for AI-generated internal tools should live in a centralized platform underneath the app, not in per-app configuration (7% favor that) or policy documents alone (26%).⁷ That's the clearest data point in the whole survey on what actually works.

In practice, a paved path looks like this:

1. Build an inventory first. You can't govern what you can't see. Track what's running, who built it, what data it touches, and whether it's still in use. Most companies currently can't answer whether an incident has even happened, let alone which tool caused it.⁷
2. Push identity and access control below the app layer. Instead of trusting each tool to implement its own auth, mediate data access through a shared identity layer so no internal tool can quietly pull customer records or credentials it was never scoped to touch.
3. Tier approval by blast radius, not by who built it. A personal script that reformats a spreadsheet doesn't need the same review as a tool that writes to a production database or handles customer PII. Match scrutiny to consequence.
4. Automate the gates that scale. Static analysis, dependency and secrets scanning, and architectural checks need to run on every build, employee-built or engineer-built, the same way EnFi routes all output through identical quality gates regardless of who initiated the project.¹
5. Define a graduation path. A prototype built in an afternoon and a tool that three departments now depend on daily are not the same asset. Set clear criteria for when something has to move from a personal build to an owned, supported piece of infrastructure, with a named owner and a lifecycle.

For the operational playbook that turns these principles into a working process IT can actually run, see governing the apps employees build with AI.

Build vs. buy vs. build-in-the-shadows

There's a third option nobody frames clearly enough. It's not build versus buy. It's build openly, on infrastructure that treats what you make as an asset, versus build secretly, on nothing, and hope IT never asks.

The companies handling this well aren't slowing employees down. They're giving them a sanctioned place to build that comes with the security and visibility baked in, so the tool an ops manager ships on a Tuesday afternoon is owned infrastructure by Wednesday, not a liability discovered during an audit two years later. That's the same instinct behind platforms like Remy, which treat internally built software as something a company owns and operates, not a side project someone forgot to mention.

The leverage AI coding tools handed your employees is real. So is the tax on quality and security that comes with it.³⁴ Companies that pretend the leverage isn't happening will keep discovering it the hard way, in an incident report. Companies that build the paved path get the speed and keep the asset.