Software Reengineering in the AI Era

One of our clients, AMC Theatres, had a mobile app built in Xamarin that had been limping along for years. A small group of engineers rebuilt it in Flutter, mostly on nights and weekends, and shipped it in a few months. The original estimate to do that kind of rebuild had been closer to three years.

That story sounds like it’s about the code. It isn’t.

The rebuild went fast because the team knew the app, knew the users, and agreed on what the new version had to do. The hard part of any rebuild was already handled before they wrote a line of Flutter. That judgment, knowing what to build and why, is exactly what the developer-vs-engineer distinction was always really about. That’s the part I want to talk about, because AI is about to change one half of software reengineering completely and leave the other half exactly as painful as it has always been.

The code was never the part that killed these projects. It still isn’t.

What software reengineering actually is

Software reengineering is the process of taking an existing system and rebuilding it into something better without throwing away what it already does. You keep the business logic that works, and you modernize the parts that don’t: the old framework, the slow database, the architecture that can’t scale, the code nobody on the current team understands anymore.

People mix it up with refactoring, so it’s worth drawing the line. Refactoring cleans up code without changing what the software does from the outside. Reengineering can change the behavior, the stack, and the architecture all at once. Refactoring is tidying a room. Reengineering is gutting it to the studs and rebuilding.

The classic version of software reengineering in software engineering has three steps. You reverse engineer the old system to figure out what it actually does, you restructure it into something cleaner, and you forward engineer it into the new version. For decades, that first step was the expensive one. Somebody had to read thousands of lines of undocumented code and reconstruct what the original team was thinking.

That’s the step AI just ate.

The half of software reengineering AI just made easy

Reading old code used to be the worst job in engineering. You’d inherit a fifteen-year-old codebase with no docs, no original authors, and comments that lied. Now you can point an AI model at that codebase and get a readable explanation of what each piece does in minutes.

This isn’t a someday thing. Gartner projects that 40% of legacy modernization projects will use AI-assisted reverse engineering this year, up from under 10% a few years ago. Fujitsu shipped a tool that reads source code and writes the design documents automatically, and claims it cuts that work by around 97%. The grunt work of reengineering is collapsing.

Here’s what AI genuinely does well right now:

• Reading and documenting legacy code. It explains what undocumented functions do and maps how the pieces connect, which is the part that used to take weeks of detective work.
• Refactoring and migration. Moving from an old framework to a new one, or one language to another, is exactly the kind of pattern-heavy work AI handles fast.
• Generating tests. You can build a safety net of tests around the old system before you touch it, so you know when you’ve broken something.
• Finding the risks. Security holes, dead code, slow queries, the stuff a human audit would eventually catch, surfaced in a fraction of the time.

I built the pre-AI version of this at Stackify, where we made tools to help developers find and fix bugs in production. It took real engineering to give people that kind of visibility into a running system. Now a lot of it is a prompt away. That’s a genuinely good thing, and any team doing reengineering today that isn’t using these tools is leaving huge amounts of time on the table.

But here’s the line I keep coming back to, and it’s as true now as when I wrote it: AI is a powerful tool that can boost productivity, but relying on it to generate code nobody understands just creates tomorrow’s technical debt today. The hard part of software development isn’t writing code. It’s understanding the problem you’re trying to solve.

The half AI can’t touch

Now for the part the SonarQube-and-Copilot crowd doesn’t put on the slide.

The reason software reengineering projects fail has almost nothing to do with the code. It’s the rollout. It’s getting a room full of stakeholders to agree on what the new system should even do. It’s convincing the people who run the business on the old system to give up the workarounds they’ve spent a decade building.

You can write perfect code and still fail completely, because the system you’re replacing isn’t just software. It’s how people do their jobs.

The numbers back this up. Large system replacements, like ERP projects, fail somewhere between 55% and 75% of the time. And when you look at why, it’s rarely the engineering. Prosci’s research found that on average only about a quarter of employees actually use the new system their company spent millions to build, and that strong change management is the single biggest predictor of whether one of these projects hits its goals. The software wasn’t the problem. The people side was.

Every legacy system has a whole human world built around it. There are workarounds people rely on, tribal knowledge nobody wrote down, and jobs that exist only because the old system works the way it does. Replace the technology without dealing with that world, and people quietly reject the new thing and keep using the old one. AI can read the codebase. It cannot read the office.

I learned this the expensive way at Stackify. We had a solid roadmap and we shipped constantly, but one launch we spent $10,000 sponsoring a developer conference for, and we got zero new customers. The code was fine. We just hadn’t figured out what people actually wanted.

