Source Recovery and AI Refactoring Share the Same Trust Problem
One reconstructs maintainable source from shipped artifacts; the other transforms known source. Both can produce plausible code that lacks evidence of behavioral control.
Source recovery and ordinary refactoring begin from opposite directions.
Recovery starts with software that runs and tries to regain maintainable source. Refactoring starts with source and tries to change its structure without losing behavior.
Both can end with code that looks excellent and is wrong.
Plausibility is cheap
A model can turn minified code into readable modules. It can also decompose a large source file, move packages, consolidate helpers, and improve performance.
The resulting code may:
- parse and typecheck;
- follow common architecture patterns;
- use convincing names;
- pass visible tests;
- render a familiar screenshot;
- come with a coherent explanation.
None of those facts alone establishes control of the transformation.
Recovery can invent history
When original names and boundaries are erased, there may be no exact historical answer to recover.
An agent can infer useful meaning, but it can also assign overly specific roles, split effects incorrectly, replace modified vendor code, or rename an external contract.
The evidence system needs to separate exact recovery, supported inference, operator choice, and unresolved debt.
Refactoring can erase behavior
Known source does not remove uncertainty. A structural change can alter initialization order, singleton identity, dynamic discovery, style scope, side effects, or timing while preserving every obvious function body.
Tests are essential but bounded. An agent that edits both code and tests can also make the suite agree with its own misunderstanding.
The transaction needs independent constraints and before-state evidence.
Both need immutable authority
In recovery, the deployed donor and captured runtime signals outrank the candidate.
In refactoring, the immutable before-state and declared contracts outrank the agent’s proposed postimage.
The candidate remains disposable until it satisfies the required evidence.
This creates the same operational loop:
- bind the authoritative input;
- declare scope and protected surfaces;
- prepare a bounded transformation;
- mutate an isolated candidate;
- run proportionate evidence;
- explain gaps and causality;
- keep, repair, or refuse the candidate;
- transfer through an exact gate.
Deterministic tools and model judgment have different jobs
Models are useful for naming, semantic grouping, architecture choices, and interpreting ambiguous runtime evidence.
Source-aware tools are better for binding identity, enumerating references, applying exact rewrites, checking stale plans, preserving protected strings, and rolling back failed postimages.
The model should supply meaning where necessary. The system should retain mutation authority.
Parity must remain scoped
Neither recovery nor refactoring can prove every behavior of a nontrivial application empirically.
The honest result names:
- states and flows observed;
- static contracts checked;
- project gates run;
- environment and versions;
- exclusions and unsupported surfaces;
- coverage regression;
- remaining uncertainty.
That statement is narrower than “behavior preserved” and more useful to the engineer deciding what to do next.
Why Kalu Kode builds across the lifecycle
KodeCapture preserves deployed evidence. KodeBack uses it to recover a maintainable candidate. KodeProof applies the same evidence discipline to future changes, including ordinary repositories that never needed recovery.
The products solve different jobs. The shared thesis is that plausible code is not enough—whether the code was reconstructed from a bundle or transformed from source.
Trust comes from retaining an authority outside the model and making every important transition answerable to it.