Matt Shumer did it again. His latest project, Claude-of-Duty, is a first-person shooter built entirely from a single prompt to Claude, generating about 55,000 lines of Three.js code with zero external art assets. The result is a playable 3D FPS that looks more like a tech demo than a AAA game, but that misses the point entirely.
The project lives on GitHub at mshumer/Claude-of-Duty, and its description captures the ambition: “A Call of Duty-quality FPS in Three.js, built from a single prompt.” The prompt itself is public in the repo at prompt.md, and it is worth reading if you want to understand how far you can push a single-shot generation request.
What it actually does
Claude-of-Duty is a browser-based 3D shooter rendered in Three.js. The player moves through a procedurally generated environment, aims and shoots at targets, and gets a first-person view with basic physics. There are no downloaded textures, no Blender models, no asset pipeline. Everything – the geometry, the lighting, the collision detection, the weapon mechanics – was generated from that one prompt.
The 55,000 lines of code include the game engine loop, rendering logic, input handling, physics simulation, and procedural environment generation. For context, that is roughly the size of a small commercial game built with a proper engine, but it was produced in a single pass by an LLM rather than iterated over months by a team.
What matters here
The interesting question is not whether the game plays like Call of Duty. It does not. The textures are procedural, the physics are basic, and the gameplay loop is simple. The interesting question is what it means that an LLM can generate 55,000 lines of interconnected, runnable 3D application code from a single request.
Shumer has a track record of these demonstrations. His previous projects include GPT-Investor (an investment analysis agent) and other one-shot AI builds. Each one pushes the boundary of what people assume LLMs can do in a single generation pass. Claude-of-Duty is the most technically complex so far because it requires the model to maintain consistency across rendering, physics, user input, and game state simultaneously.
The fact that the generated code compiles and runs on the first try is itself notable. Even experienced game developers deal with runtime errors, undefined variables, and broken references in a 55,000-line project. That the model produced coherent code at this scale speaks to advances in both the underlying model and the prompting technique used.
What it says about AI code generation
Projects like this tend to generate two reactions. One camp sees it as a glimpse of a future where anyone can build complex software by describing it in natural language. The other camp points out that the result is still a long way from a polished product and that the real work – debugging, optimization, edge case handling – still needs human attention.
Both are right. The output is impressive relative to what was possible even six months ago, and the output is still rough compared to hand-crafted software. Where this gets interesting is the trajectory. If each generation of models doubles the quality and scale of what can be produced in a single pass, the gap between “single prompt prototype” and “shippable product” is closing faster than most people realize.
For game developers specifically, the implication is that procedural generation of code is about to become as important as procedural generation of art. Indie developers who can describe a game mechanic in enough detail to get a working prototype in minutes, then iterate by refining the prompt rather than rewriting the code, will move faster than those who start from scratch every time.
The catch: quality at scale
There is a gap between “it runs” and “it is good.” The generated code runs, but it has the hallmarks of single-shot generation – repetitive patterns, inconsistent naming, and sections that look like the model lost track of context toward the end of a long generation. The game works, but it does not feel polished. The aim assist is basic, the collision detection can be unpredictable, and the environment generation produces scenes that look similar after a few minutes of play.
These are the kinds of issues that would take a human developer days to smooth out. The model got the architecture right in one pass, but the fit and finish are still human territory. That is not a criticism of the project – it is an honest assessment of where the technology stands and where the remaining work lives.
The practical takeaway for developers looking at this is: use single-shot generation for prototypes, demos, and experiments. It is a fantastic accelerator for getting something working. But plan on spending real time refining before you ship anything to users. The model handles the 80 percent case. The remaining 20 percent is where the quality lives, and that still needs a person.
How to try it
The repo is public and the game runs in a browser. You can clone the repository, host the files locally, and play it yourself. The prompt.md file is the most valuable part of the repo if you are interested in understanding the technique. It shows exactly how the request was structured to get Claude to produce coherent 3D code at this scale.
If you want to experiment with your own version, the key lessons from the prompt are: specify the technology stack explicitly (Three.js), describe the expected behavior in concrete terms (movement speed, shooting mechanics, environment layout), and include constraints about what to avoid (external assets, complex physics engines). The model handles the rest.