A few weeks ago I asked an AI agent to delete a directory from a live production repository.
The ticket described it as a dead legacy backend. The HTTP service it contained had been retired, the product ran on a newer backend written in another language, and removing the old one was the obvious first cleanup before handing the codebase over to a team of agents.
The agent didn't delete it. Its first instruction was to prove which component actually serves production, and it came back with evidence instead of a diff: the "dead" directory held 192 applied database migrations, the entire schema history of the live database, and two of the five production container images were built from it.
Deleting it would have destroyed the product. And the agent didn't save it by being clever. It saved it because a rule made it prove the belief before acting on it.
This post is about that rule and four others, each earned by something that went wrong while moving a live product, with real paying users, to a way of working where agents write all the code.
Why rules at all
I've built several SaaS products with AI coding agents. Building them turned out to be the easy part. The hard question came after: how do you maintain and grow software that no human on the team wrote?
Every methodology I learned, from waterfall to Scrum, was built around one scarce resource: the time of skilled humans writing code. Sprints, story points, standups, velocity: all of it exists to coordinate something expensive and slow. When agents make code cheap, that scarcity disappears, and the difficulty moves to three places:
- Specifying precisely what should exist, edge cases and failure modes included
- Verifying that what was built is correct, when nobody reads every line anymore
- Deciding the architecture, the stack, and what is worth building
So I reorganized the work around those three, and then ran it on a real product. Here is what broke.
1. The dead backend that wasn't
Covered above. The failure wasn't the agent's: the ticket stated a human conclusion ("this is dead") as a fact.
Rule: a destructive ticket (delete, drop, revoke, rewrite) states a belief and its source, never a conclusion. It starts with a discovery stage that changes nothing, and a human decides after seeing the evidence.
2. The rollback point that didn't exist
The backlog named a git tag as the rollback point for the whole cleanup phase. The tag had never been created. We only found out because an agent went to use it.
It happened again later, to me directly. I told the agent four preconditions were met: toolchain installed, remote configured, initial commit pushed, branch protection on. It checked. Three of the four were false.
Rule: every precondition a ticket names is verified to exist at approval time, not at execution time. And an agent never takes a human's word for it, including mine.
3. Gates that were never going to fire
The repository's documentation described a make target that "refuses to push unless it passes". The target had no recipe. It existed only as a comment. Two CI workflows sat fully intact behind a manual-only trigger, so they never ran. Every document cited them as protection.
Then an agent wrote a new checker for us, and on its first run it returned failure on clean and dirty trees alike, while its cleanup trap wiped the evidence. It looked exactly like it was working.
Rule: "present but reporting nothing" is a named defect class. A gate is only considered installed once it has been seen to fail on a deliberately planted defect. Every document that cites a gate must name the trigger that fires it, and a liveness check fails loudly when an expected check hasn't run in its window.
4. Eleven references that didn't exist
Four agents drafting documentation produced eleven citations to sections that don't exist. One of them would have justified removing scheduled security and smoke checks that the process explicitly requires.
Rule: references are checked mechanically. The methodology's section index is machine-readable, a checker validates every reference, and the drafting error rate (about 3.4% of cited claims on the first measurement) is tracked like any other metric.
5. Credentials nobody would ever rotate
The inventory turned up live API keys for payment providers the product had stopped using long ago, some of them only in backup files. No rotation cycle would ever touch them, because the integrations no longer existed, and nobody was watching those vendor accounts.
Rule: revocation is a separate step from rotation, and it comes first. Kill every credential whose integration is gone, then rotate the ones still in use.
The pattern
Looking back at all of them, none of these failures were invented by the agents. Every single one was a human belief written into an artifact as a fact, or a control that existed on paper.
The agents caught them because the process demanded proof rather than agreement. That changed how I think about reviewing AI work: the most valuable review isn't "is this code good", it's "what is this relying on that nobody has checked".
One number worth knowing
When I had one model audit the specification that another model wrote, it raised 130 findings. I then had each finding challenged by two independent refuters. Only 42 survived: a 68% refutation rate. A single-pass AI review would have been wrong two times out of three.
The spread by topic was even more useful. Findings about citations were refuted 27% of the time (mechanical: a reference resolves or it doesn't). Findings about gates were refuted 94% of the time (interpretive: the reviewer kept mistaking deliberate layering for a conflict). A review lens with a refutation rate that high isn't a strict reviewer, it's asking too broad a question.
What came out of it
I wrote all of this down as AICD (Artificial Intelligence Centered Development): a complete methodology for teams where agents write the code. Agents build, test, operate and document; engineers specify, verify, decide and supervise. The specification is the source of truth and code is a generated artifact. Roles are separated so the agent that writes code never judges it. Changes are tiered by risk, escalation has a protocol, every agent has its own scoped permissions, and there's a step-by-step procedure for migrating a product that already exists.
It's free, under CC BY 4.0: https://github.com/rachidsahane/AICD-METHODOLOGY
If you only read one part, read Lessons from the first application. If you have a vibe-coded app in production and wonder how to hand it to agents without breaking it, read Migrating an existing product into AICD.
Your turn
If you're running agents on something real, I'd like to know what broke. That's more useful than what worked. Discussions are open on the repo, or tell me in the comments.
