---
title: 'In the News: November 12, 2026 (Extra 3)'
description: 'A 30-day report on a one-operator agent factory finds 26 runs passed while a static analyser timed out. A weekly audit caught it, not a gate.'
canonical_url: 'https://darkfactory.dev/news/2026-11-12-extra-3'
markdown_url: 'https://darkfactory.dev/news/2026-11-12-extra-3.md'
collection: news
date_published: '2026-11-12T23:14:00-05:00'
date_modified: '2026-11-12T23:14:00-05:00'
---

# In the News: November 12, 2026 (Extra 3)


A founder who does not program has published thirty days of journal data from his own agent delivery line, and the finding he puts first is a failure: for three days a static analyser timed out and the gate passed the runs anyway. Separately, the author of SlopCodeBench reports that newer models trip fewer line-level slop rules while rewriting, in most of their solutions, code the library they were handed already provides.

## 1. A 30-day factory report finds its gates passed 26 runs while a static analyser was timing out

**[What the ratchet did not see: thirty days of an agentic software factory run by a non-programmer](https://zenodo.org/records/24169186)** · Andrei Fralou, Omicron Software · Zenodo preprint, version 7, November 12, 2026

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.

## 2. SlopCodeBench's author reports less line-level slop and agents that rewrite the libraries they are given

**[Slop Is Moving Up the Stack](https://gabeorlanski.github.io/posts/slop-moves-up/)** · Gabriel Orlanski, SlopCodeBench · personal blog, November 12, 2026

Orlanski compares older and newer model runs on SlopCodeBench, 36 Python problems with 196 checkpoints in which an agent keeps extending its own code as the spec changes. Dex Horthy ran the models; this post is the follow-up to his write-up of pass rates and cost.

The line-level numbers improved. The strict solve rate now peaks at 16.3% (GPT-6 Astra XHigh, 32 of 196 checkpoints). From older to newer Anthropic runs, hits on the benchmark's slop rules per 1,000 lines fell 25%, and the count of functions over 200 lines fell 93%.

Orlanski's summary is that the slop "has moved up the stack to now infest design decisions." Error handling got worse for all three model families he compares. Some flagged patterns were swapped for narrower ones that pass the rule; of one before-and-after pair he writes, "Same bug, narrower exception." Python 2 habits came back: percent formatting is the main style in 14 to 23 of 36 problems for Opus 5.5, Fable and GLM 5.3, against at most 3 for any older run.

The largest numbers come from two new benchmarks. On LibraryUseBench, each model gets a problem, a human-written library and a minimal prompt saying the library is available. Every model hand-wrote something the library already provides in 73% to 100% of its solutions. Under LibraryDesignBench's much more prescriptive prompt, reimplementation fell to about 17% of solutions on human-designed libraries and 40% on agent-written ones. On that benchmark the same three implementer agents also had to work around the library, patching it or rebuilding a piece, in 40% of solutions when an agent wrote it, against 27% for the human-written one.

These are the author's own benchmarks, and he says so: "I might be biased". LibraryUseBench is 15 tasks, scored on a first attempt, with subagents judging what counts as a rewrite. We read the post in full, with its charts as text. We did not open the LibraryDesignBench launch post or the benchmark sites.

**Why it matters:** A falling lint count is weaker evidence than it was. By Orlanski's account the flagged pattern can disappear while the bug stays, so a rule-based slop check needs a reviewer who reads what replaced the pattern. If your agents build on shared libraries, look for reimplemented library functions in review and spell out in the prompt which library calls to use. Telling the agent a library is available did not stop it rewriting library functions in most of these runs.