Six changes a day: how chess.rodeo is built

Since May 6, 2026, 1,159 pull requests have been merged into chess.rodeo: six a day on average, 58 on the busiest day. Of 4,988 commits, 3,695 were written together with Claude. I build the service alone. I've already written about how it grew; this post is about how the work itself is set up. There won't be ready-made files: the rules and prompts are written for this particular code. The approach carries over to any project.

chess.rodeo commits by day since October 2025: the darker the cell, the more commits. Since August almost every day is dark; the busiest was November 5, 2026, with 182 commits. Late October is empty: I was on holiday and not working.

How many agents run at once

I sometimes have up to 15 agent sessions open, but usually I actively work with five. Inside each one the agent can start as many subagents as it needs.

How many sessions I run depends on how much context I'm ready to hold in my head. Tasks differ. An opening course takes several days to prepare, and I'm needed only at the end, to check the finished course. Changes on the analysis screen are quick and many: each needs a look, I respond to fixes other agents are making on neighbouring pages, and I come back if I asked for something to be corrected.

Each agent works in its own copy of the repository, so they don't get in each other's way. It wasn't always like that. Here's how the rule reads in the agents' instructions:

git stash is banned while worktrees run in parallel. refs/stash is one stack for the whole repository, not per worktree: agent A's git stash push followed by agent B's git stash pop hands B's tree to A's work and loses B's. On 2026-09-08 three agents on four branches did exactly this to each other, and two of the four working trees ended up holding another agent's diff. Nothing was lost, but the untangling cost more than the work. An agent that wants a clean tree commits first, or adds another worktree.

Many rules are written like this: next to the ban, the incident that caused it.

How a change reaches production

1. The agent makes the change in its own branch and opens a pull request into the staging branch.
2. I ask for new behaviour to go behind a flag I can switch on or off on the stand myself.
3. Every pull request gets its own stand: a live copy of the site with a test database and nine test users with different roles.
4. Automation walks a demo scenario twice, on the main branch's stand and on the pull request's stand, and posts before-and-after frames and a captioned, voiced walkthrough video to the pull request. Often I decide from those without opening the stand.
5. Changes go into staging without sign-off. At night tests run over everything that has piled up.
6. A release is a separate pull request from staging into main. It says what's included, what will happen on deploy and how to roll back. It's merged only after my OK.
7. The new version starts next to the old one, and traffic switches once it answers. Then the deploy checks that production is actually running the new image. That check was added after five merges passed with green checks while production kept serving a two-day-old frontend.
8. Every 5 minutes a canary runs tests against the live site, including from a home line in Russia: some breakage is visible only from there.

The agent opens a pull request when the work is already done, so the time to merge is mostly the time I take to check it. Half of the pull requests are merged in under 14 minutes, three quarters within an hour. Each square is one pull request; the colour is how long it waited to be merged:

1,100 pull requests since May 2026, excluding releases and back-merges.

One change from start to finish

Here's one change from November. After feedback that "there's too much on the screens", the agent started with the game page:

• removed the "Turn this game into a video" banner: the "Create video" button already sits under the last move;
• moved "+ Block" and "Reset" into a "Layout" menu;
• dropped the time-per-move chart from the default layout: each move's time is already in the move list;
• on phones, put the moves right under the engine.

In the pull request description the agent wrote separately what it left alone and why. For example, the number of engine lines: it drives the analysis of the whole game and how many lines are saved for users. It translated the new "Layout" string into 14 languages right away, and in Korean it also removed two different words for the same thing.

Here's what that button is called now in all 16 languages:

Раскладка · Layout · Disposición · Disposition · Układ · Düzen · Joylashuv · Орналасу · लेआउट · Tata letak · Bố cục · レイアウト · 레이아웃 · 布局

