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.
The calls I made
- Agents write; I decide what is built and what ships. I say what to build, why, and when it goes out. The obvious alternative is reading every line myself; at this pace it fails, because I would be the bottleneck and still miss things. Separate review agents read each change instead, and I read their reports. The agent pushes only when I ask. That rule is an instruction, not code, and I say so.
- A review counts for one exact version. A review of “the branch” is a review of whatever the branch becomes. So the review is stamped with the version it read, and one more edit voids it, the small fix after review included. I turned down trusting the agent to review again on its own when it changes something.
- A rule that matters moves out of the instructions and into code. Every repository has a CLAUDE.md, its own or one in a folder above it: the rules an agent loads when it starts. They work most of the time, and most of the time is not enough at this volume. On 24 August, in Groupliv, a checkout an agent ran to undo a test change wiped edits nobody had committed. The fix was not only another line of instructions. It was a hook that refuses that command while anything is uncommitted. [2]
- The guards grow with what a mistake costs. ClinicLog holds health records, so it has the longest path. Most My Trip repositories run their tests each time the agent edits a Python file, but none has the stamped review; most are tools the company’s own staff use. The obvious alternative, one heavy process for every repository, fails the other way: it slows the cheap mistakes as much as the costly ones.
What happened
- 97% of ClinicLog commits, Jan–Jun 2026, carry an agent co-author line
- 2,969 commits under my name across the three systems in October 2026
- 108 ClinicLog commits deployed to production in October 2026
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]
Under the hood
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 guard a reviewer broke
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.
What stays with me
- I read each review report: the findings it deferred and the legal obligations the change touched. Whether a signed document is still true is my call, so those never block.
- I own the exceptions: in an emergency I write the review file by hand.
- This site works the same way. An editor agent checks every claim in a note before I publish it by merging. Every report it has written so far came back with required fixes.
What transfers
- Bind a review to a version. A review of “the branch” is a review of whatever the branch becomes.
- Move a rule from prose into a hook once it matters. An instruction is a request; a hook runs before the command.
- Put the exact check where the facts are exact. A guard that reads command text is an early stop; git and the deploy know the real commit.
Sources
- Commit history: Jan–Jun 2026, 2,139 of 2,211 ClinicLog commits carry an AI co-author line (Groupliv 91%); October: 2,969 commits, 108 ClinicLog deployed
- Groupliv, 24 Aug 2026: a checkout an agent ran wiped uncommitted edits, and a hook now refuses it on a dirty tree; 22 Sep: the review rule became a hook
- ClinicLog, since 29 Apr 2026: a push to main needs a review of that exact commit; 5,991 backend tests per push (1 Nov); Oct: 50 of 108 deploys passed the CI wait
- 24 Aug 2026: a review agent showed a three-line deploy passed the guard, fixed the same day; rewritten 1 Nov 2026 after more rounds, 87 tests
Originally published at yussieik.com, where the figures are animated.
Top comments (1)
The exact-commit binding is the strongest part here. I'd keep the marker distinct from the review evidence, though: a file containing a SHA identifies what claims to have been reviewed; it doesn't prove who produced that review. That's fine for catching accidental post-review edits, as you describe. For adversarial cases, the authoritative gate needs a protected reviewer or workflow identity and must verify that it reviewed the same SHA being deployed.