{"id":34667,"date":"2026-08-13T00:25:30","date_gmt":"2026-08-12T22:25:30","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=34667"},"modified":"2026-08-13T01:46:25","modified_gmt":"2026-08-12T23:46:25","slug":"loop-engineering-with-super-mario-and-twelve-ai-coding-agents","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/loop-engineering-with-super-mario-and-twelve-ai-coding-agents\/","title":{"rendered":"Loop Engineering with Super Mario and Twelve AI Coding Agents"},"content":{"rendered":"

I gave twelve AI coding agents the exact same job: implement a Koopa Troopa \u2014 Nintendo's shelled enemy \u2014 in the same small Angular-based Super Mario clone, working from the same two tickets, under the same automated agent loop. Then I watched what came back.<\/p>\n

\"Screenshot<\/p>\n

This is a backyard test setup<\/strong>, not a leaderboard \u2014 n=1, one codebase, one domain, no statistical significance. What I was after isn't a ranking of models but a feel<\/em>: how an agent loop actually behaves when you swap the model underneath it.<\/p>\n

The tasks<\/h2>\n

The project is a deliberately compact Mario clone: a tile-based level, a hero with jump physics, and one existing enemy \u2014 the Gumba \u2014 as the reference implementation. Each of the twelve agents got a pristine copy of this baseline and two GitHub issues:<\/p>\n

    \n
  1. koopa-troopa<\/strong> \u2014 implement a green Koopa Troopa: stomp it and it hides in its shell, touch the shell and it slides, a sliding shell kills other enemies and Mario (with a short immunity window after the kick).<\/li>\n
  2. enemy-bounce<\/strong> \u2014 when Mario stomps any enemy, he bounces; holding the jump key at that moment gives a higher bounce; and a held key must never trigger repeated jumps (release-latch).<\/li>\n<\/ol>\n

    Both tickets are exactly the kind of work I wanted to test: a new feature woven deep into existing behavior (collision system, stomp mechanic, jump physics) rather than bolted on beside it, complexity well beyond CRUD demos, and a nearby example to steer by \u2014 the situation you find in large business systems, where new requirements almost always land next to something structurally similar.<\/p>\n

    Each ticket read like one from sprint planning: a user-facing description, scope and out-of-scope lists, Given\/When\/Then acceptance criteria, and a verification section ("all tests green, build passes"). The refinement conversation was simulated up front: an LLM posed the clarifying questions a developer would ask, and the answers went back into each ticket as a Design Decisions<\/strong> section. Remediation was sprint-like too: bugs from the first review went into a single QA-style fix ticket, and each agent got exactly one more run. A wrong sprite tile as the only<\/em> defect went un-ticketed \u2014 more on why below.<\/p>\n

    The harness<\/h2>\n

    Every model ran under its vendor's own official agent<\/strong> \u2014 Claude Code, Codex CLI, cursor-agent, Antigravity, Grok CLI \u2014 at stock configuration. So this doesn't compare bare models; it compares the products<\/em> developers actually use, model plus agent plus system prompt and tooling.<\/p>\n

    Each was wrapped in the same orchestration harness, Sandcastle \u2014 essentially a Ralph loop<\/strong> (the agent re-invoked over its own output until the work is done) with four stages: a planner<\/em> reads the open tickets, an implementer<\/em> takes each ticket on its own branch and writes tests as it goes, a reviewer<\/em> passes over the diff, and a merger<\/em> integrates what survives. Wired to GitHub, a run leaves the same paper trail a human sprint would \u2014 issues in, branches and comments out, including a token and wall-clock report per issue.<\/p>\n

    \"Diagram<\/p>\n

    Each stage ran inside a sandbox. That matters beyond network hygiene: twelve solutions to the same tickets sat in adjacent directories, and each had to be arrived at independently. On the two agents whose transcripts I audited call by call (Grok and Opus 5), that held \u2014 no neighbor's repo was ever read.<\/p>\n

    The results<\/h2>\n

    The numbers are sums across both tasks plus any fix rounds, covering all phases, taken from the reports Sandcastle posted on each GitHub issue. It all happened in July 2026.<\/p>\n

    Costs are each run's metered usage (fresh input, cache writes\/reads, output, all phases and fix rounds) at public API list prices \u2014 a normalized what-if<\/strong>, not necessarily what a run costs you<\/em>: under flat-rate subscriptions the marginal run is free until quota. Fine print: Composer's cache-read rate is assumed (unpublished), Sonnet uses its introductory price, GPT-5.6 the late-July cut.<\/p>\n