Two words to a Game Boy game in 15 minutes

We gave TransistorKit a two-word prompt: “Build tetris.”

Fifteen minutes and forty-five seconds later, it handed back a finished Game Boy game — a real .gb cartridge, compiled from C, running in a real emulator, with falling tetrominoes, a next-piece preview, a live score, line counter, and level display. Nobody wrote a line of code. Nobody picked a toolchain. Nobody told it what Tetris was.

That screenshot is the actual output — captured by the harness itself, mid-play, before a human ever saw the game.

The prompt was the easy part

The Game Boy is not a friendly build target. It’s a 1989 handheld: a 160×144 screen, four shades of grey, 8×8 tiles, 40 hardware sprites with a hard limit of 10 per scanline, and a CPU you have to hand-feed one frame at a time or the game runs too fast to play. There’s no Swift, no garbage collector, no forgiving runtime. You write C against GBDK-2020, you manage tile memory by hand, and you call wait_vbl_done() at exactly the right moment or the whole thing falls apart.

Getting an AI to write that code is one thing. Getting a system to write it, compile it, run it, prove it actually works, and only then show it to you — that’s the part that matters. That’s the part that’s TransistorKit.

Opus 4.8 wrote the game. The harness made it trustworthy.

Under the hood, a single builder agent — running on Claude Opus 4.8, the strongest model we have — planned the architecture and wrote the full implementation in GBDK C: piece rotation tables, collision detection, line clearing, and score logic, all in constrained C, first project.

But a model writing plausible-looking code is not a finished game. What turns a hopeful draft into something we’re willing to put in front of you is the TransistorKit harness wrapped around the model:

It owned the toolchain. GBDK-2020 has no Homebrew formula, so TransistorKit installed it and pointed the Makefile at it. The builder never had to guess where lcc lived.
It compiled for real. An actual make producing an actual game.gb. A build that doesn’t link doesn’t get to call itself done.
It tested the game before we saw it. Every retro target ships with a Lua self-test harness that drives the real emulator — for Game Boy, that’s mGBA. It boots the ROM, advances it frame by frame, reads the console’s actual RAM to confirm the game logic ran, and captures screenshots of the title screen and live gameplay. It prints a single verdict line — TK_SELFTEST PASS — that the build system watches for. No pass, no ship.
It looked at its own work. The screenshot above wasn’t taken by a person. The harness grabbed it, so the loop closes with pixels on a screen, not a model’s self-assessment.

Why “it tested itself” is the whole story

Anyone can wire a language model to a compiler. The hard, unglamorous work is everything around the model: knowing that a Game Boy ROM needs mGBA and not FCEUX, that a green compile isn’t the same as a working game, and that the only honest proof is watching the thing run.

TransistorKit knows all of that so you don’t have to. When “Build tetris” comes back fifteen minutes later, it comes back tested — booted, played, screenshotted, verified. That’s the difference between a code generator and a build system. One gives you a draft and wishes you luck. The other gives you a cartridge that already runs.

Try the two-word test yourself

Point TransistorKit at a Game Boy target and type the smallest prompt you can think of. Then hit ▶ — the emulator pops straight open with the latest cartridge, no ceremony. Watch the harness build it, test it, and screenshot it before it ever asks for your opinion.

Fifteen minutes and forty-five seconds. Two words. One finished game.