Let me say this up front: I’m a big fan of AI. I use it every day, for writing, for analysis, and for building real systems. It has changed how I work, and I’d encourage every business to use it more.
But I’ve become increasingly worried about one thing. Well-meaning people across the business, who aren’t developers, are now building systems with AI. They’re bright, they’re motivated, and the tools make it look easy. What they don’t yet know is what they don’t know.
A few months ago I wrote about building a system in five days, and the five more it took to make it safe to launch. That was about getting to day one. This one is about day two hundred.
Here’s the part almost nobody talks about. AI doesn’t just write code into your system. It reads from it.
Every time you ask an AI tool to add a feature or fix a bug, it looks at what’s already there and follows the patterns it finds. If the code is clean and consistent, it copies that. If it’s a mess, it copies that too.
So the quality of your code today decides the quality of what your AI produces tomorrow.
How the decline happens
Week one. The system is clean. There’s one way of doing each job. The AI follows it, and the results are impressive.
Month two. The person building it is bright and well-meaning, but not a developer. When they ask for a new feature, the AI does the same job a second way rather than reusing the first. They don’t spot it, because they don’t know to look for it, and they don’t know to ask the AI to check. Nothing’s broken. But the AI now sees two patterns, and next time it has to guess which one is right.
Month six. There are three versions of “calculate the franchise fee”. Old instructions contradict new ones. Code nobody uses anymore is still sitting there. The AI picks the wrong version. It fixes a bug in one copy but not the other two. Results get slower and stranger.
Think of a busy kitchen where nobody puts anything back. The first cook is fine. By the tenth, nobody can find anything, there are three knives being used for the same job, and the food is getting worse. The cooks haven’t changed. The kitchen has.
What the evidence says
This isn’t a theory. It’s showing up in the data.
Research from GitClear and GitKraken analysed 623 million real-world code changes from 2023 to 2026, and found code duplication up 81% compared with pre-AI times. The same job, being done in more and more places.
At the same time, the tidying up has stopped. Changes that update or remove code last touched more than a year ago have fallen 74% since 2023. The mess is building up, not being cleared.
And the AI is hiding problems rather than surfacing them. AI tends to write code that never throws an error, whatever it is given, and this kind of error masking is up 47%.
Across a broader study of more than 500,000 code samples, AI-generated code was found to carry 1.7 times more issues than human-written code, with logic errors 1.75 times more frequent.
Why nobody notices
This is the dangerous part. The decline is almost invisible.
- The system still works. Customers see no difference, and each change is only slightly worse than the last. No single day looks like a problem.
- Nobody knows what to look for. An experienced developer would spot the warning signs early. A well-meaning amateur doesn’t know they exist, so they can’t ask the AI to check for them either.
- The AI smooths it over. It’s built to give you something that looks finished. It doesn’t put its hand up and say “this is getting messy”.
- People blame the wrong thing. “The AI’s having a bad day.” “That feature’s just tricky.” Never “our foundations are rotting”.
By the time you do notice, every change takes three times as long, every fix breaks something else, nobody fully understands how it works, and the AI that built it can no longer reliably fix it.
It’s a slow leak behind a wall. You only find it when the ceiling comes down.
Why it matters most for critical systems
For a throwaway tool, none of this matters much. Bin it and start again.
But a critical system, the one that takes payments, manages your franchisees or holds customer data, can’t just be binned. You’re stuck with it. And unpicking six months of quiet decay costs far more than doing it properly in the first place.
What to build, and what not to
None of this means people shouldn’t build with AI. They absolutely should. The trick is knowing which side of the line you’re on.
Go for it:
- Prototypes. Show what an idea could look like before anyone spends real money. This is where AI is a gift.
- Personal tools. A tracker, a calculator, something that saves you an hour a week and only you use.
- Small team tools. Something a handful of colleagues use, with no customer data, where it breaking is an inconvenience rather than a crisis.
- Analysis and one-offs. Crunching a spreadsheet, drafting a report, testing an assumption.
Get help first:
- Anything customers or franchisees rely on. If it going down means phone calls, it’s critical.
- Anything touching money or personal data. Payments, bank details, customer records, staff records.
- Anything that connects to your core systems. One bad connection can corrupt data everywhere.
- Anything you expect to keep and grow. This is where the quiet decay does its damage.
A simple test: if this stopped working tomorrow, or got something wrong without anyone noticing, how bad would that be? If the answer is “mildly annoying”, build away. If it’s anything worse, bring in someone who’s done it before.
And the best route is often both: let the enthusiast build the prototype and prove the idea, then have someone experienced turn it into the real thing.
Your codebase is now part of your AI. Look after it, and the AI gets better over time. Neglect it, and the AI gets worse, along with everything it touches.
And the tools won’t tell you when that happens. They’ll just quietly keep going.
Colin Rees is the founder of Xpera, where we help business leaders make smarter technology decisions. If you’re building with AI, or wondering whether what you’ve already built will still hold up in a year, we’d welcome a conversation.