The code nobody wants to touch

For twenty years, walking into the room nobody else will enter has been my bread and butter. Aviation, banking, automotive: Fortune 500 enterprises where technical debt had quietly frozen an entire roadmap, and smaller companies built on one old system that everybody relies on and nobody dares touch. The scale differs every time. The shape never does. The software still runs the business, and the business can no longer move.

The debt was never the barrier

We call it technical debt, a metaphor borrowed from a balance sheet, and the metaphor misleads. Debt suggests a quantity: too much owed, so pay it down. What stops a team is not a quantity. It is fear.

The fear is rational. There are no tests, so you cannot know what you broke. There are no seams, so you cannot change one thing without touching six. So the estimate inflates, the ticket slips, and the debt compounds because nobody dares touch it.

It does not show up on an engineering dashboard. It shows up in your roadmap. Features get ruled out for years because they touch the wrong module, and nobody writes it down. Your own system stops being an asset and becomes a moat around your product, with you on the wrong side.

The order is the craft

Every rescue I have run follows the same order, and I have never negotiated on it.

Lock the behavior before you change it, with tests that describe what the system does today rather than what you wish it did. Prove those tests have teeth. Fix security and correctness before anything cosmetic. Remove duplication and break apart the classes that quietly became gods. Then reshape what is left around the business.

Get that order wrong and you are not refactoring. You are rewriting with extra steps and no safety net.

Coverage is not teeth

There is one moment where a rescue is won or lost.

I keep a deliberately ugly demo application as a rehearsal harness and run the full governed rescue against it, live, on client calls. There, the phase that locks down existing behavior finished at 62.8 percent coverage. On plenty of dashboards that is a green number. It has never been a green number on mine.

Then we ran mutation testing against the same tests, which plants small bugs in the code and counts how many the tests notice.

The score was 18.3 percent.

Two thirds of the code covered, and the tests caught almost nothing. Had we started refactoring there, we would have been working without a net while looking at a number most teams would have called good enough. That is worse than working without a net and knowing it.

Coverage tells you what ran. Mutation tells you what would have been caught. Only one makes it safe to change something, and only one cannot be flattered.

Then I taught the whole thing to a machine

For most of my career this was craft, carried in my head and handed over one engineer at a time, by pairing. It does not scale, and when I rolled off an engagement most of it left with me.

So I wrote it down as a governed workflow, phase by phase, with the order enforced rather than advised. The agent does not advance by reporting that it is done. It advances by producing evidence a tool can confirm, and where judgment is required, a human approves first.

Then I watched it run.

In that same rehearsal, the certification gate goes from failing to passing once, at decomposition, and holds from there. Coverage finishes above 95 percent. The mutation score, the number that actually matters, finishes at 98.8. Those two numbers move independently. Coverage rose because we wrote characterization tests. Mutation rose only because we then killed the survivors. No gate was skipped. Every gate is enforced at runtime, a blocked gate halts the work, and there is no path that quietly proceeds past a failed check.

The first time I watched this at real scale, on a backend system inside a Fortune 500, a rescue that would normally have been a multi-quarter program finished in a fourteen hour agentic run. I was there for it.

Here is what that felt like. After twenty years of doing this by hand, one engineer at a time, I watched my own order of operations execute without fatigue, without drift, and without anyone deciding that just this once we could skip the boring part. It is the most fun I have had in my career, and I do not think I am going to get over it.

What actually changed

The fourteen hours is the part people repeat back to me. It is not the part that matters.

What collapsed was not the judgment or the gates. It was the distance between knowing the right order and executing it, over and over, without getting tired. That distance is where twenty years of my working life went.

None of this works if the agent does not know what good looks like, and legacy is where that bites hardest. In greenfield, good is whatever you establish on day one. In legacy, the codebase is full of confident, load-bearing examples of bad, written by people under deadline doing their best. An ungoverned agent reads all of it as the local convention and produces more of the same, faster than any human could. You do not get a rescue. You get the same system, larger.

So you need one of two things. An engineer who has spent twenty years learning to tell the difference, which is scarce and expensive. Or that standard written outside the codebase, enforced at every step.

Here is the part I did not see coming. Teams have started touching code they had avoided for years. Not because anyone gave them permission, but because the cost of being wrong changed. They are learning the craft by running it, with the reasoning visible at every gate, roughly how I learned it, except it took me two decades and an unreasonable number of Fridays. Let me be precise about what that replaces. The workflow carries the discipline. Which system to rescue first is judgment, and that is still yours.

That is what I mean when I call this the work of a lifetime. Not that it takes a lifetime to do. That a lifetime of it now fits inside your team's Monday.

If you have a system nobody wants to touch, book a walkthrough and I will run the first phase against your own code, live.

---

Adeel Ali is the founder of ClickChain AI, where teams use AI to amplify their best engineers instead of replacing their judgment.