AI agents write almost all my code; a review counts for one exact commit

A solo developer running three production systems — ClinicLog, Groupliv, and roughly thirty tools for the group-travel company My Trip — has built a review-binding workflow in which AI coding agents write nearly all the code but a single file holding one commit hash gates every push to main. The review file is written only after a clean final review pass on that exact commit, and git's pre-push hook on each pushing machine refuses any commit whose hash doesn't match, with CI running full suites and deploys waiting on a green run for the same commit. The developer reports 2,969 commits across the three systems in October, including 108 ClinicLog commits deployed to production, and notes the mechanism guards against skipped steps and post-review commits rather than a dishonest agent.

I run three production systems on my own: ClinicLog, therapy practice software the Israel Tax Authority registered as diary software in October; Groupliv, a real-estate marketplace with live buyers and developers; and about thirty tools and libraries for My Trip, a group-travel company. AI coding agents write almost all of that code. I decide what gets built and what is allowed to ship. The risk: code nobody typed, reaching health records and real buyers, faster than I can read it. Telling an agent to be careful is a request, and requests get skipped. The question I design for is not whether the agent writes good code; it mostly does. It is what stops the change it gets wrong. Figure: Example: the versions are invented. The stamp is a file the agent writes after a clean review; the check before a push to main compares it with the version being pushed. The tests and the deploy check the version, not the stamp. See the animated figure in the original note. https://yussieik.com/notes/review-bound-to-the-commit/ From January to June 2026 the agent signed its commits with a co-author line. In that window 2,139 of ClinicLog’s 2,211 commits had one, and 91% of Groupliv’s. After mid-July the line drops off most commits my agent settings now leave it out , so later months can’t be counted the same way. The pace didn’t drop: 2,969 commits under my name across the three systems in October, and 108 ClinicLog commits deployed to production. 1 The ClinicLog path, step by step. Above the dashed line, models and I judge; below it, code checks the commit. Me I say what to build, why, and when it ships. Every file edit Hooks block token-shaped strings and run the linters. Fresh context Code, simplicity and security reviews run separately; must-fix findings are fixed and reviewed again. Bound to a hash After a clean last pass the agent writes the reviewed commit. A later commit voids it. Two guards A hook in the agent stops a push command early; git’s own pre-push hook, on each machine that pushes to main, refuses any commit but the reviewed one. Every push to main Both test suites run in full. A change to a file tied to a legal obligation goes into a review issue for me. Deploy It waits for a green run on that exact commit, skips the wait only when CI cannot start at all, and rolls back if the health check fails. After A model checks both regions’ health four times a day. Instructionwhat, why, when Agent buildsin codesecret scan on file edits Review agentsfix, review again Review fileone commit hash ↑ models and I judge↓ code checks the commit Push to mainin codehash must match CI on mainin codefull test suites Deployin codegreen CI, this commit Productiontwo regions The centre of it is one file holding one commit hash. The review skill tells the agent to write it only when its last pass found nothing that must be fixed and the full checks pass on that commit, in a clean copy of the repository. Any commit after that moves the hash and voids the review. On each machine that pushes to main, git’s pre-push hook compares the file with the exact commit being pushed, then runs the privacy lint and the migration check. CI runs the full suites on every push to main, and the deploy waits for that run on the same commit, 5,991 backend tests among them on 1 November. The wait exists since 9 October. Of October’s 108 deployed commits, 50 passed it, 27 shipped before it existed, and 31 shipped during a CI billing block through a switch that works only when CI cannot start at all. 3 The file is not a lock against a dishonest agent. The agent writes it, and git can be told to skip its hook. It is a lock against the failures I plan for: a step skipped, or one more commit after the review. A pull request merged on GitHub reaches main without a push, so no hook sees it. For those the review runs after the merge, over everything since the last reviewed commit, and the agent’s hook refuses to start a deploy until it has. Groupliv got the same kind of lock, a review marker for the exact commit, on 22 September. The comment in its hook says why: the old review “lived in prose only, and prose is skippable”. 2 The hook inside the agent is the early stop: it refuses a push or a deploy command before it runs. On 24 August a review agent, reading a change to that guard, proved it could be walked past. The guard split commands with Python’s standard shell tokenizer, which treats a bare newline as a space. A command spread over three lines, the exact deploy sequence the repository’s instructions were teaching the agent, went straight through. For starting a deploy, that hook was the only review check, and it still is. It was fixed and tested the same day. 4 More rounds followed in October and on 1 November. Reviews kept finding forms that hid a push or a deploy: subshells, wrappers, a line piped into a shell. Each round of special cases left another composed form through. So on 1 November I stopped parsing. The guard now matches the command’s text: a line is a deploy when it names the deploy workflow with a run verb, or pushes to main. Its own docstring lists forms that still get past it. That is what the git hook, there since April, is for: git knows which commit it is pushing, whatever the command looked like. The price of matching text is that a line which only quotes a deploy command needs a valid review too. The exact checks stay where the facts are exact: git knows which commit it is pushing, and the deploy knows which commit it is building. Originally published at yussieik.com https://yussieik.com/notes/review-bound-to-the-commit/ , where the figures are animated.