Can Codex Build an Entire x86 Assembly Game Autonomously? A Real-World Experiment

A developer tested whether OpenAI's Codex could autonomously build an entire x86 Assembly game. Codex independently planned, implemented, debugged, and delivered a complete Asteroids-style DOS game without the developer writing any code. The experiment demonstrated Codex's ability to handle a full software project in a low-level language with minimal human intervention.

Most demonstrations of AI coding focus on generating snippets of code, building CRUD applications, or creating small projects in modern programming languages. I wanted to test something different. Rather than asking whether an AI could generate Assembly code, I wanted to know whether it could complete an entire software project with minimal human involvement. To make the experiment as challenging as possible, I deliberately chose one of the least forgiving environments I could think of: The goal was to recreate a classic Asteroids-style arcade game. There was one more rule: I would not write any Assembly code, in fact, I wouldn't participate in the implementation at all . My role was limited to defining the initial objective, playing each delivered version, and reporting any gameplay issues I discovered. Everything else—from architecture and implementation to debugging, documentation, repository management, building, and running the project—was handled autonomously by Codex . This article documents what happened. Before starting the experiment, I established a set of rules that would remain unchanged until the project was complete. The objective wasn't simply to build an Asteroids-style game. The objective was to evaluate how autonomous Codex could be when acting as a software engineering agent. To keep the experiment fair, I intentionally limited my own involvement. My responsibilities Codex responsibilities Everything else. This included: One rule never changed throughout the experiment: I never wrote a single line of Assembly code. In fact, I never built the project manually or launched the game during development. Every build and every execution was performed autonomously by Codex. My role was simply to evaluate the delivered result as if I were testing software developed by another engineer. Reality Check Although Codex handled the implementation independently, this was not a "hands-off" experiment. After each milestone I played the game, looked for unexpected behaviour and reported anything that didn't work correctly. During the entire project I reported only two gameplay bugs that had not been detected automatically. Both were analyzed, fixed and verified by Codex before development continued. Apart from defining the original goal and validating each milestone, I had no involvement in the implementation itself. One of the biggest challenges when evaluating AI-generated software is separating the work performed by the AI from the work performed by the human. Many demonstrations claim that an AI built an application, but the human developer still makes architectural decisions, edits the generated code, fixes compilation errors and completes the final implementation. I wanted to eliminate as much of that influence as possible. The goal was not to see whether Codex could assist me, to see how far Codex could go without me writing the code. Once the rules were established, I created an empty GitHub repository and described the project. From that point on, development became an iterative process. Codex planned the work, implemented a milestone, built the project, ran it, verified the result, committed the changes, and then handed the project back to me for testing. My job was simply to play the latest version and answer one question: Does it behave as expected? If I found a problem, I described what I observed. I never suggested how to fix it or where the bug was located. Codex analyzed the report, identified the cause, implemented the fix and presented a new version for testing. The cycle then repeated until the next milestone. Over time, the project grew from an empty repository into a complete DOS game with structured source code, documentation, persistent high scores and a fully playable gameplay loop. By the end of the experiment, Codex had produced: During development: One thing surprised me the most. Codex behaved much less like a code generator and much more like a software engineer. Instead of immediately writing gameplay code, it spent time planning the project, documenting the architecture, organizing the repository and verifying each completed milestone before moving on. | | Milestone | Main Result | Initiated By | Active Time | Status | |---|---|---|---|---|---| | 0 | Architecture | Platform, memory model, modules, roadmap | Codex | ~1 min | ✅ | | 1 | Video Foundation | Build system, Mode 13h, back buffer, clean exit | Codex | ~4 min | ✅ | | 2 | Input & Drawing | Keyboard IRQ, timing, lines, rectangles, bitmap font | Codex | ~11 min | ✅ | | 3 | Player Ship | Rotation, thrust, inertia, speed cap, wrapping | Codex | ~1 min | ✅ | | 4 | Shooting & Sound | Bullet pool, cooldown, lifetime, PC speaker | Codex | ~2.4 min | ✅ | | 5 | Asteroids & Waves | Random spawning, shapes, movement, wrapping | Codex | ~0.7 min | ✅ | | 6 | Scoring & Splitting | Collisions, asteroid splitting, scoring, wave progression | Codex | ~0.3 min | ✅ | | 7 | Complete Game Flow | Lives, respawn, invulnerability, game over | Codex | ~0.6 min | ✅ | | 8 | Polish & Hardening | Edge rendering, fair spawns, difficulty, 8086 audit | Codex | ~3.2 min | ✅ | | 9 | Persistent High Scores | Three-letter initials, Top 5, disk persistence | Human | ~1.2 min | ✅ | The "Active Time" represents the time Codex spent actively implementing each milestone. It does not include my play-testing, discussions, or the time between development sessions. Source code: https://github.com/mbostjan/AssemblyAsteroids The entire repository, including the complete commit and documentation, is publicly available for anyone who wants to review the experiment or reproduce the results.