I’m happy for AI to work while I’m not watching. I’m not happy for it to change a main branch on its own say-so. The rule that reconciles the two is short: nothing reaches a main branch without passing its tests, passing its checks and having its diff reviewed.
\nWhen I counted 101 attempts in my job runner’s record in October 2026, the workers said they were done 72 times. Thirty of those then failed a check. That is the number I think about whenever someone says a model has finished.
\nOn 3 and 4 November 2026 a cheaper model’s change passed its tests, and the review still caught a real security hole that the tests had missed. That attempt was fixed by hand, and it went no further.
\nWhoever writes a change doesn’t get to judge it. Something that took no part in writing it reads the diff, and I read it again before it merges.
\nIt doesn’t prove the code is right. It makes a wrong change hard to get through, and it makes sure I find out before it lands, not after.
\nThat is the bar I set for unattended work, and it’s why I’m comfortable leaving it running overnight. It’s also the reason cheap models are safe to use at all, which I wrote about in software that gets built and tested while I sleep.
" }, "markdown_text": "---\ntitle: 'The rule that lets me trust work I’m not watching'\ncanonical: 'https://www.dealmobile.co.uk/writing/the-rule-that-lets-me-trust-unattended-work'\nurl: 'https://www.dealmobile.co.uk/writing/the-rule-that-lets-me-trust-unattended-work'\ntype: Post\npublished: '2026-11-04'\nsummary: 'Unattended AI work is fine when nothing reaches a main branch without passing tests, passing checks and a reviewed diff. Why I hold to that rule, with two numbers and one catch that explain it.'\n---\n\n# The rule that lets me trust work I’m not watching\n\nPublished 2026-11-04\n\n\n\nI’m happy for AI to work while I’m not watching. I’m not happy for it to change a main branch on its own say-so. The rule that reconciles the two is short: nothing reaches a main branch without passing its tests, passing its checks and having its diff reviewed.\n\n## A worker’s word counts for nothing\n\nWhen I counted 101 attempts in my job runner’s record in October 2026, the workers said they were done 72 times. Thirty of those then failed a check. That is the number I think about whenever someone says a model has finished.\n\n## Tests alone aren’t enough\n\nOn 3 and 4 November 2026 a cheaper model’s change passed its tests, and the review still caught a real security hole that the tests had missed. That attempt was fixed by hand, and it went no further.\n\nWhoever writes a change doesn’t get to judge it. Something that took no part in writing it reads the diff, and I read it again before it merges.\n\n## What the rule doesn’t do\n\nIt doesn’t prove the code is right. It makes a wrong change hard to get through, and it makes sure I find out before it lands, not after.\n\nThat is the bar I set for unattended work, and it’s why I’m comfortable leaving it running overnight. It’s also the reason cheap models are safe to use at all, which I wrote about in [software that gets built and tested while I sleep](https://www.dealmobile.co.uk/writing/software-that-builds-while-i-sleep.md).\n\n- **Projects:** [Mullet](https://www.dealmobile.co.uk/projects/mullet.md)\n- **Tags:** [AI](https://www.dealmobile.co.uk/writing/tag/ai.md), [Testing](https://www.dealmobile.co.uk/writing/tag/testing.md), [Security](https://www.dealmobile.co.uk/writing/tag/security.md), [Mullet](https://www.dealmobile.co.uk/writing/tag/mullet.md)\n\n---\n\nIndex of this site: [llms.txt](https://www.dealmobile.co.uk/llms.txt)\n" }