This morning I read an essay by Addy Osmani called "Own the Outer Loop." One line stayed in my head all day: the model may write the line, but the Verdict is yours.
By that evening, the line had become a real file named ACCOUNTABILITY.md sitting in 5 of my own repos. This is the story of that day, and the principle it left behind.
As AI writes more of the code for us, the thing that goes missing is not capability. It is the person who signs for the work, and that has to be written into a file, not kept in someone's head.
The story runs in order: the question a demo never answers, then the principle that accountability has to be committed with the work, then the day the principle became a real file, and finally how to use it on your own work.
Part 1The question a demo never answers
In a demo, AI-written code looks easy. Type a prompt, code appears, tests pass, done. But real work carries a question the demo never answers: if this code breaks, who can explain what changed, why it was safe, and what to do when it is wrong.
Osmani frames it sharply. He splits the work into an inner loop and an outer loop. The inner loop is what the model can do: investigate, implement, test, report. He calls it capability. The outer loop has only one kind of work: agency, deciding, verifying, approving, and owning the result. What crosses the boundary from inside to outside is evidence, not code.
The problem is that the gap grows fast. Osmani cites Sonar's 2026 report that around 42% of committed code is now AI-written or heavily AI-assisted. Creation keeps getting cheaper, but the scarce things are review, understanding, and long-term care. Generation speed has already outpaced control speed.
Part 2Accountability has to be committed with the work
Many teams think "there is a human review" equals accountability. It is not enough. A review is a behavior, and when people or shifts change, it fades with memory. What makes accountability real is writing it into a file and committing it with the work, so that whoever comes later can open git log and reconstruct the story on their own: what changed, why it was safe, what to do when it is wrong, without tracking down the author.
Osmani gives three pillars. In plain engineering terms:
- Quality is all the checks before you release. It produces evidence.
- Verdict is the final decision before work enters production. It belongs to a human.
- Answerability is the guarantee that someone can explain why the decision was made.
The common mistake is thinking you must give the AI the least freedom possible. The opposite is true. Give it just enough freedom that ordinary engineering can still stop it in time. Type checks, tests, sandboxes, audit logs are the back-pressure that holds it. As long as the AI keeps emitting those signals, ordinary engineering can regulate it. A railing is not a wall. It just keeps you from falling.
Part 3The day the principle became a file
A principle is worthless until you act on it, so I tried it for real in a single day. The contract that went into each repo has four core lines.
- Accountable human named in the PR, the one who carries the consequence if it breaks. An AI can choose, route, and merge inside policy, but cannot inherit consequence.
- Evidence, an Acceptance line that was actually run with a real result,
command → expected output, not the words "it works." - Checklist accepted at intake, the repo's invariants, for example no secrets leaked, additive-only on your own branch.
- Rollback if it is wrong, plus the blast radius.
The important part is that it is not copied identically into every repo. The invariants adapt to the work. A repo that touches real money states plainly that money paths equal a human approval only. A repo that deploys to customer-facing sites states that no personal data may leak into the tree, and it must pass staging first. Same contract, different rules.
Then it goes into the tool you actually use, not a file floating on its own. Every PR now has an Accountability section filled in automatically: accountable human, evidence run, rollback. That makes these things commit with the work, instead of living in one person's head.
Part 4Using it on your own work
If you are having AI help write code in your own work, three things you can use right away.
- Separate the inner loop from the outer loop. Let the AI work inside the loop (investigate, implement, test), but the decision before production is yours, and what crosses the line is evidence, not a vague assurance.
- Make answerability a file. Not just "I will review it later." Write a short contract: who is accountable, what evidence, how to roll back if it fails, then commit it with the work.
- Watch for comprehension debt. The longer you let AI think for you, the wider the gap between the code produced and your understanding of it. Osmani cites an Anthropic trial where people who used AI scored lower on comprehension quizzes than those who did not. The fix is to treat understanding as a decision point, not just a handoff step.
Start with just one. On your next PR, add four lines: who is accountable, evidence actually run, checklist, rollback. That alone shifts it from "the AI wrote it" to "someone has signed for the work."
Machines keep making things faster, so the question moves from "can we build this" to "should this exist, and can we answer for it." Skills give you leverage, but accountability is what turns leverage into trust. An AI can write the line, but before it reaches users, someone has to explain why it should exist, whether it is safe enough, and what they will do when it is wrong. That is the work that is left for people.
Sources and references
- Addy Osmani, "Own the Outer Loop" (addyo.substack.com, 9 Jul 2026), the inner/outer loop frame and the figures cited within it. The Sonar 42% and the Anthropic trial are numbers Osmani cites.
- The author's own work, 10 Jul 2026, placing
ACCOUNTABILITY.mdin 5 repos and adding an Accountability section to the PR template.