What happens when rebuilding decades of software becomes cheaper than maintaining it?
In short
- For decades we assumed existing software is too expensive to rewrite. AI is changing the economics of understanding, reproducing, and transforming it.
- The limiting factor shifts from writing code to establishing, verifying, and approving correct behavior.
- The most valuable artifact becomes an executable understanding of the business, with code as a replaceable implementation of it.
- Rebuilding the same mess faster is the trap: a rebuild must separate essential behavior, accidental complexity, and unknown behavior.
- Cheaper building also makes selected SaaS optional, which calls for small, accountable teams that own business capabilities rather than codebases.
For most of the history of software engineering, we have operated under one fundamental assumption: existing software is too expensive to rewrite.
We build on top of it. We patch it. We wrap it in APIs. We create abstractions to hide its complexity. We migrate small pieces when absolutely necessary. And over decades, we accumulate enormous amounts of technical debt.
Some of the world’s most important systems still run on software designed and written generations ago. Banks, insurance companies, airlines, governments, healthcare organizations, and countless enterprises depend on architectures whose original creators may have retired long ago.
The software works. Or at least, it works well enough. And rewriting it has historically been considered one of the riskiest things an engineering organization could attempt.
What if that assumption is about to become obsolete?
I think we might be entering a remarkable new chapter in software engineering: the era of the total software rebuild.
Not because every old system is broken. Not because modern programming languages are inherently better. But because AI is fundamentally changing the economics of understanding, reproducing, and transforming existing software.
The Software We Could Never Afford to Rewrite
Consider a large bank running core financial operations on COBOL.
Over decades, its software has accumulated millions of lines of code, thousands of business rules, integrations with countless other systems, and assumptions about behavior that may not be documented anywhere.
Some of those rules are intentional. Others are historical accidents that became permanent requirements.
The original engineers are gone. Documentation is incomplete. The system has become its own source of truth.
For an engineering organization, replacing it introduces a terrifying question:
How do we guarantee that the new system behaves exactly as the old one did, including all the edge cases nobody remembers?
Traditionally, answering that question required enormous human effort. Entire teams spent years reverse-engineering systems, documenting behavior, recreating functionality, testing implementations, and carefully migrating customers and data.
The economics usually favored keeping the old software running. And so the technical debt stayed.
AI Changes the Equation
Now imagine a different approach.
Instead of asking engineers to manually understand every part of a legacy system, autonomous agents begin by systematically examining the existing software. They analyze source code, dependency graphs, data schemas, interfaces, historical changes, operational behavior, logs, and test results.
They reconstruct the system’s effective specification. They identify business rules, undocumented assumptions, and opportunities to simplify.
Then other agents use that specification to implement a modern replacement. Additional agents generate tests, compare old and new behavior, discover discrepancies, and iterate.
What previously required years of sequential human investigation could increasingly become a massively parallel process.
This doesn’t mean the transformation becomes automatic or risk-free. Understanding business semantics, preserving data integrity, handling concurrency, and proving correctness remain extraordinarily difficult.
But it does suggest something profound:
The cost of understanding an existing software system may begin approaching the cost of asking AI to understand it.
And the cost of implementing a replacement may become a relatively small part of the overall modernization effort.
The limiting factor shifts from how quickly engineers can write code to how effectively the organization can establish, verify, and approve correct behavior.
From Technical Debt to Rebuild Economics
We have traditionally treated technical debt as something to manage indefinitely. A certain amount of debt was unavoidable. Paying it down was expensive, and the business often had more immediate priorities.
But AI changes the financial calculation. Consider a simplified decision:
The second option may become cheaper every year. At some point, the rational decision flips.
Technical debt that once made economic sense to preserve becomes economically irrational to keep.
And when this happens across thousands of companies, we’re no longer discussing individual modernization projects. We’re discussing an industry-wide software reconstruction cycle.
Modernization Becomes a Competitive Necessity
There is a second force that I think may be even more important than the falling cost of rebuilding.
The cost of not rebuilding is also increasing.
Imagine two insurance companies. One continues operating a complex legacy platform, adding AI capabilities through layers of integration and manually maintained workflows. The other reconstructs its core platform around explicit business rules, accessible data, automated verification, well-defined interfaces, and processes designed to be operated by both people and agents.
Both companies may offer similar products today. But their ability to evolve could become dramatically different.
The second company can potentially introduce products faster, automate operational processes more deeply, experiment with new business models, and continuously adapt its software. Its engineering organization no longer spends the same proportion of its capacity working around historical limitations.
Over time, that advantage compounds.
This is why I suspect rewriting legacy systems may shift from an optional technology investment to a strategic competitive necessity.
Not every company will need to rebuild everything. Some systems are already reliable, efficient, and well suited to their purpose. But every company may need to reconsider the economic justification for keeping what it has.
The question changes from “Can we afford to rebuild?” to “Can we afford not to?”
The Most Important Artifact Is No Longer the Code
There is an interesting connection to how I think about the future of the AI-powered software development lifecycle.
Historically, source code was the most valuable artifact because it represented the enormous effort required to implement business behavior.
But if implementation becomes relatively cheap, the value moves elsewhere:
- Toward the specification of what the software is supposed to do.
- Toward the business rules.
- Toward the data contracts.
- Toward the guarantees about correctness, security, availability, and performance.
- Toward the tests and evidence that demonstrate those guarantees.
This raises an intriguing possibility.
Instead of migrating legacy code directly into modern code, perhaps we should first migrate it into an executable understanding of the business: a continuously maintained specification that captures what the system does, what it must preserve, and what can be changed.
Once that exists, the implementation becomes increasingly replaceable. A modern engineering organization could regenerate or reconstruct components as technology evolves, without repeatedly rediscovering decades of business logic.
Code becomes an implementation of the knowledge, rather than the primary place where knowledge lives.
That is a much more fundamental change than translating one programming language into another.
The Software Factory Meets the Legacy World
A large-scale rebuild is especially interesting when viewed through the lens of autonomous software factories.
Consider a network of agents responsible for different aspects of modernization:
- Agents discovering business behavior and dependencies.
- Agents producing and maintaining specifications.
- Agents implementing replacement components.
- Agents creating deterministic and property-based tests.
- Agents comparing production behavior between legacy and replacement systems.
- Agents investigating divergences and generating corrective changes.
- Agents preparing deployment plans, migration evidence, and rollback procedures.
These agents could operate continuously. Not just for individual tasks, but across a coordinated modernization portfolio.
An insurance company might have hundreds of applications undergoing analysis and reconstruction simultaneously. Its engineers would increasingly focus on architecture, prioritization, business interpretation, risk, and acceptance criteria.
A major bottleneck would no longer be the organization’s capacity to type new code. It would be its ability to determine which changes are correct, valuable, and safe enough to deploy.
This connects directly to my earlier thinking about optimizing engineering teams with autonomous AI teammates and the importance of strong feedback loops in an AI-powered software factory.
When implementation accelerates, feedback and verification become even more important.
The Trap: Rebuilding the Same Mess Faster
There is, however, an important danger in this vision.
If we simply ask AI to rewrite millions of lines of COBOL into millions of lines of Java, we might accomplish very little. We could reproduce decades of unnecessary complexity on a newer technology stack. The result would be modern syntax with legacy architecture.
A successful rebuild must distinguish between three very different things:
- Essential behavior: What the business and customers actually depend on.
- Accidental complexity: Historical implementation decisions that no longer serve a purpose.
- Unknown behavior: Things the existing system does that nobody has fully understood or validated yet.
AI can help discover and classify these differences. But organizations still need judgment to decide what must be preserved.
Sometimes the right outcome is exact behavioral compatibility. Sometimes it is a redesigned business process. And sometimes the best modernization decision is not to rebuild a feature at all.
In regulated industries, this distinction is crucial. A system cannot simply be declared correct because its replacement passes generated tests. Independent validation, auditability, financial reconciliation, resilience, and careful rollout remain essential.
Perhaps the greatest opportunity isn’t merely rebuilding the software faster. It’s finally being able to question the assumptions that previous generations never had the economic freedom to revisit.
A New Kind of Engineering Organization
If this thesis plays out, I expect the implications for engineering leadership to be substantial.
Imagine a company with twenty years of accumulated internal software. Today, much of its engineering capacity may be dedicated to maintaining existing behavior, addressing incidents, navigating dependencies, and incrementally improving systems.
Tomorrow, the organization might have the capability to recreate large parts of its software estate with comparatively little implementation effort.
What does an engineering leader optimize for in that world? Not simply the size of the engineering team. Not lines of code. Not even the number of features delivered.
Instead, the critical competencies may become:
Understanding the business. Capturing what matters and separating genuine requirements from historical accidents.
Establishing trustworthy context. Giving agents accurate access to system knowledge, operational behavior, and architectural intent.
Building strong verification systems. Making it possible to distinguish a convincing implementation from a correct one.
Coordinating parallel execution. Allowing many autonomous agents to work across large portfolios without losing architectural coherence.
Managing the rate of safe change. Increasing the organization’s capacity to adopt improvements, not merely generate them.
This could produce an interesting paradox. As writing software becomes easier, the importance of engineering leadership may shift toward deciding what software should exist at all.
What Happens to Software Companies?
There is another implication worth exploring.
If software becomes dramatically cheaper to reconstruct, some of the economic advantages of existing software vendors may weaken. A vendor whose differentiation comes primarily from having spent twenty years implementing complicated workflows may find that customers can reproduce portions of that functionality far more cheaply.
That does not mean established software businesses disappear. Distribution, trust, customer relationships, proprietary data, compliance, operational reliability, and network effects remain valuable. But accumulated implementation effort may become a weaker competitive moat.
We could see businesses increasingly ask whether they should keep purchasing and extending aging platforms, or build systems tailored to their needs using autonomous software development.
The same economic forces that make legacy modernization attractive could reshape the market for enterprise software itself.
And perhaps that is the biggest irony of the coming rebuild. The companies selling software modernization may also need to modernize their own products and business models.
The Return of Custom Software: When SaaS Becomes Optional
For the past two decades, the default advice to enterprises was simple: buy before you build.
Why maintain your own CRM, workflow engine, reporting dashboard, or internal approval system when a SaaS vendor can spread development and maintenance costs across thousands of customers?
That logic was sound when building even a modest application required a substantial team and a permanent maintenance commitment.
But what happens when a small team equipped with agents can build a useful, company-specific application in weeks, and continuously evolve it at a fraction of the historical implementation cost? The buy-versus-build equation changes.
Imagine a company paying for an elaborate SaaS workflow platform, while using only a fraction of its capabilities. Employees spend hours accommodating the vendor’s process model. Data is replicated into yet another system. Critical workflows live in brittle integrations and awkward configuration layers. Every new requirement becomes a negotiation with the product’s limitations.
Now imagine the alternative: a focused application that supports exactly how the company works, uses its internal data model, integrates naturally with existing services, and evolves alongside its operating processes.
It doesn’t need to compete with a general-purpose SaaS product across hundreds of features. It only needs to solve this company’s problem better.
That distinction matters. The economic advantage of SaaS has always been the ability to amortize software development across customers. AI may reduce the amount of development effort that needs amortizing in the first place.
We may see companies selectively insource software that they previously outsourced to SaaS vendors, especially internal tools, niche workflow systems, reporting applications, and differentiated operational processes.
Not every SaaS category is a good candidate. Identity systems, payment infrastructure, payroll, security-critical tooling, and highly regulated platforms often carry compliance, availability, ecosystem, and operational burdens that are easy to underestimate. Vendors also provide ongoing research, upgrades, support, and accumulated expertise.
The useful question is not, “Can an agent clone this product?”
It is, “Can we own the complete lifecycle of the narrow capability we actually need, with better economics and less risk than renting it?”
The total cost includes on-call ownership, data migrations, security reviews, observability, disaster recovery, compliance, vendor integrations, and the possibility that the original builders move on.
Still, even a selective shift would be significant. SaaS pricing power could come under pressure precisely where customers pay for broad standardized platforms but need only a small, specialized slice of functionality.
And the biggest opportunity may not be cost savings. It may be the ability to shape software around the business rather than repeatedly reshaping the business around software.
The Teams That Will Build and Own the New Internal Software
If companies begin rebuilding legacy systems and replacing selected SaaS capabilities, they will need something more durable than a temporary migration task force. They will need organizations that can continuously create, operate, and replace their own software.
I imagine small, highly capable groups responsible for portfolios of business capabilities rather than a collection of long-lived codebases. A team might own customer onboarding, underwriting operations, claims processing, revenue workflows, or internal knowledge management.
Its mission wouldn’t be to keep a particular application alive forever. Its mission would be to ensure the business capability remains effective, reliable, secure, and economical, regardless of how often the underlying software is rebuilt.
Several roles could become more important, even if their eventual titles look different:
- Business capability owner. Defines the outcomes, economics, and business decisions the software must support. Makes explicit which workflows deserve custom treatment and which should remain purchased services.
- Specification and context engineer. Turns business knowledge, operational history, rules, data contracts, and policies into reliable context and executable specifications that agents can use.
- Agentic software factory engineer. Designs the agent workflows that analyze, implement, test, and evolve systems, with clear boundaries and traceable changes.
- Verification and assurance engineer. Builds independent tests, behavioral comparisons, security checks, audit evidence, and controlled rollout mechanisms; makes correctness measurable rather than assumed.
- Software portfolio architect. Maintains coherence across shared interfaces, identity, data, infrastructure, and governance so that hundreds of bespoke applications don’t become the next generation of fragmented legacy systems.
These are responsibilities, not necessarily five new job titles per team. In a small organization, several can belong to the same person; in a regulated enterprise, some will require independent review.
The team itself might be surprisingly small. A handful of engineers and domain specialists, supported by multiple autonomous agents, could maintain and evolve a portfolio that historically required much larger delivery teams. That is a possibility, not a guaranteed staffing ratio: operational complexity and risk do not scale down at the same rate as code generation.
The emerging operating model might look something like this:
Business owner defines the intent → context and specifications capture the rules → agents propose and implement changes → independent verification establishes evidence → humans authorize consequential changes → the team operates and continuously improves the capability.
Crucially, each internal application must have an accountable owner. An abandoned custom tool is still technical debt, even if AI made it cheap to build.
And there is a larger organizational challenge: if every department creates its own AI-generated software independently, companies may recreate the worst parts of the old enterprise IT landscape (duplicated systems, inconsistent data, and unclear responsibility) at unprecedented speed.
That suggests a balance between decentralized creation and centralized guardrails: shared identity, data contracts, security controls, observability, approval processes, and agent infrastructure, with business-aligned teams free to build what makes their workflows distinctive.
Instead of measuring engineering organizations by the amount of software they produce, we may increasingly measure them by the business capabilities they can safely own and continuously reinvent.
In a world where implementation is cheap, ownership, judgment, and trust become the scarce resources.
The Great Rebuild Won’t Happen Overnight
I don’t expect banks to replace their core systems in a weekend. Nor do I expect autonomous agents to safely reconstruct every critical application without extensive human involvement.
The hardest aspects of modernization are often not about writing code. They’re about discovering the truth, moving data, managing organizational dependencies, ensuring operational continuity, and proving that the new system is trustworthy. Those challenges don’t disappear just because code generation gets cheaper.
Still, the direction matters:
- A project that was economically impossible yesterday may become plausible tomorrow.
- A project that required five years may eventually require months.
- A portfolio that previously had to be modernized sequentially may become amenable to parallel transformation.
We don’t need fully autonomous software engineering for the consequences to be enormous. We only need enough improvement to change the economics.
A Civilization Running on Software Ready to Be Reconsidered
For decades, we have built software as though every major implementation were a permanent structure. We treated our systems like buildings: expensive to construct, difficult to modify, and expected to remain standing for generations.
AI may change that metaphor. Software could become something closer to a renewable implementation of a continuously evolving specification.
We preserve the business knowledge, behavior, and guarantees. We rebuild the implementation when it makes sense. And we do so repeatedly, rather than carrying every historical decision into the future.
If that becomes possible at scale, the implications are enormous. Not only for banks running COBOL, insurers managing decades-old policy systems, or governments operating aging infrastructure, but for nearly every company that has ever accumulated software.
The next great wave of software engineering may not be about writing the world’s next generation of applications.
It may be about rebuilding the world’s existing applications and, in the process, reconsidering what those applications should have been all along.