The Gauntlet Loop Has a Huge Flaw (and the Claude Skill That Fixes It)
We build software, and we ran the gauntlet loop on real work to see where it holds up and where it falls apart.
The gauntlet loop lets people build entire games and apps from a single three-line prompt. We gave it a huge product and it built the whole thing without bugs in about an hour. But there are two problems nobody mentions, and they're exactly why it works for games and breaks on real projects. The fix is already built and shipped, in a form you wouldn't expect.
We build software, and we ran the gauntlet loop on real work to see where it holds up and where it falls apart. The results are genuinely impressive, and the prompt behind them is far simpler than you'd think. But the same two flaws show up every time, and they decide whether this method is useful to you or a trap. Here's how the loop works, what breaks, and the skill that fixes it.
First, what the gauntlet loop is
Skip this if you already know it. Before loops, you were the one checking the agent's work: prompt, review, correct, repeat, until it was right. A loop takes you out of that. You give the agent a goal and a standard, and it keeps checking its own work until it reaches that standard. You only see the result at the end.
The gauntlet loop is a newer kind that people have used to build games, 3D worlds, and full websites from one prompt. It started when Matt Schumer posted a demo on X of a first-person shooter Claude built from a single prompt with no existing assets. That's not what people thought these models could do yet, so it spread fast. He later published the method and named it the gauntlet loop, and others (including Andrej Karpathy) pointed out why work like this matters: output this high was never worth producing before, because the time cost more than you got. A model doesn't have that limit.
How three lines run the whole thing
Schumer's prompt was three lines, and each handles a different part of the build.
Line one: what you're building, and the quality bar. His was a first-person shooter at the level of the most recent Call of Duty games. He asked for AAA quality and spelled out that it had to be perfect in everything, from textures to physics.
Line two: how it should build. This splits the work. You tell the main agent to break the goal into smaller parts itself and hand each to its own sub-agent (separate agents it kicks off, each working on one small task in its own memory without seeing the others). The prompt is specific that the agent splits the work itself, so you don't have to. Each builder gets a loop, and attached to it is a review sub-agent called the critic. The critic only checks work, sends it back to the builder if it isn't good enough, never builds anything, and starts with no memory, so it doesn't know who made the work or how many times it's been sent back. It just grades brutally and honestly.
Line three: the quality level the final output must match, which tells the critic when to stop. Schumer set Call of Duty as the standard and had the critic compare the two blindly, meaning it isn't told which one Claude made, then say which looks better.
There's one more word at the end: Ultra Code, a Claude Code keyword that turns this into a dynamic workflow, running a whole fleet of sub-agents at once instead of a few. Run it that way and it's a graph (an advanced loop where many sub-agents loop rather than one). Specifically, it's a diamond graph: one task splits into several sub-agents side by side, then narrows back to a single agent that pulls everything into one answer.
The two flaws nobody mentions
Flaw one: the agent controls its own checking. The main agent decides on its own how it spins up the critics and writes their instructions, so you have no control over the critics or the judgment prompt passed to them. All you gave it was a thing to compare against, and past that the prompt just says "be a harsh critic and check it visually." Checking is something you should set concretely instead of letting the agent verify itself, and at this scale you won't be able to trace what caused an issue later.
Flaw two, the one that decides if this works for you at all: the quality bar is an existing product. Call of Duty already shipped, so the critic had a real thing to measure against instead of inventing a standard. That's the entire reason it worked, and it's fine for a game, a landing page, or a 3D world, because there's always something to compare to. But when you're building something new, there's no existing app to set the bar. The critic makes up a standard and starts passing work by it, and by the time you realize its assumed direction isn't what you wanted, you've burned a lot of time and tokens on features built against a standard the agent invented.
Having nothing to compare against is the normal case, not the exception. If you're building the billing rules your own business runs on, there's nothing finished to hand the critic. The gauntlet loop works when there's something close enough to copy, and it breaks the moment there isn't.
Takeaway: The gauntlet loop's strength is a fixed external standard to judge against. On anything original, that standard doesn't exist, so the loop invents one and drifts.
The fix, in two parts
The first part is verification: plan the checks properly instead of letting the agent invent them (we covered this in the graph engineering piece). The second is giving the loop concrete requirements so it can't drift, and that's where a skill called Wayfinder comes in.
What Wayfinder does
Wayfinder is made by Matt PoCo, a developer who's shipped a set of installable skills, each for a different job. Wayfinder is his intensive planning one, built on planning fundamentals from before AI, and it isn't tied to coding. You can use it to plan anything.
It exists to solve a problem you've probably hit. When you plan something big with an agent, the destination is clear but the path isn't, and that stretch in between is what PoCo calls the fog. The agent never tells you it's in the fog. It fills the gap with its own assumption and carries on as if the thing were settled, so you get back a plan that looks finished with invented parts in the middle.
Wayfinder builds a map instead. Every decision still to be made goes on the map as its own question, split into two groups: the ones you can settle now because everything they depend on is decided, and the ones still in the fog because something you haven't looked into is holding them up. When it hits fog, it doesn't guess. It sends the agent to clear the fog, by researching, building something rough to react to, or a real-world task like signing up for a service to judge it. Each is handled on its own, and once settled, the answer goes back on the map and unlocks whatever was waiting on it. You work through the map question by question until there's no fog left, and every decision is written down with its reasoning.
Wayfinder turns all of that into a single spec, the one document laying out what you're building and why. And that spec is the fix for the gauntlet loop. Just as Call of Duty was the bar for the game, the spec becomes the bar for your app, and a way to mark what "done" means. Every decision in it was actually settled instead of assumed, so when you're building something with nothing to copy, the critic still has something solid to check against instead of inventing a standard.
Takeaway: The gauntlet loop needs a source of truth. Wayfinder produces one by turning your planning decisions into a spec, so the loop measures against your real requirements, not a guess.
How we ran it on a real app
We used an HR system where people apply for leave, file complaints, and more.
We didn't use the original Wayfinder as-is. It's built to carry you all the way to a finished spec, writing every decision into its own separate requirement file. We only wanted the part that gets you to clarity, so we asked Claude to change the skill to turn those decisions into a single answer key the agent keeps checking itself against, instead of many files. It rewrote the skill, kept the core, and reshaped the rest, and we ended with a simpler version that writes just two files: the map and the answer key. We also trimmed the other skills it calls (Wayfinder relies on some of PoCo's other skills, like grill-me for the questioning) down to three.
We ran the wayfinder command in Claude Code (it won't start on its own), told it we wanted the HR system, and it questioned us: who the app is for, what has to be in it and what doesn't, what "done" looks like, and what could go wrong once people use it. It ran to 34 questions, then wrote two files into a .finder folder: the map (every decision, the reasoning, and what the finished thing should look like) and the answer key (checks where every line comes back pass or fail).
Then we set up the loop. We copied Schumer's exact prompt, asked Claude to rewrite it for the HR system, and changed the one thing that matters: instead of a game, the source of truth is the wayfinder folder from planning. Everything gets checked against what's in there, exactly the way Call of Duty worked originally. Claude handed back the same gauntlet-loop format written for our app.
From there it ran like the original, except the sub-agents now had the answer key to check against. We told it there was no "close enough" and no shortcuts. It planned what to build first, the tools to install, then the foundation work, then launched many agents at once, each on a different part. The build took 1 hour 33 minutes and used about 40% of our session limit. On the API instead of our max plan, that build would have cost around $116, which is a lot. But what came out was the app as planned, with every feature working. It had some issues, but it was the closest to what we actually needed.
FAQ
What is the gauntlet loop? A method, from Matt Schumer, where a short three-line prompt has a main agent split a build across sub-agents, each reviewed by a "critic" that grades the work against a named quality standard until it's good enough.
Why does it work so well for games? Because there's always an existing product to measure against, like Call of Duty. The critic compares the work to something real instead of inventing a standard.
Why does it break on real projects? Most real work has nothing finished to compare to. The critic makes up its own standard and passes work by it, so you get features built against a bar the agent invented.
What does Wayfinder fix? It clears "planning fog" by turning every real decision into a spec and answer key. That spec becomes the standard the loop measures against, so it doesn't drift.
Is this expensive to run? Yes. Our build took over 90 minutes and about 40% of a max-plan session. The same on the API would have been roughly $116.
The takeaway
The gauntlet loop is real, and it one-shots impressive work, but only when there's something to measure against. Its two flaws, self-managed checking and a borrowed quality bar, are exactly why it shines on games and fails on original work. The fix isn't a new technique. It's giving the loop a real source of truth. Plan the checks properly, and use Wayfinder to turn your decisions into a spec the critic can hold the build to.
Our trimmed Wayfinder skill and the rest of the setup live inside AI Labs Pro.