AI for legacy code has a context problem before it has a code-generation problem. A repository may contain years of changes, while its design documents describe an older system and its tests cover only part of the current behavior. An assistant can read all three and still receive conflicting instructions about what the software should do.
NTT’s October 23, 2026 announcement addresses that mismatch through software traceability and systematic test generation. The research is useful because it shifts attention from producing more code to connecting requirements, design, implementation and verification. Its preliminary results also need to be read within the limits of the experiment.
Research status: NTT reports preliminary experiments, not a universal guarantee for existing software. We have not independently tested the technology. The workflow examples in this article are editorial guidance, separate from the company’s reported findings.
The problem: three artifacts, three different stories
Consider a hypothetical booking system. Its requirements say a booking may be canceled before a deadline. A design document still describes an earlier rule, while the code implements a later exception. Existing tests verify only the normal booking path. Asking AI to “fix cancellation” leaves a basic question unresolved: which behavior is intended?
The assistant may produce a technically valid change that follows the wrong document. It may also add tests that merely confirm the current implementation. Neither outcome establishes that the system matches the intended requirement. A useful maintenance process needs a way to expose the disagreement first.
What NTT announced today
The official announcement describes two complementary technologies: tracing relationships between development artifacts and generating tests for uncovered perspectives. NTT aims to make existing software easier for AI to understand, modify and verify.
The preliminary traceability experiment used documentation and code for ATRS, a sample application. Of 41 intentionally embedded documentation errors, the proposed method detected 33, compared with 11 for the conventional RAG baseline. Those results describe that setup; they do not establish the same detection rate across production repositories.
Traceability means making the relationships explicit
Software traceability connects a requirement to the design choices, implementation and tests associated with it. It helps answer questions such as: which function implements this rule, which test verifies it and what might change if the rule is updated? The relationship is the useful part, not simply putting files in the same folder.
A function name alone may not explain the business rule behind it. A test may check an output without making its purpose obvious. Documentation may use different language from the code. A traceability record gives a reviewer a navigable path between those representations.
Our context engineering guide explains why relevant information matters around an AI request. Traceability adds structure to that information: the assistant can inspect how pieces relate instead of treating every passage as an isolated fact.
Why finding documents is not the same as checking consistency
Retrieval can bring relevant material into an AI workflow. Consistency checking asks an additional question: do the retrieved artifacts agree about the same function? A document can be highly relevant and still be outdated or contradictory.
In the booking example, retrieving both versions of the cancellation rule is useful. But the system must still flag the conflict and establish which version is authoritative. It should not silently combine incompatible rules into a plausible explanation.
This does not make retrieval unhelpful. It shows why a complete maintenance workflow may need retrieval, explicit relationships and validation together. A result from one baseline comparison should not be presented as proof that all RAG systems are ineffective.
Read the reported numbers with their denominator
| Reported experiment | Result | What to keep in view |
|---|---|---|
| Conventional RAG baseline | 11 of 41 embedded errors detected | A specific baseline and test set |
| Proposed traceability method | 33 of 41 detected | Eight embedded errors remained undetected |
| Generated-test evaluation | 4 of 6 embedded bugs detected | A small preliminary experiment |
The test-generation evaluation also found three previously unknown latent bugs, according to NTT. That is a useful finding, but it is different from a claim that the system found every defect. Detection rates need the target, sample and conditions attached to them.
For a team evaluating similar technology, a second question is how much review an alert requires. A tool that flags an inconsistency still needs a way to explain the evidence. Reviewers must decide whether the document, code or requirement should change.
Missing tests are more than missing lines of coverage
A test suite can execute a function without checking the conditions that matter. Normal input may work while boundary values, invalid input or interactions with another function fail. More test files do not automatically mean those perspectives are covered.
A useful test plan names the behavior and conditions being verified. For cancellation, that might include the exact deadline, an already canceled booking and a request for a booking that does not exist. The expected result must come from an agreed rule rather than a guess about the current code.
The test should be capable of failing for a meaningful defect. A generated assertion that repeats an implementation detail may offer little protection when the same misunderstanding appears in both the code and the test.
A practical preparation sequence for one legacy feature
1. Choose a bounded feature
Start with a small area whose purpose can be described clearly. Identify its users, inputs, outputs and dependencies. Avoid beginning with an unrestricted instruction to modernize the entire system; that makes both the scope and success criteria difficult to assess.
2. Collect the evidence and identify its status
Bring together the relevant requirement, design notes, implementation and existing tests. Record which version each belongs to and whether it is considered authoritative. Preserve disagreements as review items instead of rewriting them away before anyone understands them.
3. Map the relationships
Create a short record that connects each important rule to its implementation and verification. Include source locations so a person can inspect the claim. A relationship suggested by AI should remain a candidate until the supporting artifacts have been checked.
4. Resolve uncertainty before editing
When the evidence conflicts, ask the appropriate owner to confirm the intended behavior. A model cannot establish business intent simply by selecting the most recent-looking sentence. Record the decision so the next maintenance task does not rediscover the same ambiguity.
5. Add checks that match the confirmed behavior
Use the agreed rules to derive relevant test cases. Cover important boundaries, error paths and interactions, then run the checks in an isolated working copy. Review what remains untested alongside what passed.
Example AI request: For this feature, map the stated requirements to the relevant code and tests. Cite file locations. List contradictions and missing evidence separately. Do not change behavior or invent an intended rule. Suggest test cases only after identifying which requirement supports each expected result.
What teams should measure in a pilot
A useful pilot evaluates the whole maintenance process, including the effort needed to check the tool’s suggestions. Faster generation is helpful only if it leads to a change that can be understood and verified. Preserve a record of failed or uncertain cases.
- Confirmed inconsistencies found and important ones missed.
- Incorrect alerts and time spent reviewing them.
- Accuracy of links between requirements, code and tests.
- Meaningful defects caught by the proposed tests.
- Time needed to complete and review a bounded change.
- Whether source locations and decisions remain useful afterward.
Use a representative sample rather than only a clean demonstration repository. Include old comments, inconsistent naming and incomplete documentation if those are normal in the target environment. Keep the pilot’s limits visible when interpreting its results.
What the announcement does not establish
NTT describes further evaluation across systems with different sizes and characteristics, along with broader artifact and language support. That future work matters. The announcement should not be treated as a ready-made guarantee for every programming language or maintenance process.
It also does not mean a team can skip review or automatically rewrite a business-critical system. The strongest use of the idea is to make uncertainty and evidence easier to inspect. Clear relationships improve the basis for a decision; they do not remove responsibility for the decision.
Frequently asked questions
What is AI-ready legacy software?
In this context, it means existing software and its supporting artifacts are organized so AI can use them more reliably. Relevant documentation, code and tests need understandable relationships, with inconsistencies made explicit rather than hidden.
Does an 80% detection rate mean 80% fewer production bugs?
No. The reported figure concerns 33 of 41 intentionally embedded documentation errors in a preliminary experiment. Production defect rates, maintenance effort and long-term reliability are different outcomes that require separate measurement.
Can generated tests replace a test strategy?
Generated tests can help implement checks, but the strategy still needs to define the behavior, risks and conditions that matter. Expected results need a reliable basis. A large quantity of tests does not establish that those questions were answered.
Should all documentation be rewritten to match the code?
Not automatically. The code may contain the defect, or the documentation may describe an intended behavior that was never implemented. Establish the intended rule before deciding which artifact needs correction.
The useful takeaway
AI for legacy code works from a stronger foundation when requirements, implementation and tests tell a consistent story. NTT’s research highlights the value of connecting those artifacts and exposing missing checks. Start with one feature, make the evidence inspectable and measure verified maintenance outcomes.
Source: NTT’s October 23, 2026 research announcement. Reviewed October 23, 2026. Reported experimental findings are attributed to NTT; the booking example and preparation workflow are editorial explanation.