At VinSolutions it was a slower version of the same lesson. As we grew, customer feedback got filtered through a support person, then a couple more layers, until there were four people between me and the customer and I only really talked to users at trade shows. The further I got from the people using the software, the easier it became to build the wrong thing well.

There’s a useful way to think about why these rollouts stall. In Product Driven, I lay out the common shapes organizational resistance takes: the leadership void where nobody owns the change, the one loud person who blocks everything, individual resistance from people protecting their turf, process bloat that smothers momentum, and plain cultural drag. None of those are engineering problems. You can’t prompt your way out of any of them.

Resistance isn’t dysfunction. It’s feedback from your culture, your roles, and your systems telling you what needs to change.

Cheaper to build makes the change problem worse

Here’s the trap. When the building gets cheap, more teams decide to rebuild. That sounds great until you remember that the building was never the bottleneck.

AI lowers the cost and the apparent risk of a rebuild, so the bar for saying “let’s just reengineer the whole thing” drops. More projects get greenlit. But the rollout is just as hard as it ever was, the stakeholder alignment is just as messy, and the change management still gets underfunded. So you end up with more reengineering projects hitting the same wall, just faster and at higher volume.

The teams that win in this era won’t be the ones that generate code the fastest. They’ll be the ones that still take the human side seriously when the tooling makes it tempting to skip. Shipping isn’t the goal, change is. If nothing got better for the people using the software, the work isn’t done.

When reengineering is the right call

Not every old system is worth reengineering, and not every one should be rebuilt from scratch. The decision usually comes down to how much real business value is still locked inside the current system versus how much it’s costing you to keep it running.

	Reengineer the system	Rebuild from scratch
Best when	The core logic still works and is worth keeping	The system is past saving or the business has fundamentally changed
Risk	Lower, you keep proven behavior	Higher, you reintroduce solved bugs
Speed	Faster, you modernize in place	Slower, you start at zero
What you keep	Years of hard-won edge cases	Almost nothing

A few signals it’s time to reengineer rather than limp along:

• Nobody on the current team understands how big parts of the system work, and the people who did have left.
• Technical debt has piled up to the point where small changes take weeks and break things in places you didn’t touch.
• The old framework, language, or database is out of support, and security or hiring is getting harder because of it.
• Performance or scale has hit a wall that the current architecture can’t get past.

If you see two or three of these at once, the system is already costing you more than a reengineering project would. The question isn’t whether to act, it’s how to do it without blowing up the rollout.

How to actually do software reengineering in the AI era

The right model is simple to say and hard to do: let AI handle the reading and the drafting, and keep senior engineers and humans on everything that involves judgment and people.

That means AI reverse engineers the old system, documents it, and proposes the refactors. Senior engineers decide which of those proposals are right, own the architecture, and validate that the new system actually behaves. And somebody, a real human with authority, owns the rollout: the stakeholder conversations, the requirements fights, the training, the slow work of getting people to trust the new thing. The industry has a name for this now, human-in-the-loop, but it’s really just the same truth dressed up: the tools got better, the judgment still has to come from people who’ve done this before.

This is why the work suits a dedicated team rather than a quick project shop or a freelancer who vanishes mid-sprint. A reengineering project lives or dies over months of rollout and adjustment, not in a single sprint of code generation. You want engineers who stick around, learn your business, and sit in the hard meetings. Plenty of well-known companies have run rebuilds this way, and I collected the best offshoring examples, wins and failures both, in a separate post.

At Full Scale, the senior engineers we place in the Philippines join your standups and your roadmap and stay for the long haul, which is the part of the model that actually matters when the hard work is change, not code. It’s also one of the bigger benefits of staff augmentation over a hand-off project shop, and it’s why we keep 93% developer retention: the same people see the project through.

And the cost math is friendlier than most teams expect. A senior US developer runs to a median base around $133,000, and once you add benefits, taxes, equipment, and overhead at the usual 1.25 to 1.4 multiplier, the real cost lands well north of that. A senior engineer in the Philippines does the same work for a fraction of it. That gap is what lets you fund the part of reengineering that AI won’t do for you, the change management, the training, the patient rollout.

Reengineering works the same way. The new system only earns its keep when people actually use it.

The bottom line

AI has made the code half of software reengineering faster than I would have believed a few years ago. Use it. But don’t confuse a cheaper rebuild with an easier one. The hard part was always the people, the politics, and the rollout, and that part is still yours to figure out.

The code was never the hard part. It still isn’t.

Talk to us about your reengineering project and we’ll help you figure out what to keep, what to modernize, and how to actually roll it out.