The Vibe Coding Curve

Why every enterprise AI rollout follows the same five stages. Here's what you can do about it.

If you run IT, security, or AI at a large company, you have sat in this meeting. A CIO or VP of Engineering opens with "the board wants us to be AI-first by next year." Someone in the room, often not from engineering, has already been building on Replit, Lovable, Bolt, or v0. They ask the obvious question: why can't we just let people build things?

I lead solutions engineering at Superblocks. Over the last few months my team and I have sat with dozens of the fastest-growing companies, many of them in their offices, most a few hundred to a few thousand people, as they roll out AI. We have worked with IT to centralize governance, access, and data controls, then helped completely non-technical teams like legal and finance ship hundreds of applications safely and securely. This article is the pattern we see over and over. Wherever you are on your vibe coding journey, read through to find out what comes next.

Stage 1: The AI mandate comes down from the top

AI mandates rarely start in IT. They come from the board or the CEO, driven by competitive pressure. They land as a directive, not a plan. One IT security manager put it this way: "CEOs are just dropping and going, we're getting this new thing, everyone needs to use it, and we want you to start yesterday."

The people carrying the mandate think about speed, not deployment. They have seen a consumer tool build something in an afternoon. They assume the rest of the company can move that fast too. What no one asks at this stage is what happens after the demo:

• Where does the app get hosted?
• Who owns its data connections?
• What happens when it needs a login system?
• Who owns it in six months, after the builder changes teams?

That is not a knock on the people driving the mandate. It was not the problem they were handed.

Stage 2: Business teams start building their own apps

The mandate lands and building starts. Finance builds a reporting dashboard. Ops builds a tracker. Someone in HR wires up a tool that touches the HRIS. Each one looks like a win. Non-engineers ship working software fast, without waiting on the backlog. This is the most exciting part of the rollout for the people living it.

The problem is that none of it is visible above the team level. It runs on laptops, in personal accounts, against whatever data the builder could connect to. There is no inventory. No one reviews how each app handles credentials. No shared definition of "production-ready." From the top, this looks like adoption. From a security seat, it looks like an unmanaged fleet of unknown size. One IT lead said it plainly: "It's like, what do you mean, we have a thousand apps in this org?"

Stage 3: The apps can't get to production

Then one app needs to do something a prototype was never built for. Get shared with a wider team. Connect to a system of record. Handle data that matters. This is the production wall. It stops almost every vibe-coded app at the same point.

The tools that made prototyping easy have no real answer for authentication, access control, or a secure path into core systems. The builder gets stuck. A VP of Business Transformation described the problem: "We are on a hunt to find somewhere we can host some of these apps so that they don't just die in GitHub."

The wall is also a security problem. The numbers are blunt. Veracode's 2025 analysis found that nearly half of AI-generated code, 45 percent, failed security testing. Its early-2026 follow-up found no improvement. That is fine for a sandbox and dangerous for anything touching customer or financial data. And the failures are usually simple ones:

One access-control flaw in Lovable exposed more than 170 published apps, including names, emails, and API keys (CVE-2025-48757).

Stage 4: IT either locks it down or lets it sprawl

At the wall, companies split two ways. Both are wrong.

They under-govern. They rolled out a broad mandate before building any way to govern it. They find out after the fact. Security discovers a backlog of apps touching production data. IT gets flooded with "make this real" requests. There is no audit trail. A VP of Information Security described the moment it got real: "Two months ago someone says, we just want to use Lovable, it's for a demo, there's no data in it. Two months later, there's customer data in what they showed us. How would I even know?"

They over-govern. They saw the risk and locked AI down to engineering only. This kills the mandate. The board asked for velocity. It got a compliance problem to contain. Business teams go back to filing tickets and waiting in the queue, the exact bottleneck the mandate was meant to remove. As one VP of Information Security put it: "Everyone under the sun wanting to be a coder. We're drowning."

Both paths share one root cause. No one could tell productivity from risk, because no one could see what got built, by whom, on what data, with what safeguards. So leadership either clamps down or looks away. There is no middle option without a governance layer.

Stage 5: Put a governance layer underneath the building

The way out is not a better prototyping tool. It is not a ban. It is a layer that sits between "someone had an idea" and "an app is in production." IT sets policy, access, and integration standards once. Every app built on top inherits them, no matter who built it.

Here is what that layer does:

• Blocks vulnerable code at publish. When a builder hits publish, security agents scan the app for logic flaws, authorization bypasses, and vulnerable packages, then fix them before it ships. No one has to remember to run a scan.
• Ships clean, exportable code. Real production software, not a black box. Engineering is not signing up to rebuild it later.
• Keeps data in your own cloud. The app deploys in your own environment and inherits your network, identity, encryption, and audit controls. Users come in through your SSO. When the answer to "where does the data live" is "in our account," the residency review and the audit get short. For AWS shops, that means deploying in your own AWS account, running inference through Bedrock, and connecting to services like Redshift, S3, and DynamoDB, so nothing leaves your account.
• Makes every app queryable. Every app, builder, integration, and data touch becomes one system of record. A CISO can answer "what got built, on what data, by whom" in one query, instead of finding out during an incident.

That last point solves a problem every IT leader knows. As one described it: "It would become a very production-important tool, but it sat on somebody's desktop. And when it broke, the person who built it left the company three years ago." That was Microsoft Access. It is back at AI speed, with hundreds of builders instead of a few. A system of record is how you keep the knowledge when the builder leaves.

This is the model Superblocks is built for. It gives CISOs and CIOs a third option. Today they have two: block vibe coding, or open the floodgates. The third is to let everyone build, with the security and governance an enterprise needs.

The proof is not theoretical:

• Flex went all-in on AI for its 500 employees, then hit the wall when a business user built an app holding company IP on a personal Replit account. It moved to Superblocks in its own AWS account and built 150+ apps in the first 30 days, with 16 of 18 departments building.
• Matthews Real Estate turned down an $850,000 vendor quote and built the app itself. More than 800 agents use it every day.
• NHS Royal Surrey had a designer with no engineering background build the app replacing Workday HR. It is deploying to more than 100,000 users, SOC 2 and GDPR compliant.
• Virgin Voyages has teams across multiple functions building apps its executives defer to, including one a fleet captain uses to optimize $200 million in annual fuel spend.

The pattern is the same each time. Business teams build. IT governs the system once. Apps reach production without a rewrite.

The takeaway

None of these five stages means a company did AI wrong. They are the default path for any organization that mandates AI without building the layer underneath it. The companies that get ahead of stage three decide one thing in advance, instead of during a crisis: who can build what, on what data, with what oversight.

That is a far easier conversation to have before an app touching customer data shows up in a security review. If you are somewhere between stage two and stage four right now, it is the conversation worth having this quarter.