Why policy cannot govern vibe-coded apps

Most IT leaders never got to decide whether people in their company would build software with AI. The answer arrived without them.

What’s still open is what sits underneath those people once they’ve built something. That has a policy answer and an architecture answer, and most organizations reach for policy first. It keeps failing. Here’s why, and what I’d build instead.

Building left engineering

The numbers on adoption stopped being interesting a while ago. In Stack Overflow’s 2025 developer survey, 84% of respondents said they use or plan to use AI coding tools, and 51% of professional developers use them every day.¹ Satya Nadella told investors in July 2025 that around 90% of the Fortune 100 use GitHub Copilot.²

For IT, the telling number came from OpenAI in June 2026: one in five Codex users works outside development, as an analyst, marketer or operator.³

Building software used to happen inside a team with a deploy pipeline, an on-call rota and a security review. Now it happens in finance, in RevOps, in support, wherever someone has a problem and an assistant open.

That makes it a problem for whoever owns what runs in production, because that’s where these apps end up, or try to.

Four things the builder cannot supply

Take the app your analyst built last week. It works on their laptop. To be useful to anyone else it needs four things.

• Infrastructure. Hosting, a database, a domain, someone on call.
• Credentials. Real, granted access to real systems: the CRM, the warehouse, the ticketing tool.
• Identity. SSO in front of it, roles behind it, a way to scope who gets in.
• An owner. A named person who answers for it at 3am.

The person who built the app can supply none of these. The reason is structural: every one of the four belongs to IT. The analyst can’t grant themselves production access to Salesforce or put the company’s identity provider in front of their app, and they aren’t the one accountable for running it overnight. Everyone who’s run production knows who is.

That’s also why so much of what gets built stays on the laptop. I haven’t seen a measure of how much dies there that’s worth quoting, so I won’t put a number on it. The mechanism is plain enough without one: the app needs four things and the builder has no way to get them.

Building outran running and governing

Picture three curves over the last two years.

The first is the ability to build. When AI coding assistants arrived, it went close to vertical. Claude Code, Codex and Cursor made an internal app almost free to produce, and the number of people who can produce one went from a few thousand engineers to anyone with a laptop.

The second is the ability to run those apps in production. It rose, but slowly. Hosting, SSO, credentials and uptime still land on someone, and that someone is usually one platform team with the same headcount it had before.

The third is the ability to govern them, and it barely moved. Reviews, inventories and approval meetings scale with the number of people doing them, and that number stayed flat while the apps multiplied.

Everything in the gap between the first curve and the other two got built anyway, and none of it has a team running or governing it. Your governance can have improved a lot over those two years and still miss the test that counts: did it move as fast as building did?

Blocking drives it underground

The natural instinct is to flatten the first curve: restrict the assistants and block the tools until governance catches up.

Gartner, in research on local AI agents published in July 2026, says blocking them fails. Adoption carries on out of sight, and you lose the visibility you’d need to manage the risk. Their comparison is with open-source Linux, where enterprises eventually moved from blocking it to governing it.⁴ Most people reading this lived through one version of that already, and blocking lost that one too.

You can already measure what lost visibility costs. In a January 2026 Cloud Security Alliance survey of 418 IT and security professionals, 82% had found at least one AI agent built without security, IT or governance knowing about it, while 68% of the same group rated their visibility into agents as strong.⁵ The gap between those two numbers is the gap between what organizations believe and what they find.

There’s a fair objection here, and it deserves a straight answer. Gartner has also said, in separate research, that vibe-coded software should be kept out of customer-facing production and confined to sandboxes.⁶ That caution is reasonable, and this argument agrees with it.

For anything that needs to go further than a sandbox, Gartner’s answer is a governed platform with a promotion pipeline, so what moves into production moves through a controlled path.⁷ Their caution and the architecture argument point the same way: toward a governed path to production.

A policy answer cannot solve an architecture problem

Most organizations have built some version of the policy answer, which is a reasonable thing to have. Here’s how it works next to the alternative.

Read down the left column and every item on it shares one property: each control is opt-in for the person you’re trying to control. The approved-tools list works if the builder checks it. The review board works if the builder submits to it. The policy works if the builder remembers signing it. Discovery works after the app has already shipped.

In the right column, the controls attach because the app runs on the platform. Identity is in front of the app because the platform put it there. The credential is out of the code because the platform holds it. You can see every app because every app executes on infrastructure you operate. You get visibility by construction, so it holds up regardless of anyone’s good intentions.

If you’re thinking “we need both”, you’re right. Policy decides the tiers: what’s allowed, what needs review, what’s off-limits. Architecture enforces them. A policy with no architecture under it is a request.

The gate and the road

Gartner’s guidance on scaling vibe coding makes the mechanism specific: make the safe path the easy one, with approved templates, reusable components, secure integration patterns and deployment guardrails, and stop relying on users to interpret enterprise standards themselves.⁸ That last clause describes the whole failure of the policy answer.

Picture two lanes. In the first, a builder who wants their app live today meets a review board that meets every two weeks, if it meets. The app ships anyway, on a personal cloud account, off the record. All the gate decided was whether you have a record of it.

In the second lane, the same builder meets one governed path that’s faster than going around it. The app reaches production with identity, an audit trail and an owner attached, because the path attached them. That middle step is the whole design, and it only works if it really is faster.

Builders will always take the fastest route to a working app. Friction in the sanctioned path moves the app somewhere you can’t see.

Where Tray Helix fits

You can build the architecture answer yourself, and some teams should: if you already run an internal developer platform with engineers to look after it, much of it is a matter of extending what you have. Tray Helix is our implementation of it. Builders keep the AI assistant they already use, and one command deploys the app to a managed runtime with SSO, managed credentials, an audit trail and a named owner attached on the way to a live URL.