ع
⚡ Productivity

The Gauntlet Loop: Make AI Actually Improve Its Work

Instead of saying 'make it better' and hoping, this technique imposes a clear bar, a separate critic, and a blind comparison — until the output genuinely wins.

Advanced10 min read

What you'll be able to do by the end

  • Understand why 'make it better' is a weak instruction, and replace it with a comparable standard
  • Apply the Build → Critic → Compare → Fix → Re-test loop to any inspectable task
  • Use a ready-made prompt you can paste straight into ChatGPT, Claude, Gemini, or any coding agent
  • Recognize the cases where the technique fails — and why a project with no reference point fails with them
  • Control cost and tokens instead of letting them spiral unchecked

Before you start

  • Access to an AI tool that can manage a long conversation or act as an agent (ChatGPT, Claude, Gemini, or a coding agent like Cursor)
  • A clear idea of your target output plus at least one real example to compare against

Most people use AI with one request and one edit: “write me this,” then “improve it a bit.” The problem with “improve it” is that it contains no standard — the model guesses what you mean and returns a cosmetically altered version with no guarantee it’s actually better.

The Gauntlet Loop is a recent technique built to solve exactly this: it forces AI to judge its own work against a real standard, through a separate critic, via blind comparison — and repeats the process until the output genuinely wins, not until an allotted number of attempts runs out.

Where the technique came from

It’s associated with developer Matt Shumer, who wrote the original prompt and named it while building a demo code project imitating a video game style (he called it Claude of Duty) as a proof of concept for a model improving its own work when given a strict standard. Since then the technique has been widely discussed, and packaged tools and bundles have appeared from other developers (including open-source repositories wrapping the prompt as a ready-made ‘skill’ for coding agents).

The copy-paste prompt

Paste this directly into a new conversation with ChatGPT, Claude, or Gemini, or into a coding agent:

I want you to apply the "Gauntlet Loop" method to the following task:

Goal: [describe exactly what you need — e.g., a landing page for my product, or a function that does X]

The Bar: [give a real, concrete example to compare against — a competitor product, working code, a text you consider excellent]

Operating rules:
1. Divide the task into the smallest parts that can each be judged independently.
2. For each part: produce a version (Build), then open a completely separate evaluation acting as a critic (Critic) with no prior knowledge of who built what.
3. The critic compares my output against the bar blind (Compare) — don't tell it which is the original.
4. If the output loses, identify the single biggest gap between it and the bar, and fix exactly that (Fix) — don't randomly edit everything.
5. Run the comparison again (Re-test).
6. Keep looping until the output actually wins the blind comparison, not until some round count expires.
7. Hard ceiling: do not exceed [8] rounds per part. If you hit the limit without winning, report the last remaining gap and stop.

Start by dividing the task, and show me your plan before executing.

The critical factor separating a successful prompt from a failed one: a real, concrete bar in step two. Write “high quality” instead of an actual example and the whole loop fails at the starting line.

The loop in detail: Build → Critic → Compare → Fix → Re-test

  1. Build — one agent produces the first version of the required piece.
  2. Critic — a second agent, in entirely fresh context, inspects the output with no prior knowledge.
  3. Compare — the critic compares your output against the real bar, blind, and decides which is better.
  4. Fix — if your output loses, it names the single biggest gap, and the builder fixes precisely that.
  5. Re-test — the comparison restarts from scratch, and the loop continues until actual victory.

When to use it, and when not to

Use it when you have a real reference to compare against (a competitor product, automated tests, a numeric performance benchmark), the task splits cleanly, and you’re willing to pay extra time and cost for a clearly better result.

Don’t use it for a brand-new project with no reference — the critic will invent its own standard, which is the technique’s known flaw. Skip it too for small tasks finished in one request.

Cost — be aware

The loop runs multiple agents across repeated rounds, not one request — so it’s clearly pricier than a normal conversation. Large complex projects have consumed substantial token spend for some users. Set an explicit round cap in the prompt and split work into small pieces rather than running it over a huge project in one shot.

Sources

