The Gauntlet Loop. Give AI a Bar It Cannot Argue With

In late July 2026 Matt Shumer pasted three paragraphs into Claude Code and left it running. What came back was a first-person shooter that runs in a browser. Roughly 55,000 lines of JavaScript across eleven subsystems, and not one art asset. Every texture, mesh, animation and sound is generated from code while the page loads. The repository is public under an MIT licence, there is gameplay footage if you want to see it move, and the same method has since produced dozens of browser games you can play right now.

This is the whole prompt.

I want you to build a first-person shooter at the level of the most recent Call of Duty games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of.

Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going.

Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual Call of Duty game. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.

Shumer later named the pattern the Gauntlet Loop. It reads like someone losing an argument with a computer, and the words doing the work are not "utterly" or "perfect".

Start with what it failed to do

The README carries a section called Honest assessment. It is the most useful part of the whole experiment.

Eleven independent critics scored the finished frames against real Call of Duty footage. The scores went 3.59, then 4.14, then 4.05, then 5.05 out of ten. Two shots reached "close". The rest stayed at "amateur". In every blind comparison, in every round, the critic picked the real game.

The shortfalls are named precisely. Hands look like blocky slabs that do not grip the weapon. Surfaces read as procedural noise rather than photographed material. Enemies read as mannequins at distance. Indirect light is an approximation. The shipped build runs at 28 to 30 frames per second on an Apple silicon laptop.

So the loop lost. It also produced a number every round and knew why it lost. That is the difference worth copying. Most AI work stops when the output stops feeling embarrassing, which is a feeling rather than a measurement.

Four moving parts

Take the shouting out of the prompt and four instructions remain.

The first is a bar that lives outside the model. Not "AAA quality", which a model can define downward until it qualifies. An actual Call of Duty frame, which it cannot.

Then comes permission to split the work. The prompt never names the subsystems. The agent decides what the pieces are, and that is the decision people most often take back and then make worse.

The critic is not the builder. It gets the goal, the bar and the finished artifact. It does not get the builder's reasoning or the builder's summary of what it did. Anthropic calls this shape the evaluator-optimizer workflow and recommends it where clear evaluation criteria exist and a second pass measurably helps.

Last comes permission to continue. Without it an agent returns after one round, because returning is what it was trained to do.

What the commands actually do

The original prompt writes /loop as ordinary English meaning keep going. In Claude Code today those words have precise meanings, and mixing them up costs money.

/goal sets a completion condition. After every turn a small fast model reads the conversation and answers whether the condition holds. If it does not, Claude starts another turn instead of handing control back. That is the goal loop.

/loop starts the next turn once a time interval elapses. It is for recurring work and monitoring, not for grinding toward a bar.

ultracode is a third thing. Typed inside a prompt it makes Claude write and run that one task as a dynamic workflow, a script that orchestrates subagents in the background. Set through /effort ultracode it pairs the highest reasoning effort with automatic workflow orchestration for the whole session. The runtime allows sixteen agents at once, fewer on machines with limited CPU cores, and a thousand per run. A run that schedules more than twenty-five agents or projects past 1.5 million tokens raises a warning, though not in a session with ultracode on, because that setting already opts you into large runs.

For a Gauntlet Loop you want /goal for the stopping rule and ultracode for the fan-out.

The template

Fill four blanks. The reference has to be something the agent can genuinely open, run, screenshot or read.

Build <THING> that <WHAT IT MUST DO>, at the quality level of <NAMED REFERENCE>.
Choose the approach yourself.

Split the work into the smallest pieces that can be judged on their own.
For each piece, run a builder sub-agent and a separate critic sub-agent.

The critic receives the goal, the bar and the finished artifact. It does not
receive the builder's reasoning or the builder's summary. It inspects the real
output, compares it blind against <NAMED REFERENCE>, says which one is better,
and names the single largest remaining gap with evidence.

If ours loses, hand that gap back to the builder and go again.

Stop when the critic picks ours, or after <N> rounds, or when a round improves
the score by less than <X>. Print the score and the largest gap every round.

The critic prompt is the part people skip. Written badly it produces a builder with a second opinion. Written properly it looks like this.

You are reviewing an artifact you did not build. You get no history and no
explanation, and you should not ask for either.

Our artifact: <PATH OR SCREENSHOT>
The reference: <PATH OR SCREENSHOT>

Score ours from 1 to 10 against the reference. Then answer one question. If a
buyer saw both without labels, which would they pick, and on what visible
detail did they decide?