The agent writes the scenario for the album in the same pull request. It's an ordinary test, except that instead of assertions it has captions for the frames. Here's how it starts (the captions are in Russian, like the site's main interface):

/*
  Game page: less at once (interface audit, 2026-11-04).
    • no more "Turn this game into a video" banner top right:
      the "Create video" button already sits under the last move;
    • "+ Block (3)" and "Reset" moved into the "Layout" menu …
*/
demo('страница партии: меньше всего сразу', async ({ page }) => {
  await page.setViewportSize({ width: 1440, height: 900 });
  await openGame(page);
  await say(page,
    'Партия открывается без баннера про видео. Справа сверху остались только булавка, колонки и «Раскладка».',
    'Партия · первый экран');

  await click(page, LAYOUT);
  await say(page,
    'В меню «Раскладка» убранные блоки и сброс. Блоки названы по именам, а не «+ Блок (3)».',
    'Партия · меню «Раскладка»');
  // … five more steps, the last one on a phone screen
});

The pull request was opened on the evening of November 4. Twenty-five minutes later an album of five frame pairs arrived. Here's the first one.

Before:

After:

The scenario also records a walkthrough video. Our speech synthesis service on the NAS voices the say() captions: a Silero model speaks Russian, Kokoro speaks English. The finished video comes to me in Telegram. Below is the same walkthrough: frames from the album, the scenario's captions in English, voiced by the same service.

On the morning of November 5 the change went into staging, and two hours later to production, in one release with three others. The agent writes release descriptions to one pattern: what's included, what will happen on deploy and how to roll back. Here's a release from a couple of days later, shortened:

What's included

• #1255: Umami session recordings are kept for 90 days. Every hour a cleanup script deletes whatever is past that.
• #1256: migration 167 removes an empty old function signature left in 166 for the minutes of the rollout.

What will happen on deploy

• The backend deploy will apply migration 167. The code in production calls only the new signature; nothing calls the old one.
• The site's behaviour doesn't change.

Rollback. Forward only: an image without 167 starts on a schema with 167, and it doesn't need the deleted function.

Rules for the agent

The agent's main instruction file, CLAUDE.md, grew to 177,000 characters, a third of it about the knight, the coach's character. It was cut into 21 rules by area of the code. The agent sees the translation rule only when it touches translation files, the design system rule only when it touches the interface.

Here's part of the list: the rule file and which code files it applies to.

backend.md            backend/**
i18n.md               *.tsx, frontend/messages/**
design-system.md      frontend/src/**/*.tsx, *.css
demo-scenarios.md     frontend/tests/demo/**
stockfish.md          engine files and upgrade scripts
routines.md           scripts/routines/**
ci.md                 .github/**, stands
coach-knight.md       anything with "knight" in its name: 798 lines about the knight
… and 13 more

Almost every rule records the mistake that produced it. A few examples:

• Everything a person reads, the agent writes in Russian. The rule appeared after an English pull request description went verbatim into the team chat in Telegram.
• Interface copy is checked for machine-sounding text: triplets, paired negatives, one rhythm on every line. The list appeared after eight pull requests with bot lines that I sent back marked "check for AI slop".
• Every change a person could look at ships with a demo scenario in the same pull request. The fallback "generic walk" through the site was removed on purpose: without its own scenario the album looked like a check while checking nothing.

Tests and checks

The project has about 2,600 backend tests, 5,160 frontend tests, 164 browser tests and 467 demo scenarios for the before-and-after frames. Another 37 scripts in CI check the code itself, and some of them have tests of their own.

Translations are an example. If a pull request changes an English string, all 14 translations must change in the same pull request. Translations are done by a separate agent: it has a table of the form of address for each language, a glossary and a list of format traps. In October it updated 4,200 strings that had fallen behind Russian and English in a single run.

Scheduled jobs

About twenty jobs run without me, on a schedule, in a container on my home server. The most useful ones:

• Once a week a report on traffic, users, payments, search and errors. At the end the model names the week's bottleneck and two or three things to focus on.
• Every morning a review of the day's errors: what to file as a task, what to raise with me, what to skip.
• A competitor watch. It writes only when something changed for someone.
• A product analyst brings 3⁠–⁠5 proposals a week. It never implements them itself.
• When a new Stockfish version comes out, a job updates the engine, recalibrates the bots and opens a draft pull request. Before that, I heard about a new version from someone who reads the news, almost a month after it came out.
• Every week new master games are pulled into the library.
• The Dispatch agent takes a task from the tracker every 10 minutes, does it in its own copy of the repository and opens a pull request. There are 71 such pull requests so far.

One more job watches the others: if one stops running, I find out.

My day

I work roughly from 8 in the morning to 7 in the evening. I try to do the hard tasks in the morning and leave simpler ones for the evening. I set and review tasks all day. When the agents need nothing from me, I talk to Claude in the browser about general things, look at competitors, or play chess and test the service at the same time.

Commits by weekday and hour, Moscow time, since May 2026. Most land on weekday afternoons, noticeably fewer at weekends, almost none at night: the agents work while I do.

What broke

Most often the network in Russia. There were network problems in the data centre. Once the server was rebooted, the network came up in the wrong order, and the services couldn't start on their own after the reboot. That was fixed right away.

The serious cases:

• On July 3 the Dispatch agent judged its own change trivial, the checks were green, and the change merged itself. Every chessboard in production went blank for 1 hour 45 minutes. A user noticed, not the monitoring. After that came a test that counts the 64 squares on the board and the canary, and changes to the board code no longer merge without me.
• In early 2026, when agents were weaker, one decided the cache of position evaluations wasn't needed: it would rebuild itself after enough analyses. It deleted more than 300 million records. We had originally loaded that cache from Lichess's open evaluation database, and we restored it from there. That took a few hours, and the whole time game analysis was slower: positions that used to come from the cache had to be calculated again.

Here's how July 3 went, minute by minute (UTC):

• 09:37: the Dispatch agent merges its own pull request: the change is "trivial", CI is green.
• 09:56: the new image is in production, boards go blank across the site.
• 11:15: an unrelated deploy rebuilds and ships the broken main again.
• ~11:30: a user writes "the board disappeared".
• 11:33: the cause is found, a fixing pull request is opened.
• 11:42: the last good version is started by hand next to the broken one, traffic switches, the boards are back.
• 11:47: the fix is in production.

One line broke everything. The agent added a guard against a zero-width board:

if (!isBoardWidthValid(boardWidth)) return <div style={customBoardStyle} />;

But nobody passes a width to this component: the board measures its own container. The missing value failed the check, and every board was replaced with an empty block. The page still answered 200, there were no console errors, and the tests only checked that there were no errors and the expected text was present.

Otherwise everything runs steadily: tests and scenarios run on every change, and the canary walks them on the live site around the clock. Since August only two changes had to be reverted.

What it costs

I use my $200-a-month Claude Ultra subscription to 100%. The service itself needs two servers, because the connection from Russia is more stable that way. Otherwise one powerful server would do, or a few simpler ones for reliability.

Builds run on my home server (a NAS). It's far more powerful than GitHub's standard runners. The stands and staging run on it all the time, and with Tailscale I can reach them from anywhere. Some checks used to run on GitHub's runners, and one seven-second check on every push became the biggest line on the bill: GitHub rounds every run up to a minute.

What you can take from this

• Let the agent show the result: frames, video, a live stand. Looking at a change is faster than reading its description.
• Put new behaviour behind a flag you switch on yourself.
• Check a deploy by what is actually running on the server, not by the ticks in CI.
• Write down, next to each rule, the mistake that produced it.
• Run as many sessions as fit in your head. For me that's five.