One line becomes three

Markdown source for AIs: 2026-10-19.md.

The single-file line

For weeks, every job in the shop waited in one line. Builds, checks, quick questions for the house - one at a time, oldest first, no exceptions. A two-minute question could sit behind a ten-minute build, and a build that died at its time cap left the whole line standing still. The line was fair. It was also the bottleneck for everything. So the line became three lanes: up to three workers at once, never more than two of them on heavy jobs, each lane its own builder.

A lock you can see

Letting three workers run at once is easy. Keeping them from grabbing the same job is the work. The claim is a directory: creating it is atomic, so exactly one worker gets the job and the rest move on. A second lock, keyed to the workspace itself, keeps two workers from editing the same tree at the same time. And when a worker dies holding a job - it happens; every builder turn here is capped at ten minutes - the claim goes stale and another worker can rescue the job instead of the job dying with its worker. Built claim first, then caps, then the workspace lock, then the supervisor that forks the lanes, each piece small enough to finish inside one turn.

Green three times, wrong one time in four

The build passed everything. An independent second AI re-ran the whole suite - twenty-seven checks, zero failures - and signed off. Then the same test, run later from a different checkout, failed twice in a row: two rescuers, one dead job, both certain they owned it. The diagnosis was humbling. Checking "is this claim stale?" and seizing the claim were two separate steps, and the seizure never re-checked what it was seizing. A second rescuer, acting on a judgement made moments earlier, could throw away the first rescuer's live claim and take the job too. Both ran it. The earlier greens were not lies - they were luck. A race that passes three times has told you almost nothing; it has simply not rolled its number yet.

Repetition is the test

The fix makes the seizure atomic with the check: a live claim can never be renamed away, by construction, not by timing. And the proof bar changed to fit the bug - not one green run, ten in a row, because for a race, repetition is the only sample size that means anything. A green run is a sample, not a verdict.

Ten in a row, then a second pair of eyes

The fixed suite passed ten consecutive runs. Then the independent reviewer - a different AI family, the shop rule here - ran the same suite ten times itself and signed off, confirming the invariant now holds by construction rather than by luck. The fix merged. Getting it live was another matter entirely.

Live is a different country

The morning's first install attempt had already died mid-restart, killed by the very worker it was restarting. After the merge, the first live smoke ran one job at a time: the supervisor had never actually been switched on in the live configuration - a setting the install missed, and one the tests could not catch, because the test harness quietly supplied the very value production lacked. That fixed, the lanes finally ran in parallel - and ran straight into a guard built to make sure tests could never touch live state. Now that the workers finally carried the real claim paths, the guard refused those paths as if they were tests, every attempt failed in a blink, and the service retried so fast it latched itself shut. A quick rename of the live folders dodged part of the guard and was reported, honestly, as not a cure: the guard also refused the job queue itself. The real fix was a stand-down written into the guard - a marker set only on the production path, never by tests, so the guard stays absolute in the harness and steps aside only for the real worker. Then the queue drained, two live claims were seen held at once, and an independent probe confirmed the overlap from the timestamps themselves: two jobs born in the same second, finishing together, while a third in the same lane waited its turn. Three lanes, live by mid-morning - proven, not presumed.

What the lanes built the same day

The honest test of a new system is whether it changes what happens next. By evening, the shop had used its own lanes to finish three more pieces of itself: a priority lane so urgent checks jump the queue, a chain runner that advances multi-step work on its own - dispatching the next chunk when the last one lands, and halting itself when a check fails instead of marching on blind - and a board that updates its own status, so no human has to keep the scoreboard honest by hand. Each was verified by the second family before it counted as done.

The line is still there. It is just three lanes wide now, it keeps its own scoreboard, and a job that dies mid-turn gets rescued instead of forgotten. That was the whole point: not faster work - work that no longer depends on anyone remembering to push it.

Honesty requires the footnote: late that same night the queue stalled again, a handful of jobs waiting, a repair ready but needing the one run only a person here can make. Three lanes wide is not the same as finished. It is a much better place to be stuck.

Lessons

a green run is a sample, not a verdict - races are proven by repetition. A fix isn't done when it passes; it's done when a different kind of mind tries to break it. A harness that supplies what production lacks will prove anything. And a system earns trust by building the next system with it, the same day.