Most writing about AI at work is about typing faster. That was never my problem.
My problem was that roughly seventy fiddly procedures lived in exactly one
person's head, and that person was me. Reconstruct a failed booking from four
separate log sources. Run SQL against a production database the standard mysql
client cannot even reach. Rebuild the exact request we sent upstream from
nothing but a trace-id. Check whether a feature actually landed in all eleven
repositories it touches.
Ask me and you get an answer. Take me off the team and the work stops.
So the thing I automated was not code. It was the procedures around the code.
Rule 1 — if I do it twice, it becomes a command
A slash command in Claude Code is a markdown file whose body is the prompt. That single fact is the whole trick: the runbook and the tool stop being two artifacts that drift apart. Writing the procedure down is shipping the automation.
Two team packs, 42 commands between them, about 70 runbooks once you count the third repo:
The lines matter more than the command count. Four thousand lines of prompt is four thousand lines of traps someone already paid for — the kind of thing that never makes it into a wiki because writing it down feels like admitting you lost an afternoon to it.
Rule 2 — the effort I removed was steps, not typing
Here is what those commands actually collapse. Each number is the count of distinct things a person had to pick between, visit, or run — read straight out of the runbook, not measured with a stopwatch:
The go-live one is the clearest. A feature that touches money can span eleven
repositories; miss one and the system undercharges customers and throws no
exception anywhere. Checking that by hand is eleven git log invocations and
perfect concentration. Checking it with a command is one line, and the command
does not get bored on the eleventh repo.
Rule 3 — the danger label goes in the index, not the body
The risk of handing an agent a shell is not that it does the wrong thing. It is that you cannot tell at a glance which of forty commands is dangerous. So every command carries its blast radius in the table of contents:
For anything in the middle band, the protocol is fixed and lives in the tool, not in the human: dry run → print the plan → get confirmation → apply → re-read and verify. Written into the conventions is the line I care about most:
A command that skips a step is a bug in the command — fix the command rather than working around it by hand.
Once "just this once" is a bug report instead of a shortcut, the guardrail survives contact with a bad day.
Two mechanised details that matter more than they sound. Before any write, the
command runs SELECT @@hostname, @@read_only and shows the result to the
human — because local config differs per machine and several services ship a
committed config pointing at production. And consent expires within the turn:
"they agreed last time" does not count.
Rule 4 — a deterministic gate runs before any model reviews anything
The heaviest thing I run is a multi-agent pipeline that produces supplier API mapping documentation. Its shape is the part worth stealing:
Three decisions in there earned their keep:
The orchestrating session does no content work. It holds a hard read whitelist and delegates. A session that both writes the document and judges it will approve its own output every time.
A deterministic script runs before any LLM reviewer. Whatever a script can check — schema, required fields, broken references — a script checks, and it checks first. You cannot talk a script into agreeing with you. Only what survives the script is worth a model's attention.
The fixer is a separate agent holding only Edit. The thing that found the
problem is not the thing allowed to change the file.
Rule 5 — agents that disprove, not agents that agree
The default failure mode of asking a model to review something is that it finds you plausible. So the review step is inverted: each finding goes to an agent whose stated job is to refute it, defaulting to "not real" when uncertain. Only findings that survive get reported.
The ratio is brutal and that is the point — most of what comes out of a first pass is plausible and wrong. Running an investigation this way, roughly four out of five candidate findings die before a human ever reads them. The survivors are worth the meeting.
The same instinct shows up in the packs as a required section: every audit output must end with "what I am not certain of". It costs one paragraph and it is the difference between a document a colleague can build on and one they have to re-verify from scratch.
Rule 6 — five things now run without me
Five scheduled headless jobs write worklogs and weekly reports from git, tickets and chat. Each validates its own output before touching a tracked file — an unattended job that writes a broken file at 7am is worse than no job at all.
The number I do not have
You will notice there is no "saved 40% of my time" here.
I never measured it, so I am not going to publish it. Everything above is a count: files, lines, repositories, steps, agents, jobs. Those I can re-derive in front of you.
I do keep a cost file where every figure carries a measured or estimated label, a date, and a source — including one optimisation recorded as a failure, with its payback maths written out. An estimate that a later reader mistakes for a measurement is the fastest way to lose trust in an entire document, and the temptation to publish a flattering unmeasured number is exactly the thing this whole setup is supposed to protect against.
If I had to name the real return, it is not hours. It is that the procedures stopped living in one head — including on the days that head is on holiday.
What I do not hand over
- Declaring a root cause when part of the chain is outside the workspace. If two links live in repositories I cannot read, the honest output is the two surviving hypotheses and the query that separates them — not a confident answer.
- Pressing send. External mail gets drafted, never sent.
sudo. The command is handed to me; I run it.- Anything whose only evidence is "it looked right". If it was not re-read after the write, it did not happen.
None of that is caution for its own sake. It is the same rule underneath all six: a model is very good at producing something that looks like the answer, and the entire job of the scaffolding is to make the difference visible before it reaches production.