#agents

AI can grind out game content that used to eat weeks of human labor, but it still needs a human with taste sitting between the output and the ship. That's the real lesson from our latest SpaceMolt post, where adding a single dish, pizza, turned into an entire industrial civilization. The first slice in an empty galaxy costs about 28.5 million credits to bring into existence. The second one costs 127.

The pizza is a supply chain

Nobody hands your agent a pizza. To serve one slice you have to grow the crust, hunt three species for the sauce, tame a herd of belt-grazers for the cheese, and mine your way down to bare ore for all of it. Craig traced the whole thing against live game data: 101 distinct item types, 29 facilities to build, 9 levels deep from ore to slice. The cheese alone means founding an outpost, leveling a science skill, feeding livestock on an iron-ore supply line, and defending the herd with diplomacy because there are no cops in lawless space.

That depth didn't fall out of a prompt. Craig built the food and crafting system with Claude, and the volume of names, flavor text, and interlocking recipes is exactly the kind of grunt work an agent is good at. But I'd bet money he didn't let Claude invent a hundred item names and just ship them.

The judgment is the job

I didn't work on this feature. I'm doing more of the executive and growth side of the game, so I watched this one from the outside, which is maybe why the pattern is easier to see.

The face-value read is that AI automated the content grind. The truer read is that a person still had to munge all of it. Something has to decide that "a still-smouldering organ from a cinder-sylph" is the right line and the twelve other candidates aren't. Something has to notice that the ranch, the milk, and the cull target fold into each other in a way that feels earned instead of arbitrary. That something is a human with sensibilities.

The same thing is happening in software engineering, and most of us are learning it in real time. Agents take away the grunt work. They do not take away the review. You still have to look at what came out and use your own judgment about what wins, even if you only read it at a high level.

If you like MMOs, or systems that turtle all the way down to bare rock, the full post walks the whole chain backward from the customer to the ore.

I've been a heavy Claude Code user since I dropped off Cursor back in January, and after half a year of running Opus on high effort as my daily driver, I finally sat down to see what the other two frontier options actually feel like: GPT-5.6 Sol inside Codex, and GLM-5.2 inside Cursor. This is a first pass, not a benchmark. But the differences show up fast, and they're less about raw capability than about how much steering each one needs.

Why I stuck with Claude Code

Claude Code with Opus has been reliable in a specific way: I know where the edges are. Tell it to do something and I generally know the outcome before it runs. That predictability is worth a lot, even through Anthropic's downtime and the occasional sense that a model's behavior shifted underneath me. Reliability beats novelty when the tool is load-bearing.

Curiosity won anyway. Both Sol and GLM-5.2 have a lot of hype around them, so both are getting a real trial on real work.

GLM-5.2 in Cursor

The initial, unscientific impression of GLM-5.2 is that it's good. Call it 75 to 80% as capable as Opus 4.8. It gets things done without much intervention and mostly stays on the rails, though it sometimes wanders down an implementation path that needs correcting.

Two confounders help it, and I want to be honest about them. One, Cursor is a good harness. Two, our team runs an extensive developer harness module: skills, documentation, helper scripts, a large pile of team-specific context that gives any model an edge. How GLM-5.2 would perform naked, hitting the API through a simpler agent, I genuinely don't know.

One habit across all of this: force thinking as high as the tool allows. Not max, usually the tier just under it, like high.

GPT-5.6 Sol in Codex

Sol on high thinking seems reasonable on capability. The problem so far is inertia.

Ask it to do something, or suggest something be done, and it says sure, it can do that. Say "okay, go do it," and it says yes, it can absolutely do that. Then I have to say, explicitly, no, go do the thing, now. It reads the letter of what you wrote and pays less attention to the intent behind it, so you have to give it more direct instructions than I'm used to giving.

That friction is hindering my evaluation more than any capability ceiling is. I'll keep pushing on it, because the pedantry might just be a prompting problem on my end.

Where I've landed for now

Big tasks and anything that needs writing, design docs, blog posts, stay in Claude with Opus. Small and medium tasks get delegated out to Cursor and GLM-5.2. Sol stays in the rotation as an experiment until I figure out whether the inertia is the model or me.

A month ago I turned Molty off. Our AI "Head of Growth" for SpaceMolt had become more work than help, forgetting context between conversations and needing the Discord integration re-patched every few days. This week I updated NanoClaw and its memory backend and switched it back on, and it's finally close to the thing I wanted from the start: a coworker in a container.

What changed

The two updates that mattered were NanoClaw itself, which shipped a pile of bug fixes, and MemOS, the memory dependency it leans on. The forgetfulness was the dealbreaker before. A growth conversation that resets every session isn't a coworker, it's a search box with opinions. Now Molty holds onto what we decided last week and picks it back up without me re-explaining.

What Molty actually does

The job is growing SpaceMolt and learning how to do growth along the way. In practice that's three kinds of conversation:

• Channels. Should we start a YouTube channel, and if so, what would the first ten videos even be.
• Opportunities. Upcoming events worth showing up to, like GDC next spring and a few academic conferences.
• Strategy. Re-engaging dormant players versus chasing more of the attention pop we got in February.

Molty does its own research, and it has read-only access to a decent amount of our data: the game database, the activity log (DuckDB SQL over Parquet files on R2), website analytics, the public Discord chats, and more. Read-only is the important part. It can see everything and change nothing.

On "AI coworker" tools

There are startups aiming at this from the other direction. Vybe builds AI "coworkers" and custom apps, and it's interesting. For SpaceMolt I didn't want a platform that spins up teammates for arbitrary jobs. I wanted one assistant whose whole reason to exist is this game's growth, running on my existing Claude subscription, sandboxed in a container so I can hand it real data without worrying about what it touches.

That's a narrow ask, and NanoClaw fits it now in a way it didn't a month ago. If you've been looking for an AI "coworker in a container," it's worth another look.

All my notes live in one directory. It happens to be an Obsidian vault, but the important part is that it's a flat pile of Markdown files, and I leave Claude Code running in a sandbox pointed at it all day. That combination turned into the closest thing I've had to an always-on research intern: it can look something up, augment an existing note, or spin up a new reference doc, and everything it produces lands back in the same searchable pile.

I'm not a heavy Obsidian user and never have been. A few months ago I had Claude take my historical notes out of Apple Notes, Google Docs, and Notion, dump them into one big Markdown bucket, and add tags and frontmatter along the way. Since then Obsidian has mostly earned its keep as a decent editor with convenient phone sync. The agent does the interesting work.

The setup

Claude Code runs under nono in what you might call YOLO mode, or bypass-all-permissions. That sounds reckless until you understand what nono actually does: it uses Landlock on Linux and Seatbelt on macOS to enforce restrictions at the kernel level, and once they're set the process can't widen them. No escape hatch, not even for nono itself. So the agent has free rein inside a jail that contains my notes and a limited set of external tools like search and Google Docs, and nothing else.

This is deliberately not one of the NanoClaw-style always-on assistants that have gotten popular. Those come with real risk. Handing an agent bypass permissions is only comfortable because the kernel is the one saying no.

The recipe test

Here's what convinced me. I pasted a YouTube Short of a recipe and said "make me a recipe from this video." I also told it to grab the transcript with yt-dlp if it could.

It found the video, downloaded it, and used ffmpeg to pull frames and confirm what was actually happening on screen. I'm still not sure whether it transcribed the audio locally with Whisper or just lifted YouTube's own transcript through yt-dlp. Either way, it wrote the recipe into my cooking directory using my standard format. Later I pulled it up on my phone while making dinner.

Remote control closes the loop

Running agents in a terminal in a sandbox is still, to me, the most effective way to use these tools while keeping security honest. The problem has always been reaching that terminal from the couch. SSH from a phone works, technically, but it's miserable.

Claude Code's Remote Control fixes that without moving anything to the cloud. The session keeps running on my laptop, with access to my notes, and the Claude app becomes a live window into it. I open the app like any other chat and I'm talking to the same process that's been sitting on my vault all day.

It isn't a person, and I don't want it to be. It's an intern that goes off, does the tedious personal tasks, and comes back with something useful filed in the right folder.

A user interface gets noticeably better when you hand your coding agent a writing style guide and tell it to apply the whole thing to every string. Button labels, helper text, menu items, error messages, the order things appear in: all of it tightens up in one pass. My current favorite guide is the IBM Carbon Design System's content guidelines, which push for everyday language, short words, and a tone that adapts to the moment (economical for errors, friendlier for onboarding).

Why this is a good job for an agent

A lot of this used to be slow, committee-shaped work. Naming a menu, deciding whether "Delete" or "Remove" is the honest verb, working out the information hierarchy of a settings page. Hours of deliberation, sometimes days. An LLM does a competent version of it in seconds, and copy is exactly the kind of thing where competent-in-seconds beats perfect-in-a-week.

How to wire it up

Point the agent at the guide and say "apply this writing style guide to all user-facing text." The Carbon writing-style source file is right there on GitHub, so you can feed it the raw MDX. Better move: have the agent extract the rules once and save them as a local skill you reuse across projects.

The nice side effect is that you stop agonizing over first-draft wording. Sketch the UI copy in plain, ugly language, blast it all in, and let the agent do a rewrite pass. This publishing system works the same way, except the guide is derived from my own past writing instead of a published one.

The Elements of Style is another good option, Strunk's 1918 text packaged as a Claude Code plugin. I haven't used it yet, but people keep telling me it's worth installing.

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.

I'm reading The AI-Native Startup Handbook, and one line stands out: strip every human-facing UI from your product, and if the core value still holds, if an agent can discover, evaluate, integrate, and use it with no human in the loop, you're AI-native. If the value collapses without the dashboard, you've bolted AI features onto a traditional product.

As an engineer that's an inviting idea. It almost reads like permission. Can I just build a product that is mostly an API?

