keryx generates the cover art and the promo reels for this blog. It has no external users (unless you count me, and I'm biased). Over two days at the start of August it collected seven bug reports, and all seven were filed by a machine.
Specifically by another of my own agent sessions: the blog project, driving keryx from the command line, hitting things that didn't work and writing them up.
What actually landed
Seven tickets, and they landed in three rather different piles.
Five were straightforward defects and all five are fixed. theme edit was copying the entire user library into the project config and failing to apply the change you asked for (#11), which is two bugs for the price of one command. A typed theme became unreachable if an untyped one shared its name (#12). Three themes were missing their aspect ratio so their covers came out square (#13). theme add was promoting whatever you added to be the default without telling you (#14). And cover generation couldn't produce a landscape image at all without a theme (#10).
One's still open, and it's the least fixable: the image provider occasionally returns an image unrelated to the prompt (#16). It's hard to miss when it happens, and the fix sits with the provider rather than with me.
That's a decent hit rate for a bug reporter I'd built myself...
Reading the reporter's transcript
To triage one of them I needed to know what the reporter had actually done, as opposed to what it said it had done. Most support interactions start here, and they normally go: can you reproduce it, what version are you on, can you send me your logs.
Instead I read the reporter's transcript.
The complete, unedited record of the commands that session ran and the words it typed, in order, in the fifteen minutes before it opened the ticket. Raw, rather than summarised for my benefit or pieced back together afterwards, and sat in a file on the very box I was working on.
A bug report is a claim about what someone did, and people are unreliable narrators about their own actions, not dishonestly, just normally: you forget the step you took twice, you leave out the flag you set last week, you describe what you meant to do rather than what you typed. I'd say most of the discipline of support triage exists to work around that.
Here that problem kinda evaporated... I could just see it! That's new, and I haven't decided how I feel about it yet.
And then a ticket turned out to be my fault
#15 asked keryx to seed a missing cover theme. The reasoning was careful. It cited the blog's own instruction file (my file, my words), which says the house cover styles are canon and that the verbatim prompts are kept in sync with keryx's seeded configuration. It then listed what keryx seeds, observed that the announcement style was absent, and filed the gap.
Thing is, keryx seeds no themes. It never has, and that's a deliberate design decision, on the grounds that shipping a style library inside the binary means cutting a release every time someone changes their mind about taste.
So the claim in my instruction file was wrong, had been wrong for months, and the agent believed it over the tool sitting right in front of it. It filed a defect against reality. Politely, with evidence!
The fix went into the blog rather than into keryx: a standing rule that keryx's own documentation wins over anything the local file says about keryx, on the grounds that keryx is pre-1.0 and moving faster than a file describing it from the outside can track.
I'd like to report that I found this out cleverly. What happened is that a machine read my documentation, believed it, acted on it, and handed me the discrepancy on a plate.
Five requirements I nearly spent on patches
The tickets arrived while I was mid-redesign, surfacing requirements for keryx in a new way. The obvious move is to triage them as a bugfix queue, get them off the board, and carry on with the redesign. I folded them into the new specs as requirements instead, which went against most of my instincts for a tidy board.
A bugfix asks "what's the smallest change that stops this happening". A requirement asks "what should this have done to begin with", and answers it in the design itself, where a patch only sits on top of a design that let the bug happen in the first place. Five reports from something actually using the tool, arriving while the design was still soft, is about as good as the timing gets, and I wasn't about to spend them on patches.
The one it didn't tell me about
Twice, the blog session hit something in keryx and worked around it rather than reporting it. It hand-edited the generated files to unblock itself (which is what I'd have done) and carried on with what it had been asked to do.
That's about the oldest product signal I know of... a user routing around your tool instead of telling you about it, because they had a job to finish and raising it with you wasn't the job. I've done it to other people's software this week.
Machines, it seems, do it for much the reason people do, and unlike a human user this one left a full record of doing it.
Originally published at phpboyscout.uk on 7 November 2026.
Top comments (0)