The Gauntlet Loop: A Quality Bar AI Can’t Talk Its Way Around
Before getting into the technique, here is what I was building. Dance of Ashes is a mobile-first, choice-driven dark-fantasy browser game in which players create a character and navigate ten consequential decisions during a civil war fought with dragons. Each choice affects the character’s relationships, abilities, reputation, achievements, and eventual ending. I began the project using Legionnaire, developed by Gal Bartov, as a quality reference—not to copy its football setting or design, but to learn from the way it turns a simple series of decisions into a compelling, persistent career.
The first version was not broken. That was the problem.
It loaded. The buttons worked. The colors were tasteful. It was recognizably the thing I had asked for—and it was completely forgettable.
This is a common failure mode in AI-assisted work. A capable model can produce something locally coherent on its first attempt. Because nothing is obviously wrong, both the model and the human are tempted to call it done. The result clears the low bar of “it works” while missing the much harder bar of “I want to keep using this.”
The Gauntlet Loop is a way to keep that first plausible draft from certifying itself.
Before going further, the credits should be explicit because this project owes two different debts:
- The method: This article is a continuation of Matt Shumer’s original post on X and his later explanation, How to Run a Gauntlet Loop. The prompt and project that demonstrated the method are also public in the Claude of Duty repository.
- The product reference: the source and quality bar for my game was Legionnaire, developed by Gal Bartov (@Krysuss). Dance of Ashes is an independent adaptation of lessons I observed in his work; it is not the origin of those interaction ideas.
Gal’s development deserves real praise. Legionnaire compresses an enormous career simulation into a remarkably approachable mobile loop. It makes identity, progression, risk, history, and the next decision legible without making the player feel as though they are operating a spreadsheet. That balance is difficult product work. Its restraint is especially impressive: the game understands that persistent consequences and good pacing can create more attachment than spectacle alone.
What follows is my attempt to apply the idea, understand why it works, and make it useful outside one spectacular demo.
The real problem is not generation. It is stopping.
Most prompting advice focuses on the input: add context, define a role, request a format, include examples. All of that helps. But once an agent can edit files, run code, inspect a browser, and test its own work, the larger opportunity is no longer a single perfect prompt. It is a better process for deciding when the work is good enough.
A normal agent loop looks something like this:
- Interpret the request.
- Build a solution.
- Look at the solution it just built.
- Explain why the solution is reasonable.
- Stop.
Step four is the trap. The builder knows every constraint it encountered and every compromise it made. That context makes it an excellent defense attorney for its own work. It can explain why the spacing is acceptable, why the test coverage is sufficient, or why the interaction is “intuitive.”
But users do not experience the explanation. They experience the artifact.
The Gauntlet Loop changes the stopping rule. Instead of asking the builder whether the work is good, it introduces a real quality bar and a separate critical pass that inspects the finished output. If the reference still wins, the loop continues.
In its simplest form:
Set a concrete bar. Build. Compare the real artifact against the bar. Fix the largest gap. Repeat.
The loop is simple. Choosing the bar is not.
A reference is not a mood board
“Make it amazing” is not a quality bar. Neither is “production-ready,” “premium,” or “addictive.” These phrases express ambition, but they give the critic nothing falsifiable to inspect.
A useful bar is concrete enough to win or lose against.
For a visual product, that may be a live site at a specific mobile viewport. For prose, it may be a handful of exemplary passages judged on clarity and compression. For infrastructure, it may be a recovery test, a latency distribution, or a known implementation. Shumer’s write-up makes the same point: the reference does not need to be realistically beatable; it needs to keep the work moving in the right direction instead of allowing “pretty good for AI” to become the finish line.
I used Gal Bartov’s Legionnaire as the bar for a mobile browser game. The goal was not to copy its football theme, artwork, content, or interface. It was to study the excellent product decisions underneath them and understand why a session felt like a career rather than a sequence of forms.
That distinction matters. A weak comparison says:
The reference has large background images, so add large background images.
A stronger comparison asks:
What does the reference make the player understand, feel, and anticipate—and what mechanisms create that effect?
The live comparison surfaced things that a screenshot alone would have missed. The reference made identity persistent. It showed accumulation clearly. It kept a season-by-season record. Every decision immediately changed a visible career. A collection created unfinished business. The next choice arrived before the energy of the previous one disappeared.
My game, Dance of Ashes, already had more atmosphere: generated character art, dragons, cinematic endings, music, sound, and animated fire. More spectacle was not the largest remaining gap. The gap was legible continuity.
That led to a different set of changes: a daily shared prophecy, completion streaks, a visible legacy score, persistent decision ledgers, and a Vault that turns old lives into a collection. The reference supplied the standard, not the skin.
The anatomy of a useful gauntlet
A strong Gauntlet Loop has five parts.
1. A destination
Describe the outcome at full ambition. Do not prematurely prescribe the architecture.
“Build a mobile-first browser game people want to replay” leaves room for the agent to discover the right systems. “Add three modals, a WebGL dragon, a PostgreSQL database, and a daily login bonus” may lock the work into an implementation before anyone has proven those are the right ingredients.
Constraints still belong in the prompt. The distinction is between constraints and guesses. “Must work on a phone and deploy as a static site” is a constraint. “Must use React” may just be a guess.
2. An inspectable reference
Name the real artifact, test, measurement, or example that represents the bar. The agent must be able to access it and compare against it directly.
If the reference is a website, inspect the live interaction—not only the landing-page screenshot. If the goal involves motion, pacing, audio, or responsiveness, the evidence must include those dimensions. A still image cannot tell you that the pause between two questions feels dead.
3. Separation between builder and critic
The full version of the method uses fresh-context critics: the critic receives the goal, rules, reference, and actual artifact, but not the builder’s diary of effort.
That context separation is not ceremony. It removes the story of how hard the work was. The critic sees what a user sees.
When a separate agent is unavailable, the principle still helps: split building and evaluation into distinct phases, discard the builder’s self-description, and restart the critique from observable evidence. It is weaker than a genuinely independent critic, so say so honestly, but it is still better than asking “how did I do?” in the same breath as the implementation.
4. One largest gap per round
A critic that returns 47 observations often creates less progress than one that identifies the most important failure.
The next round should have a sharp target:
- first minute does not establish identity;
- choice feedback takes too long;
- the player cannot explain why the run ended;
- mobile controls obscure the scene;
- the test passes on average latency while p99 is unacceptable.
Fix the largest gap, render or run again, then re-evaluate. This makes each round directional and keeps the agent from polishing low-impact details while the central experience remains weak.
5. Evidence and a stopping condition
“The critic loved it” is not evidence.
Useful evidence can be screenshots at fixed viewports, interaction traces, real-device recordings, accessibility checks, test output, performance distributions, or structured blind comparisons. The artifact determines the evidence.
In my case, the visual pass was paired with a simulation of 7,200 careers. That test verified that all 36 events were reachable, no phase was skipped, all four ambition paths could reach their rare endings, and the resulting runs did not collapse into a handful of identical sequences. It did not prove that the game was fun. It did eliminate several ways the game could quietly be broken while looking polished.
The stop condition should also be honest. Stop when the artifact clears the bar, when marginal improvements are no longer worth their cost, or when the compute budget is exhausted. Do not quietly redefine the reference downward.
The public Claude of Duty repository is unusually valuable here because its own assessment says the project did not beat Call of Duty in blind comparisons. The bar still produced a far stronger artifact. A gauntlet is a direction and a discipline, not a magical guarantee of victory.
What usually breaks the loop
The first failure is a vague bar. If the critic must invent what “great” means, it can invent a reason to pass the work.
The second is self-grading. The builder’s context leaks into the judgment, and effort gets mistaken for quality.
The third is evaluating a summary instead of the artifact. “Implemented responsive design and polished animations” tells us nothing about whether the mobile layout clips or the animations feel sluggish.
The fourth is using the wrong evidence surface. Screenshots are good for hierarchy, density, alignment, and visual character. They are poor evidence for latency, sound, pacing, game feel, focus behavior, and failure recovery.
The fifth is arbitrary iteration. “Do five rounds” may stop while the work is still improving—or waste three rounds after progress has stalled. The exit should depend on evidence, not a ritual number.
The sixth is uncontrolled parallelism. Some components can be improved independently; others share state, timing, style, and performance constraints. If ten builders simultaneously optimize tightly coupled parts, integration debt can erase their local gains. Parallelize along real boundaries, then run a whole-artifact smoothing pass.
A practical prompt shape
The most useful prompt is usually shorter than the operating process behind it. Here is a domain-neutral version:
Build [OUTCOME] at the level of [CONCRETE REFERENCE]. Preserve these
constraints: [CONSTRAINTS]. Decide the implementation yourself.
Break the result into the smallest parts that can be improved and judged
independently. For each important part, use a builder and a separate critic
with fresh context. The critic must inspect the real artifact—not the builder’s
summary—and compare it directly with the reference using [EVIDENCE].
When ours loses, identify the single largest meaningful gap, fix it, and run
the comparison again. Maintain an integration pass across the whole artifact.
Stop only when ours clears the agreed bar, improvements stall under the stated
rule, or the budget is reached. Report any remaining gap honestly.
The bracket people pay the least attention to is [EVIDENCE], and it may be the most important one.
For a landing page, it might say: “screenshots at 390×844 and 1440×900, plus keyboard navigation and a performance trace.” For an API: “contract tests, fault injection, p50/p95/p99 latency, and recovery after process termination.” For an article: “a blind edit against these five reference passages, scored for clarity, argument density, and unsupported claims.”
Once the evidence is explicit, criticism becomes actionable.
What changes for the human
The Gauntlet Loop does not remove human judgment. It moves it upstream.
Instead of manually specifying every feature, the human chooses the ambition, reference, constraints, evidence, and budget. Those decisions shape everything the agent does afterward.
This may be the more durable skill in an age of capable agents: not describing every step, but constructing an environment in which weak work cannot easily approve itself.
There is also a psychological advantage. A high reference gives you permission to reject the first competent result. You are no longer being “too picky.” The work simply has not cleared the bar yet.
The loop in one sentence
The Gauntlet Loop turns quality from an adjective into a comparison.
That is why it works. The agent is no longer asked to feel more ambitious, praise itself less, or somehow know when a product is addictive. It is given a destination, a rival, an independent judgment, and another round.
The first draft can still be forgettable. It just no longer gets the final vote.
_With appreciation to Matt Shumer for developing and sharing the Gauntlet Loop method, and to Gal Bartov for building Legionnaire—the source product whose thoughtful game design gave this experiment a meaningful bar to pursue._
And if you want to see the result of this experiment, you can play Dance of Ashes. It is a work in progress, but it is playable and demonstrates the ideas discussed here.
