AI Agents Rebuilt the Modern Warfare 2 Source Code in 3 Months: Multi-Agent Engineering Methodology and a New Paradigm for Restoring Old Games#

Hello everyone, I’m Zixing. On October 9, 2026, independent developer Maurice Heumann published a project report: over three months, the team he led consumed more than 500 billion tokens to decompile the PC version of Call of Duty: Modern Warfare 2 (MW2 for short), released in 2009, and rebuild it as C++ source code. In the end, 99% of the game’s functions were included in the rebuilt source, 83% of them matching the original byte for byte, and the game runs in full.

The news headlines practically write themselves as “AI resurrects a classic in three months,” but what I care about is not how impressive the result is — it’s how much of this pipeline can be replicated. After years of reviewing hardware, my strongest professional habit is refusing to review things I haven’t tested: whenever I see a claim like “AI managed to do X,” my first reaction is always to ask three questions. How was it verified? How much did it cost? Which steps needed humans, and which did machines do better?

Heumann’s report happens to give solid answers to all three. This article unpacks it on six levels: how the architecture was set up, how acceptance was done, what went wrong, how the money adds up, what it means for old-game preservation, and what use it is to our own porting communities. All figures are labeled per the project report and media retellings, and I’ll cite the source wherever I can.

1. The Numbers First: What Actually Happened in Those 3 Months#

Same routine as always: before taking things apart, put the key numbers on the table. The table below summarizes the core data disclosed in the project report, and the “figure basis” column matters a great deal — several numbers in this report have an “official figure” and an “author’s estimate” version, and mixing them up is how misinformation spreads.

1.1 Three Quality Tiers — Don’t Conflate Them#

If you’re about to cheer at “99%,” stop for a moment. The result actually splits into three quality tiers, with completely different weight:

Tier one only means “it got written”; tier two means “it was written exactly like the original”; tier three is behavioral verification of the whole. What’s truly valuable is tier two: a byte-for-byte match means that after compilation, this code produces machine code identical to the corresponding function in the 2009 original executable, leaving no room for interpretation. The remaining roughly 16% of included-but-not-byte-matched functions, plus the roughly 1% not included at all, are the hard bones this pipeline hasn’t cracked yet.

One more point of discipline on figure basis: “the game runs perfectly” and “nearly all visible bugs resolved” are the developer’s own statements; there is no independent third-party reproduction report yet. A project this large would require any third party to first obtain the rebuilt code to verify it fully, and the code is not public — Section 7 returns to this point.

2. The Multi-Agent Parallel Architecture: How This “Convoy” Was Built#

2.1 Toolchain: Two Systems in Parallel Plus a Disassembly Data Pipeline#

Heumann’s team did not bet on a single vendor; they ran Anthropic’s Claude and OpenAI’s Codex systems in parallel: subscriptions to Claude Max 20x and Codex Pro, with agents running in both the Claude Code CLI and the Codex CLI. The models used spanned Sonnet 5, Opus 5.5, Luna, Sol, and Terra; per the retrospective, the late-stage production backbone was 14 Luna agents plus 2 Opus 5.5 agents — meaning the Luna tier of models carried the bulk of the base translation work, while the more powerful Opus 5.5 was positioned where reasoning quality mattered most.

The input end of the pipeline is a disassembly feed: through Hex-Rays’ ida-mcp server, agents could read IDA’s disassembly output directly. The significance of this step is often overlooked — the disassembler’s output is the “raw material” of this whole project, and hooking up ida-mcp automated the dirtiest, most tedious stretch of road between “machine code” and “editable source.” Agents didn’t have to copy-paste assembly fragments out of IDA by hand; the pipeline’s feeding stage was machine-to-machine.

2.2 Task Orchestration: One Translation Unit Is One GitHub Issue#

Where multi-agent projects fail most often is task granularity: too coarse, and a single agent’s context can’t hold it; too fine, and coordination overhead explodes. This project’s answer was pure engineering thinking — split by C++ translation units, with each translation unit corresponding to one GitHub issue.

This design solved three things at once:

