Maurice Heumann used AI agents from Claude and Codex for three months, feeding them more than 500 billion tokens in total to recreate the C++ code of Call of Duty: Modern Warfare 2 (2009).
The game’s functions are now approximately 99% complete, with 83% matching the original files byte-for-byte. The difficult part was not simply getting AI to write code, but verifying that the code actually worked correctly.
What the project has achieved
The project recreates C++ code from the original 2009 PC game, aiming for an accurate, stable, and feature-complete version—not merely code that compiles, but code that can be verified to behave like the original.
After three months of continuous work and more than 500 billion tokens, the game is fully playable. Most visible bugs have been eliminated, with only a few remaining. In other words, the AI agents brought the game back to a genuinely playable state rather than merely helping write parts of the code.
What to look for in the recreation
The illustration should be split into two sides: one showing the original 2009 PC game, and the other showing the recreated C++ code alongside IDA and Hex-Rays’ ida-mcp, which the agents used to read the original code.
Another image should convey the collaborative workflow of 17 agents through GitHub issues, Discord, and CI, including an automated check that compares functions with the executable at the byte level. This should make clear that the project did not merely check whether the code compiled—it also verified how closely it matched the original.
The real problem was not writing code
Heumann found that AI agents could write code quickly, but the more difficult problem was proving that the code was actually correct. The first month’s code was “easy to read but semantically wrong,” with incorrect function signatures, types, and struct layouts, as well as logic that had been invented or omitted.
At the time, the reviewer agent could not stop these problems because there were no clear acceptance criteria. Worse, comments written by the agents to explain code changes unintentionally acted like prompt injections, so the team had to remove the comments to make verification more accurate.
Where Claude and Codex fit into the workflow
[Original PC game] → [IDA + Hex-Rays’ ida-mcp] → [Claude / Codex agents] → [Rewritten C++] → [Comparison against executable]
Heumann used Anthropic’s Claude and OpenAI’s Codex simultaneously, controlling them through the Claude Code CLI and Codex CLI. IDA provided a way for the agents to read the original code through Hex-Rays’ ida-mcp. Put simply, Claude and Codex handled the translation and code writing, while IDA served as the source of information from the original game.
From four agents to 17 working in parallel
| Work period | Structure |
|---|---|
| Initial stage | Three workers and one reviewer |
| September 30 | Seventeen agents working in parallel |
At first, the roles were clearly divided: workers translated the code while the reviewer checked their work. As the project grew, Heumann increased the number of agents until 17 were working simultaneously.
However, the original data does not separate results by the number of agents, so it is not yet possible to conclude how much adding more agents improved speed or accuracy.
When visual inspection was not enough
The early code was easy to read, but visual inspection could still miss problems, such as incorrect function signatures, mismatched data types or structures, and logic that had been recreated or removed.
The agents sometimes also changed the architecture unnecessarily, such as making config-variable lookups far more expensive. The code looked polished but did not behave like the original.
The problem was that the reviewer had no measurable acceptance criteria. A script was therefore needed to compare functions with the game executable at the byte level and clearly determine whether they passed or failed.
How the byte-level verification system changed the project
The verification system begins by compiling the recreated code with the same compiler used for the original game. Each function is then sent to a script for byte-level comparison against the executable.
C++ code → same compiler → compare functions → pass/fail
Differences in addresses used by calls and data references are skipped, while target symbols and offsets are checked instead. Data and types continue to be checked in the same way. This makes it possible to distinguish code that genuinely matches the original from code that merely looks similar.
Tools and workflows that kept the project moving
| Tool | How it was used |
|---|---|
| GitHub issue | Separate issues for each translation unit |
| Discord | Let agents and humans communicate in the same channel |
| GitHub webhook CI | Post work results to Discord |
| Auto-compaction | Reduce usage from 90% to 42% of the context window to clear completed functions |
| Cron job | Instruct agents to reread the instructions every hour, addressing context drift |
This structure made it easier to track the work even with multiple agents operating simultaneously, while also reducing the chance that an agent would drift away from the original goal as the project continued.
How much difference did the tools in the same stack make?
| Tool | Role | Cost | Stated usage |
|---|---|---|---|
| Claude Max | Anthropic subscription plan | Flat-rate 20x plan, not priced per API token | Used with Codex Pro |
| Codex Pro | OpenAI subscription plan | Flat-rate, not priced per API token | Used alongside Claude Max |
| Claude Code CLI | Harness for directing the agent | No separate price specified | Used as the primary work tool |
| Codex CLI | Harness for directing the agent | No separate price specified | Used as the primary tool alongside Claude Code |
| ida-mcp | Connector to Hex-Rays’ IDA | No price specified | Allows the agent to read code from the original game |
Based on this information, these tools do not fully substitute for one another. The subscription plans allocate access to models, the CLIs control the work, and ida-mcp provides the agents with access to the original code.
Extreme cost differences depending on the payment method
Claude Max and Codex Pro are flat-rate plans rather than API services billed by token count. This setup allowed Heumann to run many agents without paying more for every individual instruction.
| Payment method | Approximate cost |
|---|---|
| Subscription | Around €1,200 |
| API tokens | $200,000–$250,000 |
These figures are Heumann’s own estimates, so they should be viewed as a cost comparison rather than fixed prices. The same project could have dramatically different costs depending on whether it used a flat-rate subscription or pay-as-you-go API billing.
Strengths and limitations revealed by the project
- The main strength is that multiple agents can work in parallel and move faster, growing from four agents initially to 17, while bringing the game back to a playable state with nearly all visible bugs eliminated.
- The key limitation is that the early code was easy to read but semantically incorrect, including problems with function signatures, types, and data structures.
- The agents also experienced drift and were influenced by comments that acted like prompt injections. The team therefore had to remove the comments, and after spending four weeks trying to recover the code, they found that starting over took less time.
- The lesson is that generating code is not as difficult as verifying that the code is correct.
What remains after the game became playable
The latest status is that the game is fully playable. Most visible bugs have been eliminated, with only a few remaining, while 99% of the functions are already present and 83% match the original byte-for-byte.
The documentation also has limitations: two blog posts about the project were deleted, and the video in the September 30 post was disabled after being reported by the copyright holder. In short, the code is nearly finished, but the rights issues are not.
Lessons from making AI prove itself
The turning point was not adding more agents, but creating objective verification criteria. The first batch of code was easy to read but semantically wrong, including incorrect function signatures, types, and struct layouts. Meanwhile, the reviewer could not stop the problems without clear acceptance criteria.
The team therefore used the same compiler as the original game and compared each function at the byte level, producing a pass/fail result while skipping differing addresses and checking symbols and offsets instead. The project’s success was therefore not measured solely by the code or the number of tokens, but by the humans who designed the verification system, controlled the process, and recognized when the AI was going off course.