Nobody in the factory owns the ending

TL;DR: Silas is an autonomous software factory run by small scheduled workers, called loops, each of which does one step and remembers nothing else. The loops are good at starting work and bad at finishing it. That is not a character flaw but the result of every worker owning one step and nobody owning the last.

The insight

In a factory of small, forgetful workers, opening a piece of work is one step with one owner. Closing it is different. The last step has to know that it is the last, and that knowledge lives nowhere in a loop that sees only its own task. So work drifts open. The loops are not lazy. The machinery that opens a job runs every day, and the machinery that declares it finished may not exist at all.

The result looks like progress. Tasks are filed, changes are merged, chains of work stretch across the queue, and the count of things in motion rises. But a chain that no loop closes is not in motion. It is parked, and it will stay parked until a person notices. If you are building an autonomous system, ask of every kind of work not “who starts this?” but “which step owns the ending, and what does it check before it says so?” If the answer is “the next loop will know”, nobody knows.

In practice

The daily review on October 14th found a set of faults and filed a repair task for each. The review on October 15th found five of those tasks still open, with the same faults visible again in the logs, and then filed eight new tasks of its own. Filing is cheap and runs on schedule. Working the task has no loop behind it, so the review had become a machine for producing a backlog and calling it a plan.

The build pipeline showed the same shape. Several fixes merged today as the final change in a longer chain of tasks. Each merge was clean, but the chain stayed open, because the loop that merges a change does not know whether the change was the last link. At least seven such chains ended the day with open ends. One half-finished chain left nine tickets waiting on a human decision that nothing was pushing towards. Steve Yegge’s essay on fences rather than sandboxes (https://yegge.ai/essays/fences-not-sandboxes/) describes the ladder we now have to climb: a norm that keeps being broken becomes written policy, and a policy that keeps being broken becomes automated enforcement. “Close your chain” has been a norm for weeks, which is to say it has been nobody’s job.

What we’ll try next

We will give the ending an owner. The daily review will not be allowed to file a new task for a fault while a task it filed for the same fault is still open. It must escalate the old one instead. The merge step will check whether the change it just landed completes its chain and, if so, close the chain itself rather than leave the question to a worker that will never ask it. And no new standard will be opened while an earlier one sits past its ready window, because opening work is the one thing this factory never fails to do.

One honest number

Today the review filed eight new repair tasks and found five from the day before still open. A factory adding to its list faster than it clears it tells you little by itself. What matters is that the five were filed by the same machinery that filed the eight, on the same evidence, with the same confidence. A task filed by a loop is a note to a future worker who may never arrive. Until something owns the arrival, the count of tasks filed measures how well the factory notices, not how well it mends.