Last week I was listening to a podcast where the guest described how he built an app for his team. No IT, just Claude Code and a few evenings. The team loved it and started using it. Then the author went on vacation. The app crashed, and nobody at the company could fix it because nobody knew how it worked. He told it as a funny anecdote, but I heard something else. I know this story. I just usually hear that about systems that are twenty years old.
Someone at your company has probably built something similar in the past year. Sales has its own quote tracker, finance has a report that replaces “the one from the ERP”, and so on. It’s called citizen development, and in 2026 every company has it.
The question is how many of these apps you have, and who’s responsible for them. Try answering that right now. Don’t know? Then you’re in the same boat as most companies.
Speed isn’t the problem. Speed is fine.
At Coding Bear, we make our living rewriting legacy systems, and we know one thing: legacy isn’t old code. Legacy is code whose authors, the people who understood why, are no longer around.
Code is just a frozen record of decisions someone once made, and when that someone leaves, what remains is an artifact without meaning.
Now look at the app from the podcast, or at yours. Who understands why it works the way it does? Not what it does, but why. The AI doesn’t know; it wrote the how. The author understands what he wanted, not what he got. That’s the exact definition of legacy. It just didn’t take twenty years to form, only a weekend.
And it can be measured. GitClear analyzed 623 million code changes from 2023 to 2026: duplication rose by 81%, refactoring dropped by 70%. When we open up an old system for a rewrite, we see the same thing.
Nothing. For a month, maybe a year, everything will work and people will be happy.
But then one of the following will happen:
The author leaves or changes roles. By now, twenty people use the app, nobody knows how to maintain it, and IT refuses to take it over because “nobody actually wrote it”. You have a critical process with no owner. This is the most common scenario, and it comes first.
A data leak. The app contains a database with personal data, and nobody set up access controls. Your Data Protection Officer (DPO) doesn’t know the database exists, because nobody created it officially.
The supply chain. When generating code, AI makes up library names or picks them based on its training data. Attackers compromise those libraries, or register the fake names and wait for someone to download the packages. The tool installs them on its own, so nobody knows what made its way into the company. And what if you don’t even know the app exists?
IT itself. Open source has already been through this. In January, curl (a library found in practically every internet-connected device) shut down its bug bounty program after six years, because AI-generated reports overwhelmed the people who were supposed to review them. Generating code is free; understanding it costs as much as it always did. That’s exactly the ratio your IT will face once citizen developers start bringing them apps to take over.
The bottom line: two years from now, you’ll have twenty small legacy systems running real processes, and an IT department that neither wants them nor knows how to take them over.
The first step is actually a simple list, one you can put together yourself. Every app someone has built goes on it, along with the name of the person responsible for it and a few other details.
How many headaches would something this simple save you? Don’t count licenses. Count the one rewrite that never has to happen.
Everything you need fits on a single page.
Don’t ban using AI. People will build things anyway; they just won’t tell you. Give them a path that’s easier than working around you, and keep track of what’s out there.