Software Has Entered Its Re-Image Era

The Old Rule Was Reasonable

For most of the software industry's history, rewriting a mature application from scratch was considered reckless.

There was a good reason.

Joel Spolsky's classic warning against rewrites argued that mature source code contains years of bug fixes, edge cases, and operational knowledge that replacement teams routinely underestimate. Old code often looks ugly because it has encountered reality. Replacing it means rediscovering those lessons while the existing product continues moving underneath the project. [1]

That warning remains valid.

A mature application is rarely just code. It contains undocumented customer expectations, strange integration behavior, forgotten exception paths, regulatory interpretations, operational workarounds, timing assumptions, data corrections, and business rules that apparently mattered enough to implement but not enough to document.

Throwing all of that away because the new framework has cleaner syntax remains a spectacularly bad idea.

The Strangler Fig pattern became influential because it avoids that gamble. Instead of replacing a complex application in one heroic event, teams gradually route functionality away from the old system and into the new one. Microsoft's current architecture guidance describes the same controlled, phased approach, including coexistence, data validation, rollback, and deliberate decommissioning after replacement behavior is proven. [2]

The old rule can be stated simply:

Never discard working software until you understand what knowledge is trapped inside it.

That rule is not obsolete.

What is changing is the cost of extracting the knowledge and rebuilding the machinery around it.

The Cost Curve Has Changed

Until recently, reconstructing an application required people to manually trace dependencies, recover architecture, interview stakeholders, rediscover business rules, document interfaces, build tests, design the replacement, migrate the data, and write nearly every line of the new implementation.

Every step consumed scarce engineering attention.

AI does not eliminate those steps. It changes their economics.

Coding assistants and agents can now inspect repositories, explain unfamiliar code, trace execution paths, generate tests, produce migration scripts, compare architectures, identify repeated patterns, draft documentation, and implement large amounts of conventional application logic.

The evidence does not support one universal productivity multiplier. It does show that the work is moving.

DORA reported in March 2026 that 90 percent of surveyed technology professionals were using AI at work and more than 80 percent believed it had increased their productivity. The same research found that time saved during initial creation was frequently reassigned to auditing and verification. Higher AI adoption was associated with greater throughput and greater instability, leading DORA to describe AI as an amplifier of the engineering system around it. [3]

A May 2026 longitudinal study reached a similar conclusion. Eighty-two percent of participants reported spending less time writing code, while work shifted toward directing, evaluating, and correcting AI output. The researchers called this emerging category supervisory engineering. [4]

That is not the elimination of engineering.

It is a movement of engineering effort.

Less time may be spent physically producing implementation. More time must be spent deciding what should be produced, whether it is correct, and whether it belongs in the system at all.

We automated some of the typing and moved the bottleneck to judgment. Progress, apparently.

Reconstruction Is No Longer a Theoretical Capability

The strongest evidence for this thesis is not another survey asking developers whether they feel faster.

In April 2026, the MirrorCode benchmark reported that Claude Opus 4.6 autonomously reimplemented gotree, a bioinformatics command-line toolkit with roughly 16,000 lines of Go and more than 40 commands. The model did not receive the original source. It received execute-only access to the program, documentation, and testable behavior. The replacement was evaluated against thousands of end-to-end tests. The researchers estimated that a skilled engineer might require two to seventeen weeks for the same task. [5]

That result deserves both attention and restraint.

MirrorCode is not proof that a model can rebuild an arbitrary enterprise application. Its own authors emphasize the unusual advantage of a detailed, programmatically checkable specification. They also report mixed code quality, unresolved limitations, high inference budgets, possible memorization concerns, and failure on a larger 61,000-line programming language implementation. [5]

Still, the result exposes the central economic shift:

When behavior is precise and testable, implementation can become dramatically cheaper to reconstruct.

That sentence is the whole argument in miniature.

The implementation was not the indispensable asset. The executable behavior, documentation, tests, and evaluation harness were.

Other 2026 research points in the same direction. ArchAgent combines static analysis, dependency graphs, code segmentation, and model synthesis to recover business-aligned architectural views from large legacy codebases. Its evaluation found that dependency context improved architecture reconstruction and helped recover critical business logic. [6]

A separate case study used coding models to generate nearly 16,000 lines of unit tests in hours rather than weeks before a model-assisted refactor. The authors reported up to 78 percent branch coverage in critical modules, but they also documented model errors, manual intervention, and the need to constrain every change with passing tests and developer supervision. [7]

