Every enterprise takes the same vibe coding journey. Here's how you get to the golden path to production faster.

Most enterprises are running the same sequence right now, in the same order, about a quarter apart from each other.

It starts with a mandate. The board asks for an AI strategy, the CEO commits to one, and coding agents go out to the whole company instead of just the engineering org. Finance, ops, support, and revenue teams all get access in the same week. Within a month, people who have never shipped software are building things that work.

This is the exuberance phase. An analyst who spent a long time trying to build the same report can now do the app in hours. A customer support lead who wants to track responses can do it within a few days versus two days. But then the prototypes try to become real, and everything stops at once.

The six things every prototype is missing

The apps built in the exuberance phase are missing the same six things, everytime.

No database. Someone built against a spreadsheet or a personal access token, and there is nowhere for the data to live.

No authentication or authorization. Access is either everyone or nobody, and it does not inherit from your identity provider.

No audit trail. You cannot answer who did what, when, and against which system.

No code security. A coding agent pulls in whatever packages it wants, and nobody reviews the output.

No cost control. Nobody knows what inference is being spent, or by whom.

No deployment path. The app either sits on a laptop or ends up hosted somewhere outside your network.

Any one of these stops an app from reaching production. Most companies discover all six in the same week.

Why the CISO ends up owning this

The instinct is to treat this as an infrastructure queue. Business teams built things, IT is behind, hire faster or buy a hosting layer.

That reading misses what has changed underneath. Code generated by an agent is insecure until proven otherwise, and the volume being generated is far past what any review process built for human commits can absorb. At the same time, the frontier models now shipping have real offensive capability, supply chain attacks against public package registries are routine, and prompt injection is a live technique against systems that read untrusted input. A business user building an app has no idea any of that exists.

The threat side moved at the same time. This is what happened in the last five months.

A business user building an app has no idea any of that exists. They are not going to check what a package does at import time, and they should not have to

So the surface area expands, and visibility contracts. You cannot secure what you cannot see, and by this stage a lot has been built that nobody has an inventory of. That is the wake-up call, and it is why the CISO and the CIO end up owning this problem rather than the platform team.

What security and IT leaders tell us

We have this conversation with security and IT leaders several times a week. Three responses come up almost every time.

The first is that they do not want to shut it down. Not one has told us the mandate was a mistake. They want the building to continue and they want a channel it has to run through.

The second is an analogy to the last time this happened. More than one CIO has compared it directly to the spread of desktop databases in the nineties. People built something useful, it quietly became load-bearing, the person who built it left the company, and years later nobody could touch it or turn it off. The concern is not the app that gets built. It is the app that becomes critical without anyone deciding it should be.

The third is that their engineers cannot be the gate. Six months ago the most requested capability we heard was source control integration, so every change could route through an existing review process. Now the same customers tell us the volume makes that impossible, and they want agents doing the review with policy checks they define centrally.

What a governed path actually requires

Getting from prototype to production in a serious company is not a hosting problem. Treating it as one is why most internal efforts stall six months in.

We split the whole list into five themes: who can access what, whether the code is safe, whether the app stays up, what it costs to run, and what you can see afterwards.

The themes of a golden path to production

None of these are things the person building the app can supply. A finance analyst is not going to configure SSO, run a package firewall, or provision a database, and asking them to is how you end up with none of it. Every theme here has to be owned centrally or it does not exist at all.

The important part is that IT configures this once. After that, business teams move through it without filing a ticket and without a human in the loop on every publish. You are not approving apps. You are defining the path, and the path does the approving.

What changes at hundreds of apps

Companies that build this path do not end up with a handful of governed apps. They end up with hundreds, and the ones furthest along are heading toward thousands.

That is the actual design constraint, and it is why the governance layer matters more than the building experience. At that volume you need a system of record for software. Which apps exist, who owns each one, what data each touches, which packages are running inside them, when each last ran, and which ones you can shut off tomorrow. Build the path without that and you have industrialized the sprawl instead of ending it.

So where are you on this curve? If you are somewhere between the exuberance and the wall, book a consultation with me and my team. Those conversations with CIOs and CISOs at large and fast-growing companies are most of our week, and we will tell you what we are seeing at your stage and what usually comes next.