The migration inventory used to be a list of what you had. Now it is a search for what you do not know you have. For two decades, the tell was a file extension. You found the .mdb on a shared drive, or the Excel workbook with four thousand lines of VBA, and you added it to the modernization backlog. The Access database took a motivated business analyst weeks to build. The replacement takes an afternoon.
Somewhere in your organization right now, a financial analyst is pasting a database schema into a browser window and asking a large language model to build a web app. By Friday, it will have a URL, three colleagues using it daily, and a place in a critical business process.
We spent twenty years trying to corral shadow IT built in spreadsheets and SaaS subscriptions. Procurement reviewed vendor contracts. IT reviewed architecture. The governance model was built for vendors and platforms. It does not cover a Python script a business analyst deployed to a free-tier cloud host on a Tuesday.
The barrier to entry has collapsed. Vibe coding requires a browser, an API key, and a willingness to describe a problem. The feedback loop is immediate. A user encounters a bottleneck, describes it to an LLM, and gets a script. When they get an error, they paste it back until it works. They share the local URL. It becomes a critical business process before anyone decides it matters.
These apps are born production. They skip the lifecycle stage where someone reviews the requirements, provisions the infrastructure, or assigns an owner.
The first time IT hears about the new scheduling app is when the factory floor goes dark. The plant manager built it over a weekend to replace an unusable ERP module. It runs on a laptop under a desk. When the laptop goes to sleep, the schedule stops.
In another building, a finance team’s month-end close depends on a tool that pulls from the ERP API, enriches the data with a model, and emails a formatted report. It works for eight months. Then the ERP API changes. The report stops. IT finds out when the CFO asks why the numbers are missing.
During an Active Directory cleanup, an identity team disables the account of a departed marketing director. The next morning, a regional sales team escalates a total work stoppage. Their automated lead-scoring tool has stopped working. It was a script running on a desktop computer under the departed director’s desk, kept alive by a mouse jiggler, using their personal credentials to scrape an internal API.
The generated code often looks clean. It is syntactically correct and well-commented. This tricks infrastructure teams into thinking the application is maintainable. It is not. The actual business logic and architectural decisions do not live in the code repository. They lived in a transient prompt window that the creator closed three months ago.
The prompt is the business logic. It encodes pricing rules, eligibility criteria, and classification logic. Nobody reviewed it. Nobody versioned it.
AI made the first 80% cheap and the last 20% invisible. Authentication, error handling, audit logging, data retention, and backups are the parts these tools do not generate by default. The builder never sees the gap because the app works. The data store is whatever was easiest—a free database tier, a Notion page, a personal Airtable. The authentication is a shared password or a magic link. The deployment is a personal Vercel or Netlify account.
When the app breaks, the creator submits a high-priority ticket claiming the server is down. They did not write the code. They just supervised its generation. When it breaks, they are as helpless as the support desk.
You cannot put a vibe-coded app in the configuration management database. It does not have a server name, a license, or a contract. It has a bookmark.
Discovery is the hard part. Assessment is easy once you know what you are assessing. You will not find these applications by scanning for code. You find them by monitoring network traffic for anomalous API calls, watching for unusual spikes in service account usage, and auditing departmental credit card expenses for cloud hosting tiers. SSO registrations, OAuth grants, and DNS entries provide partial evidence.
The risk changes when the prototype starts writing back. A tool that reads a CSV to help a team reconcile records is one problem. A tool that updates customer status in the CRM, assigns work in a ticketing system, or sends approval emails is another. The useful dividing line is not whether the app was built with AI. It is what the app can change, and who can recover if it changes the wrong thing.
The instinct is to ban the behavior. You cannot ban a capability. If IT takes six weeks to provision a database, the business will use a free tier. If the security review takes three months, the business will skip it. Bans create shadow processes. Speed creates compliance.
The sanctioned path needs to be faster than the unsanctioned one. If you provide a secure environment for business users to deploy AI-generated scripts with approved hosting, scoped credentials, and logging, they will use it. Give them a safe place to play.
When you find one of these applications, do not turn it off immediately. If it is running, it is solving a business problem IT did not solve. Map the data flows, secure the credentials, and put it in a sandbox. Find the ones that touch money, customer data, or regulated processes first.
Redefine the support contract. Publish clear guidelines on what constitutes a supported application. If an application is submitted for IT support, it must meet basic standards for source control, documented architecture, and standard deployment pipelines. If IT did not build it and it does not live in the approved repository, the service level agreement is zero. IT will restore the underlying data connection. IT will not debug a hallucinated regular expression.
Every vibe-coded app is a signal pointing at a process IT underserved. The scheduling tool exists because the ERP scheduler was unusable. The quote generator exists because the CRM module took six clicks. Treat them as free requirements gathering. The builder is a source of information, not a source of blame. They know what the app does, who uses it, and why it exists.
The handoff is not complete when IT gets the source code. It is complete when someone else can operate the service. The builder solved a real problem. IT did not. The application will eventually end up in the migration inventory, but the inventory will not explain why the business had to build it.