Blog / Architecture and integration

Why your integration backlog leads to ungoverned vibe-coded apps

An integration request can sit in a queue for months. The team waiting on it doesn't wait with it — they build it themselves, and it comes back to IT as something nobody reviewed.

Adam White avatar

Adam White

Editor-in-Chief

An integration request for a new AI project can sit in a queue for months. The team waiting on it does not wait with it.

They open an AI assistant, point it at the systems they already have credentials for, and build the connection themselves. It works. Then it needs somewhere to run, and it comes back to IT as something nobody reviewed, wired into systems IT still answers for.

Everybody keeps coming to engineering asking us to run their stuff.
— Platform engineering lead, cybersecurity company
Figure 1 · How an integration backlog produces ungoverned applications
How an integration backlog produces ungoverned applications Five steps in causal sequence: AI needs data; middleware predates AI; teams build their own; they want it deployed; risk compounds. Step three is highlighted as the hinge. 1 AI needs data 2 Middleware predates AI 3 Teams build their own 4 They want it deployed 5 Risk compounds

IT owns the AI data mandate, whether it asked for it or not

Every AI initiative runs on data, and the systems holding it already sit inside IT’s mandate. Customer records, product data, ticket history, financial systems. The models need all of it, and IT answers for how it moves.

Whoever signs the integration renewal is usually the same person who answers for the AI roadmap, and nobody else in the building owns both. That makes IT the gate for AI, whichever team owns the roadmap on paper.

The middleware holding that data was chosen before AI existed

Most integration platforms running in production today were built to connect a fixed set of systems for people who could wait weeks for a new one. AI does not wait.

36%1

of software engineering leaders name strengthening integration their single most important action for the next twelve months, ahead of every other priority.

The teams building AI initiatives feel that delay before anyone else does.

So teams build their own

People solve it themselves because the official path takes months and the unofficial one takes an afternoon. Someone in marketing operations or revenue operations opens an AI assistant, points it at the systems they can already reach, and builds the connection nobody had queue capacity to build for them.

Figure 2 · Two routes to the same connection, over the same period
Two routes to the same connection, over the same period Two horizontal timelines sharing one axis from day one to months later. The official route spends most of the period in the queue, then a short build, then deploys. The AI assistant route builds in a sliver at the start, then runs ungoverned for the rest of the period, and lands back on IT at the point where the official route deploys. Official route Queue Build Deploy AI assistant Build Running, ungoverned Back to IT Day one Months later

Vibe-coding inside a company follows the queue. Where the sanctioned route to data is slower than the unsanctioned one, people take the fast one. The time saved at the start is not saved. It is spent running without an owner, an identity, or a log, until the thing lands on IT anyway.

Then they want it deployed

The build works well enough that people keep using it. One person built it, one person can run it, and it runs on that person’s machine. When the laptop is closed or its owner is on leave, the process stops, and the first IT hears of it is the ticket asking why.

Then it needs to run somewhere real. On a schedule, for a team, past the point where a laptop staying on counts as infrastructure.

That is when it arrives back at IT, and it is no longer a request for a connection. It is a request to host, secure, and support something IT never reviewed, wired into systems IT still answers for. Engineering becomes the hosting team for work it did not commission and cannot vouch for.

Every unofficial build is exposure you cannot see

Multiply that across every team solving its own integration problem the same way, and IT ends up governing an inventory it cannot fully name.

60%2

of IT and information security leaders report evidence of, or suspicion of, unsanctioned AI agent automation already running inside their organization.

None of it appears as a line item. It appears as credentials nobody scoped, actions nobody logged, and apps with no named owner, sitting inside systems that still carry your name on the audit.

What changes when the queue stops being the constraint

Yext moved more than 100 services off its previous integration platform in three months, at more than 60% lower cost.3 Airbnb turned an eight-week integration project into a week’s work, and scaled to more than 40 automations across the org at 90%+ faster delivery.3

None of those numbers describe AI work. They describe the queue getting shorter, which is the one point in the sequence where it can be stopped from repeating.

Shortening the queue does not retire what your teams already built. Those apps still need governing. But a governed path to production that nobody uses, because the official route is still slower, refills with the same problem inside two quarters. The route that works has to deploy, run, and govern what teams build, and it has to be faster than building around it. The queue and the governance are one job.

Where to start

Two questions decide what you're dealing with: what controls hold today on the apps, agents, and integrations your teams have already built, and does the request queue that produced them still run slower than building around it? The governance checklist covers both, and returns your gaps in the order worth closing them.

Take the checklist →
Sources +

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

  • Gartner, How to Choose the Best-Fit Integration Platform as a Service Vendor, G00847070, Pasricha, Guttridge, Humphreys, April 6, 2026.
  • Gartner, Best Practices to Counter MCP Security Risks, G00844301, Lord, Guttridge, Coqueiro, February 5, 2026.
  • Customer-reported outcomes for Yext and Airbnb, published on tray.ai. Each comparison is scoped to the platform that customer migrated from.