dooopSoftware · Process · 12 min

How to Safely Adopt AI in Legacy Systems

Use AI in legacy systems with small changes, observable tests, and human review to preserve critical behaviors.

Published on September 6, 2026

CORE THESIS

In legacy systems, AI fails when it changes what no one has named. Gains come from short scope, evidence, and capable review.

AI integrates better into legacy systems when it preserves critical behavior. The boundary of change matters more than the amount of code generated.

A small change in a legacy system may seem simple until it touches an implicit rule, an old integration, or an exception still used by operations. Before activating AI, the central question is: which critical behavior must remain unchanged while the change is made?

In legacy code, risk usually lies in implicit rules, side effects, and old integrations. Therefore, AI should be applied in well-defined changes, with observable testing and human review proportional to the risk.

The Risk of AI in Legacy Is Not Writing New Code

A legacy system is rarely just an old system. It is often a set of accumulated decisions, tolerated shortcuts, business rules that survived multiple managements, and integrations no one wants to touch unless necessary.

When a team uses AI in this environment, the problem is not only the possibility of the tool suggesting incorrect code. That risk exists but is visible. The more difficult danger is different: AI can produce a seemingly clean, coherent, and well-structured change that alters behavior the operation depended on remaining the same.

In new systems, teams generally have more freedom to redesign. In legacy systems, too much freedom is part of the problem. A local improvement can change the execution order of a routine, alter error handling, modify rounding, remove an old exception, or affect an integration that was never well documented.

Technical leadership must treat AI in legacy systems as a controlled intervention, not as open modernization. The practical question is: which part of the behavior will be changed, which part must survive, and how will the team know the difference?

This care is not a romantic defense of legacy. It is a way to reduce ambiguity before increasing speed. Generating code is too easy to be the center of the decision. Preserving critical behavior is what separates an assisted change from a gamble.

Map the Behavior That Must Survive the Change

Before asking AI for help, the team needs to transform tacit knowledge into an operational description. It does not need to write perfect documentation of the entire system. It needs to name the behavior that cannot change in that task.

A good scope describes at least:

which inputs trigger the affected flow;
which outputs must remain compatible;
which known exceptions are part of the current behavior;
which side effects are expected, such as writing, sending, blocking, or notification;
which integrations depend on this behavior;
which cases should not be modernized along with the change.

This description acts as a small behavior boundary for the task. It is not bureaucracy. It is the material that prevents AI, the reviewer, and the developer from confusing correctness with redesign.

Imagine a legacy internal billing system in a fictional company. The team needs to change the discount calculation for a corporate order category. A poor request for AI would be: “refactor the discount module and fix the calculation.” This command opens space to reorganize logic, change names, clean conditionals, and touch neighboring rules.

A better request starts smaller: “change only the discount rule for corporate orders above a certain value, preserving rounding, taxes, error messages, and integration with invoice issuance.” The example is fictional, but the criterion is concrete. If the team cannot say what must remain the same, the task is not yet ready to be assisted by AI.

Legacy charges dearly when the right change happens in the wrong place.

Choose a Small, Independent, and Testable Change

Adopting AI in legacy systems should favor small, independent, and testable changes. DORA recommends working in small units to get earlier feedback and review hypotheses sooner. The same guidance warns about the difficulty of reviewing and integrating large AI-generated changes.

This point is especially relevant in legacy. A large change may seem productive because it concentrates several improvements in a single delivery. In practice, it increases the area of uncertainty. When something breaks, the team does not know if the cause is in the fix, refactoring, cleanup, dependency replacement, or flow reorganization.

A well-defined change has a clear boundary. It states where AI can touch and where it should not. It may involve a file, a function, a method, a rule, or a specific flow. The exact size depends on the system, but the review criterion is simple: if the team cannot review the change in a focused reading and test the preserved behavior, the scope is too large.

Signs that the task has become broad refactoring disguised as a change include:

the request mixes fix, aesthetic improvement, and modernization;
AI needs to infer business rules from obscure code;
the change touches areas not directly involved in the described behavior;
the justification for changing neighboring files is only “while we’re here”;
the review depends on general trust in the tool, not specific evidence.

This does not mean refactoring is forbidden. It means it should be a separate decision, with a different scope and level of evidence. In legacy, each intervention must clearly state where it starts, where it ends, and which behavior it must preserve.

Provide Enough Context to AI, But Do Not Deliver the Entire System

The quality of AI’s response depends on the selected context, within the limits of the available window. Anthropic defines context engineering as selecting and maintaining the information available to the model during inference, including instructions, tools, external data, and history within a limited window.

In legacy systems, this should be translated practically: provide context that reduces ambiguity without inviting AI to redesign neighboring areas.

Good context for AI includes:

code snippet directly affected;
business rule to be changed;
behavior that must remain the same;
input and output examples;
compatibility constraints;
local patterns to be preserved;
clear definition of what is not part of the task.

Poor context is broad and vague: “analyze this module and improve possible problems.” In legacy systems, this type of request often turns a behavior change into an opportunity hunt. AI may suggest a more elegant structure, but elegance is not a sufficient criterion when operations depend on compatibility.

It is also useful to differentiate context from authority. Giving AI more files does not mean delegating the decision. The tool can help locate dependencies, propose minimal changes, explain obscure parts, and suggest tests. Authorization to change remains human, especially when there is impact on operations, customer service, data, or integrations.

