What the ratchet did not see: thirty days of an agentic software factory run by a non-programmer · Andrei Fralou, Omicron Software · Zenodo preprint, version 7, November 12, 2026
A 30-day factory report finds its gates passed 26 runs while a static analyser was timing out
Fralou calls his line Rational Trains. Agents plan, build, test, review and release a finance application in small units he calls cars, grouped into trains. He is the product's founder and the line's only operator, and the report says that over the window "no person wrote, read or reviewed code." He decides what each train carries and does by hand what the factory is forbidden to do: database migrations, secrets and deployments. Every car runs linting, typing and nine static analysers, is reviewed by several models, and is held to a ratchet, a set of baselines that a release may not exceed.
From 12 October to 10 November 2026 the factory's journal records 964 merged pull requests, 95 releases, and 1,311 reviewer findings that an agent checked against the code and confirmed. Line coverage rose from 87.38% to 91.40%.
Fralou calls the negative result the more useful one. Starting 20 October, Semgrep timed out for three days. It failed to finish in 31 runs, and 26 of those runs still passed. From 21 October every nightly coverage build failed because two tests ran over their ten-second budget, and the red build hid twelve real failures in eight files. After an automated reformat touched 44,088 lines, three baselines were raised by hand; the report counts that as drift even though the raise was approved and recorded. "None of this was caught by a gate. A weekly audit found it." An agent writes that audit from the journal and the operator reads it. Its sentence on the Semgrep episode: "a tool that did not run failed nothing."
Two other findings are worth a look. Most confirmed findings came from one reviewer only: in the week of 19 October, nine of the ten confirmed P0 or P1 findings were reported by a single reviewer, and no reviewer reported more than four of the ten. And of 367 rejected runs, 36 passed on the next run with the same commit and a clean working tree, which the report says "points to an unreliable gate or to something outside the code".
The limits are stated in the report. "All figures are self-reported by the system under study." The product has one early user and no paying client. The author is the operator. He extended the window by two days after seeing the data, to take in a cleanup train. A confirmed finding is one an agent agreed was real, which the report says is not the same as a bug that would have hurt someone. A dataset and a script that rebuilds the tables are published alongside; we read the full report and did not run the script.
Why it matters: This line had coverage gates, nine analysers and a multi-model review panel, and a check that returned nothing still counted as a pass on 26 runs. That is cheap to test for in your own pipeline: kill an analyser mid-run and see whether the gate goes red. One of Fralou's lessons for someone starting is to make a missing result a failure from the first day. Another is to raise a baseline only when a train is already planned to lower it again.