Gauntlet Loop Explained: AI Agents That Build, Judge & Fix Their Own Work

At a glance

Execute Automation breaks down the gauntlet loop, the one shot orchestration prompt that has been tearing through developer feeds since Matt Shumer used it to generate a browser based first person shooter in Three.js from a single message, a stunt he called Claude of Duty. The pattern is builder versus critic: you hand a coding agent an objective, tell it to fan out sub agents to do the work, and set a boundary that only a harsh judge agent can decide has been met. Nobody has to write the agents, wire the handoffs, or sit in the loop grading output, because the prompt makes the model build that machinery itself and keep going for hours. The host then runs the same three part prompt twice on his own work, using MiniMax M3 rather than a Claude plan to protect his tokens, and gets back a complete Playwright test framework and a full course listing website scraped from his own Udemy catalog. The receipts he shows are the interesting part: 444 total messages in the run, three of which were his, one percent of a daily usage limit, and one hour and 13 minutes wall clock for the website.

One prompt, 40 plus games, and nobody in the middle

The video opens on a claim big enough to sound like a joke. There is a single prompt, sitting on screen, that has been used to build more than 40 video games. Not 40 prototypes, playable games. And people are not stopping at games with it. They are pointing the same prompt at web applications, at full software builds, and even at larger fine tuning work on applications.

The mechanism is what makes it worth a video. This gauntlet loop prompt, handed to any of the coding agents you already use, whether that is Codex, another vendor's coding agent, or Claude Code, does not answer you. It spawns a pile of different agents on your behalf and then works for hours to complete the task, with no human intervention at any point in the run.

The host is clear about where this sits on the ladder. It is not a longer agent loop and it is not a better one shot prompt. It is a different shape from both.

"It is way beyond than the agent loops as well as the single one shot prompt that you can actually give." (0:26)

Claude of Duty: the exhibit everyone points at

Before explaining anything, he shows the evidence, because the first reaction to this claim is that it is fake. Matt anticipated exactly that. His post says, for anyone who thinks it is fake, here is the repo and the prompt in the thread below to generate this in one single shot. Both are public: the Claude-of-Duty repository and the prompt itself.

What plays on screen is a first person shooter running in the browser at a size and level of detail that does not look like a demo. It has audio. It is completely playable. You move around, you shoot, you do everything you would expect to do in a shooter. And all of it, every texture and behavior on screen, came out of one prompt.

That combination, a claim that sounds absurd plus a repository you can clone to check it, is why the technique went viral, and it is why the host wanted to bring it to the Execute Automation channel rather than let it stay a Twitter curiosity.

Builder versus critic: what the gauntlet loop actually is

Now the definition. Matt called the pattern a builder versus critics pattern, and popularized it through the Claude of Duty experiment.

"It's a one shot orchestrational prompt, started a many hours run, that produced a technically ambitious browser based first person shooter in Three.js." (1:52)

Read that sentence slowly, because every clause is load bearing. One shot: the human speaks once. Orchestrational: the prompt is not a request for an artifact, it is a request for an organization that will produce the artifact. Many hours: the run outlives your attention span on purpose. Technically ambitious: the target was deliberately set above what a single pass would produce.

Reading the prompt line by line

The prompt Matt gave, as read out on screen:

"I want 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 in a AAA quality form, texture to physics to anything you can think of. Fan out the sub agents and have sub agents tackle each one individually so that the game is utterly perfect." (2:18)

Then the closing instruction, which is the part that actually does the work:

"Don't stop until each sub agent is utterly wowed with the quality when compared with the actual Call of Duty games." (2:55)

The host pulls the structure out of it. There are three sections here, and they are the whole technique:

1. The objective. What you want, stated at a level of ambition that is uncomfortable. Not "a shooter" but "at the level of the most recent Call of Duty games."
2. The metrics. How the work gets done and measured. Fan out sub agents, have each one tackle a piece individually, keep looping, and make one of them a genuinely harsh critic.
3. The boundaries. The stop condition, expressed as a bar rather than a budget. Don't stop until every sub agent is utterly wowed against the real thing.

