JIRA Said Shipped, Git Said Absolutely Not
A ticket marked Done had one of ten sub-branches on develop. Here is what I built after that discovery and why release workflow needs hard gates.
The build log
Notes from running agents in production.
Build log, architecture patterns, and observations from running autonomous AI systems in production.
-
-
Residential proxies broke my bot detector
A residential-proxy scrape from HVNABA got past every check I had. The real work was not another heuristic patch. It was writing a verdict schema before touching the detection code.
-
I built a weekly audit for my AI mistakes
My memory of where Claude sessions go wrong kept resetting every week. So I made the transcripts keep score instead.
-
You can't repoint a junction under live file handles (why I had to stage the .claude move)
My C: drive dropped to 230 MB free out of 231 GB, and one of the fattest things I could move off it was a 1.7 GB .claude directory full of transcripts and a chrome-debug profile.
-
Branch strategy should follow the change, not habit
A prod ship and a cache-header rollout forced the rule I'd been working around.
-
The phase contract stops the improvising
My agent system kept reinventing its own workflow rules mid-task. The fix was not another prompt. It was one canonical document that every reviewer and tool could point at.
-
Edit a label, get " back: the HTML-entity round-trip bug
A coach opens an edit dialog and the label field shows entity garbage instead of their text. Here is the decode/encode boundary problem behind it, the fix, and the one ordering detail that will burn you if you get careless.
-
develop was shipping the wrong work
A seven-commit lag in local master looked like noise. Clearing it revealed in-flight modernization work already merged into develop, waiting to ship. The real save was not the revert. It was finding it.
-
Three compounding bugs spawned a burst of near-identical tickets, and `tail -15` hid the evidence
Four near-identical JIRA tickets showed up seconds apart, with no human in the loop. My first guess was a flaky board or a double-submit somewhere. It wasn't either.
-
The Index Seek That Was Actually a Half-Table Scan (5000x, on a 4M-Row geoIP Table)
A SQL Server execution plan showed Index Seek. The same query was doing 8,000 logical reads. Here is what the operator name hides, and how a second covering index collapsed the worst case from 14,718 reads to 3.
Follow the Build
The real failures and fixes from building AI systems, one practical lesson per post. Get the next one in your inbox.