The Systems You Most Want to Point an Agent At Are the Ones Where Agents Are Least Safe
You might have a sense of this already, but nearly every AI adoption conversation I have had this year arrives at the same place. Someone says: what about the old stuff.
They usually mean the same thing. The system that has been running since 2009, a few hundred thousand lines nobody has read end to end, the two people who understood it now retired. It is on every roadmap and it never moves, because the estimate is a year and the risk is unacceptable.
Then agents arrive, and the temptation is obvious. An agent can read that codebase in an afternoon; it does not get bored, it does not resent the assignment, and it will happily produce a migration plan by Friday. This is often the most dangerous place in the estate to start, and it is where a lot of programmes start anyway.
The difficulty is not that agents are bad at legacy code; they are remarkably good at reading it. It is that reading it produces a confidence the estate does not deserve.
Why it is dangerous
Autonomy is best granted on two variables: what it costs if a change is wrong, and how well you would know. Legacy systems tend to be the worst available combination on both. Consequence is high, because these systems are usually load bearing; that is why they survived, and very few organisations keep a business critical system running for fifteen years by accident.
Verification is weakest here, and usually weaker than teams assume. The test suite, if there is one, was written against an earlier version of the world, and there is no living specification. Behaviour is documented by the fact that it currently works, which is not documentation; it is an observation. The failures also tend not to appear in a test run: they appear in a month-end reconciliation, a regulator’s question, etc., or in a complaint about something that has quietly been wrong since March.
There is a subtler problem underneath. In a legacy system the code is often the only specification, so an agent asked to change it infers intent from the implementation, and that implementation encodes fifteen years of bug fixes, workarounds and compromises nobody dares remove. The agent cannot tell which lines are the design and which are the scar tissue, and frequently neither can anyone still employed. What comes back is confident, plausible, and faithful to behaviour that may itself be a defect.
The right order
In autonomy terms, legacy sits at Proposed: the agent drafts, and a named human decides. That is a statement about the strength of your verification rather than about the work. The instinct is to raise autonomy where the backlog is biggest; the better move is to earn a higher grant by building the verification first, and to use agents to build it.
- Characterisation tests. Point agents at the system to capture what it actually does now, rather than what anyone thinks it does. They make no claim about correctness; they pin current behaviour, bugs included, so that any later change surfaces as a visible difference. A change that faithfully preserves a defect will pass, which is the point rather than a flaw: it separates what changed from what is right. Tedious, high volume work, which is precisely what agents are for.
- Contract tests at the boundaries. Every integration point gets a recorded, asserted expectation. Most legacy risk is not internal; it is the six other systems quietly depending on a response shape nobody wrote down.
- A reconstructed specification. Have agents produce a written description of what the system does, then walk it through whoever is left who knows the domain. This is usually the highest value hour you will spend, because it is where somebody says that rule was for a customer we lost in 2016, and scar tissue gets identified as scar tissue rather than design. Sometimes nobody is left, in which case the output is a list of open questions, and that list is the first honest inventory of what the organisation does not know about a system it depends on.
Only then do you raise autonomy on changes to that system. By that point the verification is independent, because it was built before the changes it will judge.
Why this is not a delay
The obvious objection is that this postpones the visible win by a quarter, and there are two answers to it. Every step above is agent work delivering value from week one; reading, documenting and characterising an estate nobody understands is low consequence work with easy human verification, so you get the productivity story immediately, on work that is safe to get wrong.
You were also probably never getting the fast version anyway. What tends to arrive instead is a quarter of impressive velocity, then a defect surfacing in the most expensive place available, and an organisation that concludes AI-assisted delivery is unsafe. That conclusion is the expensive part, and it lasts years.
So the quarter you spend building verification is not a delay to the AI programme; it is the part that decides whether the programme survives contact with your oldest systems. Unowned capability creates debt for someone later, and a legacy system is mostly that debt with a longer history than most.