He defined those three sections, passed it to Claude Code, and got the game.

The old loop: you were the judge

To show what changed, he draws the traditional prompt loop first. A user sends a prompt. The AI agent sends back a response, maybe a full codebase, maybe exactly the thing you asked for in shape. And then reality hits.

"Every single time you get the response, that is not going to be a finished product for you, because now here the human in loop for this particular prompt, which you are using prompt engineering for that matter, is going to be the one who is going to evaluate whether the answer is correct or not from the AI agent that you are getting in." (3:15)

That is the hidden cost of every prompt engineering workflow anybody has been running for the last three years. The model produces. You evaluate. You are the quality gate, which means the ceiling on quality is your patience, and the number of iterations is capped by how many times you are willing to read output and say "no, again."

The new loop: the judge is an agent too

With the gauntlet technique, that arrangement inverts. You do not give the agent a prompt. You give it a job definition.

From that job definition, the AI agent instantiates multiple agents on its own: a designer agent, a tester agent, a UI agent, or whatever agent the job implies. It keeps designing, and it keeps fanning out work.

Those worker agents do not report to you. They talk to the judge agent, which is the critic or evaluator in the system. The judge is handed two things: reference and benchmark details to score the workers' output against, and the boundaries that decide whether judgment should continue at all.

"So this judge agent is going to get some reference and benchmark details whether this output that you are getting from the other worker agents are actually correct or not, and also going to check for the boundaries to whether to stop the judgment any further." (4:12)

If the judge is not happy, the workers go again. If the judge is happy, it emits a stop signal to every agent still working, and that signal is the only thing that ends the run. The judge then returns to the lead agent, and the lead agent returns the output to the user. What lands in your lap is much closer to a finished product than a first response, because the response you would have received in the old loop was rejected internally a dozen times before you ever saw anything.

The three sections, and how to write them for your own job

Here is the punchline the host wants you to leave with: in that prompt, you are not doing any of this. You do not build the designer agent. You do not build the judge. You do not define the handoff protocol between them. You write three sections, and the coding agent plus the large language model construct the rest.

He maps the sections back onto the screen. The objective is the first paragraph. The metrics are the middle block. The boundaries are the last block.

Then he translates it out of game development, because most viewers are not shipping shooters. Say you are building a website:

• Objective: I want to build a website for my portfolio, covering these courses, with this purpose.
• Metrics: spawn this many agents to perform these specific operations, and keep looping until it is perfect. A separate sub agent should be a really harsh critic, and if the result does not look like an actual website of the kind you are aiming at, it should keep going.
• Boundaries: don't stop until each sub agent is utterly wowed with the output for the application you are looking for.

"So you're setting the loop in here for the agents to keep continuing, and then you are setting a boundary." (5:35)

Notice what the boundary is not. It is not a token budget, a time limit, or a number of iterations. It is a quality bar tied to something real that exists outside the run, which is the only reason the loop can terminate honestly. Call of Duty exists. A modern course website exists. The judge has something to lose against.

The boundary row is where the two runs genuinely differ, and it is worth sitting with. Matt's boundary is a ceiling: keep going until you clear this bar. The website boundary is a fence: you may do anything except leave this machine. Both are legitimate uses of the same slot, and a serious prompt probably wants one of each.

Why MiniMax M3 and not Claude

Having explained the technique, he shows his own two runs. Both were done with MiniMax M3 rather than Claude, and he is candid about why.

"I have not used the Claude model or my standard plan that I have got, because I'm not sure whether it's going to burn out the whole token for me. That's the reason why I'm sticking with the MiniMax M3 model, because they are pretty good in terms of the cheapest price for the amazing model that they have got." (6:25)