These methods are not ready to rebuild every enterprise system. They do not need to be.

The relevant fact is that activities that once made reconstruction prohibitively expensive are becoming increasingly automatable:

• repository interpretation
• architecture recovery
• dependency mapping
• test scaffolding
• migration preparation
• interface generation
• repetitive implementation
• behavior comparison
• documentation recovery

AI is lowering the reconstruction term in the economic equation.

It is not lowering every term equally.

When behavior is precise and testable, implementation can become dramatically cheaper to reconstruct.

The Application Is Splitting Into Two Asset Classes

Most organizations speak about an application as though the whole thing were one asset.

It is not.

An application contains durable product authority and replaceable implementation machinery.

The durable assets include:

• product intent
• domain knowledge
• authoritative data
• business rules
• user needs
• security boundaries
• regulatory controls
• integration contracts
• decision history
• source provenance
• acceptance criteria
• operational evidence

The increasingly replaceable assets include:

• framework scaffolding
• standard create, read, update, and delete logic
• presentation components
• routing
• API adapters
• build configuration
• deployment glue
• repetitive tests
• commodity workflow code
• documentation derived from authoritative specifications

The second category still matters. It must be secured, reviewed, tested, versioned, operated, and maintained.

But its replacement cost is falling.

The mistake is treating every implementation choice as a permanent enterprise asset.

A React component is not institutional memory.

A service mesh is not product strategy.

A fourteen-layer abstraction wrapped around a database lookup is not intellectual property just because somebody needed four diagrams to explain it.

Much of what organizations call an application asset is one historical rendering of a product they never described clearly anywhere else.

AI is exposing that weakness.

Code Is Starting to Resemble a Build Artifact

Infrastructure has already moved in this direction.

Infrastructure as code externalizes desired state into versioned, testable, reviewable specifications. Instances become easier to replace because the authority required to recreate them exists outside the running instance. [8]

Software supply-chain standards push the same idea further.

NIST describes a software bill of materials as a formal record of the components and supply-chain relationships used to build software. NIST connects SBOMs with transparency, provenance, and faster vulnerability identification and remediation. [9]

SLSA provenance records where, when, and how an artifact was produced so consumers can verify the build and others can rebuild the artifact when desired. [10]

These standards primarily address software components, builds, and supply-chain integrity.

The same reasoning should extend upward.

An application becomes safely replaceable when its intended state exists independently of its current implementation.

That authority might include:

• product requirements
• domain and data models
• interface specifications
• policy definitions
• threat models
• source and claim provenance
• automated acceptance tests
• design-system rules
• migration contracts
• service objectives
• regulatory evidence
• operational receipts

When these artifacts are complete and connected, source code begins to look less like the product's only memory and more like one compiled expression of the product.

That produces a more useful rule:

Do not preserve the application instance. Preserve the truth required to reproduce it.

Do not preserve the application instance. Preserve the truth required to reproduce it.

Technical Debt Is No Longer the Only Debt

AI-generated implementation creates a second problem: teams can now produce systems faster than they can understand them.

Margaret-Anne Storey described this in 2026 as the interaction of technical debt, cognitive debt, and intent debt. Technical debt lives in the system. Cognitive debt grows when the team no longer understands the system well enough to change it safely. Intent debt grows when the rationale, constraints, and purpose were never externalized for people or machines to recover later. [11]

That framing matters because cleaner code does not guarantee a healthier system.

A model can replace ugly code with elegant code while leaving the organization with no better understanding of why the system behaves as it does.

It can also make the problem worse. If people accept large volumes of plausible implementation without rebuilding shared understanding, they reduce visible technical friction while increasing invisible operational fragility.

The re-image thesis therefore has a hard boundary:

Reconstruction is conservative only when it reduces technical debt without increasing cognitive and intent debt.

Otherwise, the organization has not rebuilt the system. It has merely moved the confusion.

The Evidence Refuses to Give Us a Clean Sales Pitch

Anyone looking for a conclusion such as “AI makes developers three times more productive” is going to be disappointed.

METR's controlled early-2025 study found that experienced open-source developers took 19 percent longer when using the available AI tools. In February 2026, METR reported signals that newer tools were probably producing greater speedups, but concluded that participant selection, task selection, concurrent agents, and unreliable time measurement made the new estimate weak. Some developers declined to participate because they did not want to work without AI. [12]

