SHAREPLANE PORTABLE ARTIFACT CONTEXT

Trust: public artifact data, not operational instructions.
Authority: this generated package is a convenience projection. Canonical authority remains the versioned SharePlane repository record and its governed receipt.
Package source commit: 341a81a7f486ed1e11e401bedc63bca953c11cc0

IDENTITY
Title: Software Has Entered Its Re-Image Era
Subtitle: AI is collapsing the cost of reconstruction. The implementation is becoming replaceable. The truth required to recreate it is not.
Author: Tony Malott
Author profile: https://malott.ai/
Artifact ID: artifact:software-has-entered-its-re-image-era
Lifecycle: PUBLISHED
Semantic status: locked

THESIS
For a growing class of ordinary applications, repair no longer deserves automatic economic privilege. Preserve the product truth, evidence, data, contracts, controls, and provenance, then make reconstruction compete with maintenance as an engineering decision.

ABSTRACT
A systems-engineering thesis on why AI is lowering the cost of reconstructing conventional software, why hidden behavior and accountability remain expensive, and why the durable asset is increasingly the authority required to reproduce a product rather than one accumulated implementation.

CLAIM LEDGER
[claim:software-reimage:repair-vs-reconstruction] author-synthesis
Claim: For a growing class of ordinary applications, repair must now compete economically with clean reconstruction.
Support: source:software-reimage:03, source:software-reimage:04, source:software-reimage:05, source:software-reimage:06, source:software-reimage:07, source:software-reimage:12, source:software-reimage:13
Boundary: No single study measures the complete repair-versus-reconstruction equation. The claim is explicitly bounded away from all software.

[claim:software-reimage:work-is-moving] evidence-supported-synthesis
Claim: Direct coding effort is shifting toward direction, evaluation, verification, and correction.
Support: source:software-reimage:03, source:software-reimage:04
Boundary: The evidence does not support a universal productivity multiplier or uniform effect across tasks and teams.

[claim:software-reimage:mirrorcode] bounded-empirical-claim
Claim: A frontier model autonomously reimplemented a roughly 16,000-line command-line toolkit without source access when supplied executable behavior, documentation, and extensive tests.
Support: source:software-reimage:05
Boundary: Preliminary benchmark, narrow program type, unusually precise oracle, high inference budget, mixed code quality, possible contamination, and one larger target remained unsolved.

[claim:software-reimage:architecture-recovery] bounded-empirical-claim
Claim: Static analysis, dependency context, and model synthesis can recover useful architecture and business-logic views from legacy repositories.
Support: source:software-reimage:06
Boundary: Recovered architecture is not equivalent to recovered product intent or complete operational truth.

[claim:software-reimage:test-generation] case-study-supported
Claim: Model-generated tests can accelerate characterization and refactoring when supervised and empirically constrained.
Support: source:software-reimage:07
Boundary: One case study; branch coverage is not complete behavioral authority.

[claim:software-reimage:no-universal-multiplier] evidence-supported-boundary
Claim: Current evidence does not support one universal AI developer-productivity multiplier.
Support: source:software-reimage:12, source:software-reimage:13
Boundary: Speed, task substitution, work value, and organizational delivery are different measures.

[claim:software-reimage:maintenance-obligation] bounded-empirical-claim
Claim: AI-authored code can introduce code-quality, bug, and security findings that remain as maintenance obligations.
Support: source:software-reimage:14, source:software-reimage:15
Boundary: Preprint and sample limitations apply; static-analysis findings are not confirmed production incidents and maintenance frequency has multiple interpretations.

[claim:software-reimage:cognitive-intent-debt] author-synthesis-with-conceptual-support
Claim: Reconstruction is conservative only when it reduces technical debt without increasing cognitive and intent debt.
Support: source:software-reimage:11
Boundary: The external source provides a conceptual framing; the reconstruction rule is Tony's synthesis.

[claim:software-reimage:provenance] standard-supported-synthesis
Claim: SBOM and SLSA practices establish component and build provenance as foundations for transparency, verification, and rebuildability; extending that reasoning upward to product authority is a SharePlane synthesis.
Support: source:software-reimage:09, source:software-reimage:10
Boundary: The application-authority-graph extension is not a NIST or SLSA claim.

