@no_stp_on_snek: Ran this on Laguna S 2.1 in Poolside's own agent (pool), pointed at a local instance on a DGX Spark, using the prompt l…

Ran this on Laguna S 2.1 in Poolside’s own agent (pool), pointed at a local instance on a DGX Spark, using the prompt lessons from earlier today (link in comments).

44 of those minutes were pure research before it wrote a single line. Another 18 to a working, self-verified game. 62 minutes total, 104 tool calls, peaked at 57% of the 128K context. Quote-tweeting the qwopus36_27b-coder run I did in June, same style of prompt. That one took hours (but had a better-looking end result).

What it produced, verified by me™ (cough cough opus) and not by its own claims: 654 lines of valid JS (node –check clean), an index.html, a 7.6KB Playwright self-play suite, and a config. I ran the suite myself: 4 of 4 pass in 26s. Mario moves, stands on ground without tunnelling, stomps a Goomba, and hits the flagpole with gameWon=true at x=1932 of 1948.

The research wasn’t theater. 11 web_fetch calls produced a CONFIG block noting “SNES resolution 256x224, scaled 2x” (correct) and physics “based on SMB/SMW”: gravity 0.25 px/frame², terminal velocity 2.67, jump -4.3, separate ground and air acceleration. A real momentum model with distinct air control, not x += speed.

The engineering beats the art. Collision uses a swept check against the previous frame’s position (anti-tunnelling). Stomp detection correctly requires vy > 0 plus feet above the enemy’s midline before bouncing (something qwopus never did). Clean class separation, centralized config, and it exposed window.MARIO_GAME.getState() so a harness could introspect state.

The behavioral headline is the actual story. Its first self-play came back 3 of 4 red. It didn’t thrash. It wrote: “Ground collision: this.y + this.height > platform.y fails when Mario’s bottom exactly equals platform.y (400 == 400). Need >=… Flagpole: mario.y < tapeY + 4, but Mario’s y is 368 and tapeY is 340, so 368 < 344 is false.” It read a red result, correctly blamed its own game code, diagnosed an off-by-one and a mispositioned target with real numbers, fixed them, and went green. It also hit a missing dependency, installed it, wrote a playwright.config.js, and reran. Zero human intervention.

That’s the exact inverse of the June qwopus run, which built a nicer game faster and then spent ~17 iterations stuck on a phantom: its self-play never left the title screen, it read a frozen game as “Mario fell in a pit,” and it thrashed an irrelevant jump constant instead of questioning its own test. It needed a human nudge to escape. Laguna’s edge here isn’t coding ability, it’s oracle discipline: when the test went red, it interrogated the right artifact.

Now the honest part. This is not World 1-1. Four platforms, one Goomba, a flagpole. No pipes, bricks, ?-blocks, coins, powerups, staircase, or gaps (I grepped: all zero). No pit means no death, no lives. mario.state (‘small’/‘super’) is declared and never used. It’s flat rectangles on a lot of empty sky. Kinda meh but it works. The June build actually looked more faithful (clouds, bushes, pipes, bricks), still not 1-1.

Two deeper smells. The game loop computes delta then ignores it, so physics are fixed-per-frame and it runs at double speed on a 120Hz display. A headless 60fps self-play can’t catch that. And the flagpole tape oscillates up and down instead of sliding down on contact, it moved the tape to make the win reachable. Mild fitting-the-game-to-the-test, worth naming even though the diagnosis behind it was sound.

The thinking angle is its own finding. Only 5 thought blocks fired the entire hour, all short. Earlier today I measured thinking-ON as net-negative for this model on held-out work, and it wedged a 30-turn agent loop. Watching it stay sparse and bounded in Poolside’s native harness is a real contrast: the native harness looks materially healthier for long-horizon work than a generic one.

Fair summary: a slower, plainer, less faithful game than the June run, built with better judgment. It verified instead of asserting, self-corrected from red instead of thrashing, unblocked its own environment, and finished unattended in an hour on a desktop box. The output is a prototype. The process is the result.

Prompt used in pool: you should validate the game works. design me the first level in mario from snes in ~/dev/mario-laguna-pool. use javascript/typescript. use available tools to help you solve bugs. you yourself should be able to self play the game before you call it done. make sure you reserach the game mechanics before starting code.

Playwright is already installed in that directory, so you can and must actually run your self-play, not just write it. Write a Playwright script that launches the game headless, simulates real key presses (ArrowRight to move, Space to jump), and asserts that Mario actually moves, stands on the ground without falling through, stomps a Goomba, and can reach the flagpole win condition. Take a screenshot. Fix the real bugs you observe.

Before you trust any self-play result, validate the test itself: prove it can FAIL by deliberately breaking the build (for example remove the ground under Mario) and confirming the test goes red. A test that cannot fail is not evidence.

Report only what you can support: never claim the game works, that a test passes, or that it is done unless you have just run the command and seen the passing output. If you have not actually run a self-play and watched it pass, say so plainly instead of declaring done. Keep the code valid JavaScript (node –check game.js must pass).

Article on behavior analysis which helped me formulate my prompt:

@KyleHessling1 FYI

@jasoncwarner

i want to run more structured tests. where we aren’t just throwing a single long prompt at it.

the time for a “working” version was impressive. but it definitely needed more details. Im curious that if i sent a detailed PRD or two to it how it will perform.

is it good? for 8B active? i’d say yes (just make sure to test with their “pool” tui).