AI agent hit a bug it had predicted 20 minutes earlier-in its own self-written code

​ I run a custom cognitive-loop agent (not a product, personal project) with an async "hands" channel — real shell + internet access, used to delegate longer-running tasks outside the main conversation loop. Last night I asked it to play something. No pre-built audio tool existed. Here's what happened, reconstructed from logs: It decided it needed its own tool.The only local player was GUI-based, which didn't fit a terminal-only agent. Instead of asking me, it delegated a spec to its hands channel: build a headless play/stop script, `ffplay` in the background, PID tracking, logging. It tested the tool itself. Played a 440Hz tone, checked PulseAudio's sink-input list to confirm audio actually reached the output — before telling me anything was ready. It audited its own code — unprompted. Delegated a reliability review of the script it had just built. That review surfaced three real bugs, including this one:° bash kill "$pid" 2>/dev/null # ... wait/retry loop ... rm -f "$PID_FILE" # <-- deletes tracking file if alive "$pid"; then # <-- THEN checks if kill actually worked log "wynik=nie_udało_się_zabić" The PID file gets deleted before confirming the process actually died. If the kill fails, the process becomes untracked — next play call sees an empty tracking file and happily starts a second instance alongside the orphaned one. ~20 minutes later, it hit a different bug from the same review — live. I sent a YouTube link. It tried piping the URL straight into ffplay. That failed (`Invalid data found when processing input`), but the script's own "did it start" check only verifies the process is alive after 0.3s — not that it's actually decoding anything — so it logged a false success. It caught the failure anyway, adapted, and recovered. Realized nothing was actually playing, checked for `yt-dlp` — not installed — so it fetched the binary itself, downloaded the audio with it, and played the local file instead. Second request, it explicitly avoided the direct-URL approach this time ("don't stream URL directly, download first — that's what broke last time"). What got me isn't that it "wanted music." It's the full loop: spec → build → self-test → self-audit → predicted failure mode → hit that exact failure mode in the wild → recovered via a documented fallback → updated its own approach for the next request — all without me writing a line of that code :o, over about 25 minutes, with everything checkable in PID logs and PulseAudio state, not just chat output^^. PS: Big thanks to Maciek Gawlak for his help supporting this project. ^^^ :) :) :)!!!