That is a real consideration and not a throwaway. A gauntlet loop is designed to run for hours and to reject its own work repeatedly. Rejection is not free. Every "go again" from the judge is another full build pass by a fan of sub agents. If your plan meters you, a technique whose entire value proposition is "loop until wowed" is the fastest way to find your ceiling. He picked the cheapest capable model precisely because the pattern is token hungry by design.

Run one: a complete Playwright test framework

The first thing he pointed the gauntlet loop at was his own domain, test automation. One prompt, and out came a Playwright test framework.

What is on screen when he scrolls the generated repository:

• Accessibility testing specs
• Authentication testing
• Console error testing
• Employee CRUD operations specs
• Employee details spec
• Employee list spec
• Fixtures
• Navigation specs
• Register specs
• Responsive spec
• The Playwright configuration itself
• Debug scripts it wrote for itself, to help work out what was going wrong

That last item is the tell. Nobody asked for tooling. The run produced its own debugging aids because a judge agent kept sending work back and the workers needed a way to see what they were failing on. A one shot prompt does not produce scaffolding for its own iteration, because it does not expect to iterate.

"Everything is generated for me with just one single prompt." (7:20)

The receipts: 444 messages, three of them his

Then he opens the usage panel, and this is the most quietly convincing part of the video.

The run took roughly 444 total messages. Of those, three were messages he sent, the three sections of the gauntlet loop prompt. The assistant side accounts for 222 calls, all of them automatic. Everything else in the count is the machinery talking to itself.

And the cost of that, on his plan:

"The total number of usage for this particular operation is not much as well. It just used like 1 percentage of my daily five hours limit in my MiniMax. So it's not that much as well, to be honest, for this whole operation it has performed." (8:20)

Three messages to 444 is the number to remember. It is not a claim about quality, it is a claim about where the human attention went, and that ratio is the entire argument for the pattern.

Run two: the course listing website

The second run was more ambitious, because it required the agents to go get real data from the open internet before they could build anything.

The objective: build a modern 2026 quality course listing website for Execute Automation that showcases every course he teaches on Udemy. And critically, go and fetch the courses from Udemy first, because there are more than 40 of them. Once you have that information, start building.

Then the metrics section. Then the boundaries, which in this run is a fence rather than a ceiling:

"Build a static local site that renders locally, and do not deploy it anywhere, register any domains, or push it live. I'm setting a hard limit there, that this is the boundary that it should not really break for me." (9:05)

He is explicit about why: he did not want a long autonomous run putting something on the public internet on his behalf. When you hand an agent hours of unsupervised time and permission to fan out, the boundary section is also your safety rail, not just your quality bar.

Scrape, V1, then the critic rounds

The execution unfolds on screen in phases, and the phases are exactly what the architecture predicts.

• Prompt One gauntlet loop message with the three sections. That is the last thing the human does.
• Scrape The coding agent goes out and does real scraping of the Udemy course data, which he notes took quite some time. Nothing can be built until this returns, so the run spends its first stretch just acquiring ground truth.
• V1 With the data in hand, it builds the first version of the site. In the old loop, this is the moment output would have come back to a human for grading.
• Critics Instead it goes straight into the critic review, with fixed rounds. This is the gauntlet proper: the judge agent grading the site against what a modern course website should look like, and sending it back.
• Done The application is up and running locally. Total wall clock: 1 hour and 13 minutes, and not a minute beyond that, at which point execution simply completes.

The "fixed rounds" detail is worth flagging. The critic pass was not unbounded. The run had a defined number of review cycles, which is how a loop whose stop condition is a subjective quality bar avoids running until the heat death of your API budget.

Touring the finished site

He clicks through what came out, and the tour is a list of things nobody specified.

The landing page describes him as software architect, consultant, YouTuber and bestselling instructor. His photo is on it. Then a detail he clearly enjoyed:

"It also shows you my YouTube channel as well over here, which I have not even told, but it's bringing it up for me as well." (10:30)

The agents scraped past the literal ask and pulled in his channel because a course instructor's site should have one. That is a judge agent enforcing "does this look like a real site of this kind" rather than "did you do what the ticket said."

