There's a slide that shows up in a lot of enterprise architecture reviews right now. It's a demo of an app nobody on the engineering team has seen before. It works. It solves a real problem. And it was built last week by someone in operations, or finance, or claims, using Lovable or Bolt and a weekend's worth of prompting.
The sponsor in the room wants it live. And the moment it goes live, the accountability for it rolls up to you.
This is the part of AI-assisted development that the tooling conversation keeps skipping. We spend a lot of energy debating whether business users should be building software. That debate is over—they already are. The question that actually matters for an enterprise architect is different: What happens when the thing they built arrives at your production gates, bound for real data, real customers, and a real audit trail?
Shadow IT grew up, and it can code now
Shadow IT isn't new. Architects have been managing the gap between what business units adopt and what IT approves for as long as SaaS has existed. What's new is the kind of thing slipping through the gap.
The old version of shadow IT was a business team expensing a subscription to some tool without telling procurement. It created data-sprawl and integration headaches, but the tool itself was a finished product someone else operated. The failure modes were known.
The new version is different in a way that changes the whole risk picture. Business teams aren't adopting finished software anymore—they're authoring it. A vibe-coded app isn't a subscription. It's a production system with a database, business logic, and integrations, generated by a model that nobody in the room can fully account for, running on infrastructure that whoever built it happened to spin up. It looks like a demo. Underneath, it's a full application with all the obligations that implies.
And it's not one app. It's the pattern repeating across every business unit that has access to these tools, which is now all of them. Here at Xano, we have been naming this as a landscape-level problem for enterprise architects rather than a series of one-off incidents. If you treat each vibe-coded app as an exception to be handled case by case, you'll be doing that forever. The volume isn't going down. The tools are too good, and the business demand behind them is completely real.
The 90% nobody built
Here's the mechanical reason these apps stall at the gate. The frontend—the part that demos so well—is the easy 10% of a production system. It's the part AI builders are genuinely excellent at generating. What they mostly don't generate is the submerged 90%: the data-flow controls, the auditability, the integration discipline, the environment separation, the access controls that determine who can do what.
This is the same asymmetry Xano has written about in the context of why AI-generated backend logic deserves more scrutiny than the frontend. A generated UI that looks wrong is obvious to anyone. A generated business rule that's subtly wrong—applies the wrong tax treatment, routes a case to the wrong queue, exposes a field it shouldn't—looks completely fine right up until it doesn't. The code runs. It passes a casual review. And the defect lives in the logic, which is exactly the layer that has no governed home when an app is vibe-coded in isolation.
When that app reaches your gates, the gates do their job. Security can't see how data flows through it. Architecture can't verify how it touches systems of record. IT can't deploy it on approved infrastructure. None of these are the gates being difficult. They're the gates working as designed—catching software that was never built with them in mind, because the person building it didn't know they existed.
Every answer at the gate is a bad one
This is where it gets genuinely hard for the architect, because when a vibe-coded app arrives bound for production, engineering has three options and none of them are good.
Block it. Engineering becomes the department of no. The sponsor who championed the app learns that the fast path runs around IT, not through it. You've protected production and taught the organization to route future work where you can't see it.
Rebuild it. An app that a business user built in a day takes engineering a quarter to productionize—unplanned work, on a roadmap that was already full. You capture the value eventually, but you've absorbed the cost, and you've confirmed that "IT will just redo it properly" is the operating model.
Wave it through. Now you own code you didn't write, can't fully inspect, and can't prove is correct—holding real data, in production, under your name.
The gates aren't the problem here. Production is simply where your data, customers, and audits live, and the standard for what runs there exists for good reason. The problem is a menu with no good choice on it. And whichever choice gets made, the accountability in production is still yours.
The numbers are already being quantified
If this still reads like a future risk, it's worth noting that independent analysts have started attaching figures to it. Gartner has projected that prompt-to-app development without governance could drive a dramatic increase in software defects—defects that surface as customer-facing errors and failed audits, not tidy compile-time failures. Forrester has described a majority of leaders already facing AI-driven technical debt.
The through-line in that research is that AI-generated code becomes debt fastest precisely where the logic has no governed place to live. Every app that slips past the gates and lands in an ungoverned spot is where those numbers actually materialize. The exposure is live long before anyone notices it.
Banning the tools is not the fix
The instinct, faced with all this, is to write a policy. Restrict the tools. Require approval before anyone touches Lovable or Bolt.
It won't hold, for the same reason every shadow-IT crackdown eventually fails: the demand is real and the tools are too easy. A policy that stands between a business team and software that solves their problem in an afternoon is a policy people learn to work around. You don't get governance from it. You get better-hidden shadow IT.
The more useful way to see this is as a structural gap rather than a behavioral one. The business teams aren't the risk. The architecture is—specifically, the absence of a governed place for their output to land. This is close to the point Xano has made about how the gap between what architects design and what actually gets built is where AI risk accumulates. You can't close that gap by telling people to build less. You close it by giving what they build somewhere safe to run.
Put a governed backend under every vibe-coded frontend
Here's the structural version of the fix. Let the business teams keep building frontends in the AI tools they love. Change what those frontends sit on top of.
Instead of each app spinning up whatever backend the tool improvised—generated files only the model understands, on infrastructure nobody provisioned—every app builds against a governed operational layer that IT controls from day one. The frontend stays fast and disposable. The things that define what the app actually does—its APIs and data models, its business logic and workflows, its integrations to systems of record, its environments and deployment—live in one place that's auditable, testable, and owned.
That's the model Xano is built around, and it changes the answer at the gate. The same responsibilities split cleanly across two roles in a single workflow. Business teams describe apps in plain language and see working software in minutes. The backend those apps run on is enterprise-ready from the first prompt—IT-provisioned tenants with role-based access control, isolated dev, staging, and production environments, and compliance standards like SOC 2, HIPAA, and GDPR built in rather than retrofitted after something's already gone live.
Concretely, the difference between vibe-coding alone and vibe-coding on a governed layer looks like this. Alone, the logic lives in generated files only the AI understands, on whatever infrastructure the tool spun up, reviewable only by someone who can read the code—if anyone can. On a governed layer, the logic lives as centralized, visually auditable function stacks that developers, architects, PMs, and compliance can all read before anything runs. Alone, the path to production is blocked, or rebuilt by engineering. On a governed layer, you promote the same artifact you've been reviewing all along, with prior releases retained for rollback.
The speed the builder experiences is identical. What the enterprise gets to govern is completely different.
What this does to your three bad options
Go back to the menu with no good choice on it. A governed backend doesn't just add a fourth option—it dissolves the original three.
You don't have to block apps to protect production, because they were never running ungoverned in the first place. You don't have to rebuild them, because they were built on the production layer from the start—there's no prototype-to-production rewrite, just promotion of an artifact through environments IT already controls. And you don't have to wave anything through on faith, because review stops being a forensic investigation of generated code and becomes a pass/fail check against logic you can actually see.
For the architect specifically, that's the shift that matters. Apps arrive built on a layer you can reason about. You have visibility into system behavior and integrations from the start, rather than reverse-engineering it after a sponsor has already gone live. Xano frames its enterprise posture around exactly this—auditability, isolation, and deployment control baked in rather than bolted on—which is the posture that lets you say yes to business-built software without inheriting an unbounded liability every time.
The point isn't control for its own sake
It's tempting to read all of this as IT reasserting authority over business units that got too independent. That's the wrong frame, and it's the frame that makes governance feel like a brake.
The organizations that get value out of AI-assisted development won't be the ones that clamped down hardest, and they won't be the ones that let everything through either. They'll be the ones that let the business keep its speed while making sure everything it builds lands somewhere accountable. Innovation and governance stop being opposing forces the moment the governed path is also the fast path—when saying yes to a business team's app doesn't require anyone to choose between velocity and a clean audit.
Your business units are going to keep shipping software. That's not a problem to be solved; it's the new normal to be architected for. The vibe coding you didn't approve is already happening. The question is only whether it lands on infrastructure you govern—or on infrastructure you'll be explaining to an auditor later.
Let the business build. Just make sure it ships on something you can stand behind.
===
Want to see how this works with Xano? Try it for free and connect it to any frontend.
