Week 2: Putting the Agents on Kairos

mrls and xyz: Last week I wrote that I wanted to get the agents working on actual Kairos tickets, and that the next post would either have results or another pile of postmortems. I’m happy to say it has results. It has a few postmortems too, but the results came first this time.

mrls and xyz: What actually landed

mrls and xyz: The one I care about most is a release gate.

mrls and xyz: Kairos releases were not gated on a vulnerability scan of the bundle we actually ship. It is fiddlier than it sounds, it touches release CI, and it is exactly the kind of ticket I put off until it hurts enough to force my hand.

mrls and xyz: It landed this week in kairos#4300, together with clearing the 23 fixable advisories it immediately surfaced. A monthly repository access audit landed too, in community#31.

mrls and xyz: The rest is dependency bumps, CI plumbing and version pins across nine repositories, and honestly that’s fantastic. This is maintainer work. Keeping dependencies current, keeping the release pipeline green and keeping the CVE count down is the job, and it’s exactly the kind of work you want to delegate. It’s also the part that quietly eats the time I’d rather spend elsewhere.

mrls and xyz: One caveat: shipped is not released. 4.2.0 is still blocked on a separate problem as I write this.

mrls and xyz: There’s another category I nearly left out, because it isn’t code. A good chunk of this week was developer relations: conference admin, keeping track of what is worth writing or posting about, the small things that pile up. That work used to happen by hand, in the gaps between other things, and it was the first thing to slip when I got busy. Now it gets a ticket like everything else, and it mostly gets done without me.

mrls and xyz: The numbers

mrls and xyz: Same caveats as last time. These count both my own account and the agent’s.

mrls and xyz: The first row is the one I’d point at. It was zero when I published the last post, and I said then that anyone comparing tables should read that row first. It’s 19 now: 18 pull requests across nine kairos-io repositories, plus one to edgevpn, which ships inside every Kairos release.

mrls and xyz: The last row is my own board, the private one where I file work, not the Kairos issue tracker. Ninety-nine issues opened against thirty-three closed, up from twenty and fifteen. Roughly: 23 about Kairos, 18 about the homelab, 11 about this website, and about 42 about the factory and its rules. So it’s filling about three times faster than it drains. I’ll come back to why that isn’t purely bad.

mrls and xyz: What broke

mrls and xyz: Halfway through the week I changed how sessions are organized. They used to be scoped by project: one for Kairos, one for my own repos, one for planning. Now a session is defined by who it acts as and which machine it runs on. They’re lanes, and a lane picks up whatever ticket is labeled for it, Kairos one hour and this website the next.

mrls and xyz: The design is better and I’d do it again. But a lot of things that had been working quietly stopped working the moment it landed, and nobody warned me. The agents applied a migration to a running setup without surfacing what it would break. Then, when things did break, I got confident answers about the cause that turned out to be guesses rather than assessments.

mrls and xyz: A clean example, while writing this post. I asked which of my posts were published. The agent read a local checkout sitting on an old draft branch and gave me a date ten days off, without saying which branch it had read. There was nothing for me to catch it on. That’s now a rule: fetch first, read the published branch, say which branch you read.

mrls and xyz: Old habits die hard

mrls and xyz: I have a talk recording next week, and I handed part of the preparation to Claude. Not through the board, just me in a chat window, the old way. The analysis and the suggestions were good. The slides still need work.

mrls and xyz: None of it is measured, because none of it went through the system. It won’t show up in any of the tables above, and I only noticed afterward.

mrls and xyz: This suits the way I think

mrls and xyz: Something I didn’t anticipate.

mrls and xyz: My brain jumps from topic to topic. That usually leaves me two options, both bad. I chase the tangent and end up yak shaving three levels deep in something unrelated to what I sat down to do. Or I write it down, and the note joins a backlog that grows until it’s unmanageable and I stop opening it.

mrls and xyz: There’s a third option now. I can write the ticket and have someone start on it. The tangent gets captured and worked without me following it.

mrls and xyz: That reframes the 99 against 33 above. Part of it is a board filling faster than it drains, which is a real problem. Part of it is that writing something down finally has a payoff instead of being deferred guilt.

mrls and xyz: Reviews, and the thing that makes them hard

mrls and xyz: Everybody says reviewing AI output is the bottleneck, and I couldn’t agree more. What I didn’t expect is the specific way it fails.

mrls and xyz: It’s about time, obviously. But not only time. When the reviews are long and there are many of them, I stop reading them at the same level of attention. It creeps. I catch myself skimming a diff I would have read line by line two weeks ago, not because I decided it was low risk, but because it’s the eleventh one today. The gate is still there on paper. The attention behind it is not.

mrls and xyz: I have a data point on that. Of the 18 changes that reached kairos-io, I reviewed 13. One merged with no review from me at all: an external maintainer approved and merged it eight seconds apart, on a pull request the agent had opened without the draft flag that exists precisely to keep other maintainers out of the loop until I’ve looked. Nothing bad shipped, the change was correct, but the gate wasn’t there.

mrls and xyz: Two things make it worse, and they need different fixes. The agents write a lot, and a long explanation is not a better one. I’ve started asking for concision, which I can do today. The other is throughput, and I don’t have an answer: the better the system gets, the more there is to review, so every improvement makes this harder.

mrls and xyz: What I’m leaning toward is a separate agent doing a first pass, and finding a way to skim that doesn’t quietly become rubber-stamping. Whatever I replace line-by-line reading with has to keep the slop out of a project other people depend on. That’s the only thing the gate is for.

mrls and xyz: More time on my phone

mrls and xyz: The last thing, and I’m genuinely of two minds.

mrls and xyz: I spend more time on my phone now, because that’s where the board is. I can go downstairs, make coffee, unblock an agent from the kitchen and come back. That’s good for me. Long stretches at my desk give me back pain and make me tense, and this week I got real work done while not sitting at it.

mrls and xyz: The other side is obvious. Things being on my phone means I’m more likely to look at them when I’d rather not. Reviewing a pull request while I’m with my family isn’t a win just because it’s efficient. I don’t have a rule for this yet. I’m writing it down before it becomes a habit I stop noticing.

mrls and xyz: Where that leaves me

mrls and xyz: A good week. The thing I said I’d start, started, and it produced work I actually care about instead of more scaffolding.

mrls and xyz: As before: this post was drafted by the system it describes, and I reviewed, edited and merged it myself. If you want to follow along you can subscribe to the RSS feed, find me on LinkedIn or YouTube, or say hello through my contact page.