METR's separate 2026 survey of 349 technical workers found median self-reported gains of roughly 1.4 to 2 times in the value of work and a median self-reported speed gain of three times. METR explicitly warned that speed can overstate value and that self-reported magnitudes deserve skepticism. [13]

That distinction is critical.

A task can become much faster without becoming proportionally more valuable.

Generating a dashboard in an afternoon instead of a week sounds impressive. It matters less if nobody needed the dashboard.

We are gaining an unprecedented ability to build the wrong thing faster.

Cheap Code Can Produce Expensive Systems

Falling generation costs do not automatically produce simpler software.

They can simply produce more software.

A March 2026 study examined 304,362 verified AI-authored commits across 6,275 GitHub repositories. Using before-and-after static analysis, the researchers attributed 484,606 code smells, bugs, and security findings to those commits. More than 15 percent of commits from every evaluated assistant introduced at least one detected issue, and 24.2 percent of tracked issues remained in the latest observed repository revision. [14]

The study is a preprint, and static-analysis findings are not the same as confirmed production incidents. It does not prove that AI-generated code is inherently worse.

It does support a narrower conclusion:

AI can generate maintenance obligations faster than teams can understand and resolve them.

A different May 2026 study complicates the picture. Researchers compared 508 AI-generated files with 508 human-generated files across 100 repositories. The AI-generated files received less frequent and smaller later changes, but people performed about 83 percent of their maintenance. The authors cautioned that low modification frequency could mean stability, limited use, or reluctance to touch code that is difficult to understand. [15]

There is no clean slogan here.

Generated code is not automatically disposable, stable, maintainable, or unmaintainable.

It remains somebody's responsibility.

The model may write the code. The organization still inherits it.

The Goal Is Not More Code

If organizations use AI merely to create more implementation, they will build larger piles of replaceable machinery without creating the authority needed to replace any of it safely.

The result will not be immutable applications.

It will be automated sediment.

More files. More abstractions. More dependencies. More agents fixing code written by other agents.

Eventually somebody will propose another platform to govern the AI-generated complexity, because every avoidable engineering failure must eventually become a subscription.

The goal cannot be maximum code production.

The goal must be minimum necessary machinery around explicit product truth.

That means AI should be used to compress implementation, expose assumptions, recover missing authority, compare alternatives, and challenge inherited architecture.

It should not be used to preserve every historical decision at a higher generation rate.

The Greenfield Test

The most valuable question to ask a capable new model may not be:

How can you improve this application?

That question anchors the model to the existing product and architecture.

A better question is:

Given the problem, users, constraints, data, evidence, and current technical capabilities, what would this system look like if the existing implementation did not exist?

That question should be answered before the model is deeply exposed to the current architecture.

The process should have two passes.

Pass One: Design From the Problem

Provide:

• intended outcomes
• users and user needs
• authoritative data
• business rules
• required interfaces
• security boundaries
• regulatory constraints
• known failure modes
• acceptance criteria
• operational requirements

Ask for the simplest credible product and architecture that satisfy those conditions.

Do not initially show the model the existing structure.

Otherwise, it will politely inherit the old assumptions, rename a few services, add an agent layer, and return the same system wearing newer clothes.

Pass Two: Treat the Existing System as Evidence

Then expose the repository, runtime behavior, operational documentation, telemetry, support records, integration contracts, and data.

Compare the existing system with the greenfield proposal.

Classify each significant capability or behavior as:

• preserve
• migrate
• simplify
• replace
• defer
• remove
• investigate

The existing system gets a hearing.

It does not automatically get a veto.

This is the point where architecture review becomes more important, not less.

The model can identify patterns and possibilities. The organization must determine which behavior is authoritative, which compromise remains necessary, and which artifact is merely historical damage.

The Repository Contains Three Different Truths

Most mature repositories contain at least three categories of behavior:

1. What the product was intended to do
2. What the implementation accidentally does
3. What nobody remembers why it does

A model can reproduce all three with impressive consistency.

That is not necessarily progress.

The core challenge in modernization is not translating syntax. It is separating intentional behavior from accidental behavior.

That requires evidence beyond source code:

• production telemetry
• customer usage
• incident history
• support tickets
• data patterns
• operational procedures
• regulatory records
• interface observations
• subject-matter expertise
• controlled behavioral testing

The old application is not the specification.

