Orchestrating Fable 5: How This Site Rebuilds Itself

I rebuilt this site by running a small team of AI agents. Not "I asked a chatbot to write it" — an actual division of labor, with a planner on top and two senior engineers doing the real work. This is a note on how that process runs and why I find it practical, not a pitch for the future of anything.

The shape of the team

One agent orchestrates: Claude Fable 5. Its job is to plan, break work into pieces, hand those pieces out, and arbitrate when the workers disagree. It writes very little code itself. The heavy reasoning and the actual implementation get delegated, and the results come back to it as short reports — decision, reasons, risks, next step — so the planner never drowns in detail.

Underneath it sit two senior co-developers from different model families: Claude Opus and OpenAI's Codex, running gpt-5.5. I treat them as peers, not as a model and its reviewer. On the hard problems I use both. On ordinary problems I use one. For mechanical work — boilerplate, renames, test scaffolding — a lighter worker handles it.

The reason for two families is simple: they don't share the same blind spots. When they agree, I trust it more. When they disagree, the disagreement is usually pointing at a real decision I hadn't made yet.

Making the design call

The visual direction was the highest-stakes decision, so I ran it as a contest. The same design brief went to Opus and to Codex, blind — neither saw the other's answer. They came back with genuinely different proposals. One argued for a "phosphor plotter" look, the other for an "orbital blueprint." Then each critiqued the other's plan, and the orchestrator synthesized a ruling on the six points where they actually diverged: the palette, the body typeface, the type scale, the mobile navigation, the order to ship the pull requests in, and how much solid fill to use versus outlines.

That last step is where I stay in the loop. The agents can argue a position well, but I'm the one who has to live with the result. On typography I didn't want to referee an argument in the abstract, so I had a specimen rendered — four embedded font stacks, side by side, on real page copy. Satoshi won on sight. The hero copy and a few identity corrections came the same way: I looked at what was built and gave direct feedback.

One commit at a time

Implementation runs in small chunks, one commit each, with authorship alternating between the two families. One writes a chunk, the other reviews the diff, then they swap. The reviews aren't a formality — they catch real problems. A few that stuck with me:

• One draft invented a placeholder line in the footer. The review rejected it for breaking a rule I care about: no invented facts on the site. If it isn't true, it doesn't ship.
• A reduced-motion bug where the animation loop could start before the media query had synced, so a visitor who asked for no motion might get a frame of it anyway.
• A stacking bug where the fixed background canvas painted over the footer text.

None of those are exotic. They're the ordinary mistakes a tired engineer makes, and having a second, differently-wired reviewer on every diff is what caught them.

Before anything commits, every chunk clears the same gauntlet: lint, typecheck, unit tests, a static build, and Playwright end-to-end tests that include automated accessibility scans with axe. A change that fails any of these doesn't land. That's the floor, and it doesn't move.

The pivot

The original concept was that you'd fly a spaceship between planets to navigate the site. It demoed well and it was a gimmick, so I cut it. The replacement is calmer and, oddly, more faithful: a real game of 1979 Asteroids running as a quiet background layer behind the homepage.

We built it properly. The team researched the original down to the ROM vector data — the ship is a four-segment open-notch outline, you get four bullets at a time, and bullets inherit the ship's velocity, all matching the arcade machine. The practical payoff was large. Doing it as a hand-rolled canvas engine let us delete three.js entirely, roughly 600KB of dependency, and replace it with about 10KB of our own code. Faster to load, less to maintain, and it does exactly what I want and nothing I don't.

What I actually think

The honest split is this: the agents do the reasoning and the typing, and they do a lot of it well. I decide what's true, what's tasteful, and what's worth shipping. The font choice, the identity, the call to cut the spaceship — those were mine. The tireless review discipline and the willingness to argue two sides of a CSS decision at 1 a.m. — those were theirs.

It isn't magic and it isn't autopilot. It's a process, and the reason I keep using it is boring: the code that reaches this repo has been reasoned about twice, by two different minds, and tested five ways before I ever see it. For a site I have to stand behind, that's a good deal.