There are trillions of dollars in critical systems running on COBOL, Delphi, Visual Basic 6, ABAP, RPG, ColdFusion, old PL/SQL, Perl, Fortran. Banks, government, industry, corporate ERP. These systems will not disappear because someone decided to rewrite them in Rust over the weekend. They work, they support the business, and they would cost far too much to replace. The real problem is a different one: who still knows how to read, maintain, and evolve these codebases?
In 2026, specialist agents powered by LLMs have become the best answer to that question. They do not replace the rare engineer who knows COBOL, but they amplify the current team, translate knowledge, generate tests, and accelerate incremental modernization. This guide shows how.
The real problem: knowledge debt, not just technical debt
Treating legacy as "old code" is an oversimplification. What makes the problem acute is the gradual loss of knowledge: the people who wrote the system have retired, the documentation evaporated, the comments are in another language, critical business rules exist only in the heads of three employees, and the build depends on a specific machine in the corner of the room.
LLMs help precisely in that vacuum. They were trained on immense amounts of legacy code, they know dialects humans have forgotten, and they can read hundreds of thousands of lines in minutes, extracting rules, flows, and dependencies and generating actionable documentation.
What LLMs do well with legacy code
Five uses with a clear ROI. 1. Reverse documentation: generating a plain-language description of what each program, module, or stored procedure does, with flows, inputs, outputs, and embedded rules. 2. Business-rule translation: extracting rules tangled in the code into a spec that product can read. 3. Test generation: creating a test suite that covers current behavior, serving as a safety net for changes. 4. Incremental modernization: translating module by module into a modern language while preserving behavioral equivalence, with regression testing. 5. Support for junior engineers: a specialist agent answers "what does this snippet do and why" with confidence and a citation of the source code.
Architecture of a legacy specialist agent
A recipe that works. 1. Full indexing: the entire legacy repository goes through extraction, chunking that respects the structure (program, procedure, copybook), and embedding generation. 2. Dependency graphs: static ones (calls, includes, JCL) built in parallel, complementing the RAG. 3. Hybrid RAG: semantic search + exact keyword (important for identifiers like a variable, a copybook, a transaction). 4. Specialized tools: a copybook parser, a JCL reader, a CICS transaction map, structural pattern search. 5. System prompt: a specialist persona in the target language, with an instruction to cite the file and line in every answer. 6. Validator: for code changes, the agent runs the target language's compiler or linter and iterates if it breaks.
Incremental modernization: the safe path
The biggest mistake is trying to rewrite everything. Market history shows that a big-bang rewrite fails in 70-80% of cases. The safe path is the strangler fig: a new system grows around the old one, module by module, with coexistence. Agents accelerate every step of the strangler.
Typical steps. (a) The agent maps the functional domain of the module to be replaced. (b) It generates an SDD spec of the current behavior, with acceptance criteria derived from the real use cases. (c) It generates a suite of characterization tests over the legacy system to guarantee parity. (d) It implements the equivalent module in a modern language (with the agent's help). (e) It runs in parallel (shadow), comparing output in production until it can be trusted. (f) It does a gradual cutover with a feature flag and easy rollback.
Language-specific considerations
COBOL: watch out for PIC clauses, packed-decimal conversion, and edge cases of decimal arithmetic that modern languages handle differently. Delphi: a strong dependency on VCL components and third-party libraries; often the best strategy is to keep the Delphi client and move logic to services. VB6: COM and old DLL dependencies; modernization tends to carve out the surface first. ABAP: deep integrations with SAP require knowledge of BAPI, IDoc, RFC; the agent needs RAG over SAP objects, not just code. RPG/AS400: persistence in physical files, logic embedded in screens; modernization requires separating UI, rules, and data.
Risks and mitigation
Four typical risks. 1. Technical hallucination: the agent "invents" syntax that does not exist in the exact dialect. Mitigation: a validation tool (compiler, linter) and RAG over the official documentation. 2. Silent behavior change: the translation looks correct but handles an edge case differently. Mitigation: shadow mode with a diff in production, rigorous characterization tests. 3. Loss of tribal knowledge: the agent "swallows" the know-how without humans absorbing it. Mitigation: mandatory human review and documentation published as team content. 4. Vendor dependency: using a vendor's closed agent for all the legacy creates lock-in. Mitigation: keep prompts, evals, and RAG in your own infrastructure, and switch the model according to the price-quality ratio.
Team and culture for this journey
Modernization with agents needs three profiles. 1. A veteran engineer who knows the system. Without them, the agent errs and no one notices. 2. A modern engineer who knows the target stack and has the habit of testing aggressively. 3. Product/business who validates that the translated behavior matches the current intent, not just what the code happens to do.
Culture: patience, tolerance for iteration, and an explicit abandonment of the fantasy of a "rewrite in 6 months". Serious modernization of a critical system is a 1-to-3-year journey. Agents accelerate the journey, they do not eliminate it.
Measurable ROI
Real cases in 2025-2026 show productivity gains of 3x to 8x in reading, documentation, and test generation over legacy code. For translation, the gain is smaller (1.5x to 3x), but it comes with a substantial reduction in risk when done with characterization tests. The true ROI, however, lies in unlocking knowledge: companies that manage to onboard a junior on a legacy system in weeks, instead of years, capture a competitive advantage that is hard to measure but strategic.
How Steply works in this scenario
We work on three fronts: assisted archaeology (mapping and documenting the current system with agents), incremental modernization (planning and executing the strangler fig with specialized squads), and internal enablement (training the client's team to operate specialist agents as part of their day-to-day, instead of depending on a vendor). This combination takes legacy out of the "elephant in the room" and turns it into an evolvable capability, without a suicidal rewrite.