The Changing Calculus of Software Stewardship: An AI-assisted Rails Upgrade Story

Let me be clear upfront: leaving a production application unpatched and running on a known-vulnerable framework is not responsible stewardship. If an app matters, it deserves to be kept current. Full stop.

But here’s the reality that a lot of teams are quietly living with: there are applications out there that can’t afford to catch up. Not because nobody cares about them, but because the budget math never worked out. Low-usage internal tools. Legacy customer portals that still function but haven’t been touched in years. Apps where the upgrade estimate came back at 100 hours and the business just… couldn’t justify it.

So they sit. Aging. Accumulating CVEs. Everyone knows they should do something, but the cost of doing it right keeps pushing it to the bottom of the backlog.

But the economics of which apps are worth maintaining are shifting fast, and it’s worth paying attention before you write off another one.

A 100-hour Rails upgrade took 10 hours

I recently ran into exactly this situation. There was an app stuck on Rails 4. The manual upgrade estimate to get to Rails 7 or 8 was around 100 hours. That’s a few weeks of developer time for an app that doesn’t generate enough activity to warrant that investment on its own right now. The honest answer was probably: this app is on borrowed time.

Before writing the app off, I wanted to put a hypothesis to the test. We’ve been working with AI coding agents on client projects for most of this year, and I had a working theory about how they’d handle the kind of grinding, version-bump-heavy labor that makes manual upgrades so expensive. So we set one on the upgrade to see whether the pattern would hold against a real legacy codebase.

Even with calibrated expectations, the result was striking.

The AI gave us bad advice, but still cut the estimate by 90%

The AI wasn’t perfect. It gave us bad advice, insisting certain changes were mandatory when they were actually optional. Some of the “upgrades” it recommended we were able to postpone without any issues. It took some judgment to separate the real blockers from the overcautious suggestions.

But here’s the thing: even with the false starts and the course corrections, we got the app upgraded from Rails 4 to Rails 8.1 and deployed to a staging environment for QA in about 10 hours. Not 100. Ten.

An order of magnitude difference. The kind of difference that turns an impossible business case into a straightforward one.

There’s a fourth option beyond accept, invest, or sunset: apply leverage

This isn’t just about Rails. It’s about a broader shift in what’s economically feasible.

For years, the calculus of software stewardship was pretty brutal. If an app wasn’t generating enough value to justify its maintenance budget, the options were limited: accept the risk, invest the money, or sunset it. Many teams chose “accept the risk” and hoped nothing happened.

Now there’s a fourth option: apply leverage.

The apps that didn’t have enough budget to stay alive suddenly might. The projects that got shelved because the ROI didn’t pencil out might be worth revisiting. The upgrade that was a non-starter last year might be a two-day project today.

Agents compress the tedious work. The pattern matters more than the tool

Two things, really:

AI coding agents are genuinely useful for this kind of work. They’re not replacing engineers; they still need guidance, review, and course correction. But they compress the tedious parts of an upgrade dramatically. Dependency resolution, deprecated API calls, version-specific migrations are grunt work that an agent can chew through while a human focuses on the judgment calls.

The pattern matters more than the tool. Whether it’s Claude Code, Codex, or whatever comes next, the real insight is that large, scary, estimation-heavy tasks can be broken down and delegated in ways that weren’t possible before. You build intuition for where they help and where they don’t. You adjust when the agent gives bad advice. You iterate. And the total human time drops substantially.

The question shifts from “can we afford it?” to “have we tried an agent first?”

I don’t think this means every team should just set an AI agent loose on their oldest, scariest codebase and hope for the best. Responsible stewardship still means QA, staging environments, and human judgment. Our app went through manual review, and then staging for testing before production, and that’s the right way to do it.

But it does mean the conversation is changing. The question is no longer just “can we afford to upgrade this?” It’s also “have we checked what an agent can do with it first?”

Apps that were living on borrowed time might get a reprieve. Ideas that were shelved for budget reasons might deserve another look. And the engineers who would have spent two weeks on a Rails upgrade can spend those two weeks building something new instead.

That’s the real shift. It’s not just about doing the same work faster. It’s about changing the answer to the question of which work is worth doing at all.

If you’ve got an app that’s been sitting on the maybe-someday list, we’d love to talk about whether an agent could change the math.