Ask an AI coding agent whether its work is done, and it will tell you yes. That answer is not evidence. It is a summary the model wrote about its own output, and I stopped treating the two as the same thing. What changed how I build was not a better prompt. It was a process wrapped around the model that checks the work, instead of asking the model's opinion of the work.
An agent's word is not evidence
How do you make AI-generated code trustworthy?
Not by trusting the agent's own report that it's done — treat that as a claim, not evidence. Trustworthy AI-generated code comes from independent verification built around the model: audits, test runs, review from a different model, and a production sentinel that catches what shipped anyway, all logged as rows in a ledger rather than accepted on the model's word.
I keep a live ledger of every defect, bug, regression, and new requirement that surfaces across the projects I run — 893 tracked issue rows across 55 projects as of this writing. I did not find most of them. Of the 893 rows, 22 (2.5%) were reported by a human. The other 871 were caught by something that was not me: an automated audit pass, a test run, an independent review, or a sentinel watching a system after it was already live.
Break that 871 down by where it came from and the shape of it says something on its own:
Five things that are not a prompt
Why aren't prompts and rules files enough to control an AI agent?
A prompt or rules file is something a model has to remember and correctly re-apply for the length of an entire session — it competes with everything else in the model's attention and eventually loses. Prompts and rules files describe intent; they don't enforce it.
What does a governed AI development process actually look like?
Five things sit outside the model's context window: a blueprint reviewed before build, hooks that block bad actions, evidence-based release gates, independent review, and a production sentinel.
- A written blueprint, reviewed before build. Another model must find problems before implementation starts.
- Hooks that block, not advise. The action fails with an exit code before a forbidden change happens.
- Release gates that read evidence. The gate checks that the claimed artifact exists in the required form.
- A different model doing the review. Of the 557 closed rows, 544 were verified by an agent other than the fixer; zero were self-verified.
- A sentinel watching production. 225 of the 893 rows were caught after shipping by something watching the system run.
622 of the 893 rows carry a recorded root cause, and 292 became a new requirement. The fix is not just “patch it and move on”; it can change what gets built so the defect class stops recurring.
The honest part
A ledger like this is only worth trusting if it doesn't only report good news about itself. It doesn't. Thirteen of the 557 closed rows carry a verifier but no recorded fixer — a gap in exactly the process that's supposed to be airtight. That gap is itself logged as a defect, tracked as P0-0002, sitting open in the same database as everything else, waiting on its own fix. Six rows have been reopened at least once, meaning a "fixed" defect came back and had to be dealt with again.
Median time from a defect being found to being closed: 26.5 hours. 214 of the 557 closed rows — 38% — closed within 24 hours. That's not "everything gets fixed instantly." Some things sit. The ledger says so, because it's built to say so whether the news is good or not. That honesty isn't a caveat I'm adding at the end. It's the actual argument. A system I only trust when it's telling me things went well is not a system I trust.
Put the rule in machinery, not in a prompt
If you take one thing from this: whatever rule you're currently writing into a prompt, a policy file, a README, a message to your future self — ask whether it needs to survive a model's attention for an entire session, unaided. If it does, it will eventually fail. Not because the model is careless, but because a sentence in a context window is not a mechanism. Move the rule into something that runs whether or not anyone remembers it's there: a hook that blocks, a gate that reads a file instead of an opinion, a second reviewer with no stake in the first draft, a database row that has to carry a root cause before it's allowed to close.
I don't prompt AI to get good outcomes. I built a factory that makes bad outcomes hard to ship, and I keep the receipts.