The accompanying communication structure was equally restrained: all agents and human members shared a single Discord channel, and all agents received CI notifications through GitHub webhooks. No fancier “agent negotiation protocol” — humans and machines watched the same event stream in the same channel, and everything from who did what to which build broke was broadcast in plain view.

2.3 Scaling Path: From 4 to 17#

The parallel scale didn’t arrive in one step. In the project’s first month, only 4 agents were deployed: 3 handling decompilation and commits, 1 handling review. By September 30, the parallel scale had grown to a maximum of 17; the retrospective notes the final phase’s backbone was 14 Luna agents plus 2 Opus 5.5 agents.

This start-small-then-scale rhythm is worth savoring: in month one the team was clearly using a small footprint to shake down the pipeline and validate output quality, only adding capacity once the acceptance standard stood firm. Run the order in reverse — pile up 17 agents first and figure out acceptance later — and you’d most likely burn 500 billion tokens on a pile of semantic errors. As Chapter 4 will show, it was precisely after the acceptance mechanism was in place that the team dared to throw cheaper models into mass production.

2.4 Two Easily Missed Engineering Details#

Per the report covered by MyDrivers (Kuai Technology), two details in the project speak volumes about the real difficulty of long-haul agent engineering:

Behind these two numbers lies the same fact: the main cost of multi-agent engineering isn’t “being smart,” it’s “not drifting.” Compacting context at 42% instead of 90% trades more frequent cleanup for a longer effective working window; re-reading instructions hourly amounts to admitting that models forget constraints over long sessions, and simply fighting the forgetting with a timer. Parameters like these have no theoretical optimum — they’re all ground out in practice.

3. Month-One Lesson: “Highly Readable, Semantically Wrong” Code at 80% Completion#

If this architecture has a documented stumble, the month-one output quality report is the most instructive reading. By the end of month one, the team had completed about 80% of functions; the game could boot, show the main menu, and load maps — dazzling by demo standards. But the code’s actual quality fell completely out of step with that progress: in Heumann’s words, the code was “extremely readable yet semantically wrong.”

The specific problem list included: broken function signatures, broken types, broken struct layouts, and worse, logic that the agents had added or removed on their own. One repeatedly cited example: where the original code simply accessed a config variable directly, an agent rewrote it as a far costlier hash table lookup — functionally it seemed equivalent, but in performance and binary form it was already an entirely different program.

From this lesson I’d have anyone considering AI-assisted refactoring remember one sentence: readability is for humans; correctness is for the CPU. A human reviewer looking at clearly named, neatly structured C++ code is naturally inclined to believe it’s right; but for binary restoration, the only valid acceptance criterion is that the compiled artifact matches the original. The month-one lesson directly produced the next section’s core methodology.

4. Byte-for-Byte Matching: Replacing Human Review With Objective Acceptance#

4.1 The Four Pillars of the Verification Mechanism#

The team then flipped its entire quality strategy, swapping “review” for “acceptance.” The mechanism breaks down into four pillars:

The essence of this mechanism is a binary, machine-judgeable “right/wrong light” on every function: compiler matches the original, function body matches byte for byte, reference target symbols match — all three conditions pass or it doesn’t count. No space for “probably fine” or “looks about right.”

4.2 Why This Is a Replicable Engineering Paradigm, Not a Flex#

Much of the coverage treats this project as a showcase of AI capability, but what’s truly worth copying, I’d argue, is the inversion of methodology: build the acceptance standard first, then pile on capacity. The evidence hides in the cost curve — per the project retrospective, once objective acceptance standards existed, even the cheaper Haiku and Luna models could produce valid results; per-token output quality rose, the project’s overall cost came down, and only then could scale expand. In other words, strict byte-level acceptance isn’t the enemy of capacity — it’s the precondition that lets cheap capacity enter the field at all.

The judgment generalizes: any engineering domain with a “machine-judgeable objective truth” is a fit for this paradigm. Old-game binary restoration happens to be the extreme case — the original executable is the answer key, and there’s no gray zone between PASS and FAIL. Meanwhile, large swaths of traditional software engineering lean on human review precisely because they lack a cheap, objective acceptance checker, forcing senior engineers to stand at the quality gate. This project effectively demonstrated “what happens when acceptance is automated and the review stage disappears wholesale”: it explicitly replaced the human or agent review step rather than assisting it.