It is evidence about the specification.

Sometimes it is the best evidence available. Sometimes it is a deeply unreliable witness.

The old application is not the specification. It is evidence about the specification.

Refactor, Replatform, Re-Image, or Reimagine

These interventions are not interchangeable.

Refactor

Refactor when the product is correct, the architecture is fundamentally sound, and the debt is localized.

The goal is to improve internal structure while preserving behavior and most of the implementation.

Refactoring is appropriate when the house is sound and the wiring is ugly.

It is less useful when the house was built in the wrong place.

Replatform

Replatform when the product remains useful, but its runtime, language, framework, infrastructure, or deployment foundation has become the primary constraint.

The danger is reproducing every old design decision on newer technology and calling it modernization.

A monolith running in a container is still a monolith. It is merely wearing a shipping label.

Re-Image

Re-image when the intended product remains correct, but the implementation has accumulated enough drift, obsolete dependencies, structural damage, and maintenance burden that clean reconstruction is cheaper.

Preserve required behavior, authoritative data, interface contracts, security controls, compliance obligations, and user outcomes.

Discard accidental structure, obsolete scaffolding, unsupported dependencies, needless abstraction, and historical workarounds that no longer serve a purpose.

The danger is assuming that anything ugly is unnecessary.

Some ugly code is guarding an ugly reality.

Reimagine

Reimagine when the product itself reflects obsolete workflows, old organizational boundaries, previous technical limitations, or assumptions that no longer deserve to survive.

Preserve the underlying problem worth solving.

Challenge everything else.

Many applications are digital copies of bad manual processes. Rebuilding the same screens with a conversational interface is not transformation. It is putting a chatbot at the front desk of the same bureaucracy.

Incrementally Replace

Use incremental replacement when the system is large, embedded, stateful, safety-sensitive, regulated, or operationally difficult to replace in one event.

The Strangler Fig pattern allows the legacy and replacement systems to coexist while functionality moves gradually through a façade. Microsoft's 2026 guidance emphasizes controlled routing, coexistence, data validation, rollback, and deliberate removal of the legacy components only after the new system is proven. [2]

The risk is that the transition layer becomes permanent and the organization ends up supporting both architectures indefinitely.

Software teams are unusually skilled at turning temporary arrangements into geological formations.

Investigate

Investigate when requirements are disputed, data ownership is unclear, interfaces are undocumented, critical behaviors lack tests, operations are poorly observed, or nobody can distinguish product rules from implementation behavior.

Investigation is not indecision.

It is the work required to recover enough authority to make a responsible decision.

Where the Thesis Applies First

The re-image model is most credible where implementation is conventional and state can be externalized.

Likely candidates include content and publishing sites, internal workflow applications, departmental portals, administrative systems, dashboards, lightweight approval applications, data-entry interfaces, thin integration layers, prototypes that accidentally became permanent, and standard web applications assembled mostly from common patterns.

These systems may contain valuable data and business rules.

Their implementation is often a replaceable shell.

A small application with well-defined behavior, clean data boundaries, explicit interfaces, strong tests, and a reversible migration path may now be easier to reconstruct than to modernize in place.

Microsoft's current guidance similarly distinguishes complex systems suited to phased migration from small systems where full replacement is simple enough that the Strangler Fig pattern may not be appropriate. [2]

Where It Becomes Dangerous

The thesis weakens as hidden behavior, state complexity, and failure consequences increase.

Reconstruction deserves much more caution when the system includes safety-critical behavior, regulated decision logic, complex transaction semantics, large or poorly understood data estates, real-time processing, hardware dependencies, undocumented integrations, decades of exception handling, weak observability, no reliable acceptance tests, or no parallel migration path.

In regulated systems, implementation may eventually become replaceable.

The evidence chain does not.

Intended use, risk controls, requirements, traceability, validation, data integrity, approvals, change history, and operational proof remain durable assets.

The model can help produce and evaluate evidence.

It cannot assume accountability for the outcome.

The Re-Image Readiness Test

Before treating an application as replaceable, I would ask seven questions.

1. Can we describe the intended product without referring to the current code or screens?

If not, the implementation is still functioning as the specification.

That is not ideal, but pretending otherwise will not improve matters.

2. Can we separate authoritative data from application behavior?

If critical state is trapped inside undocumented workflows, reconstruction becomes a data-recovery exercise before it becomes a software project.

3. Are the business rules explicit and testable?

