Skip to content

AI, decoded

Can AI modernize legacy code and old applications?

It can do a lot of the work, but not unsupervised. AI is good at the slow parts of modernization — reading undocumented code, explaining what a function does, translating between languages, and drafting migrations. Where it can fail is the part that matters most: it may not know the business logic and edge cases the old system encodes, so it can confidently rewrite something subtly wrong. The pattern that works is AI as an accelerator with engineers verifying, plus tests that prove the new code behaves like the old. MongoDB's Rachelle Palmer told Chain of Thought she believes an 80/20 rule applies: LLMs can assist with 80% of modernization work, but the remaining 20% is purely manual effort.

· Updated · Chain of Thought

Level 3: Leading with AI

AI CodingEnterprise AI

  • 4 episodes
  • 5 guest clips
  • 2 glossary terms
A big 80/20 beside a bar split into a large blue share and a small ember share that ends at a gate, with the words: AI lifts about 80 percent, engineers verify. The 80/20 split is Rachelle Palmer’s rule of thumb.

In detail

Where AI is good

Legacy modernization is mostly archaeology, and that’s exactly where models help. They can read a sprawling, undocumented codebase and explain what a module does, map dependencies, translate from an old language to a modern one, and draft the first version of a migration. The work that used to take an engineer days of careful reading, AI can compress into a reviewable draft.

MongoDB’s Rachelle Palmer, who leads a forward-deployed AI engineering team, put a ratio on it in episode 14 at 9:05: “the eighty twenty rule applies here,” with LLMs assisting on 80% of the work and the remaining 20% “purely manual effort,” though the 80% runs in minutes, hours or days rather than on a human time scale. Google reports something similar from its own codebase: an experience report on LLM-assisted code migrations finds evidence that LLMs can significantly reduce the time migrations take, while presenting itself as practitioner experience rather than a controlled study.

Where it breaks

The danger is the knowledge that isn’t in the code’s syntax: the business rules, the edge cases, the weird exception that exists because of, say, a contract signed in 2011. A model reads the code, not the intent, so it can fluently reproduce structure while getting a critical behavior wrong — and a subtly wrong migration is more dangerous than an obviously broken one, because it ships.

Generated code can also end up with no owner. OutSystems co-founder Rodrigo Coutinho said in episode 19 at 12:51, published in April 2025, that some OutSystems partners using AI helpers to generate traditional code went as far as turning them off, because of the question of who owns that code. He describes an accountability issue at 13:18: a lot of generated code that nobody understood, which worked until it stopped, with nobody responsible for maintaining or fixing it. He calls that “kind of a limit situation.” You still need the expertise to read the code, he says, and to make sure it fits your architecture and compliance requirements (13:47). His remedy is low code, which OutSystems sells, so read that part as a vendor position. The episode aired in season two, which Galileo sponsored while Conor worked there; Galileo CTO Atindriyo Sanyal co-hosted (0:30).

The pattern that works

Treat AI as an accelerator, not an autonomous rewriter. Let it do the reading, explaining, and drafting; keep engineers on verification and the decisions that require understanding why the old system does what it does. Above all, lean on tests: characterize the legacy behavior first, then prove the modernized code matches it. Palmer describes the same step in episode 14 at 8:39: to prove equivalence between a legacy application and its replacement, “you actually need to generate effectively equivalent tests” for both, and LLMs can help write the tests a legacy codebase never had. Episode 14 is co-hosted by Galileo CTO Atindriyo Sanyal (0:22).

Using AI to modernize legacy code: AI does most of the lift, engineers verify, tests prove it A bridge from a legacy app, which combines situations from Rachelle Palmer's examples: a million lines of code, poor documentation, no test coverage and nobody left who knows the app, to a modernized app. The span is split by her rule of thumb: LLMs can assist with about 80 percent of the work, and the remaining 20 percent is manual effort. The AI share covers the slow parts: reading and explaining undocumented code, mapping dependencies, adding comments, translating from an old language to a modern one, drafting the migration and generating tests. The engineers' share is verification and the decisions that require understanding why the old system does what it does. Before the modern app goes live there is a gate: equivalence tests, which characterize the legacy behavior first and then prove the modernized code matches it. Underneath: the safety net isn't the model's confidence, it's the test that catches where the model was wrong. AI does the lift, tests hold the line MongoDB's Rachelle Palmer: LLMs can assist with 80%, but the remaining 20% is manual effort. LEGACY, SAY a million lines thin docs no test coverage nobody left whoknows the app AI · ABOUT 80% 20% · MANUAL minutes, hours or days people MODERN same behavior, new stack The slow parts, as a reviewable draft: read and explain undocumented code, map dependencies, add comments, translate old languages to modern ones, draft the migration, generate the tests. Engineers: verification, and the calls that need to know why the old system works the way it does. THE GATE · EQUIVALENCE TESTS Characterize the legacy behavior first, then prove the modernized code matches it. Palmer: to prove equivalence you need effectively equivalent tests between the legacy app and the new one. The safety net isn't the model's confidence. It's the test that catches where the model was wrong.
AI accelerates the reading and drafting; tests prove the result. The 80/20 rule of thumb, the legacy situations and the equivalence tests are MongoDB’s Rachelle Palmer’s, episode 14; the legacy box combines several of her examples. Download the image

Hear it from the guest

“I do believe the eighty twenty rule applies here, which is that you can get LLMs to assist with 80, but you still have this remaining 20% that's like purely manual effort.”
Rachelle Palmer, MongoDB EP 14 · around 9:05 · read the transcript
“In order to prove equivalence between a legacy application and a replacement application, you actually need to generate effectively equivalent tests between your legacy app and your new modernized app.”
Rachelle Palmer, MongoDB EP 14 · around 8:39 · read the transcript
“You end up building so much tech debt tech debt that is like a cancer in every organization you go to.”
Atindriyo Sanyal, Galileo EP 9 · around 8:13 · read the transcript
“If we were to rewrite it, it's like six people over six months and 2 million in hardware.”
Anush Elangovan, AMD EP 56 · around 6:11 · read the transcript
Watch on YouTube
“An accountability issue where they had a lot of generated code that nobody understood or knew exactly what it was doing”
Rodrigo Coutinho, OutSystems EP 19 · around 13:18 · read the transcript

Quotes lightly edited to remove filler words.

From the conversation

This explainer is drawn from these episodes — each carries its full transcript.

Concepts in this explainer

Technical DebtLarge Language Model

Keep exploring