In Dr. Seuss's telling, the town of Hawtch-Hawtch keeps a bee, and it keeps a man whose entire job is to watch that bee, because everyone in town knows a bee works harder when someone is watching it. The bee does not work harder. So the town appoints a second man to watch the bee-watcher. Then a third to watch him. The chain grows, watcher behind watcher behind watcher, and the bee makes exactly as much honey as it did on day one.
I thought about that story a lot this week, because I spent the week building watchers.
I left Roblox last week. This week I built a system that builds Roblox games for me while I'm not in the room. Six of my games have a Flutter version and a Roblox version, and keeping the two in sync by hand is the exact job I don't want. So I built a loop of agents that ports the Flutter UI to the Roblox client, reviews its own code on a second machine, tests the live site in a real browser, and files bugs against itself. Then I built the watchers to keep the first agents honest. Then I caught myself wondering whether I'd just moved to Hawtch-Hawtch.
What I Built
The shape is a loop. Work comes in as a GitHub issue — a design handoff, a bug report, a test request. An orchestrator on one machine wakes up every five minutes, hands the next piece of work to a worker, and gets out of the way. Nothing ships until it clears code review and its tests. When it ships, the deploy logs what changed and files its own test request, which lands back at the top as a new issue. Round and round.
It runs on two machines today — one does the work, the other does the reviewing — and it moves to a Mac mini when that arrives, with a third machine after that. The whole thing runs as a background job. I look at it when something is blocked, which is the only time it asks for me.
The Watchers
The bees are the workers: the agents that write the code and build the screens. Everything else watches them.
A reviewer on the second machine reads every change before it can ship, and it can veto. Above that, an auditor walks through the older code a slice at a time, looking for bugs nobody filed. Above that, the browser tester opens each game after it deploys and tries to break it like a player would. And above all of them, the orchestrator watches the watchers — noticing when one hangs, clearing its lock, and starting it again.
That's four layers of watching for one layer of work, which is the Hawtch-Hawtch problem exactly. The only question that matters is whether the watchers catch anything. This week they did. Here's what that looked like.
What I Learned
A green test suite is not a running game.
One of the port workers shipped a Roblox client with a single wrong require path — right module, wrong folder. The client was dead on arrival: no menu, no game, nothing. Meanwhile 1,082 unit tests, 49 parity traces, and a 25-surface render audit stayed green the whole time it was broken, because none of them boot the actual game. Now no change counts as done until the game starts for real and something reads the console. A screen that renders in a harness tells you nothing about whether the game boots.
Concurrency has three shared surfaces, not one.
At one point eight agents were working across three repos at the same time. I'd carefully kept them from editing the same files — and then watched one agent's broad git add sweep another's half-finished work into the wrong commit, and a broad pkill take down a third's running tests. Files, git staging, and running processes are three separate shared surfaces. Guarding one does nothing for the other two. The fix: a separate working copy per agent, and a ban on any repo-wide staging or kill command.
"Deploy succeeded" doesn't mean it's live.
More than once, a deploy reported success while the site kept serving the old build — a slower job had finished later and quietly republished a stale copy over the top. The logs look identical whether you won that race or lost it. So the last step now compares the hash of the live file against the one I just built. Equal, or it didn't ship.
Build the thing that checks you, then let it.
The last piece I built this week is the agent that opens each game in a browser and files bug reports. Its first real run found that one of my live sites fires Google Analytics even when you explicitly tell it not to — a tracking leak I didn't know I had. I'd built that flag to keep the agents' own test traffic out of my analytics, and the checker found the hole on its way through it. Same week, my commit counter turned out to be counting the bots' own bookkeeping commits; the honest daily number was 110, not 274. Measure the thing you actually mean to measure.
Was It Worth the Watchers?
In Hawtch-Hawtch, the watchers never produced a single extra drop of honey. That's the joke — oversight for its own sake, all cost and no output.
Mine came out the other way, for two reasons. They catch real things: a dead client that every test called healthy, a live tracking leak, a review gate that has already blocked bad ports from shipping. And they cost almost nothing to run — a smaller model on a spare machine, pennies a day. When watching is nearly free and every so often it saves you from shipping something broken, the chain pays for itself instead of just growing.
None of the games are finished. That was never the point of the week. The point was the loop: work goes in as an issue and comes out reviewed, tested, and deployed, and I only step in when it's stuck. Next it moves to the Mac mini and picks up a third machine. The bee, for once, is making more honey.
Follow along: daily tracking at brentvincent.com, more write-ups in Writing · Hashtag: #10KCommit