How AI Is Rewriting the Economics of Software Rewrites: Costs Plummet, But Risks Remain

Software Rewrites: Once a Forbidden Path

In software engineering, one piece of advice has long been considered gospel: never rewrite your code. This wisdom stems from Netscape's famous cautionary tale — the company spent years rewriting its browser engine and handed the market to Microsoft's IE in the process.

The Netscape Lesson: The Mozilla Project that Netscape launched in 1997 is one of the most notorious rewrite failures in software engineering history. Faced with a chaotic codebase, Netscape decided to rebuild the entire browser engine from scratch. This decision meant the company went nearly three years without shipping a competitive new version, allowing Microsoft's IE to crush Netscape's market share. Software engineer Joel Spolsky captured this lesson in his 2000 blog post Things You Should Never Do, Part I, calling a full rewrite "the single worst strategic mistake that any software company can make." The article remains one of the most widely cited pieces in software engineering to this day.

There's also a lesser-discussed psychological factor at play: what Frederick Brooks called the Second-System Effect in The Mythical Man-Month. When engineers build a second system, they tend to stuff in everything they wished they'd done the first time around, causing scope to balloon and complexity to spiral out of control. Netscape's engineers fell squarely into this trap — they weren't just trying to replicate existing features, they were simultaneously trying to build a brand-new, future-proof application platform. They ended up achieving neither goal on time.

The core logic of this warning is that existing codebases, however messy they look, contain countless fixed edge cases, bug patches, and business rules. This tacit knowledge is rarely documented — it lives in the code itself. Start over from scratch, and your team has to rediscover every one of those hard-won lessons at enormous cost in time and effort.

But with AI coding capabilities advancing at a remarkable pace, this long-standing rule is being challenged like never before. The economics of software rewrites are being fundamentally transformed.

Why Software Rewrites Were Once So Expensive

To understand what AI changes, we first need to break down where the costs in traditional rewrites actually come from. It's worth noting that the scale of this problem is larger than most people realize.

The Industry Scale of Technical Debt: The concept of "technical debt" was coined by software engineer Ward Cunningham in 1992 to describe the hidden costs that accumulate when teams take shortcuts to ship faster. According to a 2018 developer survey by Stripe, developers globally spend an average of 33% of their working time dealing with technical debt, costing an estimated $300 billion in lost productivity each year. Legacy systems — software built on outdated technology stacks that's hard to maintain but still runs core business functions — are especially prevalent in banking, insurance, and government, where critical systems written in languages like COBOL decades ago still process transactions daily. The risk and cost of rewriting them is so high that most organizations choose to maintain them indefinitely.

This is especially stark in U.S. government systems. The Social Security Administration still runs COBOL code written in the 1960s to process retirement payments for hundreds of millions of Americans. Parts of the IRS's core systems similarly rely on assembly language programs written decades ago. Globally, there are an estimated 200+ billion lines of COBOL still running in production, processing roughly $3 trillion in financial transactions every day. These systems can't simply be replaced — not just because migration costs are enormous, but because no person or document fully describes their complete behavior. Their logic can only be inferred through continuous observation. This is the most extreme expression of why "rewrite at your peril" became conventional wisdom.

Three Core Cost Drivers

First, comprehension costs. Developers must spend enormous amounts of time reading and understanding legacy code logic — especially in undocumented, poorly named, spaghetti-structured codebases. On a large historical project, just figuring out "what does this code actually do" can take weeks or months.

Second, translation costs. Re-implementing an old system's functionality in a new architecture, language, or framework requires manual, line-by-line and module-by-module work. It's pure labor-intensive effort.

Third, validation costs. Ensuring the new system behaves consistently with the old one — especially covering all the hidden edge cases — requires extensive test writing and regression verification.

These three costs stacked together meant that code rewrites were almost always a losing proposition in the past: enormous investment, sky-high risk, and hard-to-quantify returns.

How AI Is Reshaping the Cost Structure of Software Rewrites

AI's involvement delivers order-of-magnitude reductions at every one of these cost points.

Comprehension Costs Drop Dramatically

Modern large language models can rapidly read and explain tens of thousands of lines of code, generating a coherent overview of an unfamiliar codebase in minutes.

LLM Code Comprehension Capabilities: The core of modern AI coding tools is large language models (LLMs) pretrained on massive code corpora — OpenAI Codex powering GitHub Copilot, Anthropic's Claude, and Google's Gemini series. These models have learned cross-language syntax patterns, API calling conventions, and common algorithm structures from billions of lines of open-source code. At the comprehension level, LLMs can ingest tens of thousands of lines of code in a single context window and perform semantic-level logic analysis. By 2024, leading models have expanded their context windows to 100K or even 200K tokens, making holistic analysis of medium-sized codebases practical — something that was completely impossible just two years ago.

For extra-large codebases that exceed context window limits, a technique called RAG (Retrieval-Augmented Generation) is gaining traction in engineering practice: the entire codebase is pre-vectorized and stored, then the most relevant snippets are dynamically retrieved and injected into the context during analysis, effectively bypassing the window constraint. Next-generation AI coding IDEs like Cursor and Codeium use similar mechanisms to support analysis of enterprise-scale projects with millions of lines of code. At the architectural level, all of this is grounded in the Transformer model's attention mechanism — which allows the model to dynamically associate relevant information anywhere in the context when processing any given piece of code, rather than linearly and progressively forgetting it the way early RNN models did.