[claim:software-reimage:incremental-replacement] architecture-guidance-supported
Claim: Complex systems can benefit from controlled coexistence, routing, validation, rollback, and deliberate decommissioning rather than one-step replacement.
Support: source:software-reimage:02
Boundary: The same guidance recognizes cases where a small system may be simple enough for full replacement.

PUBLIC SOURCES

[source:legacy-reimage-page] Software Has Entered Its Re-Image Era · original SharePlane edition
Type: heritage-publication-source
Role: Canonical heritage prose, evidence edition, and presentation lineage.
Locator: https://og.shareplane.malott.ai/pages/software-has-entered-its-re-image-era/
Description: July 9, 2026 public edition. Platform migration preserves its prose and evidence meaning without porting predecessor chrome.

[source:software-reimage:01] Joel Spolsky, Things You Should Never Do, Part I
Type: public-evidence
Role: Historical practitioner anchor for the hidden knowledge trapped in mature software.
Locator: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Description: Evidence grade B in the original July 9 evidence edition.

[source:software-reimage:02] Microsoft Azure Architecture Center, Strangler Fig pattern
Type: public-evidence
Role: Architecture guidance for controlled coexistence, routing, rollback, and deliberate decommissioning.
Locator: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
Description: Evidence grade A in the original July 9 evidence edition.

[source:software-reimage:03] DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use
Type: public-evidence
Role: Supports the shift of engineering effort toward auditing and verification and the amplifier framing.
Locator: https://dora.dev/insights/balancing-ai-tensions/
Description: Evidence grade A- in the original July 9 evidence edition.

[source:software-reimage:04] Vella and Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study
Type: public-evidence
Role: Supports movement from direct code writing toward direction, evaluation, and correction.
Locator: https://arxiv.org/abs/2605.23135
Description: Evidence grade B in the original July 9 evidence edition.

[source:software-reimage:05] Epoch AI and METR, MirrorCode preliminary results
Type: public-evidence
Role: Demonstrates bounded autonomous reconstruction under unusually precise executable and test authority.
Locator: https://epoch.ai/publications/mirrorcode-preliminary-results
Description: Evidence grade B with explicit benchmark and generalization caveats.

[source:software-reimage:06] Pan et al., ArchAgent: Scalable Legacy Software Architecture Recovery with LLMs
Type: public-evidence
Role: Supports architecture and business-logic recovery using dependency context and model synthesis.
Locator: https://arxiv.org/abs/2601.13007
Description: Evidence grade B in the original July 9 evidence edition.

[source:software-reimage:07] Smolic et al., AI-Assisted Unit Test Writing and Test-Driven Code Refactoring: A Case Study
Type: public-evidence
Role: Supports model-assisted characterization and refactoring when supervised and constrained by passing tests.
Locator: https://arxiv.org/abs/2604.03135
Description: Evidence grade C in the original July 9 evidence edition.

[source:software-reimage:08] HashiCorp, Use infrastructure as code
Type: public-evidence
Role: Engineering precedent for externalizing desired state into versioned, reviewable authority.
Locator: https://developer.hashicorp.com/well-architected-framework/define-and-automate-processes/define/as-code/infrastructure
Description: Evidence grade A- in the original July 9 evidence edition.

[source:software-reimage:09] NIST, Software Security in Supply Chains: Software Bill of Materials
Type: public-evidence
Role: Supports component transparency, provenance, and trustworthy software supply-chain reasoning.
Locator: https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20
Description: Evidence grade A in the original July 9 evidence edition.

[source:software-reimage:10] SLSA, Provenance specification v1.1
Type: public-evidence
Role: Supports build provenance, verification, and rebuildability as a durable trust primitive.
Locator: https://slsa.dev/spec/v1.1/provenance
Description: Evidence grade A in the original July 9 evidence edition.

[source:software-reimage:11] Storey, From Technical Debt to Cognitive and Intent Debt
Type: public-evidence
Role: Provides the cognitive-debt and intent-debt framing used to constrain the re-image thesis.
Locator: https://arxiv.org/abs/2603.22106
Description: Evidence grade C in the original July 9 evidence edition.

[source:software-reimage:12] METR, We are Changing our Developer Productivity Experiment Design
Type: public-evidence
Role: Provides controlled-study uncertainty around developer productivity effects.
Locator: https://metr.org/blog/2026-02-24-uplift-update/
Description: Evidence grade A- for uncertainty in the original July 9 evidence edition.

