Your Legacy Codebase Is Becoming an AI Productivity Tax

I've worked on two software products where rebuilding the existing codebase turned out to be the better decision.

At Doctify, the rewrite went live in just three days.

The complete rebuild and surrounding work took about two weeks.

At Zèya, we rebuilt the application and restructured the engineering team. Afterward, weekly commits increased from 40 to 200, and pull requests from 10 to 40.

Both experiences changed how I think about legacy software.

Historically, rebuilding a working system was considered a bad business decision. You'd spend months reproducing functionality you already had, without delivering much new value.

But AI has changed that calculation.

Rebuilding software is now significantly cheaper, while maintaining a codebase that coding agents struggle to understand introduces an entirely new productivity cost.

Two things have fundamentally changed in the AI era.

1. Badly written legacy systems limit what coding agents can contribute

If AI is one of your biggest competitive levers for software development, a legacy system that AI cannot effectively understand becomes a serious liability.

The way coding agents work is by reading the source code, making sense of it, and trying to understand the goal you are asking them to accomplish.

When you give an agent an initial prompt, the AI and IDE will typically search the repository for keywords, symbols, functions, and other pieces of code relevant to your request.

In a well written codebase, this search usually produces a relatively consistent set of information.

You find functions that do what their names suggest they do. Variables are named appropriately. There is little unnecessary duplication. Comments are relevant. Dead code is gone.

The AI gets something close to a single source of truth.

It can then interact with you based on a shared understanding of how the system works.

Now consider a badly written legacy system, of which there are almost infinitely many.

The same search might return:

• Duplicate code
• Poorly named functions
• Poorly named variables
• Old and stale comments
• Dead code that is no longer used
• Multiple implementations of what appears to be the same functionality
• Contradictory assumptions about how different parts of the system work

This is where AI becomes less reliable.

Not necessarily because the model itself is incapable, but because you have given it multiple conflicting answers to the same question.

You have effectively dirtied its context.

Think about it like working with a coworker who is trying to help you solve a problem, but every time you ask them what is happening, they respond:

"Maybe."

"Perhaps."

"I don't know."

"It could be A."

"Actually, it's B."

"Wait, no, it's C."

You cannot build reliable software with that coworker.

They become counterproductive rather than productive.

This is exactly what a badly written legacy system can do to coding agents.

It can completely undermine one of the biggest advantages of using AI in software development: speed.

2. Rebuilding the system is now dramatically cheaper

The second thing that has changed is the cost of the rebuild itself.

A rewrite used to mean putting a significant portion, if not all, of your engineering team on hold while they spent months rebuilding something that already existed.

Those engineers weren't building new revenue generating features. They weren't improving the product from the customer's perspective. They were reproducing functionality that the business already had.

That made rewrites extremely difficult to justify.

Today, the economics are different.

With the right understanding of the software's goals, AI can analyze the existing system, extract the important behavior and business logic, and help rebuild the codebase much faster.

You still need an authority figure who understands the system well enough to determine what is actually true and what isn't.

But instead of spending months manually navigating thousands of lines of legacy code, you can use AI to scan the system, identify its behavior, surface inconsistencies, and help reconstruct it into a much cleaner architecture.

The goal isn't simply to have a newer codebase.

The goal is to create a codebase that can support fast development for years to come.

If the old system prevents your team from effectively using coding agents, then the cost of keeping it may actually be higher than the cost of rebuilding it.

And this is where the ROI calculation changes.

You're no longer comparing:

"Spend money rewriting software that already works"

against

"Keep the software that already works."

You're comparing:

"Spend money rebuilding the system once"

against

"Continue paying the productivity tax of a system that prevents your engineers and AI agents from moving quickly."

That is a completely different calculation.

It isn't just me. Earlier this year, Bun moved its runtime from Zig to Rust in 11 days using about 64 Claude Code agents, work estimated at three engineers for a year. Checkly had an agent rewrite a Node service handling 92 million messages a day in Go overnight, and now runs 70% fewer pods.

Two examples from my own work

Here's what happened in those two projects.

Doctify

Doctify was an AI assistant designed to help doctors eliminate many of the repetitive tasks involved in documenting patient interactions. It used AI augmented transcription to create patient documents and maintain a useful record of patient progress.

When I first got my hands on the project, I tried my hardest to contribute to it using the best AI tools available at the time.

The agents struggled to contribute reliably.

The codebase had too many occurrences of dead code, multiple ways of implementing the same functionality, no proper architecture, multiple programming paradigms, and many god classes contained in extremely large files.

It was, in almost every way, a terrible environment for AI.

The agents repeatedly struggled to find reliable context for the changes I was asking them to make.

At that point, I had to make the difficult decision to start refactoring the entire codebase.

I cleaned up the badly implemented parts, removed dead code, established a more coherent architecture, and corrected the way the application was engineered so that it better served its actual purpose.

The rewrite was live in three days.

The complete rebuild and surrounding work took about two weeks.

And the impact wasn't just that the codebase was cleaner.

Before I joined, the team was producing around 6,000 lines of code per week. Their fastest stretch reached around 11,000 lines per week.

After the rebuild, I was producing around 14,000 lines per week.

More importantly, the rest of the team now had a codebase they could actually build on.

They were able to sell the product, demo it, and continue building features on top of it at a much higher speed.

That application is still running today, long after I stopped contributing to it.

Zèya

Zèya was another example of an application that needed to be rebuilt.

The initial version was built without the engineering foundations and technical direction the product needed.

The application was in such a bad state that it couldn't reliably fulfill its core functionality.

It crashed constantly.

When I joined, I had a similar feeling to what I experienced when I first started working on Doctify.

But this time, the decision was much faster and much clearer.

I already knew that the rebuild could be completed in a relatively short period of time and that it would benefit the product in the long term.

So that's what I did.

This time, I brought in three developers to join forces and execute the rebuild.

Clear technical communication also became a priority. When working with AI, conveying intent precisely is essential to getting reliable results from coding agents.

The rebuild this time was more than a code rewrite.

It became a continuous exchange between product people, advisors, leadership, and the development team I assembled.

We used the rebuild as an opportunity not only to improve the codebase, but also to rethink and improve the product itself.

The UX changes, product improvements, and suggestions we made to correct many of the pitfalls that prevented the application from properly serving its intended functionality led to multiple reassessments.

As a result, the rebuild stretched to around 90 days.

That's still an incredible timeframe considering how different the application is today compared to where it started.

But the most important part is what happened afterward.

After the rebuild and the team changes, our engineering activity increased significantly:

That's roughly 5× the commits, 5× the net lines, and 4× the pull requests.

The application now has more users than ever. Users are actively interacting with it and using it to swap goods, and the team is able to develop and ship at a completely different speed.

This is the part that matters.

The value of the rebuild wasn't that we had written more code.

The value was that we had created a foundation where a team working with AI could actually move fast.

The conclusion

In 2026, a poor technical foundation carries a much bigger productivity cost than it used to.

A bad codebase isn't just an engineering problem anymore.

It is a business problem.

If your software prevents your team from taking advantage of AI, you are not simply dealing with technical debt.

You are dealing with a productivity ceiling.

And that ceiling directly affects how quickly you can ship, how quickly you can respond to customers, how quickly you can experiment, and ultimately how quickly your company can move.

The economics have changed.

Rebuilding is cheaper.

AI makes the process faster.

And a clean codebase makes AI dramatically more useful.

So sometimes, the decision with the highest ROI isn't to keep fixing the system that already works.

Sometimes, the decision with the highest ROI is to rebuild the foundation entirely.

In 2026, your codebase isn't just infrastructure.

It is part of your company's ability to compete.