Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For many engineering teams, the most useful early work AI can do on software is not writing new features. It is helping people understand the code they already run, map what depends on what, and make tightly scoped changes that engineers can check. The published evidence supports this direction, but only in a bounded way: pilots, internal case studies, and practitioner experiments. It does not show that AI can modernize any legacy system on its own, and it does not guarantee a return.
What “hidden value” means in practice
Most public discussion of AI in software focuses on generation: a prompt goes in, new code comes out. Existing systems offer a different kind of value, one that is easier to miss. It usually comes down to three things:
- Recovered knowledge. Plain-language summaries of what a module does, and explicit statements of the requirements its code is actually meeting.
- A usable map. Views of which capabilities exist, which components depend on which, and where duplicate or unused code sits.
- Safer change capacity. The ability to make a defined migration or edit across many files without relying on heroic manual effort, provided every proposed change is verified.
Each of these produces proposals rather than facts. The rest of this article explains what the evidence shows for each, where it stops, and how to work with it.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Why inherited code is hard to understand
Long-lived systems accumulate business behavior in places nobody planned for. A rule about how a discount applies may sit in a batch job, a database trigger, and a reporting query at once. Documentation tends to describe the system as it was designed, then drift as the code changes. The result is that a team can own a system completely in a legal sense and still not know, with confidence, what it does in every case.
Thoughtworks authors make this point directly in their September 24, 2024 article “Legacy Modernization meets GenAI” on Martin Fowler’s site: “But we believe there is as much, if not more, value in understanding existing code – particularly long-lived, large, and complex legacy systems.” The implication is that understanding is not a preliminary step before the real modernization work. It is a meaningful part of that work, and one where AI tools can contribute.
What AI can produce from code you already have
Low-level requirements and high-level explanations
Thoughtworks describes practitioner experiments in which GenAI was used to draw out low-level requirements from existing code and to produce higher-level explanations of how a system is put together. These outputs give engineers a starting point for conversations with product owners and with the people who originally wrote the code. They are not a replacement for those conversations. Thoughtworks frames the approach this way: “We believe that the right and responsible way of leveraging this technology is through employing GenAI in the role of an assistant, ensuring the human is in full control of its outputs.”
Capability mapping and finding unused or duplicate code
The same Thoughtworks article identifies capability mapping, and locating unused or duplicate code, as further areas of potential work. These are presented as possibilities that practitioners are exploring, not as measured results across the industry. A capability map is only as good as the code it was built from, so these outputs are most useful when checked against usage data, production logs, or the owners of each area.
Intermediate representations of legacy code
MITRE’s June 5, 2025 paper “Legacy IT Modernization with AI” reports that large language models could generate intermediate representations from legacy code at scale. That is a meaningful capability for systems too large to review by hand. The same work also reports a gap: current model metrics did not match how subject-matter experts judged quality. In other words, a generated representation can look correct to an automated measure and still be wrong in ways an expert would catch. MITRE states that performance on complex government systems remains unproven.
How AI-assisted migration works in practice
The clearest published description of a full workflow comes from Google’s July 18, 2024 post “Accelerating code migrations with AI.” It describes an internal process, not a product anyone can download, and it is worth reading as an engineering pattern. Google’s account describes a sequence like this:
- Identify locations. Existing static tools and human input are used to find the files and dependencies a migration touches.
- Generate candidate edits. A model proposes changes for those locations.
- Validate the edits. Changed files are commonly compiled and unit tests are run. Google describes validation as configurable, so the checks can vary by migration.
- Review. Engineers review the proposed changes before they go further.
- Roll out. Changes are released in stages and monitored, rather than applied all at once.
Google also says that conventional tools work well for uniform changes with limited edge cases, and that more complex edits are what motivate its AI-assisted workflow. The internal tool relies on a model fine-tuned on Google’s own code and data. Teams using off-the-shelf assistants should not expect the same outcomes simply by copying the steps.
Rank #3
When a change spans the whole repository
Single-file edits are a different problem from changes that ripple through a codebase. Microsoft Research’s CodePlan paper, published in the Proceedings of the ACM on Software Engineering in July 2024, explains that dependent code can span many files and can exceed what fits into a single prompt. Its response is to treat repository-level change as a planning task: the model works from a plan that orders and scopes the edits, rather than attempting everything at once.
Recommended Free Tools
In the paper’s evaluated sample, 5 of 7 repositories passed validity checks, which concerned builds and correct edits. The baselines without planning passed none. Those figures describe a small set of evaluated tasks, not a general success rate for AI coding, and they should be read as evidence that planning and context matter, not as a forecast for your repository.
Comparing the main approaches
Three approaches are realistic for code you already own. They are not mutually exclusive, but they differ in the kind of change they suit and the kind of evidence behind them.
| Approach | Best fit | Context handled | Validation | Rollout and reversibility | Evidence maturity |
|---|---|---|---|---|---|
| Static analysis and scripts | Uniform, predictable edits with limited edge cases (Google’s description, 2024) | Pattern-based; the cited sources do not assess cross-repository reasoning for this approach | Compilation, unit tests, static analysis | Not stated in the cited sources | Well established in practice; the cited sources do not measure it |
| AI-assisted editing with planning | Changes across multiple components, interfaces, dependencies, and tests | Repository-level dependencies; the CodePlan paper frames this as planning (Microsoft Research, July 2024) | Compilation, unit tests, and human review (Google’s workflow) | Staged rollout in Google’s internal process | Bounded pilots and one internal case study; the CodePlan result covers 7 repositories |
| Incremental modernization | Large, long-lived systems where a single cutover is too risky | Whole-system, delivered in pieces | Checked at each increment and fed back into the next | Thoughtworks describes evolutionary modernization as a way to reduce displacement risk and deliver value earlier | Practitioner guidance, not a measured outcome |
The practical question is rarely “AI or not AI.” It is whether a given change is uniform enough for conventional tooling, or whether it needs a model to propose edits across a larger area that engineers then verify.
Where the numbers stop
Carnegie Mellon’s Software Engineering Institute offers some of the most concrete figures in this area, and they are easy to over-read. Its 2025 year-in-review, “Generative AI and the Future of DoW Software Modernization,” reports three things with different scopes:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Accuracy declines as code complexity grows. This is a general finding from the SEI work and is the most important constraint for planning.
- Roughly 140 errors per thousand lines in baseline tests. This is an SEI result for its AI-assisted translation testing context, not a universal error rate for AI-generated code.
- An 86% to 100% reduction in error rates. This applies only to pilots covering two common types of cross-unit link errors in the SEI’s Ada-to-C++ translation work. It does not cover all modernization errors or other projects.
The SEI’s approach is explicitly not to remove people from the loop. James Ivers, Principal Engineer at the SEI, puts it this way: “The goal of the approach is not to remove humans from the loop but to hand developers most of the solution and focus their attention on what the LLM couldn’t do or got wrong.” The SEI also reports limitations in complex translation and architectural reasoning.
Best Value
MITRE’s context adds a further caution. It notes that some federal systems in its modernization scope are more than 60 years old. That describes the age of certain systems, not the typical age of software. MITRE recommends high supervision in mission-critical settings.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Organizational conditions decide much of the outcome
DORA’s 2025 report, “DORA 2025 State of AI-assisted Software Development Report,” frames AI as an amplifier of what an organization already does well or poorly. Its findings draw on more than 100 hours of qualitative data and responses from nearly 5,000 technology professionals worldwide. That describes the scope of the research, not a measured productivity gain, so it is best used as a lens rather than a benchmark.
The amplifier idea explains why a tool rarely fixes weak testing, unclear code ownership, or poor release discipline. If a team cannot tell whether a change is safe today, a model that proposes changes faster will not make that judgment for them.
A cautious workflow for code you already own
- Before any change, establish current behavior with tests that pin down what the code does now, including its odd cases.
- Treat every AI-generated explanation or requirement as a hypothesis. Check it against tests, production behavior, and the people who own the area.
- Scope each proposed change to a defined set of files and dependencies, and record which were identified by static tools and which by people.
- Require compilation and unit tests to pass before a human reviews the change, and keep reviewers responsible for intent, not only syntax.
- Roll out in stages, with monitoring and a tested way to revert.
- Do not assume that a fluent document is an accurate one. A tidy summary can still miss a business rule.
Further reading
For the engineering practices that make this kind of work safer, Michael Feathers’s Working Effectively with Legacy Code remains a relevant reference. The first edition (ISBN 9780131177055), listed by InformIT/Pearson with a publication date of September 22, 2004 and 464 pages, covers understanding code, introducing test harnesses, writing protective tests, locating changes, and dependency-breaking techniques. It predates generative AI, so it should be read as foundational engineering guidance rather than a guide to current AI tools.
The Bottom Line
AI’s most defensible contribution to existing software is helping teams recover knowledge about the code they own, map its dependencies, and propose changes that engineers then verify. Its strongest published results are narrow and conditional, and the outputs are hypotheses that tests, owners, and staged rollouts have to confirm.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
