Six Generations of a Source-Recovery Architecture

KodeBack did not begin as a clean product plan.

It began as a personal problem: how do you take a working interactive application, remove capabilities you do not want, preserve what matters, and make the result safe to change?

The answer evolved through six internal research generations.

Each generation solved a real failure in the previous one. The most important progress did not come from adding more AI. It came from moving authority into the right layer.

Generation 1: keep the original alive

The first architecture assumed that a shipped bundle might remain permanently opaque.

The safe response was a bridge.

The original application continued to run while small seams were reconstructed beside it. Work moved through claims, ownership, promotion, and an eventual cutover.

This generation got several things right:

• the deployed application was the authority;
• model output was not trusted by appearance;
• replacement had to be incremental;
• durable artifacts and gates mattered;
• fallback reduced the risk of replacing everything at once.

But the bridge became the architecture.

Different applications needed different shell modes, iframe behavior, storage coordination, route handling, readiness rules, and cutover logic. Status was distributed across several artifacts. The final transition removed the very fallback that had made the earlier work safe.

The system had optimized around the belief that opacity was permanent.

That belief stopped being universally true.

Generation 2: reconstruct from evidence

The second generation removed the bridge and introduced a staged reconstruction pipeline.

It formalized:

• intake;
• source and stack recovery;
• runtime signals;
• bounded model briefs;
• candidate reconstruction;
• parity;
• iteration.

The model did not need to be embedded in the core. The pipeline could produce a structured brief, receive a structured response, validate it, and apply it.

This was a major improvement.

It separated deterministic orchestration from non-deterministic execution. It created explicit operator intent for removed capabilities. It strengthened artifact contracts, state history, and validator layers.

But it relied on another false assumption:

If we collect enough screenshots, runtime signals, scene graphs, and descriptions, a model can recreate the application accurately from a clean scaffold.

The candidates could compile and look structurally plausible while still being behaviorally wrong. A scene could have the expected object count and render black. A clean implementation could approximate the observed product without carrying forward the donor’s actual logic.

The workflow was reconstructing from a description of the evidence rather than recovering from the implementation.

Generation 3: use donor code as the substrate

The third generation introduced a direct runtime seed.

Instead of beginning with an empty project, the system began with the donor’s actual shipped code:

• substitute recovered source where safe;
• retain uncertain regions;
• quarantine unsupported regions;
• keep the candidate runnable;
• improve one bounded surface at a time.

Parity changed from a final stage into a gate used throughout the process.

Each transition could be:

• atomic;
• re-runnable;
• validated;
• checkpointed;
• rolled back;
• bisected.

Vendor extraction also became explicit. Identifying a package was separated from safely replacing its bytes and consumers.

This generation established the pattern that still matters:

Start from a known runnable state. Perform a bounded transformation. Check it. Keep or revert it.

It also revealed how dangerous casual source mutation could be. Textual rename and patch algorithms corrupted code in ways that required AST-aware and binding-aware operations.

The remaining problem was the workspace itself.

Generation 4: make the candidate a normal project

The third-generation output was still shaped like a recovery laboratory.

Donor bytes, stage trees, replay machinery, evidence, generated source, and candidate code were difficult to distinguish. A developer needed a graduation step to turn the result into a normal project.

The fourth generation changed the artifact contract.

It established three trust surfaces:

Donor

Immutable shipped authority.

Evidence

Derived capture, analysis, parity, ledger, and stage state.

Candidate

The editable application at the repository root.

The candidate was no longer a late-stage artifact hidden in a pipeline directory. It was the project.

This clarified ownership for every tool and made the final software capable of living without the recovery system after the required evidence had been archived.

The ledger also became a shared platform capability: append-only, source-bound, and available across capture, recovery, validation, and agent work.

The system now had the right place to store truth.

It still needed a better way to operate.

Generation 5: drain deterministic work

The fifth generation combined capture, source maps, fingerprinting, vendor demixing, runtime evidence, protected surfaces, codemods, verification, equivalence, characterization, parity, checkpoints, and an advisor into a deterministic drain.

The system repeatedly asked:

What is the next safe action that current evidence supports?

It applied that action, refreshed the evidence, validated the result, checkpointed the green state, and continued.

This proved that a large amount of work commonly handed to coding agents could become repeatable:

• recovery-route selection;
• source-map promotion;
• dependency attribution;
• exact mechanical cleanup;
• protected-contract enforcement;
• scoped capability removal;
• runtime evidence collection;
• safe import and symbol changes;
• progress and residual reporting.

It also created a compounding system. A failure in one migration could become a fixture, guard, or policy for the next.

But the final phase still used a broad agent handoff.

Once the deterministic drain ended, an agent received a large remaining cleanup surface and repository authority.

The agent was capable. The evidence was strong. The workflow still produced build-green behavioral regressions, stale-state reconstruction, initialization-order mistakes, public-symbol drift, and repeated re-discovery of which checkpoint and evidence were current.

The false assumption was:

Deterministic work belongs to the pipeline; everything else can safely be handed to the agent.

Semantic uncertainty did not justify transferring mutation authority.

Generation 6: bounded judgment inside continuous control

The sixth generation keeps the deterministic drain running from start to finish.

When the system reaches a missing semantic fact, it pauses for one bounded judgment.

The model may decide:

• semantic role;
• ownership boundary;
• decomposition choice;
• vendor policy;
• whether more evidence is needed;
• whether the task should be refused.

The system then:

• converts the answer into a source-aware plan;
• previews the exact mutation;
• applies it transactionally;
• runs the required evidence;
• accepts or rolls back;
• refreshes state;
• continues the drain.

There is no broad handoff where the agent becomes the migration operator.

The model supplies meaning.

The mutation engine supplies mechanics.

The evidence system supplies skepticism.

The orchestrator retains authority.

What stayed true across all six generations

The architecture changed substantially, but the core lessons accumulated.

Generation 1 established that the deployed product must remain authoritative.

Generation 2 established structured, provider-neutral model work.

Generation 3 established donor code as the recovery substrate and parity as a continuous gate.

Generation 4 established a clean donor/evidence/candidate trust model.

Generation 5 established a deterministic drain and a multi-layer evidence ecosystem.

Generation 6 makes semantic judgment subordinate to the same transactional system.

The public product name changed.

The deeper thesis did not:

Recover everything the evidence can establish. Ask for judgment only where meaning is missing. Never let a plausible answer bypass the controls required to trust the change.

Why this history matters to buyers

Architecture history is not proof of market fit.

It does explain what the company has learned to distrust:

• screenshot-only reconstruction;
• build-only success;
• source maps treated as complete recovery;
• package identity treated as safe replacement;
• large-file rules treated as product truth;
• model confidence treated as evidence;
• broad handoffs treated as control;
• green verdicts without coverage;
• cleanup that cannot be rolled back;
• internal success presented as customer validation.

KodeBack is still research-stage.

Its direction is grounded in repeated technical failures rather than a single polished demo.

That is the part of the history worth making public.