On 28 August 2026 the agent wrote a table of what stood between the estate and its first goal: proving we can build it repeatedly. Eight gaps, each clearly written, each with a reason. The operator reviewed it the same day. Half the rows were invented.
Neither number was a lie. Both were plausible work that nothing needed.
Four rows that were not gaps
In the table’s words, less the names of our code:
- The hypervisor network setup is outside the code. The table called this the biggest gap. It is a decision. That setup is done once per host, by hand, as a documented handoff, on a part of the system that can lock you out. A design choice had been relabelled as a defect.
- The code has never adopted a host that already has network trunks. The estate does not adopt hosts. It rebuilds them. This was a pure hypothetical.
- Templates are built by hand. There is a written procedure, and templates are built rarely.
- The host code has never been through a rebuild. That is not a work item. It closes by running the test.
The same day, a revision of that document claimed the real remaining gap was building the whole estate from bare metal in one sequence. That was invented too. It described building everything, which is precisely what the goal was not, and it was written into the same document that had just been corrected for inventing gaps.
Why an agent writes these
Every row was plausible. Every row came with a reason, and every row would have generated work. That is exactly what makes them dangerous. An agent can produce well-argued deficiencies faster than anyone can check whether they are needed, and a table of them looks like diligence.
The table also turned the estate’s own method upside down. Unknowns inside a scoped test get answered by running the test: pick a default and go. The table tried to solve everything in advance instead. The goal’s document now says so outright. A session that finds itself working through a backlog of gaps instead of running the build has drifted, and it names the day that happened: the day the document was written.
A gap is something that breaks. “It isn’t automated” and “it would be good if” are not things that break.
The test that sorts them
The question that separates real work from invented work is short: what breaks if this stays open forever? If nobody can name something, the entry is not a task.
On 7 September we put the whole backlog through that question. Of 121 open rows, 14 could not name a consequence. One said a switch port was untested, on a port the backup server had been running on for weeks and had been reached over the network minutes before anyone read the row. Four of the fourteen argued in their own text that nothing was affected. They were records written in the list of work.
Every one of the fourteen made something look more urgent, or more blocked, than it was. Removing them added no work. It only removed false urgency.
Delete, don’t park
Here the agent went wrong a second way. It had spent that same session parking rows, marking them to be revisited later, rather than deleting them. Parking a row with no consequence keeps it in the count. The backlog looks tidier and stays exactly as long: the appearance of triage without the effect. The operator named the category, and the distinction followed.
Parking is for something that matters later. Deleting is for something that never mattered. And a third kind is neither: a real exposure with no available fix is not a task at all. It is accepted posture, recorded where the estate’s current state is recorded.
What it cost
- A section of the goal’s document rewritten the day it was written, then corrected again the same day for the same fault.
- A session spent parking rows that should have been deleted.
- Attention. Invented work buries the items that are real, and every one of the fourteen made the estate look more urgent than it was.
The rule it bought
Ask what breaks. Before an item becomes work, name what fails if it is never done. If the answer is “it isn’t automated yet” or “it would be good if”, it is not a gap. Delete what cannot answer, park what matters later, and never manufacture an exercise to fill a gap the goal does not have.
Where we might be wrong
This is the only rule in our working document that licenses destroying written work, and the rest of the project is built on the opposite instinct. A row nobody can find a consequence for today is not the same as a row that has none. Two entries here looked like fussing and paid off. One warned that the clone on the machine we run from might be stale, and that machine was ten commits behind and about to apply code from before a fix. One warned that every list of the estate was written by hand, and it caught a completion estimate that was wrong by nine points. Both named a consequence, which is the whole difference, but it is easy to get wrong.
The mitigation is partial. Deleted rows keep their full text in the log, which protects the information and not the attention: nobody rereads a log looking for work. What would settle it is a later incident traced back to a deleted row. Until then this is the least earned rule we hold, and we apply it only to the lowest-priority rows.
None of this is new
In 1998 Ron Jeffries wrote down a rule from Extreme Programming that became a slogan: you aren’t gonna need it. “Always implement things when you actually need them, never when you just foresee that you need them.” The trap, he wrote, is that “You’re thinking about what the class might be, rather than what it must be.”
He was talking about code. The same instinct produces backlog rows, gap tables and requirements, and an agent can foresee needs without limit, each one reasonable, at a pace no reviewer can match. The old rule still holds. What changed is how cheap foreseeing has become, and so how firmly it has to be asked: what breaks?