AIArticle AI-assisted coding is flipping the cost-benefit math on when to rewrite legacy systems instead of patching them.
[Priya Nair](https://sourcefeed.dev/u/priya_nair)
For decades, the standard advice for software engineering teams has been simple: never rewrite a system from scratch. It was a rational response to a specific economic reality. Human cognitive bandwidth was the primary constraint, and changing direction late in a project was orders of magnitude more expensive than patching what already existed.
Generative AI is dismantling that economic logic. When the cost of generating code drops toward zero, the calculation of whether to maintain a legacy system or throw it away and start over changes completely. We are entering an era where maintaining an inconsistent, bespoke codebase carries a heavy tax, and the ground-up rewrite is becoming a viable, even preferred, engineering strategy.
The Prompt-Cost Rework Threshold #
Historically, software development followed a linear path. You wrote a specification, designed the architecture, wrote the code, and eventually ran a demo. If you realized mid-way that the architecture was wrong, the cost of rework was prohibitive.
Today, we are seeing the emergence of what can be called the prompt-cost rework threshold. This is the point at which generating a brand-new solution from scratch becomes cheaper than maintaining or modifying an existing one. When an AI agent can produce a working prototype in seconds, code becomes disposable.
This shift is already visible at scale. AWS used AI to modernize 40 million lines of COBOL for Toyota. Anthropic recently built a 100,000-line C compiler using parallel AI agents in just two weeks, costing under $20,000. The compiler successfully boots Linux and compiles PostgreSQL, SQLite, Redis, and Lua.
When a functional compiler can be generated for the price of a modest developer workstation, the traditional arguments against rewrites begin to fall apart. The question is no longer whether you can afford to rewrite, but whether you can afford the ongoing tax of your legacy code.
The Context Window Tax on Legacy Code #
Why does legacy code cost so much in an AI-driven workflow? It comes down to how Large Language Models (LLMs) process information.
An LLM does not just generate code based on a prompt. Its output quality is heavily dependent on the context you feed it. For coding tasks, that context is your existing codebase.
Popular, standardized tech stacks have a massive AI advantage. The models have already seen millions of examples of idiomatic Python or Rust in their training data. They understand the patterns implicitly.
When you ask an AI to work on a codebase with proprietary frameworks, inconsistent patterns, and historical baggage, the workflow degrades:
- The model must ingest the inconsistent codebase and try to infer its custom patterns.
- It must read additional, often outdated documentation to understand the legacy language.
- It spends its limited context window and processing power trying to learn your specific way of doing things before it can even begin to solve the actual problem.
This is the context window tax. More context means more tokens, higher latency, more prompting overhead, and a higher rate of hallucinations.
A rewrite is no longer just about modernizing your stack for human developers. It is about rebuilding your codebase around clean, consistent, industry-standard patterns that play to the strengths of LLMs. By aligning your codebase with what the models already know, you lower the cognitive load on both your human engineers and your AI assistants.
The Verification Bottleneck #
If generating code is cheap, verifying it is not. This is the primary caveat of the AI-driven rewrite. When Google and Microsoft report that 25% to 30% of their new code is AI-generated, it sounds like a massive win. But as Chris Lattner, the creator of LLVM, has pointed out, AI amplifies both good and bad structure. Bad code generated at AI speed quickly becomes an incomprehensible nightmare.
We are already seeing a widening verification gap. Engineers, lulled by the speed of generation, fall into what Andrej Karpathy described as an "Accept All" workflow, where they stop closely reviewing diffs. Yet, nearly half of AI-generated code fails basic security tests, and larger models have not shown significant improvements in generating secure code out of the box.
Consider the scale of the risk. A single bug like Heartbleed in OpenSSL can escape human review for years and cost millions to fix. Now, multiply that generation rate by a thousand. If we do not scale our verification methods alongside our generation methods, we are simply building faster paths to systemic failure.
This is why the economics of rewrites must include formal verification. Testing and fuzzing provide confidence, but mathematical proof provides a guarantee. If AI can make generating formal specifications and proofs cheap, we can verify low-level properties, like ensuring a cryptographic library executes in constant time to prevent side-channel attacks. Without these guardrails, continuous generation is a liability.
The Legal Minefield of the AI Clean Room #
There is also a legal and ethical hurdle to the AI rewrite, as demonstrated by a recent controversy in the open-source community.
Developer Dan Blanchard recently released version 7.0 of chardet
, a popular Python character detection library. The original library was written in 2006 under the LGPL license, which restricts how the code can be reused in closed-source projects. Blanchard wanted to relicense the project under the more permissive MIT license to get it included in the Python standard library.
Using Claude Code, Blanchard completed a ground-up rewrite of the library in five days, achieving a 48x performance boost. To ensure it was a clean break, he started with an empty repository and explicitly instructed the AI not to base its work on the original LGPL code. JPlag similarity analysis showed that less than 1.3% of the new code was structurally similar to the old version, compared to an 80% similarity between previous human-written versions. Despite this, the original author, Mark Pilgrim, and the Free Software Foundation objected. They argued that because Blanchard had extensive exposure to the original codebase, and because the LLM itself had likely ingested the LGPL code during training, the rewrite was not a true "clean room" implementation.
This highlights a major risk for enterprise teams. If you use AI to rewrite a proprietary or copyleft system, you cannot easily prove that the model did not reproduce copyrighted patterns it ingested during training. The legal definition of a derivative work is being stretched to its breaking point by these tools.
The Pragmatic Path Forward #
For engineering leaders, the decision matrix has shifted. The old rule of avoiding rewrites at all costs is dead. But the new rule is not to rewrite everything blindly.
If you are dealing with a legacy system that is holding back developer velocity, a rewrite using standardized, modern stacks is now economically viable. However, you must shift your budget and time from writing code to verifying it.
Set up strict testing, property-based fuzzing, and, where possible, formal verification pipelines. Treat the AI as an untrusted junior developer who writes code at lightning speed but has no concept of security or licensing boundaries. If you manage the verification bottleneck and the legal risks, the AI-assisted rewrite is the fastest way to escape legacy technical debt.
Sources & further reading #
[AI changes the economics of software rewrites](https://thetruthasiseeitnow.com/ai-slop-starts-with-the-codebase-itself/)— thetruthasiseeitnow.com -
[When AI Writes the World's Software, Who Verifies It? — Leonardo de Moura](https://leodemoura.github.io/blog/2026-2-28-when-ai-writes-the-worlds-software-who-verifies-it/)— leodemoura.github.io -
When rework only costs a prompt: Rethinking the economics of software development | CGI Canada— cgi.com - The Brutalist Report— brutalist.report - AI can rewrite open source code—but can it rewrite the license, too? - Ars Technica— arstechnica.com
Priya Nair· AI & Developer Experience Writer Priya covers AI frameworks, developer productivity tooling, and the startup ecosystem across South and Southeast Asia, bringing a researcher's rigour and a practitioner's empathy to every story. She is deeply sceptical of benchmarks and asks hard questions so her readers don't have to.
Discussion 0 #
No comments yet
Be the first to weigh in.