Recovery Starts With Capture, Not Code Generation

Imagine giving a coding agent one instruction:

Here is a URL. Recover this application into a maintainable project and keep it behaving like the original.

Most discussions jump immediately to the code-generation part.

Can the model understand the minified JavaScript? Can it infer names? Can it rebuild the interface? Can it write clean React, Vue, or TypeScript?

Those questions skip the first and often harder problem.

What exactly did the deployed application do?

A raw agent does not begin with a complete donor. It has to create one.

A page download is not an application capture

Tools such as a basic HTTP client or site downloader can fetch HTML and statically referenced assets.

Dynamic applications reveal important surfaces only while they run.

A route may load a chunk after navigation. A button may trigger a POST request. A service worker may serve cached files. A logged-in session may depend on storage and cookies. A Three.js scene may load models, textures, shaders, and decoder files after the canvas starts. A realtime app may not become useful until WebSocket frames initialize state.

A static download may preserve the shell while missing the product.

What a recovery-grade capture needs to observe

The exact set varies, but a serious capture may need to record:

• initial HTML and document responses;
• JavaScript and CSS chunks;
• images, fonts, video, audio, models, textures, shaders, and binary assets;
• source maps and their availability at live URLs;
• routes and navigation states;
• requests by method, path, query, body, headers, status, and response shape;
• cookies, local storage, session storage, and indexed data where authorized;
• service-worker registration and cache behavior;
• workers and public runtime paths;
• redirects and external origins;
• WebSocket connections and bounded frame sequences;
• user actions required to reveal lazy states;
• console and runtime errors;
• browser and environment conditions;
• which observations were complete, partial, or unavailable.

This is not busywork around recovery. It is the source of truth the recovery will depend on.

Why an agent cannot infer what it never saw

A capable model can reason from evidence. It cannot recover an unvisited state from nothing.

If nobody opened the settings panel, the capture may miss its route chunk and storage behavior.

If nobody completed a game flow, the capture may miss the result state, late assets, and network messages.

If the donor was already logged in, the capture may preserve a warm session without proving refresh or sign-in behavior.

If the application connected to a live service, a local replay may look complete while still depending on the original authority.

These are information gaps, not model-intelligence gaps.

Capture also determines what “parity” can mean

A recovery system cannot honestly claim that the candidate matches the donor in states the donor capture never defined.

The capture should therefore produce more than files. It should produce a capability contract:

• which routes were visited;
• which actions were performed;
• which states were reached;
• which network surfaces were recorded;
• which storage was seeded;
• which realtime behavior was bounded;
• which live dependencies remain;
• which evidence the replay can reproduce;
• which gaps are known.

That contract becomes the denominator for later behavior claims.

“Parity green” without requested-state accounting can be dangerously vague. The application may have matched the donor only because the hard state never ran.

Why replay matters

A donor that exists only at a live URL is fragile.

The application may change. An asset may disappear. A vendor may deploy a new build. A token may expire. A third-party endpoint may stop responding. The organization may lose access before the recovery is complete.

A local replay gives the recovery process a more stable reference.

Depending on the application, replay may:

• serve captured assets locally;
• rewrite request paths;
• return recorded HTTP responses;
• seed storage;
• reproduce selected WebSocket sessions;
• preserve route behavior;
• record which live services could not be replaced;
• allow repeated browser checks against the same evidence.

Replay does not make every application fully offline. It makes the remaining authority explicit.

Capture quality affects every later stage

A poor capture creates downstream ambiguity.

Missing source maps can route a recoverable application into an expensive blind lane.

Missing assets can make a candidate look visually wrong and send engineers searching the code for a problem that is actually incomplete donor evidence.

Missing runtime states can make a semantic name appear unsupported.

Missing package responses can hide the exact dependency version.

Missing WebSocket frames can make the local candidate fail before the useful state is reached.

A strong recovery pipeline therefore treats capture as its own measurable product surface.

How to compare KodeBack with a raw agent fairly

A comparison that gives both conditions the same perfect donor capsule measures recovery from equal evidence. That is useful for isolating the recovery engine.

It does not measure the full customer problem.

A fair evaluation needs at least three layers:

Capture evaluation

Starting from a deployed URL, how much of the application can each condition preserve and replay?

Compare:

• a shell-only agent;
• a browser-equipped agent;
• an agent with recovery-grade capture tools;
• deterministic capture where applicable.

Recovery-core evaluation

Starting from the same frozen donor capsule, how well can each condition recover maintainable source?

This isolates recovery quality from capture variance.

End-to-end evaluation

Starting only from the deployed application and authorized access, which condition can deliver an independent, maintainable project?

This is the commercially meaningful claim.

The result should report capture lift, recovery lift, and end-to-end lift separately.

The production-artifact rule

When we create owned evaluation applications, the donor should be served as a production build—not a development server that accidentally exposes original modules, readable source paths, framework debug metadata, or hot-reload endpoints.

The evaluator keeps the canonical source private.

The recovery condition receives only the deployed artifact, URL, credentials, and allowed tools.

The hidden grader remains outside the recovery workspace.

That creates a realistic source-ownership problem without using software we do not own.

Capture is a product value, not a preliminary chore

A customer does not arrive with a perfect donor capsule.

They arrive with a URL, an installer, an extension package, an old laptop, a partial repository, a stale source map, a login, or a statement that “this is the version users still rely on.”

Turning that situation into stable, replayable evidence is one of the hardest and most valuable parts of the engagement.

KodeBack begins there.

Before asking a model to recover the source, preserve the truth it will need to be wrong against.