Before expanding AI use, the organization needs to understand its starting point, risks, and capacity to review changes. In legacy, the question narrows: do we have enough context for this specific change?

Use Tests as a Fence, Not Just a Final Formality

Automated tests do not guarantee that all critical behavior was preserved. But when well chosen, they act as a fence. They delimit what must not move while the team changes part of the system.

In legacy systems, there is not always a reliable test suite. This should not lead to two extreme responses: blocking any AI use or accepting any suggestion because “there were no tests anyway.” Between these extremes, the team can create tests that record the current behavior of sensitive parts, even when that behavior is not ideal.

This type of test does not claim the rule is beautiful or correct in absolute terms. It only makes observable what operations already expect.

In the fictional discount calculation example, the team could record cases of corporate orders with known combinations of value, category, rounding, tax, and error message. The hypothesis to measure is not “AI improved the module.” The hypothesis is more precise: “the new rule was applied without altering the preserved cases.”

Continuous integration also helps when it exists. DORA describes continuous integration as frequent integration into the main codebase, accompanied by automated builds and tests. The same source states that fixing a broken build should have priority over new changes.

Applied to legacy, the point is direct: if the AI-assisted change breaks the build or invalidates a preserved behavior test, the team should not pile up new prompts per attempt. They should stop, understand the cause, and decide if the scope needs to shrink.

Testing is not a closing ceremony. It is part of the boundary that makes the change acceptable.

Review AI Output by What It Preserved, Not Just What It Fixed

Human review in legacy systems cannot look only at whether the new rule was implemented. It must look at what AI preserved.

GitHub’s documentation on responsible use of agents with Copilot describes features with distinct environments and permissions and emphasizes human supervision and output review. This principle applies even when the team does not use an autonomous agent. The greater the tool’s capacity to change code, the clearer it must be who reviews, what is reviewed, and by which criteria.

In an AI-assisted legacy review, the reviewer should look for specific side effects:

change in function or method signature;
alteration of execution order;
change in error handling;
modification of persistence;
change in permissions or validations;
silent change in external integration;
removal of seemingly strange exceptions still used by operations;
code standardization that changes compatibility.

The reviewer should also compare the output with the authorized boundary. If AI touched unexpected areas, this should not be accepted just because the code is cleaner. The question is: was this additional change necessary to preserve behavior and implement the adjustment? If the answer is uncertain, the change should return for scoping.

There is a common trap here. Passing tests may reduce anxiety but do not eliminate judgment. If tests cover only the happy path, a change in exception, integration, or message may escape. Therefore, review must combine automated evidence with risk-oriented reading.

Leadership may have a broad AI adoption plan, but each legacy change must answer a smaller question: does this specific change have a reviewer capable of evaluating preserved behavior?

Without this reviewer, AI only anticipates a decision no one has assumed.

Minimum Criteria to Authorize AI in a Legacy System

Before releasing an AI-assisted change in legacy code, the team can use minimum criteria. They do not replace architecture, testing, or review. They help decide if the task is mature enough to receive assistance.

Named Critical Behavior

Can the team say which behavior cannot change?

Passes when there is an objective description of input, output, rule, exception, or expected effect. Fails when the justification is only “it has always worked this way” or “the user would notice if it broke.”

Explicit Change Boundary

Does the task specify where AI can and cannot touch?

Passes when affected files, functions, modules, or flows are delimited. Fails when the request mixes fix, refactoring, aesthetic improvement, and modernization.

Evidence Before the Change

Is there any way to observe current behavior?

Passes when there is an existing test, a test that records current behavior, a reproducible example, reliable log, or documented manual comparison. Fails when the team will only know if it broke after someone complains.

Selected Context for AI

Does the request include necessary information without opening space for undue redesign?

Passes when AI receives rule, constraints, relevant snippet, local pattern, and definition of done. Fails when the request is generic, like “improve this module” or “fix possible problems.”

Human Review Proportional to Risk

Does the reviewer understand preserved behavior and the changed point?

Passes when review checks solution, side effects, and compatibility with existing flow. Fails when review looks only at code style or accepts output because tests passed.

Stop Plan

Does the team know when to stop AI-assisted change?

Passes when there are triggers to reduce scope, investigate manually, or split the task. Fails when AI keeps receiving prompts until producing something plausible.

Stop Criterion: When Not to Use AI in This Change

There are situations where the best technical decision is not to use AI at that moment.

The team should stop or reduce scope when:

critical behavior cannot be described;
there is no reasonable way to observe current behavior;
the business rule depends on knowledge no one can validate;
the change requires touching many flows without a clear boundary;
there is strong dependence on undocumented side effects;
there is no reviewer capable of evaluating the change;
deadline pressure mixes fix, modernization, and cleanup in the same batch.

In these cases, the next step is not to insist on better prompts. It is to investigate, create minimal evidence, split the task, or postpone AI use until the boundary exists.

The authorization criterion is uncomfortable but direct: use AI in legacy systems only when the change has preserved behavior, explicit boundary, evidence before and after, selected context, and capable human review. If any of these pieces is missing, reduce scope before expanding use.

If you want to discuss this decision in your company’s context, talk to dooop.

Sources

NEXT DECISION

Discuss Application in the Company

Conversation about the software company context

Content by dooop. Registration allows linking this topic to the reader’s journey and tracking interest in the subject.