The rest of the walkthrough:

• All his courses are listed. Clicking browse all courses goes through to a single page view. He notes a small change glitch on that transition and waves it off as fine.
• Featured courses render with thumbnails pulled from the source, not placeholders.
• His details are there, including how many students have enrolled in his courses and the years of experience he has.
• Every topic he covers is listed, and each topic is clickable. Clicking one filters to that subject, so clicking the AI topic shows all his AI courses.

All of it from one prompt, plus a technique. As he puts it: based on the gauntlet technique that I've used, every single thing is happening, which is quite amazing.

One hour and 13 minutes, and what it opens

He closes by naming the number again, because the number is the argument.

"The total time it took to complete this particular operation for me is around 1 hour and 13 minutes, not beyond that, and after that the execution is complete." (11:23)

An hour and 13 of machine time. Three messages of human time. He is honest that he has not done any game development, so he cannot speak to Matt's result from experience, but he says he can already see the potential for his own use cases, and he throws the question to the audience: how would you use this inside your organization?

His last point is the one worth carrying out of the video:

"Now you don't even have to build these agents and sub agents, because all these fan out of the agents and sub agents are going to happen automatically by just that one single line, and you're going to be seeing amazing results already." (11:45)

The multi agent frameworks of the last two years asked you to define the roles, the message passing, and the termination logic yourself. The gauntlet loop's claim is that a capable enough coding agent will assemble all three from a paragraph, if you remember to include a critic and a bar.

Where it stands

The video is a walkthrough, not an evaluation, so it is worth adding the honest ledger the format does not have room for.

What is solidly demonstrated: the pattern really does produce large amounts of working output from a single message, and the artifacts are checkable. Matt's repository and prompt are public, and the two runs shown here produced a test suite and a site whose contents match real Udemy data, which is not something a hallucinating model produces by accident. The message ratio is the strongest evidence in the video, because it is the one thing that cannot be staged.

What deserves care. The judge agent is usually the same model that built the work, wearing a different hat, so the pattern inherits that model's blind spots on both sides of the loop. It cannot see what it cannot see, no matter how harsh you tell it to be. That is exactly why the boundary must name something outside the run, an actual game, an actual class of website, rather than "make it good." The critic rounds were also fixed in number, so the loop terminates on a schedule as much as on satisfaction. And the quality claims here are visual. A site that looks modern in a screen recording and a test suite whose files are correctly named are not the same as a site that holds up under real Customer traffic or a suite that catches real regressions. The small glitch on the courses transition, waved off in passing, is the kind of thing a harsh critic was supposed to have caught.

The economics are worth noting too. One percent of a daily allowance is a MiniMax M3 number on the cheapest capable model available, chosen specifically because the presenter did not trust the pattern with his Claude plan. Run the same gauntlet on a frontier model with hourly rejection cycles and the cost story reads differently. That is not an argument against the technique. It is a reminder that "loop until wowed" and "metered plan" are in tension, and the video is refreshingly upfront about having resolved that tension by switching models.

Key takeaways

• The gauntlet loop is a builder versus critic pattern: worker agents produce, a judge agent grades against an external benchmark, and the loop only ends when the judge is satisfied.
• Your prompt has exactly three sections. Objective (an uncomfortable target), metrics (fan out sub agents, loop, include a harsh critic), boundaries (the stop condition).
• The boundary is the load bearing part, and it comes in two flavors: a quality ceiling ("don't stop until utterly wowed compared to Call of Duty") and a hard fence ("do not deploy, do not register domains, do not push it live").
• Tie the bar to something that exists outside the run. A judge with no external reference is just the builder agreeing with itself.
• You do not write the agents. The lead agent instantiates designer, UI, tester or whatever the job implies, straight from the prompt.
• The old loop made you the evaluator, which capped iteration count at your patience. The new loop moves the evaluator inside the machine.
• The receipts from the Playwright run: 444 total messages, 3 sent by the human, 222 assistant calls, roughly 1% of a daily five hour limit.
• The website run: scrape real Udemy data, build V1, run fixed rounds of critic review, done in 1 hour and 13 minutes unattended.
• Pick your model for the pattern. Rejection cycles are the whole point, and they cost tokens, which is why this presenter ran MiniMax M3 rather than burn a metered Claude plan.
• The technique generalizes well past games: test frameworks, websites, applications, and fine tuning work are all cited as targets.

