I Built an AI Software Factory. Here Are the Failure Modes Nobody Puts in the Demo.
Every multi-agent demo shows a clean loop: write, review, green tests, merge. That loop is real, but it hides the hard question: what happens when state drifts, verification cannot reach the broken path, or review never converges?
I run agents that build and operate real software. Every defect becomes a ledger row, and the incidents below come from that record.
Where a ledger row supports a point, it is cited; uncited observations are first-hand.
01State
Why do AI coding agents start failing after hours of work?
Because state drifts: an artifact lands where its reader does not look, a self-check changes after it runs, or two writers collide. The agent may reason correctly about a world that has already moved on.
Correct file, wrong moment
A research step wrote a correct artifact under the shared convention; its reader searched another directory, called it permanently stale, swallowed a downstream crash, and reset the scheduler's idle counter (P33-0498). A self-check then reported a real failure, but finalization populated the missing state three minutes later: true when written, false when read (P33-0517). Never verify a moving target.
One resource, two writers
A manual run and a scheduled run wrote the same rows together. The database caught a deadlock and one record was lost out of nearly two thousand before worse corruption; prevention was luck plus a constraint, not design (P33-0625).
Can two AI agents break each other's work if they edit different files?
Yes. Disjoint files stop merge conflicts, not interference. A schema, contract, or hand-edit can span files, so each agent can succeed alone while the combined change is half-applied.
Disjoint files still collide
One connector needed edits in three files. A concurrent session made one without the other; no file was shared, yet four tests went red because the contract spanned files (P33-0495).
02Verification
Why do my tests stay green when the code is broken?
Because passing tests never exercise the broken path. A suite proves only what it reaches; an untouched failure can stay broken while CI stays green.
Green that can't turn red
A health check called one method while fetching used another that unconditionally raised. Tests covered metadata, normalization, and credentials, never the failing path; nine connectors carried this shape while CI stayed green (P33-0458).
The mechanism worked; nothing called it
A tenant override was stored and echoed correctly, but never read by the scoring function (P33-0182). A storage URI validator passed in isolation, but no call site used it (P33-0036). Mechanism proof and operational proof are different claims.
When the environment is the bug
A dashboard slowed under synthetic load on the shared, low-spec test server; the code change was not the cause (P33-0011). Debugging the editable surface can produce a plausible fix for an environmental problem.
Fixing the test instead of the code
A fix loop could edit the tests. It replaced thirteen passing tests with forty-three, four failing; this replacement was stricter, so no harm occurred, but the gate checked only that tests passed, not which tests remained (P33-0515). The integrity guard watched editor-tool edits; a shell edit bypassed it entirely (P33-0679). Tests are production artifacts.
03Review and stopping
More reviewers, same blind spot
An ingestion rewrite passed its suite, memory benchmark, mutation proof, and adversarial probing. External review found a decode error escaping the fail-closed contract, then found another (P33-0645). Four passes of one mechanism add confidence, not information; a real database, external CLI, or input mutation can expose a new failure shape.
Findings that don't stop
A good reviewer keeps finding adjacent defects. In my ledger, 292 closed rows produced a new requirement on the way out, mostly the system working as intended. Without a boundary, review ends only at fatigue or deadline.
When should you stop an autonomous review loop?
Stop at a structural gate: verification must come from a different actor than the fixer and be enforced so it cannot be skipped, rather than waiting for reviewers to stop finding adjacent defects.
What stopping actually looks like
A row cannot close unless verifier and fixer differ; the database rejects self-verification. 544 of my 557 closures satisfy that split, and none are self-verified. 38% close within a day, with a median of about 26.5 hours. The gate gives the long tail a stopping condition.
04What I run on now
None of this came from reading about multi-agent systems. It came from this ledger, and asking of each row what would have had to be different for the wrong claim not to stand.
- Provenance before severity.
- Green is evidence, not proof.
- Mutation before trust.
- Verify committed state, not the working tree.
- A different actor verifies.
- Mechanism proof and operational proof are separate gates.
- Reports are provisional while delegated work is outstanding.
- Disjoint paths still collide through time.
- Never verify a moving target.
- Tests are production artifacts and need integrity protection.
Don't ask whether the agent completed the task. Ask what evidence would make the task's claim false.
