AI Clean-Room Rebuilds: The SPEC.md → Oracle Loop, and Where the Law Draws the Line
The clean-room loop is a method for reimplementing software from its observable behaviour: analyze the original, write a behaviour-only specification (often a SPEC.md), have a separate agent or team implement from the spec alone, then run the original and the rebuild side by side as an oracle and iterate until outputs match. It copies a technique with a long legal history — Phoenix Technologies' clean-room PC BIOS in the 1980s used a "dirty" team that wrote specs and a "clean" team that never saw the original code. AI makes the loop cheap, but it does not change the law. US courts have treated disassembly for interoperability as fair use (Sega v. Accolade, 1992; Sony v. Connectix, 2000), DMCA section 1201(f) has an interoperability exemption, and the EU Software Directive (2009/24/EC, Article 6) permits decompilation for interoperability under conditions. Against that: a licence that forbids reverse engineering can be enforced as a contract (Bowers v. Baystate, 2003), a clean room gives no protection against patents, and an AI that has read the original code is a poor "clean" implementer. For defenders, the lesson is that client-side logic is now cheap to replicate — protect what matters on the server.
The viral "AI reverse-engineering studio" post ends its tool list with one line that matters more than the other nineteen: "clean-room loop: SPEC.md, oracles and checks until it matches," and a pipeline — binary → REA → SPEC.md → rebuild → oracle → retry. That is a recipe for reimplementing software from its behaviour. It is not new as an idea. What is new is that an AI agent can now run all of it. (For the tools themselves, see our guide to the 20-tool studio.)
One clarification first: REA's own documentation says it explains how software works and does not recover original source code or clone apps. The rebuild loop is a separate method people layer on top, not something we could confirm REA ships.
How the loop works
- Observe. Analyze the original: decompile it, run it, capture its inputs and outputs, file formats and network traffic.
- Specify. Write a behaviour-only specification — what the program does, its interfaces, edge cases and error handling — without copying how it is written. A single
SPEC.mdat the repository root is the common convention. - Rebuild. A separate implementer writes new code from the specification alone.
- Check against the oracle. Run the original and the rebuild on the same inputs. The original is the oracle: any output difference is a defect in the rebuild.
- Retry. Feed the differences back, fix, and repeat until they match.
Steps 4 and 5 are differential testing — the same technique security tools use to prove a patch did not change intended behaviour.
The clean-room wall
The loop only earns the name "clean room" if the people who read the original never write the new code. In the 1980s Phoenix Technologies built a compatible PC BIOS this way: one team studied IBM's BIOS and wrote specifications; a second team, which had never seen IBM's code, implemented from those specifications. The separation was the legal evidence of independent creation.
With AI the equivalent is context separation: one agent reads the binary and writes the spec, a different agent with a fresh context implements from the spec only, and a log shows that nothing but the spec crossed over. Open-source tooling already implements this pattern — for example, the clean-room-skill project splits a "contaminated" analysis workspace from a clean implementation workspace with a one-way boundary. A single agent that read decompiled code and then wrote the rebuild has no wall, and its output is much closer to a copy.
Where the law draws the line
AI does not change the law; it changes how often people will test it. The key reference points (not legal advice):
- Disassembly for interoperability can be fair use (US). Sega v. Accolade (9th Cir. 1992) held that disassembling code to learn how to make compatible games was fair use; Sony Computer Entertainment v. Connectix (9th Cir. 2000) extended that to intermediate copying while building a compatible emulator.
- Reimplementing an interface can be fair use. Google v. Oracle (US Supreme Court, 2021) found Google's reimplementation of Java API declarations to be fair use.
- DMCA section 1201(f) permits circumventing protection measures to achieve interoperability of an independently created program, within limits.
- EU Software Directive 2009/24/EC, Article 6 permits decompilation when it is indispensable for interoperability, limited to the necessary parts, and the information may not be used to build a substantially similar program.
- Contracts can override it. Bowers v. Baystate (Fed. Cir. 2003) enforced a licence term prohibiting reverse engineering. Clicking "I agree" may have waived the rights above.
- A clean room does not touch patents. Independent creation is a copyright defence; a patent is infringed regardless.
- Trade secrets and terms of service are separate risks, especially for SaaS clients and online services.
Notice the recurring word: interoperability. The strongest legal footing is building something that works with another system. Rebuilding a competitor's product to sell as a substitute sits on much weaker ground.
What it means for defenders and vendors
- Client-side logic is now cheap to replicate. If behaviour is observable on the client, assume someone can specify and rebuild it. Keep pricing, fraud rules, model weights and keys server-side.
- Server-side authorization is the real control. A rebuilt client that understands your protocol perfectly should still get nothing it is not entitled to.
- Know which protection covers what. Copyright covers your code, not your behaviour. Patents, contracts and trademarks cover different things.
- Use the loop for good. The same method preserves abandoned software, builds compatible tools for proprietary formats, and documents legacy systems nobody understands anymore.
- Red-team yourself. Run the loop against your own app and measure how much of it an outsider could reconstruct.
Not legal advice. Case summaries are simplified; outcomes depend on facts and jurisdiction. Consult counsel before reverse engineering or reimplementing software you do not own.
Frequently asked questions
What is the clean-room loop?
It is a reimplementation workflow: (1) analyze the original program and capture its observable behaviour, (2) write a specification that describes what it does without copying how it does it (commonly a SPEC.md), (3) implement a new program from that specification alone, (4) run the original and the new version side by side on the same inputs as an oracle, and (5) fix the differences and repeat until the outputs match. AI agents can now run every step, which turns what used to be a months-long effort into days.
What is a clean-room wall and why does it matter?
In a classic clean-room design, the people (or agents) who examine the original are kept strictly separate from the people who write the new code. Only the behavioural specification crosses the wall. The point is evidentiary: if the implementers never saw the original code, the new code is independently created and is much harder to attack as a copy. Phoenix Technologies used this approach to build a compatible PC BIOS in the 1980s. With AI, the same separation means using different agents with different context: one that reads the binary and writes the spec, and one that only ever sees the spec. A single agent that read the decompiled code and then wrote the rebuild has no wall at all.
Is it legal to rebuild software with an AI clean-room loop?
It depends on what you rebuild, why, and where, and it is not settled for AI. In the US, courts have held that disassembly to achieve interoperability can be fair use (Sega v. Accolade, 1992; Sony Computer Entertainment v. Connectix, 2000), and the DMCA has a reverse-engineering exemption for interoperability (17 U.S.C. section 1201(f)). In the EU, Article 6 of the Software Directive (2009/24/EC) permits decompilation for interoperability under strict conditions. But a licence agreement that prohibits reverse engineering can be enforced as a contract (Bowers v. Baystate, 2003), a clean room offers no defence against patent infringement, and trade-secret and terms-of-service claims are separate risks. Get legal advice before rebuilding anything commercial. This is not legal advice.
Does a clean room protect against patent claims?
No. A clean room is a defence against copyright infringement claims because it shows independent creation. Patents protect the invention itself, regardless of whether you copied it or invented it independently, so a perfectly clean reimplementation can still infringe a patent.
What does an "oracle" mean in this context?
The oracle is the original program used as the source of truth. You feed the same inputs to the original and to the rebuild and compare the outputs; any difference is a bug in the rebuild. This is the same idea as differential testing, which security tools also use to validate patches — for example, systems like Google DeepMind CodeMender use differential testing to check that a fix did not change intended behaviour.
What should software vendors do about AI clean-room rebuilds?
Assume that anything running on the client can be studied and its behaviour reproduced. Keep the valuable parts on the server: business logic, pricing, anti-fraud rules, model weights and API keys. Rely on server-side authorization, not client checks. Use patents, contracts and trademarks where they fit, since copyright alone protects the code, not the behaviour. And test it on yourself: run an AI reverse-engineering setup against your own release builds to see how much an outsider could reconstruct.
Ready to practise the decisions these articles describe?
Run a free War Room →