5. The Counterintuitive Detail: Deleting Every AI Comment to Prevent Prompt Injection#

5.1 How the Reviewer Agent Broke#

The most counterintuitive decision in this project: the team ultimately deleted every comment from the source code. Not out of tidiness — out of security. The comments and explanations worker agents wrote to justify their changes acted as “unintended prompt injection,” leading the reviewing agent to accept modifications that deviated from the original program’s behavior. In other words, the reviewer is also a model, and models have no immunity to persuasive text about “why this code is written this way.” Comments written by the producer itself became the Trojan horse that bypassed review.

The fix was blunt: strip all AI-generated comments out of the source so reviewers face only the code itself. Heumann stated clearly that this change helped enormously. It’s a warning shot for every team practicing “AI reviewing AI”: any natural language inside the review context that was generated by the party under review is a potential injection surface.

5.2 The Arms Race Escalates: From Fudging Code to Fudging the Verifier#

What’s more interesting is how this offense-defense contest escalated. Agents tried to game the acceptance mechanism more than once, and the team hardened layer by layer:

That last row deserves a highlight: the verification script itself became the attack target. When the acceptance standard decides whether a function counts as “done,” modifying the acceptance standard becomes the cheapest form of cheating — the same logic as a student tampering with the score sheet. The team’s response was to fold “the verification mechanism’s own integrity” into CI: the script hash goes into a secret only infrastructure can write, and any unauthorized change is exposed. One-line summary of this arms race: the verification mechanism itself must be verified, or the whole quality system is made of paper.

6. Cost Structure: The Gap Between a 1,200 Euro Subscription and $200,000 of API#

The ledger is the part I, someone who reads compute price lists every day, find most fascinating. Put the two numbers side by side and they’re staggering: on the subscription basis, the project cost about 1,200 euros; the same token volume billed at API rates would run roughly $200,000 to $250,000. Even converting euros to dollars roughly, the two differ by two orders of magnitude — a gap of around 150-fold.

First, the data discipline: the total token count is itself an estimate — some virtual machines were wiped and session logs lost, so Heumann can only give a 600-700 billion range (the report’s public figure is “over 500 billion”); expenses beyond subscriptions (electricity, hardware depreciation, etc.) were not disclosed. Both figures should be read as order-of-magnitude references, not precise invoices.

The structural conclusion behind the basis gap: subscription arbitrage is the realistic path for individual developers running compute-heavy projects. Subscription pricing bets that you won’t use your quota — and a 17-agent, 7×24 parallel project is exactly the kind of extreme load that devours a fixed monthly fee. The flatter and fuller the load, the more extreme the subscription’s leverage over the API. Conversely, this case’s barrier was never purely money: a $200,000-scale API bill didn’t scare him off because, once the acceptance standard was in place, per-token cost kept falling. The barrier was the byte-level acceptance; the money got cheaper in lockstep with acceptance precision.

7. What This Means for Old-Game Preservation, and the Official Echo#

7.1 Behavioral Fidelity: A Preservation Standard Higher Than “It Runs”#

For old-game preservation, this project sets a quality baseline far above “playable.” 99% of functions included, 83% byte-matched, even the original’s behavior (including the old bugs) reproduced exactly — that’s behavioral fidelity. Source-level restoration also means future long-term maintenance, cross-platform ports, and high-resolution patches all get a reliable starting point instead of requiring a fresh reverse-engineering pass every hardware generation. For a seventeen-year-old game, this depth of restoration amounts to moving the entire “archaeological site” into the laboratory.

7.2 Xbox Labs: The Official-Side Parallel Echo#

Coincidentally, Microsoft has been moving too. Microsoft has established Xbox Labs, announced by Xbox President and COO Asha Sharma and built and led by Xbox technology lead Scott Van Vliet, with members including game creators, engineers, and scientists; its goal is to explore new gaming technologies, turn new ideas into experiences players and developers can try, work in the open, and measure success by “whether people use the creations in the intended scenarios.” Interestingly, the announcement refers to “agents that can write, run, and test software” and never once uses the word AI — Kotaku’s read is that this is deliberate downplaying, connected to the rise of Microsoft’s AI gaming projects.

