Unattended coding sessions ship 72 slices in 17 days

Since 15 October I have run a software project in which no person writes code. A scheduled task starts a coding agent every six hours. The agent reads a rules file and a handoff file from the repository, picks the next task, builds it, runs the checks, pushes to the main branch, and writes the handoff for the next run. I get a summary once a week and a list of questions, each with a default answer that applies after seven days if I say nothing.

The project rebuilds the functionality of software that aging companies have stopped developing: a desktop-publishing app, a project scheduler and a form designer, as new clean-room code. The question was how well the loop holds up with nobody watching.

The method

The rules file sets one work unit per session: a vertical slice that a user can see or a test can prove. Before a push the session must pass the lint, type and unit checks and the end-to-end tests of the product it touched. It must not weaken or skip a test. It writes a log entry with what it did, what it verified and what it left. A weekly review session checks the health of the repository and plans the next slices. The numbers below come from that log, counted on 31 October.

The result

Measure	Record, 15 to 31 October 2026
Sessions	80: 75 build, 3 review, 1 scout, 1 setup
Code slices pushed	72, from 72 build sessions; the other 3 wrote a product specification
Sessions that ran the full check suite before the push	77 of 80
Pushes that left the main branch broken	4, each repaired by the same session within about two minutes
Two sessions working the same slice at once	1
Unit tests	763 on 20 October, 1,385 on 27 October
End-to-end browser tests	85 across the three products
Questions I answered	1 of 4 filed; 2 closed on their default, 1 is open
Questions asked in chat	0

The busiest day was 16 October, with 14 sessions. The scheduler reached a demo that a person runs in about nine minutes, with 19 of its 22 target features. The publishing app has 17 of 21 and the form designer 19 of 26.

What failed

All four broken pushes came from sessions that had no git access and pushed files one call at a time through an API. Three of them left out some of the changed files, so the main branch did not compile for one to two minutes. The fourth had one line split by a copy step. No broken push came from a session that used git.

Two scheduled runs started together on 20 October and built the same slice. One lost about half its time. The rule now reads the newest commit again just before any code is written.

The free continuous-integration minutes ran out on 23 October, so after that date nothing checked a push except the session that made it. Two screenshot runs timed out, and one budget test failed because two test suites ran at the same time.

What was not measured

The log records the failures a session found before it pushed. It does not record bugs that a user found later, because there is no user yet. It also does not record the cost of a session, so the price of a slice is unknown. Both go into the next version of this record.