There is a common assumption in AI-assisted software development: if the result is not good enough, you need a stronger model. My latest experiment suggests something different.
I built a Mario Kart-style racing game in Three.js using Claude Code and a free Qwen3.8 model. The model itself is capable, but compared with the strongest commercial coding models, it is clearly weaker. It makes more mistakes, loses context more easily, produces rougher first attempts, and often needs much more guidance.
And yet, within roughly eight hours, the system produced a playable 3D racing game with three different tracks.
The reason was not the model. The reason was the process.
The Gauntlet Loop
The development method I used can be described as a Gauntlet Loop:
Build → Test → Critique → Improve → Repeat
Instead of asking the model to “build a great game” and hoping for a good result, every meaningful part of the project was forced through repeated rounds of implementation and criticism.
The model did not get to stop when something merely worked. It had to survive the gauntlet.
A track was not finished because it loaded. It was finished only after repeatedly asking questions such as:
- Does the racing line feel right?
- Does the environment look visually coherent?
- Are the turns readable at speed?
- Does the camera feel stable?
- Are there obvious graphical artifacts?
- Does the scene feel empty?
- Does it look like a prototype, or like something approaching a real game?
Whenever the answer was “not good enough,” the system went back into another iteration. That distinction matters.
Weak Models Fail Differently
The most interesting part of working with a weaker model is that its limitations are very visible. A strong model can often produce a surprisingly good first pass. A weaker model usually cannot.
It may:
- implement only part of a feature
- misunderstand visual requirements
- create inconsistent architecture
- introduce regressions
- overlook edge cases
- stop at a technically functional but visually poor result
If your workflow depends on the first answer being correct, this is a major problem. But the Gauntlet Loop changes the economics. The question is no longer: Can this model generate the perfect solution?
The question becomes: Can this model improve the solution when repeatedly shown what is wrong?
That is a much lower bar. And many open or free models are already good enough to clear it.
Iteration Can Compensate for Intelligence
A weaker model may need five attempts where a stronger model needs one or two. But if inference is cheap or free, that can still be a very good trade.
This is where the method becomes interesting. Model quality and process quality are not independent. A strong workflow can partially compensate for a weaker model. A weak workflow can waste even an excellent model.
The Gauntlet Loop effectively converts cheap inference into quality through iteration. Instead of paying primarily for intelligence per request, you are paying with additional cycles of: implementation, inspection, feedback, and correction.
For many tasks, that is perfectly acceptable. Especially when the model is free.
The Critic Is as Important as the Builder
One of the most important elements is separating implementation from evaluation. The agent that builds something should not simply declare its own work finished. That creates an obvious failure mode: the model tends to accept its own output too early.
Instead, a separate critic should evaluate the result against explicit criteria. For a racing game, the critic might inspect:
- visual quality
- driving feel
- camera behavior
- track layout
- lighting
- performance
- collision behavior
- consistency between tracks
- overall polish
The critic should be deliberately harsh. Its job is not to be supportive. Its job is to find defects.
That creates a useful adversarial relationship inside the development loop. One agent creates. Another tries to prove that the result is not good enough. The builder then has to respond. This is fundamentally different from ordinary prompt-and-response coding.
Quality Thresholds Matter More Than Prompt Length
Another lesson from the experiment is that long prompts are not necessarily the answer. A giant prompt can describe an ambitious goal, but it does not guarantee execution quality. What matters more is whether the system has measurable stopping conditions.
For example:
“Make the track beautiful” is vague.
“Reject the track if there are empty areas, repeated geometry, visible clipping, poor lighting, weak landmarks, or sections that are visually indistinguishable” is actionable.
The Gauntlet Loop works best when the quality criteria are concrete. The model needs to know what failure looks like. Without that, it tends to converge too early.
Why This Matters for Open Models
The implications go beyond game development.
Open and free models are improving quickly, but they still often lag behind the best closed models in raw coding reliability. That does not necessarily make them unusable. It may simply mean they need a different orchestration strategy.
Instead of treating the model as an expert developer who should get everything right immediately, treat it as a fast junior team that can work continuously, receive criticism, and iterate.
Then surround it with: clear decomposition, automated tests, visual checks, linting, runtime validation, specialized critics, and repeated loops.
The model becomes only one component of the system. And that may be the more important architectural shift.
From Model-Centric to Process-Centric AI Development
A lot of current AI tooling is still model-centric.
- Which model has the best benchmark score?
- Which model produces the cleanest code?
- Which one is closest to a senior developer?
Those questions matter. But they may matter less over time.
The more interesting question is:
What development process allows an imperfect model to reliably produce good results?
That leads toward a different architecture for AI coding: multiple agents, specialized responsibilities, automated evaluation, continuous feedback, tool use, visual inspection, and explicit iteration loops.
In that world, model intelligence is only one variable. The workflow becomes a multiplier.
The Eight-Hour Experiment
The racing game was a useful test because it combined many different problem types.
- Three.js rendering.
- Game logic.
- Camera systems.
- Vehicle controls.
- Track design.
- Physics.
- Visual effects.
- Performance.
- Gameplay tuning.
A weak model trying to solve all of that perfectly in one pass would fail. Repeatedly.
But that was exactly the point. Failure was not the end of the process. Failure was an input to the next loop. That is what made the experiment work.
The Bigger Lesson
The most important takeaway for me is simple:
Do not optimize only for the smartest model. Optimize for the strongest development loop.
A premium model with a poor workflow may still produce mediocre software.
A weaker model inside a disciplined iterative system can produce results that are far better than its first-pass capability would suggest.
The future of AI development may therefore be less about asking: “Which model should I use?”
And more about asking: “How do I build a system that makes any model continuously improve its own output?”
That is what the Gauntlet Loop is really about. Not eliminating mistakes. Making mistakes cheap, visible, and correctable.
And when the model itself is free, that becomes a very powerful proposition.