Developers no longer have to face obscure legacy systems alone. AI can act as an interpreter, rendering complex logic in clear natural language. Code archaeology work that once required weeks of effort from a senior engineer may now take only hours.

Translation Costs Approach Zero

This is where the change is most dramatic. AI coding tools excel at exactly this kind of pattern recognition and code generation: converting Python to Go, migrating a legacy jQuery frontend to React, or decomposing a monolith into microservices. These translation tasks — once requiring massive amounts of manual labor — can now be completed by AI in bulk and at speed.

Real-World Evidence and Its Limits: Several public cases support AI's real-world effectiveness in code migration. Amazon used an internal AI tool to migrate large volumes of Java 8 code to Java 17, claiming it saved thousands of developer hours. Some teams have used LLMs to decompose PHP monoliths into Python microservices, compressing migration timelines estimated at several months down to a few weeks. Amazon disclosed in a 2023 technical blog that the tool could automatically identify deprecated API calls, update dependency declarations, and optimize code for new language features during migration — work that previously required engineers to process file by file.

However, these success stories are consistently concentrated in modules with clear logical boundaries and good test coverage. A 2023 study from the University of Cambridge analyzed multiple AI code migration projects and found that when code's cyclomatic complexity exceeded 20, AI translation error rates rose sharply. When code relied on global state or had extensive cross-module side effects, AI tended to produce "superficially correct but semantically shifted" translations — a particularly dangerous class of error because it often passes unit tests but only surfaces in integration testing or production. For deeply coupled business logic, human review remains indispensable.

When the marginal cost of translation approaches zero, the overall economics of rewriting undergo a fundamental reversal.

Validation Efficiency Improves Significantly

AI can also help generate test cases and compare behavioral differences between old and new systems, helping teams more efficiently catch edge cases lurking in the corners. Validation remains the phase that demands the most care, but AI has significantly accelerated the process.

The Shift in Engineering Decision Logic

When rewrite costs fall dramatically, the scales of technical decision-making tip accordingly.

In the past, faced with a legacy system drowning in technical debt, the rational choice was almost always "patch and maintain" — because the cost of rewriting was prohibitive. Today, "rewrite" has re-emerged as an option worth serious consideration, with several notable implications:

• Technical debt handling changes. Rather than endlessly patching a decaying architecture, teams are more likely to use AI assistance to rapidly refactor or rewrite critical modules.
• Technology stack migration becomes viable. Switching from one language to another, upgrading from an old framework to a new one — these legacy migration projects, long shelved due to cost, now have a realistic path to completion.
• Architectural experimentation gets cheaper. Teams can be bolder in trying different approaches, because "starting over" no longer implies catastrophic investment.

The Case for Caution

AI has lowered the costs of translation and comprehension, but the problem of tacit knowledge hasn't fully disappeared.

"Dark Knowledge" in Code: Philosopher Michael Polanyi's concept of tacit knowledge has a profound parallel in software engineering: the accumulated business rules, historical bug fixes, and performance tunings embedded in a codebase are often hidden between lines of code in the form of missing comments and cryptic naming — sometimes forgotten even by the original authors. Software engineer Kevlin Henney calls this "dark knowledge in code." AI tools can recognize structural patterns in code, but they often lack awareness of the historical context behind "why was this written this way" — for example, a seemingly redundant conditional check might be a critical safeguard added ten years ago to handle abnormal data from a specific customer. If it gets "optimized away" during a rewrite, it will trigger hard-to-trace failures in production.

To address this challenge, the engineering community is developing a systematic practice called "Archaeological Debugging": before a rewrite, humans lead a systematic review of the codebase's git commit history, issue tracker records, internal wikis, and code comments to reconstruct the historical context of key decisions and form a "decision archaeology report" — which is then handed off to AI for translation and implementation. This human-AI collaborative model is considered capable of partially compensating for AI's limited awareness of historical context. Thoughtworks' Technology Radar in its 2024 edition listed this kind of AI-assisted archaeological rewrite approach as an emerging practice worth watching (Trial level), believing it has the potential to become a mainstream methodology for legacy system migration within the next two to three years.

The business logic and edge cases buried in old code — the ones even the original authors might not remember — aren't necessarily things AI can fully identify. If the original requirements were themselves ambiguous, AI-rewritten code might faithfully replicate existing defects, or introduce new, hard-to-detect problems.

Furthermore, validation remains the core bottleneck. Generating code is fast, but ensuring the new system is truly reliable in production still requires rigorous test coverage and human review. The core of Spolsky's original warning — those bug fixes "written in blood" — isn't something AI can conjure up for you from thin air.

The more cautious view, therefore, is this: AI changes the economics of software rewrites, not the risk profile. Lower costs move rewriting from "infeasible" to "worth considering" — but whether it's actually worth doing still requires careful judgment based on the specific project's complexity, business criticality, and team capabilities.

A New Equilibrium for Software Engineering

AI hasn't completely invalidated the old adage of "never rewrite your code," but it has pushed software engineering toward a new equilibrium.

In the past, a code rewrite was almost always the wrong choice. Today, it has become a genuine option that deserves serious consideration. For engineering teams, the key is identifying which scenarios are truly well-suited to AI-assisted rewrites — typically legacy systems with relatively clear logic, well-defined boundaries, outdated tech stacks, but high business value — while maintaining clear-eyed awareness of AI's limitations.

The economics of software rewrites are being rewritten. True engineering wisdom lies in knowing when to take advantage of this new economic reality, and when to hold fast to traditional caution.