Steps

  1. Step 1: What is the Gauntlet Loop?

    The technique emerged from developer Matt Shumer, who wrote the original prompt and named it while building a code-based demo game he called Claude of Duty as a proof of concept. The idea: instead of asking the model to 'improve this' and leaving the meaning of 'better' to its discretion, you give it a real standard — a concrete example or benchmark to compare itself against — and let a separate agent (the critic) run a blind comparison between your output and the bar, without knowing which is which. If your output loses, the critic names the biggest gap, the builder fixes exactly that, and the comparison runs again. The loop repeats until your output actually wins — not until a fixed number of rounds expires.

    Note: The name is no accident: a 'gauntlet' is an ordeal you pass through repeatedly until you've proven yourself — not one superficial review.

  2. Step 2: Why 'make it better' is a weak instruction

    When you tell a model 'improve this' or 'make it more professional', there's no standard for it to measure against — so you get a cosmetically edited version with no real improvement, or exaggerated changes you never needed. The problem is that 'quality' without a concrete reference is a rubber word any output can claim. The core rule of the technique: any criterion the agent can't define precisely isn't actually a criterion. 'Better than the official website of app X' is a testable standard; 'professional quality' isn't a criterion — it's a wish.

    Note: Stress-test your standard with one question: could two different people easily agree whether a given output meets it? If not, the bar is vague.

  3. Step 3: The loop: Build → Critic → Compare → Fix → Re-test

    Five steps repeat: **Build** — the builder agent produces a version of what's needed (code, text, design). **Critic** — a completely separate agent in fresh context inspects the output without knowing who wrote it. **Compare** — the critic compares your output against the standard (the real example) blind — not told which is the original. **Fix** — if your output loses, the critic identifies the single biggest gap (not a random list of remarks), and the builder fixes that gap specifically. **Re-test** — the comparison restarts from zero. The loop continues until your output wins, not until 3 or 5 rounds pass — a fixed round count defeats the entire concept.

    Note: The critical condition: the critic must be truly separate from the builder — different context, unable to see how decisions were made. If the same agent builds and grades its own work, the result is automatically biased.

  4. Step 4: Worked example 1: a landing page

    The bar: a landing page from a successful competitor you know and respect. Give the agent a link or description of the reference page and ask for a page for your product at that same level. The critic compares both on concrete criteria: whether the offer lands within the first 5 seconds, how many clicks to reach the call-to-action, visual hierarchy. The first round almost always loses — and the named gap (say, 'the headline describes the feature, not the benefit') is what drives the fix, instead of generic feedback like 'improve the design'.

    Note: No competitor to compare against? Take a page from a completely different industry with the same conversion pattern (e.g., a SaaS signup page) — structural match matters more than industry match.

  5. Step 5: Worked example 2: reviewing code or a function

    Here the bar isn't a website but runnable criteria: passes every test, execution time under a set limit, fewer lines than a known-good version. The builder writes the solution; a separate critic (possibly even a different model) runs the tests and compares actual performance — not its opinion about 'code quality'. This is a common pairing with coding agents (Cursor, Claude Code) because the outcome is machine-measurable rather than a matter of taste.

    Note: For code specifically, make the bar numeric wherever possible (execution time, passing test count) rather than descriptive — it reduces the chance the critic invents its own personal standard.

  6. Step 6: When to use it and when not to

    **Use it when**: you have a real, concrete reference (a competitor product, automated tests, a numeric performance benchmark), the task can be split into small parts judged separately, and you're willing to pay extra time/cost for a clearly higher result. **Don't use it when**: the project is entirely new with nothing to compare against — there the critic invents its own standard, which is precisely the technique's known weakness: without a genuine reference, the Gauntlet Loop loses its foundation. Also skip it for simple tasks done in one request — the loop burns time and tokens a small job doesn't justify.

    Note: Quick rule: if you can state the standard in one measurable sentence, try it. If explaining 'what better means' takes a whole paragraph, the bar isn't ready.

  7. Step 7: Controlling cost and tokens

    The loop is expensive because it runs multiple agents (builder + critic) across repeated rounds, not a single request. User reports mention amounts reaching hundreds of dollars on large, complex projects like a full game simulation. To control it: (1) set an explicit maximum round cap in the prompt (e.g., 'stop after 8 rounds even without a win, and show me the last remaining gap') instead of leaving it fully open-ended. (2) Split large tasks into small pieces tested individually instead of running the loop over the entire project at once. (3) Use a lighter model as the critic when the task doesn't need deep analysis, reserving the stronger model for the builder.

    Note: Watch the actual round count after your first run — if it consistently stops at 3-4 rounds, cap yours at 6 rather than leaving it unlimited.

Common mistakes — and how to avoid them

Mistake'Improve this code / design / copy.' — with no standard, the agent decides for itself what 'better' means.

Do this insteadGive it a specific real example to match: 'Bring it to the level of [concrete example], and report the single biggest gap if it loses.'

MistakeLetting the same agent build the solution and grade it within one conversation.

Do this insteadOpen a completely separate context for the critic — it shouldn't see how the output was built or know who made which.

MistakeFixing a fixed number of rounds ('try 3 times then stop') regardless of outcome.

Do this insteadAsk the loop to continue until the output genuinely wins, with a hard cap as cost protection — not as a goal in itself.

MistakeRunning the loop over an entire massive project with no clear reference.

Do this insteadSplit it into small pieces, each with its own explicit comparison bar.

MistakeIgnoring cost and letting the loop spin unmonitored on a big task.

Do this insteadSet an explicit round ceiling and watch the first run before repeating it on something larger.

❓ Frequently asked questions

Who invented the Gauntlet Loop?

It came from developer Matt Shumer, who wrote the original prompt and named the technique while building a demo code project (Claude of Duty) as a proof of concept. It spread from there, with second developers packaging versions and tools built on the same idea.

Does the Gauntlet Loop work with any AI tool?

The principle is general and works with any tool that can hold a long conversation or split two agents into separate contexts — ChatGPT, Claude, Gemini, or coding agents like Cursor and Claude Code. The practical difference: coding agents automate the full loop best (run, check, fix) because they're integrated with a real execution environment.

Why is it expensive?

Because it doesn't run one request — it runs a builder agent and a critic agent in separate contexts, across repeated rounds, for each piece of the task. Complex projects (like a full game simulation) have consumed large token bills for some users. Set a round cap and split the task to control cost.

How is this different from just asking the model again?

Plain iteration ('revise this once more') has no external standard and no separate inspector — the model itself decides when to stop. The Gauntlet Loop adds three things plain repetition lacks: a concrete bar to compare against, an independent critic with no bias toward the builder, and a blind comparison that prevents the model from knowing it's judging its own work.

When does this technique fail?

The clearest failure case: a brand-new project with no real reference to compare against. There the critic has to invent its own standard, which drops you back into the exact 'make it better' problem the technique was built to solve.

Can I use it for writing articles or marketing content?

Yes. The principle applies to any inspectable, comparable output — not just code. Use a real article or text of the same type you consider excellent as the bar, and the critic compares style, structure, and clarity between it and your draft blindly.