Pieter Levels posted recently that every time he runs a Gauntlet Loop — an AI agent coding technique that went viral in mid-2026 — he ends up with “a total mess and chaos of unperformant code and too many things happening and nothing works properly.” He burns $500, cleans up the mess manually, and returns to where he started. His fix: go back to step-by-step, feature-by-feature coding.
This is one of the more useful AI coding observations to surface in a while, because it names the actual problem without quite identifying it. The Gauntlet Loop is not broken. What is missing is what the Gauntlet Loop is working inside of.
stateDiagram-v2 direction TB state "Session starts: no footprint" as NoFP state "AI invents structure" as Invent state "Inconsistent decisions accumulate" as Debt state "Manual cleanup required" as Reset state "Session starts: footprint defined" as WithFP state "AI works within constraints" as Constrained state "Feature shipped cleanly" as Ship [*] --> NoFP: footprint skipped [*] --> WithFP: footprint defined first NoFP --> Invent Invent --> Debt Debt --> Reset Reset --> [*]: $500 burned, start over WithFP --> Constrained Constrained --> Ship Ship --> [*]: stackable, maintainable output
What a Code Footprint Actually Is
A code footprint is the set of structural decisions that govern how a codebase is organized before any feature-specific work begins. It includes the technology stack, folder structure, data model conventions, naming patterns, module boundaries, and integration points. These are the decisions that determine whether the output of ten different AI prompting sessions will cohere into something maintainable or accumulate into something you have to tear out and rebuild.
Without a defined footprint, every vibe coding session makes these decisions on the fly. The AI picks a folder structure for this session. It names things one way here, another way in the next session. It solves authentication one way in one module, differently in another. None of this is a failure of the AI — it is a failure of the environment the AI is operating in. The model does not know what decisions were made in previous sessions. It is doing its best with what it sees.
The Gauntlet Loop failure that Pieter Levels describes is this problem at scale. Multiple agents generating in parallel, each making structural decisions without reference to what the others decided, producing a result that has to be manually reconciled because there was no shared foundation to reconcile against.
What a Starter Template Solves
A starter template is a predefined code structure that establishes the footprint before any prompting begins. It pre-solves the recurring structural decisions — authentication, routing, data access patterns, error handling conventions, UI component structure — so that the AI can work within a proven architecture rather than inventing one per session.
The value is not just cleaner individual sessions. It is cumulative consistency. Every feature built on top of the starter template inherits the same structural decisions. The codebase stays comprehensible regardless of how many AI sessions contributed to it, because all of them are working within the same framework.
I built the CleenUI framework on exactly this principle. During a contract engagement at CloudVirga, I was working on a mortgage origination web platform built on AngularJS. The front-end architecture had predefined fields and components for every common user experience element — authentication flows, content management, settings, forms. That level of reusability was striking: every new feature was built on top of something that already solved the structural questions. I was so impressed by what consistent reuse made possible that I built CleenUI a few years later to formalize it — a full-stack, reusable source code framework covering the 15 most common application areas: security, user management, content management, notifications, and so on.
The point is not the specific framework. The point is that having a solved, reusable foundation before any session-specific work begins is what transforms AI-assisted development from a series of disconnected sprints into an accumulating, coherent codebase.
The Structural Questions That Must Be Answered First
Before the first vibe coding session on a new project, the following structural decisions should be locked:
Technology stack. Not just the language, but the specific libraries and versions. If the AI is picking these per session, you will end up with a codebase that uses three different state management solutions in three different modules.
Folder and module structure. How is the codebase organized? Where do models live relative to controllers relative to views? If this is not defined, the AI will invent something that made sense locally and creates confusion globally.
Data model conventions. How are entities named? How are relationships expressed? Consistency in the data model is what makes the codebase readable to a human reviewer and navigable to the AI in future sessions.
Authentication and authorization pattern. This needs to be solved once and inherited everywhere. AI sessions that reinvent this per module produce inconsistencies that become security vulnerabilities.
Error handling conventions. What does failure look like across the system? Consistent error handling is the difference between a debuggable system and one where failures surface as cryptic state without a clear trace.
These decisions do not take long to make. They take discipline to make before starting rather than during, and they save an order of magnitude more time than they cost.
The Pattern That Makes Vibe Coding Work at Scale
The builders who are consistently productive with AI-assisted development tend to share a few habits. They define the footprint before every project. They build or adopt a starter template that captures their preferred structural decisions. They prompt within that structure — “add a route following the existing pattern,” not “build a route” — which keeps the AI’s output coherent with the rest of the codebase.
Pieter Levels’ instinct to go back to step-by-step, feature-by-feature coding is not a rejection of AI. It is a recognition that AI works best when it operates within a defined scope. The step-by-step approach is an informal code footprint: each step is constrained by the decisions that came before it. The alternative is not to abandon the Gauntlet Loop — it is to give the Gauntlet Loop a footprint to work within before it runs.
$500 burned on a session that goes nowhere is not evidence that the AI is bad at coding. It is evidence that structural decisions cannot be outsourced to the AI. Those are architectural decisions. They have to be made by the person who owns the system.
