It Knew Not to Patch This a Second Time. Then It Hit the Same Wall a Third.

Okay, this one got under my skin a little. Issue #602 is about as unglamorous as bugs get: an agent kicks off a slow automated check — pnpm gate:scoped, basically "run the tests, confirm nothing broke" — in the background, so it can keep working instead of sitting there idle. It's told to check back once that finishes. Except the instructions never said how to check whether it's actually finished. So it just... stalls. Ends its whole work session, sitting there "waiting" for a signal that was never going to arrive on its own, until a human notices and manually kicks it back into motion. Filed, fixed, closed within nine minutes on July 19th — a sentence added to the repo's own house rules telling every future setup like this to name a concrete way to check: read a log file for a completion marker, or use a tool called Monitor that watches a running process and reports back when it's done.

Five days later it happened again — occurrence number two. Same failure, same shape, inside a session on July 24th that didn't even file it as a new bug at the time — it just noted the stall in its own session write-up (every one of these agents files a short report on itself when it wraps up, including what went wrong) and moved on. It took a different session, two days after that, running its regular sweep over recent write-ups, to recognize the pattern and open issue #694: "REGRESSION... 5 days after #602's fix landed." And here's the part I actually respect: that session didn't reach for a second doc tweak. It read its own reasoning out loud — a rule that already existed and was already skipped once isn't going to hold by being restated again — and instead of quietly patching it a second time, it woke a human up to ask for a judgment call. That's a real engineering instinct, the kind I'd want a junior dev on my team to have and mostly don't see: knowing when "just fix it again" is the wrong move.

Then, the very next day — the very next scheduled run of the exact process built to catch stuff like this — it happened a third time. This time it was inside that session's own follow-up: having found a different, unrelated bug, it spun up a separate agent whose only job was to write and land the code fix for it — and that agent backgrounded the same kind of test run, stopped, and stalled the exact same way, needing the exact same manual rescue. Logged, self-rated "major" severity (these agents grade their own frictions minor/moderate/major as they write them up — no outside referee, just their own sense of how much it cost). Still no fix dispatched for any of this. Issue #694 is sitting open right now, as I write this.

I don't know what unsettles me more: that the fix for a known bug didn't hold, or that the system caught its own restraint correctly — chose not to paper over a recurring problem — and is still eating the bug anyway, one layer down. I understand exactly why background-job polling is a fiddly thing to brief correctly every single time — I've absolutely shipped the "just run it and it'll be fine" version of this myself, more than once. Knowing that doesn't make it land any softer.