· updated
How I work with coding agents
Several Claude Code sessions at once against live systems: the rules that keep that from going wrong, and the audit that produced them.
Everything I ship is built with AI coding agents (Claude Code), usually several sessions at once, against systems that are already running. One session may be editing a dashboard, another reading a mail server’s logs, a third changing a product’s search. The person who runs the result owns every change. This note is the working rules, and where they came from.
Where the rules came from
In September 2026 I audited 68 of my own agent sessions. They contained 38 wrong claims in 27 sessions: a service reported healthy from a stale status, a count given without its denominator, a cause stated from one log line. In 29 of the 38 the agent caught the error itself, minutes later, with one cheap command. The problem was not effort but order: the claim had already been committed, sent to another session, or told to me before the check ran. The fix is a rule about order, not about care.
Rule 1: a conclusion leaves the session only after its cheapest disproof has run
“Leaves” means a commit, a handover note, a message to another session, a recommendation, a status report. The agent names the command that would prove it wrong, runs it, then states the result. Until then it is a hypothesis and is called one. Five questions go with it: Am I reading the thing or a stand-in for it (an exit code, an open port, the last log line)? Could this command have shown the problem if it existed? Is the comparison the same object, window and denominator? Is the answer already written down somewhere? Did I check the effect, or only that the action ran?
Rule 2: shared things are claimed before use and released after
When several sessions touch the same machine, database or wiki, a session claims the resource first, with an expiry, and asks the holder when it is taken. An expired claim is not a free one; it means ask. Status is checked with a query, never assumed from memory.
Rule 3: commits are staged by path
No git add -A. Each session stages the files it changed and nothing else, so
two sessions working in one repository cannot ship each other’s half-finished work.
Rule 4: health is a query, not a claim
“The service is up” is answered by a check that runs now and returns the current state, including memory headroom before a heavy job. A stale “it was fine” is not accepted from an agent any more than from a person.
Rule 5: LLM features ship behind a test that has been seen to fail
The eval for a model-backed feature is broken on purpose before it is trusted. The case that made this a rule is written up separately (A test that can fail).
Rule 6: every snag is logged
An awkward tool call, an unclear message, a false alarm goes into a dated log in the repository it concerns. The logs are how the rules above get revised, and they are where the audit’s numbers came from.
Where a rule is a hook
Two of the rules are partly code, not habit. A Claude Code hook runs when a reply ends and looks up everything in it that looks like a commit hash in git; a hash that exists in no repository sends the reply back to be corrected. That is Rule 1 for the claim that is cheapest to check by machine, added after a reply named a commit that never existed. A second hook runs before every shell command. It warns when a command touches a switch another session may own (Rule 2), and it blocks three command patterns that have done damage before: killing the terminal server, a background launch that loses track of its own process, and a process kill that matches its own shell.
Hooks fail open by default: if the checker itself crashes, the reply or the command goes through. Since version 2.1.295,
Claude Code can reverse that per hook with onFailure: "block", and the command guard has it set: a guard with a broken
path stops the command instead of waving it through (tested with a guard pointed at a missing file). On the end-of-reply
check the setting has no effect, so that one still fails open.
Rule 4 has no hook: whether a service is healthy depends on the service, and that stays a query the agent has to run.
Where MCP fits
MCP (the Model Context Protocol) lets an agent call an outside tool server directly. Here it is the exception. In the session logs on my machine for 13 September to 14 October 2026 (615 transcripts, 59,551 tool calls), 1,636 calls went to MCP servers, 2.7 %; shell commands were 44,401, 75 %. Four in five of the MCP calls (1,354) drove a headless browser: load a page, live or a local build, measure it, take a screenshot, the one job a shell command does badly. Git, logs and deploys go through the shell, and nearly all database work does, where the command is in the transcript, can be rerun by hand, and passes the command guard above. An MCP call does not: the guard only sees shell commands.
What this buys
Speed where it is safe: a month-long project becomes a week-long delivery, and the invoice follows it down. Review effort goes where it matters: on behaviour (the build, the tests, the evals, what actually runs) rather than on reading every generated line. And a record: when something goes wrong, the journal shows which session did what, and the fix is a rule, not a reprimand.
What it does not buy
Agents still make the errors the audit found; the rules make them cheaper and earlier. A false alarm still costs a human minute. And the person who runs the result still has to understand it, or the ownership is fiction.