Vibe coding and the AI sprawl problem

A year ago, most people in your business had probably never heard of GitHub. Today, an increasing number will have personal accounts, and some will have published websites or apps on the odd domains that come with app building tools like Vercel, Replit and Loveable. Much of this is good news: people are experimenting, learning what’s possible, solving their own problems and prototyping faster. The downside is that control is disappearing fast. If shadow IT was a problem, and shadow AI extended it, the current vibe coding wild west multiplies the risk exponentially. Code, dependencies, vulnerabilities, secrets, domains, token costs and access permissions are spreading across immature tools run by companies that may not exist in eighteen months.

Coding is no longer just an engineering activity. It is now mainstream knowledge work, which means every knowledge-work company now needs the IT stack of a tech product company.

Vibe coding goes mainstream

The response to ChatGPT and Claude was to move to corporate accounts with SSO and centralised policy control. The response here is the same: encourage experimentation without losing control of spend, hosting, secrets or sensitive data handling.

Because code is portable across tools, there are four main areas to focus on:

• Training and/or champions.

• Code storage and version control.

• Development tooling.

• Getting from dev tool concept to production.

With great power comes great responsibility

Coding unlocks the full power of computers in a way everyday software use does not. That power needs guard rails, both to limit what can go wrong and to control who gets access to these tools.

In time, Git and the software development lifecycle will be as mainstream as Excel or email. But getting there will require significant upskilling, and as with any adoption curve, some people will move earlier than others. You should harness those people, or hire if you do not have them.

Any training you provide should focus on the software development lifecycle, Git, secret management and similar basics. You also need clear policies on what data and systems staff can use, and when work must be handed over to a more experienced IT user with privileged access.

Where does the code actually live?

If code lives in personal GitHub, Replit, Vercel or Loveable accounts, you do not own it and you have key-person risk. The pragmatic move is to centralise on one corporate Git platform such as GitHub, with identities tied to your corporate directory (Microsoft 365 or Google Workspace).

Within that platform, code lives in repositories that track changes over time. There are many configuration choices to balance security and productivity, but the key principle is least privilege: people should see only what they need, so the blast radius of a compromised account stays limited.

How do you stop “AI sprawl” across hosting platforms?

Everyone building an app or tool wants to get it live on a custom domain quickly. Most AI coding tools make that easy by bundling hosting and often the domain too. That removes the last bit of friction, but it also leaves you with too many hosting providers, too many billing relationships, and domains registered in personal names on platforms that may pivot or fold next year.

The answer is to choose one or two app-building tools, such as Replit, Vercel or Loveable, and bring them under full IT control, ideally with SSO. Give access only to people you want building things and set spend limits on token use. If you already have Claude, Claude Design is an option, though in my view it still lags the dedicated app platforms.

This means staff projects are built in an IT-controlled environment, and deployment can be handed off smoothly to more experienced IT staff.

From a cool demo to a production site or tool

Pragmatically, you will want to consolidate hosting on infrastructure you already trust and pay for. For Microsoft 365 businesses, that probably means Azure. For Google Workspace businesses, probably AWS or Google Cloud Platform. These are the same providers the app-building tools use; you are just cutting out their margin and keeping control.

You are not trying to make everyone a software engineer. You are making sure that when someone builds some useful IP, it stays within the company control environment and can be maintained. In practice, IT or more technically privileged staff should control four areas:

• Set up secrets and access tokens so least privilege is maintained.

• Set up projects in your chosen app-building tool as clones of the right corporate GitHub repo, so code is mastered in the right place.

• Control pull request approvals and deployment pipelines to production.

• Control any required DNS changes.

Subscription separation and the unit economics question

This is as much about commercial discipline as cybersecurity. If three products and four internal initiatives all run in one Azure subscription, unit economics and profitability are hard to track, and a leaked credential creates a single blast radius.

Azure subscriptions are effectively free logical containers with their own permissions and billing, that can be subdivided into resource groups with separate access controls and cost analytics, so it is worth separating workloads for clearer commercial visibility and stronger security. For example:

• One Azure subscription per product or tool production environment, with resource group separation of underlying services to help separate access and facilitate cost analysis. For example, separating out compute services and data storage. Only a couple of admin accounts should have access to this.

• One testing subscription per major department or workload, such as marketing tooling or internal ops. Again, resource groups can be used to separate projects and manage access control.

This sounds heavy, but it isn’t. Azure subscriptions are free to create, and Management Groups let you apply policy centrally including hard budgets. The payoff is cleaner billing, tighter permissions and the ability to shut down one workload without affecting the rest.

AWS does the same with Accounts under Organisations, and GCP with Projects under Folders. The principle is the same: separate logically early to avoid messy untangling later.

The role of IT is expanding, whether you’ve noticed or not

For most companies, IT has historically meant identities, devices, apps and access: Microsoft 365 admin, Intune policies, helpdesk tickets and password resets.

That scope is widening fast. It now includes functions once associated with product companies:

• Git platform governance.

• AI app tool governance.

• Cloud subscription governance (Azure / AWS / GCP).

• Secrets and developer token management.

• Deployment pipeline oversight.

• DNS and domain inventory.

This doesn’t mean hiring a platform engineering team. For a 30-person business, it might be half a day a week from someone competent, internal or external. But someone must own it, or sprawl wins. The role is no longer optional; it is just often unassigned.

Bottom line

You do not need to lock everything down. These tools enable speed capabilities that are rapidly becoming table stakes, but speed without governance becomes sprawl within months, and fixing it later is always costlier than steering it now.

Five questions you may wish to ponder:

1. Who in the business is making tools with code?

2. Has the tool they made become part of a business process?

3. If they left tomorrow, would we still have access?

4. Where is the code, the hosting and who controls the admin access and billing?

5. Who owns this internally?

If the answer to 5 is “nobody yet”, fix that first.

If you’re trying to make sure your team are well setup to take advantage of the benefits of AI, we can help. Reach out below.👇