What Happens When AI Meets a Legacy System Nobody Wants to Touch
A few weeks ago, someone shared a story that’s stuck with me. A team had a legacy Ruby on Rails application — roughly 300 tables, no longer heavily used, but running functionality the business genuinely couldn’t afford to lose. The bigger problem: nobody on the current team actually knew Ruby anymore. The developers who built it had moved on. What was left was a working system nobody wanted to be responsible for.
They had two tasks on the table.
Task one: Upgrade the app from Rails 6 to a current version. The team’s own estimate: 1–2 engineer-months. Claude did it in under an hour.
Task two: Retire Rails entirely and rebuild the application on the Java stack the company already runs everywhere else — the sensible long-term move, but the kind of project that sits on a roadmap for years because nobody wants to own the risk. Developer estimate: six months. Claude produced a fully working prototype in one week — including a Ruby test suite covering 95%+ of the codebase, up from roughly 40% coverage in the original.
That last part is the detail people tend to skip past, and it’s the one that actually matters. A prototype that runs is a demo. A prototype backed by a test suite that verifies behavior against the original system is a foundation you can actually build on with confidence. That gap — between “it works” and “we can prove it works the same way the old one did” — is usually where legacy modernization projects live or die.
Why This Story Isn’t About Ruby on Rails
It would be easy to read this as a Rails story, or an AI-coding-speed story. It’s really a story about what happens when the two hardest constraints in legacy modernization — institutional knowledge loss and estimation risk — get partially solved at the same time.
Every organization running a critical legacy system eventually hits the same wall: the people who understood it are gone, the documentation was never a priority, and the system is too important to touch casually and too outdated to leave alone. Estimates for modernization work balloon because engineers are pricing in the unknown — the undocumented edge cases, the business logic nobody wrote down, the risk of breaking something nobody remembers how to fix.
Get ProgrammersAi’s stories in your inbox
Join Medium for free to get updates from this writer.
AI tools don’t eliminate that risk. But they compress the two most expensive parts of the process: understanding an unfamiliar codebase, and generating the test coverage needed to validate that a rewrite actually preserves behavior. That’s what turned a six-month estimate into a one-week prototype — not magic, but a legitimate shortcut through the two slowest parts of the job.
The Part That Doesn’t Show Up in the Headline
A working prototype in a week is impressive. It is not the same thing as a production-ready system. Getting from “AI-generated prototype” to “system running the business” still requires the parts AI doesn’t replace:
- Domain validation — someone who understands the business rules well enough to confirm the AI didn’t just replicate behavior, but replicated the correct behavior, including the edge cases the original developers built in for reasons nobody remembers.
- Production hardening — performance under real load, security review, integration with the rest of the stack, deployment and rollback planning.
- Institutional buy-in — a rewrite doesn’t succeed because the code compiles. It succeeds because the team trusts it enough to cut over.
This is exactly the gap that separates a good prototype from a finished modernization project — and it’s the reason “AI did it in a week” isn’t actually the end of the story. It’s the fastest first draft anyone’s ever produced, handed to a team that still has to finish the job properly.
Why This Matters Beyond Ruby on Rails
This pattern isn’t unique to Rails apps. It’s the exact same story playing out across every legacy platform still running mission-critical workloads on aging talent pools — and IBM i (AS/400) is one of the clearest examples in the industry today.
Thousands of companies run core business logic on IBM i systems that have been stable for decades, maintained by a shrinking pool of RPG and COBOL developers who are aging out of the workforce faster than replacements are being trained. The parallel to the Rails story is almost exact: critical functionality, limited institutional knowledge, and modernization projects that get estimated in months or years because nobody wants to be the one who breaks production.
This is where IBM i modernization services are starting to look different than they did even two years ago. AI-assisted code analysis and test generation can do for RPG and COBOL codebases what it did for that Rails app — accelerate the slowest, most expensive parts of the process: understanding undocumented logic, generating meaningful test coverage, and producing a working starting point instead of a blank page. The six-month estimate doesn’t have to stay a six-month project by default.
That said, speed without judgment is how modernization projects fail loudly. This is exactly why IBM i advisory services matter more, not less, in an AI-accelerated world — organizations need experienced people who can validate that an AI-assisted rewrite actually preserves business logic, who understand the operational realities of a live IBM i environment, and who can make the call on what’s safe to automate and what still needs a human who’s done this before.
And once the plan is validated, someone still has to build, test, and ship it properly. That’s the role of real IBM i application development expertise — turning an accelerated prototype into a production system that a business can actually depend on, with the domain knowledge to know which shortcuts are safe and which ones aren’t.
The Real Takeaway
AI didn’t replace the developers in that story. It replaced the two most expensive constraints they were operating under: time and unfamiliarity. What’s left is still a job for people who understand the system, the business, and the risk of getting it wrong.
For any organization sitting on a critical legacy platform — Rails, RPG, COBOL, or otherwise — the question isn’t whether AI can accelerate modernization anymore. It clearly can. The question is whether you have the advisory judgment and development expertise in place to turn that speed into something safe to run in production.
That’s the part that hasn’t gotten any faster. And it’s the part worth getting right.
