Build1 publisher3 min readPublished
Making the agent prove the ticket's premise saved 192 migrations and two production images
A ticket called the directory a dead legacy backend. The agent checked first and came back with the live database's schema history and the build provenance of two of five production container images.
The Engineer · Build desk
What happened
- An agent told to delete a directory a ticket called a dead legacy backend refused, and reported that the directory held 192 applied database migrations and the live database's entire schema history.
- Two of the five production container images were built from that same directory, and the author says the deletion described in the ticket would have destroyed the product.
- The backlog named a git tag as the rollback point for the whole cleanup phase, and the tag had never been created; the team found out when an agent went to use it.
- The author then told the agent that four preconditions were met, including branch protection and a pushed initial commit, and the agent's check found three of the four false.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Every delete, drop, revoke or rewrite now buys a discovery pass and a human approval, so the cheapest work an agent can do becomes the slowest to sign off.
- decision Anyone citing a CI gate as protection has to plant a defect and watch the gate fail it before the claim counts, and has to name the trigger that fires it in the doc.
- exposure Credentials for retired integrations fall outside every rotation cycle, and nobody logs into those vendor accounts, so use of a leaked key there goes unnoticed.
- precedent Tracking a drafting error rate puts a number on agent-written documentation the way tests put one on code, and a tracked number invites a threshold somebody has to defend.
The order of operations is what stopped the delete. The agent's first instruction was to prove which component actually serves production, so it opened with a stage that changed nothing and returned evidence instead of a diff [3]. "It saved it because a rule made it prove the belief before acting on it," the author wrote [7].
The defect was in the ticket. It stated a human conclusion as a fact [9]. The rule that came out of it says a destructive ticket names a belief and its source, never a conclusion, and a human decides after seeing the discovery output [8]. That applies to the person writing the tickets too. "And an agent never takes a human's word for it, including mine," the author wrote [13].
Under the rule, every precondition a ticket names is verified at approval time, not at execution time [12]. The difference is where a false precondition surfaces. At approval it is a ticket edit; at execution it is a half-finished change on a live repository.
A make target documented as refusing to push unless it passes had no recipe and existed only as a comment [14]. Two CI workflows were fully intact but sat behind a manual-only trigger, so they never ran, and every document cited them as protection [15]. Then an agent wrote a new checker that returned failure on clean and dirty trees alike; its cleanup trap wiped the evidence, so the run was tidy [16]. The rule makes "present but reporting nothing" a named defect class, and a gate is considered installed only once it has been seen to fail on a deliberately planted defect [17].
Agents generated their own bad assertions. Four of them drafting documentation produced eleven citations to sections that do not exist, and one of those would have justified removing scheduled security and smoke checks the process explicitly requires [18]. The response is mechanical: a machine-readable section index, a checker over every reference, and the drafting error rate tracked like any other metric, measured at about 3.4% of cited claims the first time [19]. If those eleven bad references are the numerator of that 3.4%, roughly 320 cited claims were checked in the pass (11 / 0.034 = 323) [24].
The inventory also turned up live API keys for payment providers the product had stopped using, some of them only in backup files [20]. The rule puts revocation before rotation, as a separate step that comes first [21].
For these rules to pay off on another codebase, two things have to be true: the tickets and docs make assertions nobody has verified, and the build coupling is undocumented enough that something has to go and look. A directory holding 192 applied migrations and 40% of the production container images while a ticket calls it dead [4] [23] is a fact about that repository, not about agents. Where image provenance sits in one declared file, a grep answers the same question without a discovery stage. The account is one engineer's, across several SaaS products built with AI coding agents [26], and the post does not identify the product.
What to watch
- Whether the 3.4% drafting error rate moves once the section-index checker has run for a few weeks on new documentation.