Most large companies want AI.
Most large companies also run old, tangled systems that nobody currently on staff fully understands.
The person who originally wrote the logic may have left years ago. The documentation may be incomplete. Business rules may exist only in code, configuration files, database procedures, or the memory of someone who has been maintaining the system for a decade.
And now someone wants an AI agent to build on top of it.
That creates a problem that is easy to underestimate.
Before an agent can safely modify a legacy system, it first needs to understand what that system actually does.
Recent research puts numbers around the size of the problem. Developers spend roughly 58% of their time reading old code, compared with around 5% writing new code. One widely cited study has found that roughly 60% of AI leaders identify legacy systems as a primary barrier to deploying agentic AI.
The legacy-modernization market is growing alongside that pressure, from roughly $29 billion in 2026 to more than $66 billion by 2031.
Thoughtworks has built a specific product around this intersection.
In January 2026, the company launched AI/works, an agentic development platform designed to interpret legacy applications, turn that understanding into structured specifications, enrich those specifications with regulatory and security context, and use agentic workflows to generate code, tests, and deployment pipelines.
That sounds compelling.
But there is one question underneath all of it:
How do you know the AI actually understood the old system correctly?
How big is the pressure, in plain numbers?
The numbers point to an uncomfortable reality.
For many enterprises, the bottleneck isn't the ability to generate new code.
It is understanding the code that already exists.
That makes legacy-system comprehension a potentially valuable first step in an agentic development workflow.
But comprehension is also where the highest-risk assumption enters the process.
If the AI gets the old system wrong, everything built afterward can be wrong in ways that are difficult to detect.
The three shapes of the problem
Agentic AI potentially compresses all three stages.
But they shouldn't be treated as one problem.
Understanding is not specification.
Specification is not implementation.
And generated implementation is not production readiness.
Sector specialty worth naming: teams modernizing a finance or operations backbone
This problem appears inside almost every large organization with an old core system underneath a modern front end.
Banking.
Insurance.
Manufacturing.
Retail.
Government.
The industry changes.
The problem doesn't.
The company worth naming here is Thoughtworks.
In January 2026, it launched AI/works, a named platform specifically positioned around agentic development and legacy modernization.
The workflow is notable because it doesn't begin with "generate some code."
It begins with understanding the existing system.
That is exactly where the following questions matter.
1. Does it actually understand the old system — or just summarize it plausibly?
There is a major difference between an AI system that can produce a convincing description of legacy code and one that can accurately reconstruct the system's actual behavior.
The second is much harder.
A legacy application can contain undocumented dependencies, unusual business rules, dead-looking code that turns out to matter, database procedures, configuration-driven behavior, and years of accumulated exceptions.
A plausible summary can miss any of them.
Our reading: Thoughtworks describes AI/works as using AI-enabled reverse engineering to interpret legacy applications and convert that understanding into structured specifications.
That's a meaningful claim.
Reverse engineering suggests the platform is working from the actual application rather than simply asking an AI model to explain a few code files.
The missing piece is verification.
Ask what the verification step looks like: who checks the AI's understanding of the legacy system against actual system behavior before that understanding becomes the basis for new code?
For a high-stakes system, "the AI understood it" cannot be the final control.
2. Are the "months instead of years" claims measurable?
"Years to months" is probably the most memorable promise in this category.
It is also one of the claims buyers should interrogate most closely.
Modernization projects can take years because the difficult work isn't always writing replacement code. It includes discovering undocumented behavior, validating requirements, testing edge cases, migrating data, integrating surrounding systems, and obtaining approvals.
Our reading: Thoughtworks has publicly described AI/works as enabling modernization work to move from years to months, alongside claims around lower costs and improved code quality.
Those are significant claims.
But as of 6 September 2026, the public material available does not provide enough named, project-level evidence to independently establish how often the full "years to months" outcome has been achieved.
Ask for one named or anonymized customer example with an actual before-and-after timeline — in months, not a general "years to months" comparison.
A 90-day pilot is interesting.
A production modernization of a genuinely tangled legacy system completed in 90 days is a much stronger proof point.
3. What happens when the business rules change after the new system goes live?
Modernization has a recurring problem.
The new system eventually becomes the old system.
If requirements change through manual patches, undocumented workarounds, and one-off fixes, the organization can recreate exactly the maintenance problem it was trying to escape.
Our reading: Thoughtworks describes AI/works as supporting an ongoing development model in which affected components can be regenerated when requirements change.
That is a particularly interesting part of the proposition.
The goal isn't simply to modernize once.
It is to make future change easier.
Ask for a real example of a requirement changing after go-live, and exactly what was regenerated automatically versus what still required human intervention.
This is where the difference between an AI coding tool and an actual modernization workflow becomes clearer.
4. Does it work the same way on a regulated system?
A legacy retail inventory application and a core banking system may both contain old code.
They do not carry the same risk.
In regulated environments, a small misunderstanding of a business rule can have consequences far beyond a failed application test.
There may also be requirements around security, auditability, traceability, data handling, and regulatory controls.
Our reading: Thoughtworks states that the specifications generated through its approach can be enriched with regulatory, security, and industry context.
That is highly relevant for regulated enterprises.
But the important question is how that context is validated in production environments where correctness matters more than speed.
Ask for a specific example from banking, insurance, healthcare, or another regulated environment where the approach was used on a genuinely high-stakes legacy system.
"Regulatory context is included" is a capability statement.
A regulated production example is evidence.
5. How does the 90-day delivery promise hold up on a genuinely tangled system?
The 3-3-3 model, positioning idea-to-production delivery within 90 days, is unusually specific.
That is useful.
Specific promises can actually be tested.
But there is an obvious selection effect to watch for.
A clean, well-scoped application with a small number of dependencies is very different from the oldest, most complicated system in an enterprise estate.
Our reading: The 90-day model is an attractive and testable proposition, but buyers should distinguish between a controlled modernization pilot and the hardest production system they own.
Ask which past projects actually used the full 90-day model end to end, and how large, interconnected, and difficult those systems were.
The strongest proof isn't the easiest system that can be modernized in 90 days.
It's the difficult one.
Where it fits
A large organization with genuinely painful legacy systems, significant technical debt, and a need to modernize faster than a traditional multi-year rewrite would allow.
It is particularly interesting for enterprises operating a hybrid estate where old core systems still support important business processes while newer applications and AI capabilities are being introduced around them.
Where it does not fit
A company expecting to remove human verification entirely from the modernization of a regulated or high-stakes system.
It is also a poor fit for a buyer assuming that a 90-day delivery model automatically applies to the most complex system in the estate without first validating the approach through a properly scoped pilot.
FAQs
1. Is this just outsourced development with AI added to the process?
Based on the public positioning, no.
The more distinctive part of the approach is the sequence: reverse-engineering the existing application, turning that understanding into structured specifications, and then using agentic workflows to generate implementation artifacts from those specifications.
That is materially different from simply giving developers an AI coding assistant.
The important caveat is that the approach is still relatively new, so independent large-scale evidence remains limited.
2. Is Thoughtworks the only company working on this?
No.
Major technology and professional-services firms are investing heavily in agentic development.
The more specific distinction here is the legacy-first approach: understanding an existing system before using agents to build or modify it.
That is a narrower problem than general AI-assisted software development.
3. What's the one thing most buyers forget to check?
Whether "understood by AI" has actually been verified against the real system.
The dangerous failure mode isn't an obviously broken AI output.
It's a plausible interpretation that quietly misses one undocumented business rule.
If that interpretation becomes the specification, and the specification becomes the code, the original misunderstanding can propagate through the entire modernization process.
Our reading
Agentic AI may eventually change legacy modernization in a fundamental way.
But the breakthrough isn't simply AI writing the replacement code.
The harder problem is getting the machine to understand what the old system actually does before anyone decides what should replace it.
That makes the most important control point the beginning of the workflow, not the end.
For buyers evaluating Thoughtworks or any similar approach, the questions worth pressing are straightforward:
How is the legacy system understood?
How is that understanding verified?
How does it become a specification?
What happens when requirements change?
And what evidence exists from genuinely complex production systems?
If those questions have good answers, agentic modernization becomes much more interesting.
If they don't, the organization may simply be moving faster toward a system it still doesn't fully understand.
And that is a very modern way to recreate a very old problem.
Top comments (0)