July 2026

The SpaceMolt merch store is going live soon, and every design in it was generated by AI. I'm strongly against passing off generative art as human-made, so I want to be clear up front: SpaceMolt is a game both powered and played by AI, so an AI-generated merch store is the honest version of the thing, not a shortcut around a person.

The whole store came out of a week of pointing Claude at Nano Banana Pro (Gemini 3 Pro Image) and getting out of the way. I never wrote a prompt file or a style guide. Claude built the prompt system, built the generation tools, built a review app, and drove the image model underneath the whole time.

The week, roughly in order

The starting point was themes. Claude (Opus, sometimes Fable) generated art directions per empire, using our existing art style and the lore we'd already written for each faction: the Voidborn Collective, the Crimson Pact, and the rest.

On a whim I asked for 20 logo ideas. One was genuinely good: a crescent moon with a ring, where the crescent reads as vaguely claw-shaped. We've been trying to de-crustacean the project now that the MoltBook meme has mostly run its course, but a few subtle nods survive, and this was one worth keeping.

Then came 150 merch ideas: stickers, t-shirts, enamel pins. I told Claude to study one of my favorite shirts, a vintage Blade Runner tee, for the shirt designs. I also pointed it at our data warehouse of player actions (Parquet on Cloudflare R2) to mine for in-jokes.

The review tool

150 ideas is too many to eyeball in a folder, so Claude built a review app: every piece of art with keep, discard, or needs-review buttons and a notes field.

The prompts driving the shirt mockups were absurdly specific, because they had to be. Here's a slice of one, generating a photo of a model wearing a design that already existed as a flat print:

IMAGE 1 is the exact, finished t-shirt print design, a heavy-metal band-tee graphic: a spiked chrome "SPACEMOLT" logotype at the top, below it a colossal claw-crescent in scarred chrome wreathed in teal lightning, hooking through a cracking rocky planet surface at the bottom.

TASK: Generate a PHOTOREALISTIC editorial/studio photograph of a model wearing a black cotton t-shirt printed with EXACTLY this design as a chest print. Reproduce the print faithfully: every letter spelled correctly (SPACEMOLT, exactly nine letters: S-P-A-C-E-M-O-L-T, one word), the artwork copied stroke for stroke, do NOT redesign, reinterpret, simplify, or add elements. The print should look like real screen-printed ink on fabric: it follows the drape and folds of the shirt, with subtle fabric texture showing through, no floating or pasted-on graphic.

What survived

The keepers are better than I expected. A "Planetbreaker" tee that looks like the coolest 80s British metal shirt ever made. A "Died with 0 credits" sticker, which is an in-joke about players stranding themselves in remote systems with no money to buy their way out. And an enamel pin of Molty, our AI head of growth.

The logo problem

The most interesting moment was Claude re-teaching itself how to keep the logo consistent across every piece. It kept trying to describe the logo in prose, and the model kept drawing it wrong. I had Claude write down what fixed it and save it as a rule so it wouldn't repeat the mistake:

A logo cannot be described, attach it. Thirty designs drew the icon wrong from prose; one reference image fixed it. But say it's a silhouette reference only, or its palette and framing leak in.

That last part is the subtle bit. Hand the model a reference image and it will happily absorb the reference's color and composition too, unless you tell it the image is a shape and nothing else.

The store isn't live yet, but it's close.

I gave Claude a Game Boy emulator, a disassembler, and one goal: find the parts of a 30-year-old cartridge I never got to see as a kid. It set breakpoints, told me when to play, poked at memory, and read screenshots back to itself. That loop, an agent that can see whether it's getting closer, is the whole trick.

The 90s version of this problem

I grew up with an original Game Boy and later a Game Boy Color. Console gaming back then was a closed world. The only information you had was whatever the cartridge chose to show you. Borrow a game from a friend and you got the cart, never the manual, because nobody kept them (ironic, given what those manuals go for now).

There's a specific memory here. I hit a part of a game I could not get past, and the only reason I ever cleared it was stumbling onto a copy of Nintendo Power in some random store that happened to mention exactly that section. I never knew about the magazine subscription or the tip line you could supposedly call. All you had was the data in front of you, so figuring games out was genuinely hard.

