How to Run a Gauntlet Loop: The Prompting Method Behind Claude of Duty
← All writing
A few days ago, I posted a Call of Duty-style game built by Claude Opus 5 from a single prompt.
To be precise, I gave Claude Code one prompt, then left it alone. It spent many hours working, spawned a massive fleet of subagents, wrote roughly 55,000 lines of code, and generated every texture, mesh, animation, and sound in code from scratch. I did not sit there steering it, at all.
One prompt. Many hours. Roughly 55,000 lines of code, and every texture, mesh, animation, and sound generated from scratch.
Watch the run on X →
The post that started all of this.
The post quickly racked up millions of views. As it was so much higher-quality than other Opus 5 demos, understandably, a lot of people called it fake. So, I published the prompt and open-sourced all the code.
Then something pretty funny happened: people who were skeptical started running versions of the prompt themselves, assuming they could prove it wouldn’t work. Of course, it worked, and these folks ended up with fully-working games! Other people adapted the same idea to completely different kinds of work.
I get why folks were skeptical… the quality level I demonstrated was so much higher than what other people were getting. So why was I able to do it? What was the difference?
The difference was the way I prompted the agent. Instead of letting it produce one decent result and stop, I made it keep comparing its work against a much higher bar.
I have started calling this a Gauntlet Loop .
And it applies to much more than games. You can use it for code, websites, product design, marketing campaigns, writing, research, or almost anything else where the output can be inspected and improved.
The whole idea
A Gauntlet Loop works like this:
You give a lead agent a goal and a real example of what great looks like. The lead agent decides how to break the goal into the smallest pieces that can be improved separately. Each piece gets its own builder and a separate critic with fresh context.
The builder makes something. The critic compares it against the reference example. If the reference example wins, the critic explains the biggest remaining gap and sends the work back to the builder. The builder fixes it. Then another round begins.
That continues until the result reaches the bar (or, more likely, you decide it is ready).
The receipts
The prompt and all 55,000 lines are public
If you want to see what this actually produced before you try it: the exact prompt I gave Claude Code, and every line of the game it wrote, are open source.
Claude of Duty on GitHub →<br>The original prompt →
First, use an actual agent
Do not paste a Gauntlet Loop into a normal Claude chat and expect the same result.
You need to run it inside an agentic harness such as Claude Code or Codex . In plain English, that means the model can actually work: open files, run code, render the result, inspect screenshots, use tools, change things, and spawn other agents.
My default right now is Claude Code with Opus 5, especially for visual or creative work. Claude Code subagents can each run in their own clean context window, which is exactly what you want for independent critics.
Codex is very good for backend engineering and other work where visual creation matters less. It is also pretty good at looking at a visual result and criticizing it. But in my experience, it is much weaker than Opus 5 at creating the visual result in the first place.
For serious Gauntlet Loops, I also recommend turning on ultracode (type /effort and select ultracode ). It costs much more, but the extra effort usually produces better work on large, multi-agent runs.
1. Give it the goal, not your implementation
Tell the agent what you want. Do not tell it exactly how to make it.
My original game prompt did not contain a detailed architecture. It did not list all the systems the game needed or explain how the renderer should work.
It basically said:
Build a modern, AAA-quality first-person shooter in Three.js. Break the work among subagents. Put every important piece through its own loop with a separate, harsh visual critic. Compare our output side by side with real Call of Duty. If ours loses, keep improving it. Use ultracode.
That was almost the entire prompt.
The most recent models are often very good at deciding how to approach a large goal. When you prescribe the architecture, the workstreams, and every step, you replace the model’s judgment with your own.
Give it the destination. Let it choose the route.
2. Give it a real bar
The bar is the most important part.
“Make it amazing” is not a bar. Neither is “make it production-ready” or “keep improving it.”
The agent needs something concrete it can inspect and compare its work against.
For the game, I used actual Call of Duty screenshots. The critic was supposed to look at the two...