Name the single largest gap. Point at the evidence. Do not list ten small
things, and do not soften the score because the work looks hard.

Running it on a game

The original prompt still works and is worth reading exactly as written. A tighter version that fails less often looks like this.

ultracode Build a browser kart racer in Three.js at the visual level of Mario
Kart 8 Deluxe. Choose the architecture yourself.

Split it into track, vehicle handling, materials, effects, audio and HUD. Give
each one a builder sub-agent. After every round, run a separate critic
sub-agent that screenshots our game, compares it blind against reference
footage, scores it 1 to 10, and names the single largest visual gap.

Work on one coupled system at a time rather than all six at once. Lighting,
tonemapping and materials are one system, not three.

/goal every critic scores 7 or higher, or four rounds pass with less than 0.3
improvement between them

That line about one coupled system is not decoration. The reason for it sits two sections down.

Running it on a business deliverable

Nothing here is specific to graphics. The method needs an artifact you can inspect and a reference you can name. A pricing page qualifies. A quarterly report does not, until you decide first what a good one looks like.

Two that work.

ultracode Rewrite our pricing page at src/app/pricing so a first-time visitor
can pick a plan in under thirty seconds. The bar is the Stripe pricing page and
the Linear pricing page. Both are public, so fetch them and read them.

Split the work into structure, plan comparison, copy, objection handling and
mobile layout.

After every round, a separate critic sub-agent loads our page and both
reference pages in a browser at 390 px and 1440 px, with screenshots. It has
not seen our copy before. It answers three questions. Which page explains the
choice fastest. Where does our page make the reader stop and think. Which
single change closes the largest part of the gap.

Do not change our prices and do not invent features we do not sell.

/goal the critic picks our page over both references on the thirty-second
test, or six rounds pass

And one with no code in it at all.

Write the offer document for our document automation service, aimed at a
Slovak company of twenty people that processes invoices by hand.

The bar is the Basecamp pricing page and the Stripe Atlas guide, both public.
Same test. A busy owner reads it once and knows what they get, what it costs
and what happens next.

Split it into the problem statement, what we deliver, the price, the timeline
and the objections.

A separate critic sub-agent reads only the finished document. It does not see
my notes. It answers what the reader would still not know, what they would not
believe, and which paragraph they would stop reading at. It scores the document
against the references.

Rewrite the weakest section. Repeat until the critic stops finding a paragraph
where a reader would quit, or until five rounds pass.

Where it breaks

The same repository recorded a finding that contradicts the prompt that produced it. That finding is the most valuable thing in the experiment.

Parallel fan-out lost. Three rounds of six agents, each owning one directory, moved the score by 0.46 and left the count of frame-ruining defects higher than it started, going 60, then 47, then 66. Tonemapping, sky and indirect light are one coupled system, and separate agents kept breaking each other's assumptions. One sequential pass with a single owner per coupled concern moved the score by a full point and cut defects from 66 to 26.

Fan out across things that do not touch. Work sequentially through things that do.

Three more failure modes are worth naming. A bar the agent can define is not a bar, so "professional quality" fails while "better than this named page" holds. A critic handed the builder's summary reviews the summary rather than the artifact. And a loop with no ceiling runs until the budget notices. James Altucher ran the original prompt for around ten hours and 1.3 million tokens. Anthropic measured its own multi-agent research system at roughly fifteen times the tokens of an ordinary chat interaction, and recommends the pattern only where the value of the task carries that.

The loop does not stop on its own. You are the stopping condition.

What we do with it

At Rise.sk we run a review-gated version of this. An agent builds, a fresh agent with no build history reviews, and a human merges. We wrote that workflow up separately, along with the related question of where the human belongs in an AI build.

The Gauntlet Loop is the same shape pointed at quality rather than correctness. It earns its tokens when the output can be inspected, when a named reference exists, and when "good enough" has been quietly costing you something. It earns nothing when nobody has decided what good means.

If you are working out which of your processes could carry a loop like this, we build AI automation and workflows and run technology audits that start with exactly that question.

Sources

• Matt Shumer, Claude of Duty, the full prompt and the honest assessment
• Anthropic, Keep Claude working toward a goal
• Anthropic, Orchestrate subagents at scale with dynamic workflows
• Anthropic, Building effective agents
• Anthropic, How we built our multi-agent research system
• Anthropic, Loop engineering, getting started with loops
• Anthropic, Building verification loops in Claude Code with skills
• Decrypt, The dumbest-looking AI prompt just beat months of careful game-design prompt engineering