AI agents seem promising: give them access to the codebase, tell them what you want, and watch as they make changes. But when it comes to a real, years-old legacy system, this approach can be downright dangerous.
Why legacy code is different
A new codebase is like a new city: the streets are named logically, the map is accurate. Legacy code is an old city that has grown organically over decades. The streets are named for reasons that no one remembers anymore. A few bridges are closed, but no one has removed them from the map. Some buildings have been demolished, but references to them still live on.
There are three things in a legacy codebase that an agent cannot infer from the code alone:
- Undocumented decisions— why something was done the way it was. The answer is often in some meeting notes or in a colleague's head.
- Hidden dependencies— beneath direct calls are implicit assumptions, timings, and side effects that static analysis cannot see.
- Technical debt as structure— quick fixes have layered over the years into architecture. What looks redundant may be critical.
The Ralph loop: when the agent blinds itself
The Ralph loop is a situation that a naively programmed AI agent in legacy code can easily fall into: the agent makes a change, something breaks, the agent tries to fix it, it breaks in another way, the agent makes more changes — and the cycle continues. No progress is made, but damage accumulates.
The danger is that in the short term, it may seem like the agent is making progress: tests pass, syntax errors disappear. But at the same time, the code drifts away from its original purpose, and the cumulative effect of changes on the system's behavior remains invisible.
What is needed instead
The solution is not found by adding context to the prompt or making the agent faster. A structurally different approach is needed:
- Dependency graph before changes— before anything changes, it is essential to understand what depends on what. This requires static analysis, not guessing.
- Impact analysis for each change— what breaks if this is changed? The answer must be obtained before the change, not after.
- Staging and checkpoints— the agent should not be allowed to make long change sequences without verification. Each step is checked before the next.
- Meta-ontological framework— in complex systems, a way to structure both the structure (what is) and the purpose (why it is) is needed. Without this, the agent optimizes the wrong thing.
Meta-ontology as a tool
Meta-ontology sounds abstract, but in practice, it means: before doing anything, agree on how things are structured. At what level is it examined? What is considered structure, what behavior, what goal? When the agent operates within this framework, its decisions are justified — not just syntactically correct.. Millä tasolla tarkastellaan? Mitä pidetään rakenteena, mitä käyttäytymisenä, mitä tavoitteena? Kun agentti toimii tässä viitekehyksessä, sen tekemät päätökset ovat perusteltuja — ei vain syntaktisesti oikeita.
This is one of the key reasons why mere RAG (Retrieval-Augmented Generation) is not sufficient in a legacy context. RAG retrieves relevant code, but it does not understand the system's intentions. A meta-ontological approach forces us to model that as well,whythings are the way they are.
Hear more
Ville Laitila from Softagram gave a presentation on the topicat Business Oulu on February 25, 2026.The presentation goes through concrete examples, the traps that agents typically fall into, and how a more systematic approach changes the outcome.