697 Functions in 12 Days, and One Bug That Passed Every Test - the Real Story of the AI Reverse-Engineering Wave

In early October 2026, a wave swept through the dev and AI-agent community after Replit’s CEO posted that "soon all software will be open-source by default," followed by Matthew Berman writing simply "Software is done" beneath a screenshot of a GitHub repo with over a hundred thousand stars.

That repo was REA (Reverse Engineer Anything) - a tool that lets coding agents "look inside" programs you have no source code for, down to machine code, running locally without uploading anything to a server. But the really interesting story is not the star count - it is the one bug that slipped past every test.

REA in 60 seconds

REA is an MCP server + CLI (MIT license) that lets an agent ask questions about a program on your machine; it loads it into the right engine (Hopper, Ghidra, IDA for native, or its own analyzers for JS/Electron, .NET, APK, and more) and returns results with evidence: functions, call sites, and what remains unknown. It works with Claude Code, Cursor, Codex, VS Code, Grok Build and others, across Electron apps, native binaries, games, websites, even firmware.

It is built for security research, interoperability, education, and auditing software you are entitled to inspect - with a clear line: no help bypassing DRM, anti-cheat, or license checks, and no copying proprietary code.

The legend of "decompiling the whole Adobe suite"

At the peak of REA mania, a story circulated that someone had decompiled the Adobe suite and built open-source replacements. The reality was different: the ArtCraft team built native Rust apps clean-room style (PhotoCraft, LightCraft, FilmCraft, and so on), with rules in AGENTS.md forbidding reading, disassembling, or copying anything from Adobe application bundles - only observing behavior from the outside.

This is the classic clean-room approach Compaq used for the IBM PC BIOS in the 1980s, which courts have repeatedly affirmed: "understanding" enjoys far more protection than "copying."

The oracle - the judge of what is "true"

The most important part of agent-driven reverse engineering is not reading code - it is the oracle, the checker that decides whether a rebuild is actually correct. Oracles come in several flavors:

• Byte oracle: compare machine code byte by byte
• Behaviour oracle: feed identical inputs and compare outputs
• Runtime oracle: run the real program and observe behavior

A clear example is DX-Ball, where an agent rebuilt the left-right sound balance function, passing 3,205 test cases and matching every one of 63 bytes exactly.

Far more interesting is the bug that fooled the oracle, from N0zoM1z0’s Touhou (TH08) rebuild. One function passed exact byte comparison - yet the auto-collect item system was later found buggy: the original checked power at 128.0 while the rebuilt code checked 0.0. Why did it pass? The comparison tool adjusted addresses before comparing instructions but never inspected the actual floating-point constant stored there. The instructions matched; the meaning did not.

The lesson: you must test the oracle too. A blind spot in the checker silently certifies hundreds of wrong functions as correct.

The reverse-engineering factory - why the second game took only 12 days

From N0zoM1z0’s experience: TH08 started from community groundwork and took about 11 days to fully rebuild 1,107 functions plus a playable Linux port, while TH095 started from zero and took about 12 days for 697 functions. Why faster? Because checks, notes, and lessons from the previous game had accumulated in the repo.

The factory’s four rules:

1. Give the agent freedom to explore, with explicit goals and acceptance criteria
2. Use the repo + git as long-term memory (conversations end; the repo remains)
3. Let evidence decide - "unknown" is a valid answer
4. Test the oracle too

The multi-agent architecture powering the factory

The future of AI-assisted engineering is not just a bigger model - it is orchestrating a multi-agent system specialized by speed, context efficiency, and reasoning capacity. Instead of throwing every token at one expensive LLM, this style of work (following the Claude Code sub-agents approach) runs a lean team:

• Sonnet 5.5 (The Builder): the session lead - coordinates the workflow, generates code, and applies changes to the codebase
• Haiku 5.5 (The Swarm): sub-agents in throwaway contexts doing search (repo mapping), grep (call sites), and audit (diff review) without polluting the main context
• Opus 5.5 (The Advisor): on call only for high stakes - before locking a plan, after a recurring error, or before final sign-off
• JEV (The Router): resolves micro-forks (tool choice, file paths, retries) in single-digit milliseconds, escalating only genuinely multi-branch decisions

The technical payoffs are context window hygiene (noisy tool output stays in sub-contexts), cost efficiency (Opus-level tokens reserved for real decisions, not routine file reads), and safe auditing (the audit agent runs in an isolated git worktree, never touching your working branch).

Working clean-room with agents

Split into two rooms: Room A (Reader) uses REA to analyze and writes SPEC.md (behavior, inputs/outputs, edge cases) without leaking code or addresses; Room B (Builder) is a fresh session in a separate folder that receives only SPEC.md and writes new code. Use Claude Code’s /goal to make the agent loop until conditions pass - and plant three known failures inside the oracle to verify the checker still works.

Limitations and the lines that matter

• It reads only code on your machine (nothing server-side)
• Output is a reconstruction, not the original source
• Models like Opus 5.5 carry cybersecurity safeguards and will refuse work that looks like cracking or bypassing
• Understanding + building your own version = the legal path (clean room); taking someone’s features without paying, or copying code = not

Conclusion

Berman was half right - the notion that "closed software means unknowable" is ending. You can explain any feature on your own machine with evidence within an afternoon. What has not ended is the difference between "reading" and "taking" - and what decides whether a rebuild actually works is not the AI model but the oracle, and your willingness to test the oracle itself.

Build the verification system first. Then read anything you like.