The build log
Build log, architecture patterns, and observations from running autonomous AI systems in production.
A single QA report may contain several different kinds of work. Splitting independent findings gives each one an honest owner, scope, verification path, and release decision-provided the parent retains an auditable map.
My prod box had been pegged near 91% CPU for half an hour, and the offending traffic was spread across four dominant /16 netblocks with no two requests coming from the same IP.
IP-range blocking has a bad reputation. This is a defense of it as deliberate triage: when to reach for it, how to scope it to avoid collateral damage, and how to make sure each block teaches your stack instead of just buying time.
The kernel's v3 reached production with 201 passing tests and a clean architecture. A non-technical user invalidated the interaction model in ten minutes.
The cheap detector said the site was under attack.
The uptime monitor fired on a 9 PM CPU spike. Everything pointed to hostile traffic. It was one cached plan in a request-log table doing clustered scans on every request, and one OPTION (RECOMPILE) settled it.
Per-session browser isolation was the right call. Per-session isolation with no reaper filled my system drive, froze the machine, and forced a reboot. The fix was a fixed pool.
Stats pages were broken across 314 sites. The cause was a shared recordset helper opening keyset ADO cursors over aggregate queries. The data caught up.
The ticket reopened the same day it closed. A broken admin redirect after new event creation turned into five separate failures across image persistence, custom sports, freeform dates, edit routing, and cart verification, each hiding behind the last.
A new exit-feedback page shipped cleanly. The provisioning script had already silently clobbered a scheduled digest mailer row that had been live for months.
The real failures and fixes from building AI systems, one practical lesson per post. Get the next one in your inbox.