My About page says that much of the recent work on this site, and on the systems behind it, was done by an AI coding agent working from briefs I scope and review. That deserves more than one sentence, because the part I’d defend isn’t the agent. It’s how the work is divided, and what happens when something goes wrong.
First, what this isn’t. The home server, the network and the cloud machines around them existed before any of this: I built them and ran them by hand. The agent extends that infrastructure. It didn’t design it, and nothing it writes goes live until I’ve reviewed it.
Two sessions, two jobs
I split each piece of work between two Claude sessions that never share a conversation.
The planning session can read every repository but has no route to the servers. It talks a change through with me, asks the questions only I can answer, and writes a brief.
The execution session is Claude Code, running in my editor. It can reach the servers, run commands and open pull requests. It starts cold: it knows nothing about the conversation that produced the brief, only what the brief and the repository say.
The split follows from what each side can reach, and each covers the other’s blind spot. The planner can’t check a claim about the live system, so it has to write a brief that someone else can carry out. The executor has just written the change, which makes it the worst judge of whether it was the right change. That second point doesn’t go away just because the executor is careful: the same misunderstanding that writes the code writes its tests.
The loop
Anything bigger than a one-file edit is broken into phases, each small enough to deploy and check on its own. Then, for each phase:
- The brief. The goal, the steps, the exact command that verifies each step and the output it should print, how to roll back, and the assumptions, each with a confidence so the executor knows what to check first. The standard is simple: if the executor would have to ask a question, the brief isn’t finished.
- The brief goes into git first. The executor’s first commit is the brief exactly as it was handed over, before any other change. Afterwards anyone can compare what was asked with what was done.
- The work. The executor works on a branch, opens a pull request, and writes a dated Result into the brief: what happened, including everything that didn’t match the plan. That mismatch is the most useful part of the record.
- The review. The planning session reviews the pull request against the brief, and writes the review into the repository as a file. Each finding is marked either apply or needs a ruling. The reviewer never edits what it reviewed; if it wants a change, it says so.
- The rulings. Anything marked for a ruling comes to me. The executor applies the findings, runs the checks again, and records what it did under the review.
- Merge and deploy, then confirm that GitHub, my clone and the server all agree. Merged and deployed are different claims, and the gap between them is where things quietly go wrong.
It is slower than asking an agent to just do the thing. For systems I’m responsible for, it’s the right trade.
Where it went wrong
This site was built this way, and the first phase is a better example than any success story.
The brief for phase 1 included a rule for what may never appear on a public page (no internal addresses, no account names, nothing about my employer, and so on) and a search pattern to enforce it. One part of the pattern, meant to catch a single banned word, had no word boundary in front of it. So it also matched the ordinary word “from”.
The executor noticed. The brief said a hit is fixed, not explained away, and the brief was frozen once handed over. So it wrote all ten pages without the word “from”, which let the check run exactly as written, and it said so plainly in the pull request.
That was a reasonable call inside the rules, and it made the writing worse: “published out of one repository” where “from” was the natural word. The review caught both halves. It also recorded that the planning session had made things worse: a follow-up to the brief described the corrected pattern as if the brief already contained it, because the planner had checked its own copy rather than the file it handed over.
My ruling was to fix the check in the site’s own rules file, leave the frozen brief as it was, and put “from” back wherever it read better. The executor did that and ran the check again, with controls that prove the new pattern still catches what it should and no longer catches “from”.
The same review found two content problems that no search pattern would have caught. The homelab case study listed hardening work that wasn’t done yet, which on a public page is a list of what isn’t finished in the defences. It was cut. The Southern Sparkle case study mentioned the client’s billing arrangements. The owner had agreed to a case study, not to that, so it was trimmed.
Phase 2 had a smaller version of the same pattern. When the site became visible to search engines, one check failed: the robots file didn’t list the sitemap. Instead of retrying or guessing, the executor read the file straight from the server, found the server was right and Cloudflare was serving an older cached copy, and stopped to ask me. I purged the cache, it ran the check again, and the Result records all of it.
What I’ve taken from it
- The author can’t review its own work, however careful it is. A second reader with a different view of the problem finds what the author’s tests share with the author.
- A Result that says everything went to plan is the one to read twice. The mismatches are where the learning is, and a process that records them honestly is worth more than one that looks clean.
- A check has to be able to fail. Every search pattern now ships with controls that prove it matches what it should, and doesn’t match what it shouldn’t.
- Decisions that are mine stay mine. The brief marks them, the review marks them, and the executor stops and asks rather than guessing, even when guessing would be faster.
None of this is special to AI. It’s how I’d want any change to a system I run to be made: written down before it starts, checked by someone other than the person who made it, and recorded honestly when it’s done. The agent just makes that discipline cheap enough to use on everything.