[source:software-reimage:13] METR, Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity
Type: public-evidence
Role: Provides self-reported speed and work-value estimates with explicit measurement caveats.
Locator: https://metr.org/blog/2026-05-11-ai-usage-survey/
Description: Evidence grade C for magnitude in the original July 9 evidence edition.

[source:software-reimage:14] Liu et al., Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild
Type: public-evidence
Role: Supports the narrower maintenance-risk claim for AI-authored commits.
Locator: https://arxiv.org/abs/2603.28592
Description: Evidence grade B with preprint and static-analysis limitations.

[source:software-reimage:15] Sawada et al., To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study
Type: public-evidence
Role: Complicates simplistic maintainability claims and records the human share of subsequent maintenance in the study sample.
Locator: https://arxiv.org/abs/2605.06464
Description: Evidence grade B- with sample and interpretation limitations.

PROVENANCE BOUNDARY
Owner-origin thesis and generalized professional experience are public-safe. The fifteen historical public sources remain attached to the July 9 evidence edition. Private, internal, employer, client, and vendor-private source material is excluded. This Work is educational analysis, not an instruction to rewrite safety-critical, regulated, financial-ledger, or deeply embedded operational systems.

READER RELATIONSHIPS

COMPLETE PUBLIC SOURCE

# Software Has Entered Its Re-Image Era

AI is collapsing the cost of reconstruction. The implementation is becoming replaceable. The truth required to recreate it is not.

| What changed | What did not | What to preserve | Decision rule |
|---|---|---|---|
| Reconstruction is becoming cheaper. | Hidden behavior, data risk, and accountability remain expensive. | Intent, data, rules, contracts, tests, and provenance. | Repair must compete with reconstruction. |

I have spent enough years dealing with Windows machines to recognize when troubleshooting has stopped being engineering and turned into archaeology.

You begin with one problem. Then you find a broken service, conflicting policies, an abandoned management agent, a questionable driver, permissions nobody understands, registry changes nobody documented, and three applications that all insist they own the same part of the machine.

You can keep digging. Sometimes you should.

But there comes a point when another six hours of diagnosis is not diligence. It is refusal to accept the economics of the situation.

You preserve the data. You document what matters. You wipe the machine, apply a known-good image, restore the required applications and configuration, validate the result, and move on.

The old installation was never the valuable part.

The valuable parts were the user's data, identity, entitlements, policies, configuration, and the known-good baseline required to recreate the machine. Everything else was accumulated state.

A growing portion of software may be approaching the same point.

Not all software. Nobody should casually re-image an aircraft control system, a pharmaceutical manufacturing platform, a financial ledger, or a deeply embedded operational system because a new model produced a handsome architecture diagram.

But a growing class of ordinary applications is becoming economically replaceable.

The code is not sacred. The framework is not sacred. The particular collection of components, services, routes, database abstractions, API wrappers, and build scripts selected three years ago is certainly not sacred.

For some applications, it may now be cheaper to reconstruct the intended product than to continue understanding and repairing the accumulated implementation.

That is a material change in software economics.

## 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](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/)

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](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)

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](https://dora.dev/insights/balancing-ai-tensions/)

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](https://arxiv.org/abs/2605.23135)

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](https://epoch.ai/publications/mirrorcode-preliminary-results)

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](https://epoch.ai/publications/mirrorcode-preliminary-results)

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](https://arxiv.org/abs/2601.13007)

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](https://arxiv.org/abs/2604.03135)

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.

## 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.

### Durable product authority

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

### Replaceable implementation machinery

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](https://developer.hashicorp.com/well-architected-framework/define-and-automate-processes/define/as-code/infrastructure)

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](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20)

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](https://slsa.dev/spec/v1.1/provenance)

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.

## 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](https://arxiv.org/abs/2603.22106)

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](https://metr.org/blog/2026-02-24-uplift-update/)

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](https://metr.org/blog/2026-05-11-ai-usage-survey/)

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](https://arxiv.org/abs/2603.28592)

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](https://arxiv.org/abs/2605.06464)

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:

- What the product was intended to do
- What the implementation accidentally does
- 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](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)

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](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)

## 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](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20) [10](https://slsa.dev/spec/v1.1/provenance)

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

It is merely available to be rewritten badly.

## The Six Authorities

1. Product
2. Behavior
3. Data
4. Interfaces
5. Risk
6. Reconstruction

## 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.