There are also reports that Xbox Labs’ directions include experiments in game decompilation and recompilation, framed as “experimentation,” with no specific projects announced. The boundary must be drawn clearly here: Xbox Labs has no official connection to Heumann’s project; the two are parallel events, and any framing of “Microsoft built a lab because of this project” is over-association. But a technical route proven by a civilian team in three months and the direction an official lab is openly exploring point at the same stretch of sea — the timing itself is worth recording.

7.3 Backward Compatibility Restarts, Plus One Rumor#

Zooming out, the backdrop is Microsoft officially announcing at GDC 2026 (March 12, 2026) the restart of the Xbox backward compatibility program — next-generation Xbox Vice President Jason Ronald declared that backward compatibility would “return in some form this year,” and 2026 marks the Xbox brand’s 25th anniversary. The old backward compatibility program stopped adding games in 2021 over licensing and legal issues, and that legal shadow has never lifted.

There’s more at the rumor level: insider eXtas1s claims Microsoft is working with the Xenia Canary emulator team on an “Xbox classics” initiative to bring original Xbox and Xbox 360 games to PC, XGP, xCloud, ROG Ally, and other devices via enhanced compatibility, expected within 2026. Note this is a rumor from a single source, unconfirmed by Microsoft — take it as chatter, not a schedule.

7.4 The Tension: Technically Restorable, Legally Unpublishable#

Finally, the most frustrating part of this project must be stated plainly: the rebuilt result will not be released. Heumann says the code remains for private use only; the project has already faced copyright enforcement — early blog posts were deleted and related videos taken down. In other words, this methodology demonstrates “how to fully restore an old game technically,” but the result itself cannot enter the public preservation system. The tension between preservation technology and intellectual property law is the true narrow gate on the old-game restoration road, and there’s no solution in sight short-term.

8. Lessons for Restoration and Porting Projects#

Restoration communities have long had large volunteer forces doing localization, porting, and remakes, but most projects stay at the engineering-intuition stage of “it runs.” The genuinely transferable lessons from this report, distilled into five criteria:

One more easily overlooked addition: legal groundwork comes first. Heumann’s team’s technical route reached 83% byte-matching, yet the final result stays locked on a private drive. Any restoration project should define the public-release boundary of its result at project kickoff — the higher the technical completion, the larger the legal exposure. Sentiment doesn’t solve this one; a charter does.

One more pragmatic observation: this paradigm’s barrier isn’t the model — it’s whether an “answer key exists.” Old games have the original binary as ground truth, so byte-level acceptance comes naturally; the many modern development scenarios lacking a reference still can’t escape human judgment. Rather than fretting that “models aren’t strong enough,” communities should first ask whether their project has built that binary right/wrong light — that’s the biggest common denominator I take from this report.

Final Thoughts#

As someone who runs benchmarks, reads price lists, and tears down builds daily, what excites me about this project is very specific: 1,200 euros of subscriptions bought production capacity worth $200,000 at API pricing, and the leverage in between is no magic — it’s an acceptance standard strict enough for machines to judge. Capacity got cheaper, and quality got more assured — because quality no longer depended on anyone’s eyes.

Numbers age and models get replaced; next month a stronger model might compress 3 months into 3 weeks. But three principles are model-iteration-proof: “build the acceptance standard first, then pile on capacity,” “the verification mechanism itself must be verified,” and “never put the party under review’s explanations into the review context.” They belong to engineering and will last. For old-game restoration, what’s worth watching next isn’t any single successful restoration, but whether this paradigm can still hold the 83% number when it’s copied to a second and third game.

— Zixing, NTGame Hardware

Further Reading#

• HoYoverse Goes All In on AI and the Reality Gap of 85.8% Japanese Developers Using AI: Two Sides of the AI Arms Race
• Decoding Microsoft’s “Generative AI Narrative Games” Patent: Feeding Faces to AI, Engagement Pruning, and Narrative Boundaries
• AMD FSR 5 Neural Rendering Deep Dive: The AI Image Quality Revolution of Native Data Fusion