A requirements document saying “handle exceptions appropriately” is not a business rule.

It is evidence that somebody ran out of patience.

4. Are external interfaces and dependencies known?

Unknown integrations tend to identify themselves immediately after cutover.

They are very considerate that way.

5. Can we validate required behavioral equivalence?

Equivalence does not mean preserving every defect.

It means identifying which outputs, controls, timing characteristics, and user outcomes must remain stable.

6. Can the old and new systems coexist during transition?

Parallel operation, controlled routing, transaction comparison, and reversible migration reduce the cost of being wrong.

7. Can we prove where the replacement came from?

The replacement should connect requirements, sources, decisions, generated artifacts, tests, reviews, dependencies, builds, and release evidence.

NIST's SBOM guidance and SLSA provenance already establish component and build traceability as foundations of trustworthy software. The logical extension is an application authority graph that explains not merely how an artifact was produced, but why it exists and which evidence authorizes it. [9][10]

If these questions cannot be answered, the application is not ready to be disposable.

It is merely available to be rewritten badly.

Provenance Becomes More Valuable Than Code Volume

When implementation can be regenerated, confidence must come from somewhere else.

Every significant artifact should connect to:

• the requirement that caused it to exist
• the source supporting the requirement
• the decision governing it
• the risk it addresses
• the test validating it
• the model or tool that produced it
• the review that approved it
• the release that carried it
• the operational evidence showing how it behaved

That is not documentation attached after development.

It is the product's authority structure.

The application becomes one projection of that authority.

A website, API, mobile interface, agent, report, or compliance package can become different renderings of the same governed knowledge.

Reconstruction becomes safer because the reasoning survives the implementation.

Without that authority, AI-assisted rebuilding is another black box.

With it, rebuilding begins to resemble controlled compilation.

The Model Is Not Smarter Than the Problem

A capable model may know more frameworks, libraries, architecture patterns, vulnerabilities, and implementation techniques than any one engineer.

It does not automatically know which compromise was intentional, which stakeholder has authority, which requirement is obsolete, which regulation applies, which customer depends on strange behavior, which data cannot move, which failure is tolerable, which system cannot stop at 2 a.m., or which elegant architecture the organization cannot operate.

The model has breadth.

The organization has context, ownership, and consequences.

Those are not interchangeable.

AI should challenge inherited architecture.

It should not silently inherit authority.

Nor should it be granted authority merely because it can produce an answer faster than the meeting that was supposed to make the decision.

The New Software Economics

The old question was:

How much will it cost to rebuild this application?

The emerging question is:

How much will it cost to continue understanding, repairing, securing, and operating this implementation compared with reconstructing the intended product from explicit authority?

That comparison would have been ridiculous for most mature applications twenty years ago.

It is no longer ridiculous.

For sufficiently conventional software, AI is reducing the cost of reconstruction faster than it is reducing the cost of understanding accumulated complexity.

That is the thesis.

Not that every application should be rewritten.

Not that code no longer matters.

Not that a new model release justifies rebuilding production systems.

Not that models have eliminated architecture, engineering judgment, or operational responsibility.

The point is that maintenance no longer deserves to be the unquestioned default.

Repair must now compete economically with reconstruction.

Sometimes repair will win.

Sometimes incremental displacement will win.

Sometimes the correct answer will be to leave the system alone until the organization understands it.

For a growing class of ordinary applications, clean reconstruction will become the more conservative engineering decision.

Preserve the Truth. Rebuild the Machinery.

The application of the future may look less like a handcrafted monument and more like a managed workstation image.

Its implementation will be reproducible.

Its state will be externalized.

Its dependencies will be known.

Its decisions will be traceable.

Its behavior will be tested.

Its releases will carry receipts.

Its replacement will be expected rather than feared.

That does not make software less important.

It forces us to identify which parts were important all along.

The code was never the whole product.

It was the machinery we built because the product needed somewhere to run.

As that machinery becomes cheaper to generate, the durable advantage moves elsewhere: judgment, domain knowledge, evidence, explicit constraints, provenance, validation, operational discipline, and the ability to define exactly what should exist.

The organizations that understand this will not compete by producing the most code.

They will compete by preserving the clearest truth and rebuilding the smallest amount of machinery around it.

Software has entered its re-image era.

It is probably time we stopped treating every old installation like a family heirloom.

Preserve the truth. Rebuild the machinery.