Why Kalu Kode Exists

Software can keep running long after engineering control has been lost.

A website may still serve customers even though its repository is missing. A desktop application may still install even though nobody can rebuild the package. A browser extension may still perform valuable work even though the source is incomplete, the original vendor is gone, or production contains changes that never reached version control.

The software exists. The business depends on it. But the organization no longer has a trustworthy path to understand or change it.

At the same time, a second problem is growing quickly.

AI coding agents can now make large changes in minutes. They can split a monolith, move packages, rewrite imports, remove code, and produce a confident explanation of what they did. That speed is real and useful.

But the agent’s confidence is not independent evidence.

A build can pass while a public export disappears. Tests can pass while an initialization order changes. A page can load while one important interaction no longer works. A refactor can look cleaner while it leaves a compatibility bridge that defeats the intended hard cut. An agent can even declare completion without having transferred the candidate it believes it finished.

Kalu Kode exists because both problems have the same missing layer: evidence and control.

Two products, one principle

We are building two products first.

KodeBack is for deployed-software source recovery.

It is intended for cases where a team owns or is authorized to recover an application, but the usable source is missing, stale, incomplete, or no longer matches production. The objective is not to reconstruct the original developer’s exact keystrokes. The objective is to produce a maintainable candidate workspace, preserve the evidence that supports it, and state clearly what remains unresolved.

KodeProof is for controlled AI code changes.

It places a risky change inside a declared transaction. The product captures the real before-state, isolates the candidate, gives the agent bounded decisions, uses deterministic actuators where the operation is covered, runs multiple evidence layers, and transfers only when the configured contract is satisfied.

The products solve different problems, but they share one operating principle:

Facts first. Judgment only where necessary. Verification always.

Why a stronger model is not the entire answer

A more capable AI model can reason better. It may choose clearer names, notice more connections, and recover from ambiguity more effectively.

But intelligence cannot create information that was never collected.

A model cannot know which runtime state the deployed application reached if nobody captured it. It cannot prove that a recovered candidate matches the donor if the two were never run against the same declared flow. It cannot know that a short string is a storage key, event name, serialized field, shader uniform, IPC channel, or public route if the workflow never identified that surface as protected.

The same is true in a refactor.

A model cannot independently prove its own task completion when the task, implementation, explanation, and confidence all come from the same process. It needs an immutable before-state, an external declaration of intent, controlled mutation, and evidence that can disagree with it.

This is why our work is not centered on building another general-purpose coding agent.

The model will keep changing. The durable value is the system around it.

What Kalu Kode means by evidence

Evidence is not one green badge.

For recovery, it may include:

• an immutable donor capture;
• source-map coverage and provenance;
• asset and route inventory;
• package and runtime fingerprints;
• first-party, vendor, and ambiguous ownership;
• protected contracts;
• runtime values and object shapes;
• storage, network, worker, IPC, or extension-context behavior;
• browser, scene, console, and project checks;
• a record of accepted changes and remaining seams.

For a risky code change, it may include:

• the exact before-state;
• the declared files, symbols, entrypoints, and behavior scenarios;
• a source-backed structural plan;
• the candidate diff and unexpected-file inventory;
• import, export, module-load, cycle, effect, and order checks;
• affected tests and full project gates;
• independent task grading;
• a verified transfer receipt—or a retained blocked candidate.

Different evidence answers different questions. We do not want to compress all of it into one claim that something is simply “safe.”

What we are not claiming

Kalu Kode is a research-stage company.

We do not have customers yet. We are pre-revenue. We have not established product-market fit. The products have substantial internal engineering and dogfood behind them, but internal success is not buyer validation.

KodeBack does not recover every application. It cannot recover private server implementation that was never shipped. It does not promise exact historical source, perfect parity, or one-click reconstruction.

KodeProof does not prove that AI-generated code is correct. It does not replace tests, security review, or engineering judgment. It can block valid work, and false blocks are a first-class measurement problem rather than something we intend to hide.

Those limitations are not footnotes to add after the marketing. They are part of the product definition.

Why we are going public now

The company has spent most of its life in private engineering and research.

That was useful for building the pipeline, but it creates a commercial blind spot. A technically interesting system is not automatically a valuable product. A strong internal workflow is not automatically a buying process. The language engineers use inside a repository is not necessarily the language a CTO, agency owner, or platform lead uses when the problem becomes urgent.

Going public now has three purposes.

First, we need to make the thesis understandable.

Second, we need to show controlled evidence from software we own and synthetic applications whose ground truth is known.

Third, we need to meet people who have the real problem: a deployed application with a source-ownership gap, or a high-risk agent-driven refactor whose failure would be expensive.

What we will publish

The Kalu Kode Journal will focus on:

• why shipped software is not the same thing as maintainable source;
• why recovery begins with capture rather than code generation;
• how bundled dependencies are separated from authored logic;
• why AI agents rename protected contracts;
• why build-green does not mean behavior-green;
• how bounded judgment and deterministic mutation can work together;
• how we evaluate catches, false blocks, cost, and false confidence;
• what we learn from building as a bootstrapped, single-founder company.

Demonstrations will be labeled as owned, synthetic, or internal. When a result has a gap, the gap belongs in the result.

What we are looking for

For KodeBack, we are beginning a limited number of conversations about paid source-recoverability assessments. A strong fit is an organization with clear authorization, a deployed application that still matters, an incomplete or untrusted source position, a technical owner, and a real reason to solve the problem now.

For KodeProof, we are looking for a small number of JavaScript/TypeScript teams willing to evaluate one bounded, risky refactor and review the whole outcome: task quality, catches, false blocks, workflow cost, and transfer behavior.

We are not looking for generic beta signups.

We are looking for the first situations where the evidence system changes a real engineering decision.

That is the work ahead.