Four years ago, adding a field to an order took your team an afternoon. Two years ago it took a day. Now, with AI writing a good share of the code, the same change still takes a day (assuming you don't run out of tokens before it finishes), and when you go looking for whoever made it this hard, you can't find anyone.

You can search the history for the one bad commit, but you won't find it, because every change made sense on the day somebody made it. The codebase got harder to change anyway.

It's rare that anyone actually breaks a codebase. Instead, it turns fragile over time, and developers start walking on eggshells, hoping their next change won't break something else in the system. Three kinds of things pile up and make it fragile. You have probably tiptoed around the first two this week. The third is the one your team won't delete.

Second Ways

At some point your team found a better way to do something. Maybe new queries went to Dapper, or you started returning a result object instead of throwing exceptions. That was a good call, but nobody went back to rewrite the old code, so now there are two ways, and each change near both has to work with both. Your AI tool spreads the second way further, because it copies whichever pattern sits closest to the file it's editing.

I've watched this run the other direction. In 2001 I architected an ecommerce system, and we had six months to ramp up 60 enterprise clients. The first client took forever. The third took about half as long, and that's when I saw the next 57 would be the same project with different custom bits. So I built a command that copied the last project and stripped those bits out, and each new client started from one way of doing things. Clients four through sixty, combined, took about as long as client three alone.

Having one way to do things made each new client cheaper than the last. The second pile is harder to spot, because each piece of it works fine on its own.

Tangles

A tangle is two jobs stuck together in the same code, so changing one means retesting the other. Say the code that works out an order's tax and the code that builds the order confirmation email live in one service. They've been fine together for years, but the day finance changes a tax rule, you have to retest the email too. AI makes tangles grow, because it puts new code next to the code it's related to, and that spot is usually inside the tangle.

One tangle adds a little time to each change near it. Twenty of them, and a change that used to take an afternoon takes a day. At least a tangle gets noticed when it breaks something. The third and last pile never breaks anything, and that's why it stays in your code.

Guesses

A guess is code built for a future that never showed up. Early on one project I added support for multiple languages, because surely we'd need it. I maintained that feature for six years, and we never needed it.

A guess still has to compile, it still shows up in searches, and each developer who finds it has to stop and check whether it matters. Nobody is sure it's safe to delete, so it stays. These days a guess costs almost nothing to write, since an AI tool adds the just-in-case code in seconds, but it costs as much to keep as it ever did.

The Eggshell List

All that to simply say this: you can't clean up a pile you can't see. The next time a change takes longer than you expected, write down everything that slowed it down before you close the ticket, one line each.

Today you can ask your AI tool what made the change hard and have it write that list for you. Ask it which parts of the code it just touched have a second way of doing the same job elsewhere in the codebase, which are tangled with other jobs, and which may be a guess at some future need.

After a few weeks, a few items will keep showing up. That is your eggshell list. Create a ticket to fix the first one, and then the next.

If you lead the team, ask for the list on tickets that ran long. It turns complaints about a brittle codebase into specific items your team can start refactoring.

Where This Fits in Intelligent Engineering

Intelligent Engineering is the operating model for engineering organizations in the AI era. It is what comes after vibe coding.

Most of what lands on an eggshell list got there because nothing told the next developer, or the next AI session, which pattern the team had already chosen. In Intelligent Engineering those decisions are written down once, every tool starts from them, and a check catches a second way before it merges. The pile stops growing, and the code stays something your team can trust, support, and scale.

Chad Carter is the creator of DevNitro, the Intelligent Engineering platform. He's spent 29 years building software, served as CTO at multiple companies, and was a Microsoft MVP from 2009-2019.