05 · Automation · Shipped

Overnight Switchboard

A runner that works through agent-ready tickets while I am away and stops each one at a pull request for my review.

When I leave the desk, the Overnight Switchboard takes tickets from a queue, has an agent write the code for each one, runs the tests, and opens a pull request (PR) for me to review. Project Flow, the nine-stage method I use on every project, does the planning: it turns an idea into a specification and slices it into tickets, marking the ones an agent can take. I built the runner because my Claude Max plan budget runs on a rolling five-hour window that ran out mid-session, while about eight overnight hours of budget went unused. The goal: spend my daytime hours on thinking, specifying and review, and as few as possible on mechanical execution.

The risk I designed against is confident wrongness: a PR that builds, passes every test, and is still wrong. So each ticket carries a capability tier, set when the work is sliced, that answers one question: if this change is a mistake, will the automated build and tests say so? Eight kinds of change, such as user-facing copy and visual layout, are kept out of unattended PRs at any tier. A night stops at two tickets, because my review time the next morning sets the limit.

On Great Hearth, the household app I have in TestFlight (Apple's beta testing service), the runner opened six PRs. Five were merged, and the four that changed the app are part of TestFlight builds 55, 57 and 61; the sixth was an empty test of the plumbing, closed by design. My one success measure is the share of PRs that merge with no rework, and three of the five did. Nearly every open ticket for the app's 1.0 release needs a person, so I switched off the nightly schedule and start each run by hand.

  • Tiers measure how visible a failure would be. A ticket names one of three tiers (mechanical, standard or hard), and only the first two can run unattended. A missing or unknown tier stops the ticket.

  • It ends at a PR, and a person merges. The agent that writes the code has a deny list covering pushing and merging; a separate supervisor pushes and opens the PR after its own checks. Each PR that carried changes has a description that opens by saying it was written unattended and no person has reviewed it yet.

  • Why it now runs on demand. On 2026-08-29, only 14 of 168 Great Hearth tickets (8.3 percent) had ever qualified for an agent. Starting runs on demand also means work begins when I stop for the day.

  • Project Flow, the planning half. In use since 2026-08-20, its nine stages are decision council, grilling interview, product requirements document, ticket slicing, build with test-driven development, code review, quality assurance, triage, and written record. Stages 1 to 5 are adapted from Matt Pocock's AI Hero workshop and his open-source skills repository, and stage 0 from Dave Brown's decision council. The capability tiers are my addition.

The facts.

Role

Design and build, solo.

Year

2026

Stack

Python · shell · Claude Code · GitHub issues and pull requests

Shipped

6 PRs opened, 5 merged · TestFlight builds 55, 57 and 61

Status

Shipped · Runs on demand; little work qualifies for it

Source

Project Flow on GitHub · the runner itself is private

Back to all projects

If you’re making something

Tell me what it is — I’d rather hear the problem than the brief.

Start a note

Previous
Previous

Legends of Alderra

Next
Next

Raspberry Pi Lab