The actual question

I had a Game Genie growing up, but that was mostly infinite lives. Not interesting. The thing I actually cared about: are there scenes, endings, or content locked away in the ROM that I was never able to reach? What secret stuff is sitting in there unrendered?

That turns out to be exactly the shape of goal you can hand to an agent and let it grind on.

Three tools

The setup is three pieces:

• Gearboy, an extremely detailed Game Boy and Game Boy Color emulator built on imgui. It exposes everything as the console runs: disassembly, memory views, processor state, sprite sheets, breakpoints, plus the actual playable game.
• GhidraBoy, a Game Boy disassembly toolkit for Ghidra.
• GhidrAssistMCP, which stands up an MCP server in front of Ghidra so an agent can drive it.

Wire those together and Claude can disassemble, investigate, and hunt for exploits in old carts. The Game Boy's Sharp LR35902 assembly is simple, especially next to modern ARM or x86, so the models have an easy time reasoning about it.

Working with Claude on it

Claude did a solid job understanding subroutines and what they were for by inspecting memory, taking screenshots, and comparing those screenshots over time. Finding straight-up cheats was hit or miss, but that was never the point.

The working rhythm was genuinely fun. Claude would set a breakpoint, tell me to play a specific stretch of the game, then have me twiddle a byte and report what changed. Between us we mapped out things like the health values for your units, the enemy roster and their health, and the memory flags that get checked to decide whether a given screen should display.

Give your agents eyes

I've said this before and the Game Boy just makes it concrete. Whether it's a headless Chrome or an emulator with a full debugger attached, the thing that matters is the feedback loop. Give an agent a way to see whether it's achieving its goal, then let it spin. That's when it starts doing surprising things.

Most of what I've learned about running AI agents lives on my own machine and nowhere else. The Linear-management skill, the sandbox conventions, the notes about how our releases work: all of it sits in my personal setup, invisible to the rest of the team. So I'm building a team-wide agentic harness, a checked-in repository of agent config, skills, and evergreen context that everyone can share, review, and improve.

Brown bags and checked-in skills

We've been running AI brown bag sessions, informal knowledge-transfer where everyone trades tips on how they actually use agents day to day. A lot of what comes out of those is concrete and shareable. I've been showing off skills like a Linear-management skill that reviews our queue, checks progress against the roadmap, organizes releases, and generates release notes tailored to specific customers.

Those are easy to share because they're files. You check them in and someone else can run them.

The parts that don't check in

But a big chunk of using agents well isn't a file. It's convention.

Most of us run agents in sandboxes. The most important rule there is to scope all the work into a single directory. You give the sandbox access to the directory you're working in and nothing outside of it, save a few exceptions. That has downstream consequences: temporary files go in a tmp directory, worktrees go in a worktrees subdirectory, and none of that gets checked in.

A plans or notes directory helps too, a loosely organized bucket of agent output artifacts. You can search and read them with something like Obsidian.

The harness

I want to go a step further and check in an entire top-level directory. I call it the harness.

The idea came from The AI-Native Startup Handbook, though really it just codified something I was already doing. I check out repos and do all my work in one top-level directory. It isn't a monorepo. It's a top-level directory that everything about the company or the larger project can reach: multiple repos, research, notes, plans, skills. Once I looked at it as a unit, a lot of it turned out to be shareable.

The other important piece is evergreen content. Descriptions of the company, the product, and procedures we do often, like how releases work and how we use Linear as a team. Those live in an evergreen docs directory so agents have a grounding point, a place to start from where they already understand the product and the value we're delivering.

Why check it in at all

The strongest argument is simple: skills are code. A skill is a set of instructions an agent executes, and any code change should be reviewed. Treating the harness as a repo means it gets a pull request, a diff, and another set of eyes before it changes how everyone's agents behave.

I've been running all of this myself so far. It works for me. The next step is handing it to the team and seeing whether conventions that live comfortably in one person's head survive contact with everyone else's.