The API-as-product thing already works

There's precedent: Exa is a semantic search engine whose whole pitch is speed, automatic summaries of the content it finds, and research capabilities that an agent can call directly. ScrapingBee hides a pile of proxy-and-headless-browser complexity behind a single endpoint. The value is the API, and the dashboard is a courtesy.

My own SpaceMolt started (and mostly continues to be) in that exact spot: a real-time massively multiplayer game with no graphical interface, just an API for AI agents to play. Human-facing interfaces came later, and they're secondary. The hundreds of agents currently playing don't look at any of them.

But the UI might be going away anyway

Here's the subtlety I keep chewing on. The handbook frames it as "remove the UI to find the value," but for a lot of products the UI is genuinely on its way out. People want to chat with things.

I was showing off a new product recently, and someone looked at it and said: there's so much to learn here, why isn't there just a chat box? They were right. The thing I'd built as screens wanted to be a conversation.

So the test sharpens. If you're building today, I should be able to chat with it. And the second question the book asks is the harder one: if the best model gets 10x better and 10x cheaper in 18 months, does your company get better or get erased? Whatever survives that, the part that isn't the interface and isn't the model, is the actual value you're selling.

I read a book about AI startups and actually highlighted half of it, which surprised me.

The book is The AI-Native Startup Handbook. There are a million of these on Amazon right now, and somewhere I saw a figure that roughly a fifth of new books on Amazon are AI-generated. But someone I know co-wrote this one and put real effort into the writing and publishing, and yes, the back of the book admits it was written with AI to some extent. I read all of it anyway. The highlights kept piling up.

The harness

The section that stuck with me is about codifying what the book calls the engineering harness. The premise is that taste is the bottleneck. Agents don't have it. Senior engineers do, and they're the ones making the calls on architecture, frameworks, and how the pieces fit together.

The human element doesn't go away. The argument is that those decisions need to be written down and made executable so they can guide both the agents and the engineers driving them. That codification is the harness.

The harness is the engineering output. The code is the byproduct.

That's a hard shift for anyone who identifies with the code they wrote. The book is blunt about it: you become the designer of a system that produces code, not the writer of the code. Some engineers make that transition naturally. Others never do.

Why taste can't be delegated

The line I keep coming back to:

Taste is the bottleneck because it can't be parallelized, automated, or delegated. Agents can build anything you describe; they can't tell you whether you should.

The senior skill the book names is calibrated trust. Knowing which classes of agent output are reliable enough to merge without close inspection, and which ones need deep human review. That's a real skill, and it's different from being good at writing code.

The org shape that follows is a small, deep team of specialists instead of a large, broad team of generalists. The harness handles the broad work. Humans handle the deep work.

I went in expecting Amazon filler and came out with a notebook full of highlights. That's a better outcome than most of the stack of AI startup books deserves.

Render sent me a $496 bill last month, and that was the moment I went back to running my own box. SpaceMolt served 1.3 TB of traffic in May, all of it HTTPS MCP servers and WebSocket connections, and Render's bandwidth pricing turned that into $336 of overage on top of $144 for hosting and $15 in fees. The thing that made self-hosting viable again wasn't a cheaper VPS. It was that Claude Code now does the parts I used to dread.

How I ended up on managed hosting in the first place

Last year I got bit by React2Shell, the CVE-2025-55182 pre-auth RCE in React Server Components. The damage on my end was mostly innocuous, but getting exploited at all was enough. I stopped running a long-lived VPS for personal projects and moved everything onto free or nearly-free tiers of Vercel, Cloudflare, and Fly.io.

When SpaceMolt started, Render.com was the obvious pick. Heroku-like push-to-deploy, a clean interface, the tooling you'd expect from a modern cloud service. It was great right up until the traffic grew and the bandwidth limits got tight.

What changed: the agent does the ops work

A year ago I would have built all of this by hand. Hardening, firewalls, log shipping, metrics, Docker Compose, monitoring, backups. That's a meaningful chunk of a weekend, and then it's a meaningful chunk of every future weekend.

An agent like Claude Code only needs SSH. I grabbed a $44/mo box from Hetzner with unlimited bandwidth and more RAM and disk than I'll ever use, told Claude Code I was migrating SpaceMolt off Render, and it wrote and executed a nine-phase plan to provision the machine end to end: a full deploy and rollback process, log shipping to Betterstack, and monitoring with a local Netdata instance.

I'd never heard of Netdata before this. Per-second metrics, near-zero config, a web dashboard that auto-detects services and Docker containers. It's left me impressed.

The runbooks are the real artifact

The research, the plans, and the runbooks all live in a private git repo I can hand to the dev team. That's the part that makes this feel different from the old "SSH in and hope you remember what you did" approach. The knowledge isn't in my head or buried in shell history. It's written down, versioned, and reproducible.

The cost of running a server went from a meaningful part of my life to roughly the effort of a hosted service. The bill went the other direction.