Chapters

• 0:00 One prompt, 40 plus games, and nobody in the middle
• 0:52 Claude of Duty, the exhibit everyone points at
• 1:48 Builder versus critic: what the gauntlet loop actually is
• 2:14 Reading Matt's prompt line by line
• 3:10 The old loop, where you were the judge
• 3:41 The new loop: lead agent, workers, judge agent
• 4:53 The three sections, and how to write them for your own job
• 6:11 Why MiniMax M3 and not Claude
• 7:13 Run one: a complete Playwright test framework
• 8:05 The receipts: 444 messages, three of them his
• 8:46 Run two: the course listing website prompt
• 9:34 Scrape, V1, then the critic rounds
• 10:08 Touring the finished site
• 11:23 One hour and 13 minutes, and what it opens

Notable quotes

"This is one of the technique which is used to build more than 40 plus video games with just one single prompt." (0:05) Execute Automation

"It is going to spawn a lot of different agents for you and even works for hours to complete a task without even a single human intervention." (0:30) Execute Automation

"Gauntlet loop, Matt called them as a builder versus critics pattern, and he popularized it through the Claude of Duty experiment." (1:48) Execute Automation

"Don't stop until each sub agent is utterly wowed with the quality when compared with the actual Call of Duty games." (2:55) the boundary line of Matt Shumer's prompt, read on screen

"Every single time you get the response, that is not going to be a finished product for you, because now here the human in loop is going to be the one who is going to evaluate whether the answer is correct or not." (3:15) Execute Automation, on the traditional loop

"This judge agent is going to get some reference and benchmark details whether this output that you are getting from the other worker agents are actually correct or not." (4:12) Execute Automation

"In this particular prompt that I was just showing you, you are not essentially going to be doing any of these." (4:50) Execute Automation, on not having to build the agents yourself

"I have not used the Claude model or my standard plan that I have got, because I'm not sure whether it's going to burn out the whole token for me." (6:25) Execute Automation

"It just used like 1 percentage of my daily five hours limit in my MiniMax." (8:20) Execute Automation

"It also shows you my YouTube channel as well over here, which I have not even told, but it's bringing it up for me as well." (10:30) Execute Automation, on the site including things he never asked for

"The total time it took to complete this particular operation for me is around 1 hour and 13 minutes, not beyond that." (11:23) Execute Automation

"Now you don't even have to build these agents and sub agents, because all these fan out of the agents and sub agents are going to happen automatically by just that one single line." (11:45) Execute Automation

Resources mentioned

• Claude of Duty, the repository, the browser based first person shooter Matt Shumer generated from a single prompt, published so people could check the claim themselves
• The prompt itself, prompt.md, the three paragraphs the whole technique is named after
• Matt Shumer's post showing the run, the "here's the repo and the prompt in the thread below" expose referenced at 0:52
• Three.js, the browser 3D library the generated shooter is built on
• Claude Code, the coding agent Matt passed the gauntlet prompt to
• Codex, named as one of the coding agents the same prompt works with
• MiniMax M3, the model behind both of the presenter's own runs, chosen for price on a token hungry pattern
• Playwright, the test framework generated end to end in run one
• Udemy courses by Karthik KK, the 40 plus courses the agents scraped to build the site in run two
• Execute Automation on YouTube, the channel this breakdown comes from
• End to End Testing of Chatbots, AI Agents, RAG and MCP Servers, linked from the video description
• RAG and LLM App Testing for Beginners, linked from the video description
• AI Driven Test Automation: Playwright, Selenium, LLMs and More, linked from the video description