Copilots versus agents for legacy migration

We often get asked why we build on an autonomous coding agent rather than an autocomplete-style assistant. Both are useful. They solve different problems, and legacy migration happens to be a problem shaped for agents.

What a copilot does well

A copilot suggests the next line or block while a developer types. It is excellent for writing new code in a familiar language, filling in boilerplate and recalling an API. The developer stays in control of every change, which is also its limitation: the speed of the work is the speed of the person accepting suggestions.

What migration actually involves

Migrating one medium-sized COBOL program to Java is not one change. It is a long sequence of steps:

• read the program, its copybooks and the programs that call it;
• work out the data layout and how numeric fields behave;
• write the Java classes, then the tests that wire them to the golden master;
• run the build, read the failures, fix them, and run again;
• repeat the last step many times until every case matches.

Most of that time is spent in the loop at the end. A copilot cannot run the loop on its own. An agent can.

Four properties we need from an agent

It acts. Claude Code reads files, edits them and runs commands in a terminal. It does not wait for a person to paste its output somewhere.

It verifies. After each change it can run the tests and read the results. A failed golden-master case is just another input for the next attempt.

It stays on long tasks. A migration involves hundreds of steps across many files. The agent keeps the plan and the context for the whole job, not just the current prompt.

It can be bounded. This is the property that makes the other three acceptable in a regulated environment. Claude Code supports allow-lists of tools and hooks that run before a tool is used, so we can enforce rules such as “only edit files in this module” mechanically rather than by asking nicely.

Where people stay in the loop

Autonomy inside a task does not mean autonomy over outcomes. In our design, people decide which module is migrated next, confirm business rules the agent has extracted, resolve anything ambiguous the agent flags and approve every pull request. The agent does the long, mechanical middle of the work. People do the parts that need judgement and accountability.

A practical comparison

Suppose a module needs forty build-and-test iterations before every golden case passes. With a copilot, a developer drives each iteration, reading output and deciding what to try. With an agent, the developer reviews the finished result and the record of how it got there. The second is not free of human effort, but the effort moves to where it is most valuable: review.

That shift is why we think agents, used carefully, can make modernization projects that were previously too expensive worth starting.