Born at ZAR

XP was born on Chrysler's C3 payroll project. IMP was born at ZAR, where Obie is CTO. We're a financial technology company. People depend on what we build, so it has to be right.

The experiments

In September 2026, Obie deleted substantial components from Agora, our agent orchestration platform. Claude Code regenerated each one, working only from a written intent, a set of decision records and an executable Contract. It regenerated without access to the old code.

7

regeneration experiments

9

days

3

components of Agora, deleted and rebuilt

1

production bug found, and fixed through the Contract

Obie ran the experiments himself, in an interactive Claude Code session, working with Claude. Fresh agents did the regenerations. Each one worked in its own isolated worktree. The old code and its spec were off limits, along with the git history.

Agora is a Rails app. The first component was a small module with the densest incident history per line of anything in Agora. Next came one that keeps its state in a cache. The hardest was the family of methods that reboots an agent, where the behavior is an ordered run of side effects across several classes.

The experiments started from Chad Fowler's deletion test, which he puts as a question: "If I deleted this codebase and regenerated it from scratch, what would I rely on to decide whether the result was correct?" (The Deletion Test, Chad Fowler, 2026)

In Agora the Contract has three parts. An intent document describes one component, down to the invariants it must keep and the reason for each. Decision records hold the reasons behind the choices. As the method write-up puts it, "Version control says what changed; a record says why." The contract spec is the executable part, and every example in it has to pass one membership test:

Would reimplementing the component in another language invalidate this assertion? If yes, it is an implementation test and belongs in the ordinary spec.

Each regeneration was scored against the old code on behavior. In the experiments that made a change, the change went into the Contract first and got run against the unchanged code. In the writeup's words, "That red is the change request stated as tests."

It found a real bug

One experiment found that a human admin's click during an agent reboot cycle was getting lost in production. It was fixed in the next run.

It turned up while the Contract for the reboot family was being written, at the obligation that says an operator's Stop landing mid-reboot wins. The admin-triggered reboot cleared the stop flag up front and started the agent again regardless. The four reboots the platform starts on its own did check again. A Stop clicked during a Reboot's stop window left a session that was starting and marked stopped at the same time, and the platform would not revive it if the boot died.

At first the Contract described the code as it was and recorded the question. The next experiment made the fix through the Contract. The new obligation went in first, and three examples went red against the unchanged code. Then the code changed to match. The diff that shipped was a plain edit, made alongside the regenerations as a control, because it was the smallest change to code that production had already hardened. The admin Reboot message now says when a Stop won.

The rule behind it is rule 28: when a bug is found, the Contract was missing something.

The contract outperformed the old spec

Mutation testing showed the executable contract, written from the component's promises, catching more broken code than the Rspec suite of tests belonging to the old implementation.

Mutation testing breaks the code on purpose, one small change at a time, and counts how many of the broken versions a suite catches. The same mutations ran against the same original code twice, once judged by the old spec and once by the Contract. Every time the two were compared, the Contract caught more.

The old spec had absorbed the habits of the code it was written against. When the reboot family's old spec ran against the regenerations, the writeup called it "a museum of the old implementation". Twelve of one rebuild's twenty failures stubbed a private method by name, and six checked the wording of a prompt. "Zero were behavioral."

Every gap helped flesh out the Contract

Wherever the intent didn't say something, the regenerations made unpredictable choices. Each of those gaps became a sentence in the next revision of the Contract.

Every regenerator kept a notes file listing each ambiguity it hit and what it chose. The method write-up says what those notes are for:

Every regenerator question is a missing sentence. The notes from one round are the diff to the intent for the next.

On the reboot family, every divergence in the first round came down to a missing sentence, mostly about order. The original cleared the overflow counter as the first thing a reboot does, before any of its checks. All three rebuilds cleared it later. With those sentences added, the second round's rebuilds matched the original on every recorded scenario.

On the first module, the intent said a limit could be any "positive numeric" value, and five of six rebuilds across two runs accepted whole numbers only. The finding: "a regenerator makes every silence in the intent into a coin flip, and the grid is what finds the coins."

Some gaps sat in the reasons. On that same module the decision values were written into the intent, and every rebuild still asked whether they were tuned or placeholders. "The decision values were in the intent and still looked arbitrary, because the analysis that makes them non-arbitrary was one link away." The checklist for the next component got a new line: "Include the derivation behind each decision, not only its value."

The tests could leave gaps too. One rebuild passed every contract example and still behaved differently from the original, because the intent excluded a method in so many words while the contract only left it out. "A statement in the intent with no example behind it is a promise on paper."