In The Ones I wrote down a table of imaginary agents. The top row was the boring one: an agent that asks what a thing is for, and cannot propose and cannot cut. Yesterday I ran it by hand. No custom runner, no daemon, no theones binary. Two terminal sessions, two log files, and a real task on incus-compose. It found real defects and the work landed. The interesting part is where the constraint came off, and that I did not notice at the time. ...
None of them exist. What follows is a group of imaginary agents that would help me work better. I am writing them down because writing a thing down is how I find out whether it is worth building, and because this group is cheap to describe and expensive to make. Where they come from After a session with an agent I ask it for a written account of how the session went. There are 132 of those now, going back to January, and read together the failures in them are not varied. They are a small number of things, repeated: ...
One of the session write-ups in my repo opens like this: Session ended with a revert and nothing shipped. It is written as a confession. Nothing shipped is the normal state of a session, and it always has been. What shipped means On a branch, it is a draft. On main, it is merged. It is only shipped when it has a version tag. Nothing else counts. I keep that narrow on purpose. It is the only line in the whole process where the cost of being wrong changes, and everything either side of it behaves differently. ...
In a review session an agent told me the plugins in the chain must not trust each other. Treat each one like a foreign API: check what arrives, and defend the chain against a plugin that misbehaves. It was not a careless suggestion. That is what you do at a boundary you do not control, and it is the right default for most of the code anybody works on. I still said no, and writing down why took longer than saying it. ...
One of the architectural rules in the AGENTS.md of incus-compose is: Constraints outside, freedom inside. A unit is predictable from the outside: what it receives, what it returns, and which effects may escape are fixed. Inside those constraints, it is free to reconnect, coordinate goroutines, or replace its machinery without involving its callers. An operation may send messages or write files because those are its purpose. The problem is an incidental effect becoming somebody else’s responsibility: ...
It started with an LLM agent documenting the boundaries for me instead of building them. It was about concurrency, and what came out of it was a comment: which call may come from which goroutine, what has to be locked first, what to watch out for. All correct. All friendly. All just text. A boundary that lives in a comment isn’t a boundary. It’s a request. It holds as long as the comment is read and remembered. I just don’t want to remember; static linters should. Safe at any time, by any reader. ...
In Three Rewrites there was a sentence I glossed over: Hooks before and after every action — logging, dry-run, error context, all without touching the core. Half a sentence. But that’s exactly where the third attempt ended up. Today I want to unpack that one line. It’s going to be longer. What a hook is A hook is a function I slip in before or after an action. ensure, delete, start, stop — every action incus-compose runs on a resource can be intercepted. Before and after. ...
I hate spaghetti code. Warzone 2100, among other things, showed me why back in 2011. C code, globals everywhere. You change one variable and three things break that seem to have nothing to do with it. You read the code and can’t tell where a decision begins and where it ends. For three years — from 2022 to 2025 — I worked on go-orb. Alone. A framework for distributed systems, meant as the successor to go-micro. Config from anywhere, service discovery, RPC, streaming, pub/sub, kvstore, metrics. Every new idea became a feature, every feature a plugin. ...