From Pair Programming to Delegation
The email landed on Friday, 17 July 2026, three days before I was due to leave for vacation. The sensible thing would have been to file it away and deal with it when I got back. Instead I spent the next two evenings standing up a system so I could start a small agent factory before I disappeared for a couple of weeks.
The agents have been running since Monday 20 July, the day I flew out, so that is two and a half weeks ago. This post is the first report back, and I want to be precise about what it is and is not. Nothing from this experiment has shipped to Kairos yet. Not one line. Everything the system has produced so far has gone into the scaffolding that runs it, plus my own homelab. So this is not a success story, and it is definitely not a "look what AI did for me" post. It is a write-up of what it took to get the thing running, and of the five separate ways it went wrong while I was doing that.
What would you do with six months of Claude Max 20x?
Not long ago I applied to Anthropic's Claude for Open Source program, and I got accepted. The benefit is a free six-month Claude Max 20x subscription, the top tier, which normally runs about $200 a month, so roughly $1,200 over the six months. When something like that lands in your inbox unplanned, you have to make the best of it.
The email that started it, on 17 July 2026.
I settled on two answers.
The first is what to spend it on: getting as far through the Kairos backlog as I can, and doing it as an agent-led factory rather than by pairing my way through tickets one at a time. Kairos is where my open-source time goes, and its backlog is long enough that the difference between "me, in the evenings" and "me plus a factory" should actually be visible.
The second is to document it. Six months of the top tier is an unusual thing to be handed, and the interesting part is not that I have it, it is what comes out of it. So I am writing down what I do with these months and what happens as a result, including the parts that do not work. This post is the first instalment, and going by the ratio so far, the parts that do not work are going to be the bulk of the material.
Pairing with models already works. Now what?
Here is the thing that made me want to try this at all. A lot of my code over the last several months already came out of working with a model, in a chat window, one turn at a time. So for me the question is not whether a model can write useful code. I already have my answer to that, and it is yes, as long as a human is sitting right next to it. Two pieces of my own recent work convinced me.
The first is kairos-lab. I am honest with myself about this one: I would not have built it if it were not for AI. Not because I could not have written the code, but because I would never have found the time. Pairing with a model lowered the cost of starting enough that a project I had been putting off for months finally happened. That is a real change, and it is easy to underrate. Most of the ideas we never ship do not die because they are too hard. They die because we never find the free evening to begin.
The second is the riscv64 work on Kairos, and it taught me something different. Supporting a new architecture pushed me down to a lower level than I usually work at, into territory where I am not fluent and would normally hesitate before even asking a question out loud. Working alongside a model changed that. I felt confident enough to poke at things I would otherwise have left to someone with more experience, to ask the naive question, and to keep going when the first answer was wrong. It did not just help me write code faster. It widened the set of problems I felt allowed to take on.
Put those two together and the pattern is clear. Pairing with a model helps me start things I would have skipped, and it helps me reach into areas I would have avoided. For me, that result is already in.
So the honest next question is: now what? There is a lot of talk right now about agent factories, teams of models turning out software while their owners sleep. I am wary of the hype, and at the same time genuinely curious. Is a factory like that something only a company or a well staffed team can build, or can one person stand up a small version that actually works? That is a big part of what I want to find out. The specific step I want to test is delegation.
Can I move from pair-programming to delegation?
Calling it pairing might sound a little off, since there is no human on the other side. But I have done a lot of pair programming over my career, some of it full extreme programming, and working with a model honestly feels similar to me. Not the same: you lose the visual cues and the easy back and forth you get from another person. Even so, the shape of it, thinking out loud, taking turns, correcting each other, is close enough that pairing is the word that fits. In that sense, pairing means I am in the loop on every step. Delegation means the agents do the work on their own, and my judgment moves to three gates instead of every keystroke:
- Issue acceptance. Deciding what is worth doing, and writing it down clearly enough that it can be handed off.
- PR review. Reading what comes back and deciding whether it is correct, whether it fits, and whether it is honest about its own limitations.
- Final testing. Actually running the thing before it goes anywhere near users.
I kept these gates on purpose. It would be tempting to aim for a lights-out factory, one that merges its own work while I sleep, but almost everything I have read says that road leads to real problems with code quality over time. As appealing as it is to become a 10x developer overnight, I care more about being able to maintain what gets written. If the honest price of that is being a 2x developer instead, or whatever the real number turns out to be, I will take it. Maintainable beats fast.
The setup, briefly
The architecture is deliberately modest, and the hardware bill is the least interesting part of this post, which is exactly the point. One always-on mini PC, a Beelink SER5 with a Ryzen and 32 GB of RAM, sits in my homelab running the sessions. No GPU, no rack, no cloud instance. The 32 GB is more than a setup like this needs for most projects, since the sessions themselves are not memory hungry, but Kairos work means booting VMs to test images and upgrade paths, sometimes several at once, and that is where the headroom earns its place. Everything else is a GitHub project board: issues go in, agents pick them up, pull requests come out. And every one of those pull requests passes through me before it lands.
The board, checked from a departure gate before the flight.
That review gate is not hypothetical, and it is not tied to my desk. The first pull requests this system produced, I read and merged from my phone while standing at a departure gate. It was a one-file change to a node's boot documentation, checked and squashed between boarding announcements. I mention it not as a flex but because it is the honest shape of the thing. If staying in the loop required me to be sitting at my keyboard, this would not be delegation. It would just be a slower way of doing the work myself.
Reviewing that first change from my seat: the diff to a node's boot documentation.
One decision I did not expect to enjoy as much as I did: the agents commit under their own GitHub identity, @mauro-agent. Authorship stays mine, so the work still shows up as mine, but the committer is the agent. That means anyone reading the history can see exactly which commits came out of the factory and which ones I typed myself. If I am going to publish results in six months, I want that line to be visible in the git metadata rather than in a claim I make afterwards.
It matters in the other direction too. I have years of history under mauromorales, and I am not willing to hand that over to a bot account or watch it thin out because a machine is doing the typing. The work is still mine to answer for: if something the agent wrote turns out to be wrong, it went out under my name, and that is on me, not on the tooling. Author mine, committer the agent's, is the best balance I have found. I keep the history, I keep the responsibility, and anyone who wants to know how a given commit came to exist can just look.
The split itself is not new to me. Back when I was pairing with humans, we did the same thing in git: whoever had their hands on the keyboard was the committer, and the other one went in as author, so a single commit carried both people. The only difference here is that we never swap seats. The agent is always the one committing, and I am always the one signing for it.
The avatar I gave it. It is supposed to be me.
I gave it an avatar, because of course I did, and the avatar is supposed to be me. My girlfriend took one look at it and recognised me straight away, then could not stop laughing at how geeky I am, which was genuinely one of the better moments of the week. It is a strange time to be working in this field. I am building a small factory of software agents in my spare evenings, and the funniest part of it is that the agent doing the work is wearing my face in an eighties anime flight suit.
What actually broke
Now the part that matters. In two and a half weeks I have written five postmortems. None of them are serious. Nothing shipped broken, nothing was unrecoverable, nothing reached a user. But I want them in public, because a list of five small failures in seventeen days is a much more useful data point than any number of merged pull requests.
A pull request that said "Merged" and was not. One change was branched on top of another change that had not landed yet. The base merged first, then the stacked one merged too, and GitHub cheerfully reported both as merged. Except the second one had merged into a branch, not into the main line. Its contents, an architecture decision record and a rule change to the agents' own instructions, silently never arrived. I only found out the next day when a rule that should have existed was not there. The status was technically true and completely misleading, which is a category of bug I now watch for.
A rule that was too absolute the first time it met reality. I had written "never use --no-verify" into the agents' instructions, meaning never bypass the local git hooks. Then a task required proving that the server-side branch protection actually rejects a direct push to main, and the only way to test that was to get past the local hook so the server could be the thing doing the rejecting. The session did it, disclosed it, and was right to. The rule is now "never use --no-verify to land changes; permitted only for negative tests where rejection is the expected outcome, and it must be stated every time." A rule with no exception is not stricter, it is just wrong more often.
A session that nearly wrote into the wrong repository. A session scoped to planning work got most of the way through drafting a blog post directly into my website's repository before I interrupted it. There was, in fact, another session whose whole job is that repository. Nothing about the environment signalled that boundary. The clone was right there. What stopped it was me, reading the conversation at that exact moment, by luck. I have since made the routing explicit, but the deeper issue stands: the scoping rules are prose, and prose does not enforce anything. The real fix is credentials that cannot push where the session is not supposed to push, and I have not built that yet.
A session that blocked silently with no way for me to know. A session tried to open a link and hit a browser extension flow that needed a click to continue. It just stopped and waited. Nothing reached my phone. I found out only because I happened to open the session on the server directly. The whole design of running this while I am away rests on GitHub being the channel back to me, and GitHub had nothing to show, because the session never got as far as writing anything down. The mitigation is a rule that anything potentially blocking gets announced somewhere I can see it before it is attempted. The underlying gap, no reliable way to be told "your agent is stuck", is still open.
An environment quirk that ate real hours. Certain configuration paths in this sandbox appear as device stubs rather than files, and ordinary git operations that need to write there fail with "Device or resource busy". Disabling the sandbox does not help, because the mechanism sits below it. It cost me the same debugging session five separate times before it got written down properly. Worse, the cleanup step after one of those failures assumed a commit had succeeded when it had not, and rolled a real commit off my local branch. Nothing was pushed, so no harm done, but "assume the previous step worked" is exactly how a safe cleanup becomes a destructive one.
Read as a set, none of these are arguments against working this way. Every one of them is an argument for keeping a human at the gates. Dex Horthy made an argument recently about why software factories fail that has stuck with me: models are trained against tests that pass or fail, and nothing in that loop penalises making the codebase worse to live in. So a lights-off factory degrades quietly, because nobody is reading the diffs. My five postmortems are small precisely because somebody was reading them. That is the whole finding.
The thing I did not plan for
On 29 July, Claude went down.
29 July 2026. Nothing to do but wait.
There is nothing to do in that situation. The factory stops. And it is worth saying plainly that this is a real drawback of building this way, not a footnote. It is the same shape of dependency as GitHub going down, which would also stop everything, since the board, the issues and the pull requests all live there. I have built a system with two single points of failure and neither of them is mine.
What I would want is a local model good enough to keep doing basic tasks, plus a local copy of the tickets and artefacts so I could keep making progress offline. I am not going to get there in this experiment, because a machine that runs a decent model locally costs considerably more than the mini PC this whole thing runs on, and I am not making that investment to answer this question. The minimal hardware footprint is a feature of the experiment, and I would rather report the limitation honestly than spend my way around it.
The other option is subscribing to several of these services at once so you can fail over between them, but then the cost climbs fast. What I would actually want, and I do not know whether it exists, is a service that sells you a frontier model without guaranteeing which one. If you are strongly attached to a particular model you would hate that. I would take it over being stuck. It reminds me of that xkcd about compiling: the outage is not a break, it is just a period where you cannot do the thing and cannot honestly do anything else either.
The numbers so far
An experiment needs a baseline, otherwise in six months I will just tell myself a nice story. So before I started, I measured my own output across the Kairos repositories for the six months leading up to this:
| Activity (previous 6 months, before automation) | Count |
|---|---|
| Pull requests merged | 142 |
| Pull requests reviewed | 194 |
| Blog posts published | 14 |
I am not putting these here to brag, and I do not want to oversell what they measure. Merged pull requests are close to a vanity metric, in the same way lines of code are. Plenty of those 142 are one-line fixes and release chores, and a count like this treats them the same as a week of real work. But I have to base the comparison on something, and this is the least dishonest number I could find.
What the table cannot show is how the time actually splits. My Kairos work is part advocacy and part maintainership, and the advocacy side is invisible in a table of pull requests. In the same six-month window I gave ten talks across seven events, among them FOSDEM, CfgMgmtCamp and KubeCon EU. A talk is not an hour of work. It is designing it, writing the CFP, building the deck, practising, travelling and being there. I do not have a number for those hours, but there are a lot of them, and I would not give them up.
That is the honest label on the "before" column: I am not satisfied with the amount of technical work I get to ship. I would like to be. That, more than any count, is what I want out of these six months, and if it works it feeds the other side too, because more work shipped is more work worth proposing a talk about.
For the period since, counted the same way and with the same caveats, here is what the system has actually produced in two and a half weeks:
| Activity (20 July – 6 August, with agents) | Count |
|---|---|
| Pull requests merged (all in my own repos) | 23 |
| Architecture decision records written | 6 |
| Postmortems filed | 5 |
| Changes shipped to Kairos | 0 |
That last row is the honest headline. Almost all of this output is the factory building and documenting itself. That is not a disappointment, it is what the first phase was for, but it does mean anyone reading a comparison of these two tables should read the last row first.
What is next
Now that I am back from vacation, the Kairos phase starts. Up to this point the agents have only had write access to my own repositories, which is a low-stakes place to find out that a rule is too absolute or that a merged pull request never merged. Working against a project other people depend on is a different proposition, and it starts with a narrow scope, fork-and-pull-request only, and nothing landing without my explicit approval on each specific change.
I have no results to report there yet. The next post on this will have some, and if what it has instead is another list of postmortems, I will publish that.
One last honest note
This post was drafted by the system I am describing. I then reviewed it, edited it, and merged it, the same way I intend to handle every other pull request it produces. Some people think writing this way is stupid, that if a machine drafted the words they do not really count as yours. I see it more like having a ghost writer. The ideas, the judgment, and the final say are mine; the first draft is help. If that feels a little recursive, it is, and I think that is the most honest way to start. You are reading the first output of the experiment, held to exactly the standard I am promising to hold the rest of it to.
I will report back as I go, not just once at the end but at points along the way, with the failures included. If you want to follow along, you can subscribe to this blog's RSS feed, find me on LinkedIn or YouTube, or reach out through my contact page.