On April 21, hotfix/3.346.1 and hotfix/3.346.2 both merged back into develop. Same day. That is rarely a good sign.
The three tickets were ITEM-6831, ITEM-6833, and ITEM-6834. Customer-facing failures across registration, schedule management, and package deploys. Not related in any obvious way. Not one bug. Three bugs in a trench coat, presenting as a single person.
the payment data had been wrong for a while
ITEM-6831 was a PayPal IPN bug. Payments were landing, the money was arriving, but registrations were staying in Unconfirmed status. Teams were showing up on the roster as pending. Nobody was screaming loudly enough, which is the most dangerous kind of data problem.
The fix was two parts. First, the inbound IPN handler needed to repair the status automatically on any successful payment, so future payments self-heal without intervention. Second, there was already a pile of stranded rows in production with the wrong status. Those needed a bulk cleanup tool with an admin interface, a confirmation step, and a dry-run mode to walk back the damage.
That second part is the honest part of the fix. A code change that only addresses the forward path is not a fix. It is a policy update that leaves the crime scene intact.
the scope was wrong from the beginning
ITEM-6833 presented as “bulk delete doesn’t work from org accounts.” I thought this was a permissions bug. It was not.
The code was invoking the server-side delete endpoint while passing an org-level scope. The endpoint does not accept that. It expects a league or team. The code was supposed to walk orgNodes down to the child scope before making the call, and it was not doing that. Every bulk delete from an org context was silently wrong. Not dramatic. Just quietly doing nothing.
The symptom hides the shape here. “Delete doesn’t work” is what the user reports. “We never resolved the scope correctly for this caller class” is what the code reveals. Those are different bugs with different fixes and different test coverage requirements.
Claude did the codebase archaeology. The ASP stack is 25 years old. Finding where orgNodes was being constructed, tracing the call path to the delete endpoint, confirming which scope fields the endpoint actually validated: that is the kind of work that takes twenty minutes of careful reading or two hours of guessing. The agent did the reading. I checked the model.
the deploy would have re-broken it
ITEM-6834 was subtler. Package deploys were referencing assets via raw /src paths in ASP. That means any in-flight edit during a deploy could touch a live customer mid-page-load. The fix was to compile dated copies of the JS and CSS, then update the ASP references to point at those versioned files instead of the source tree.
The bug is not really fixed until the deploy mechanics cannot re-introduce it. A logic fix is necessary but not sufficient when the environmental conditions that produced the bug are still in place. I have caught myself making this mistake before in other forms. This was the version of it for assets.
the ugly days are where pairing earns its keep
Most AI coding demos show a greenfield project. Clean schema, clear spec, no legacy. The agent writes the scaffold, you fill in the business logic, you ship. April 21 was not that.
April 21 was branch juggling across hto, hto2, hto3, and the mirror repos. It was ASP files that have been accumulating edge cases since before I owned the business. Two hotfix branches, one after the other, both merged to develop the same day. Context switching between a data-repair problem, a scope-resolution problem, and a deploy-hygiene problem. None of them shared any code.
That is where the agent earns its keep. Not on the elegant problem. On the exhausting one. It holds context across the branch topology, surfaces the exact file and line that matters, tracks which fixes touched which repo, and does not make the mistake of treating three unrelated bugs as one.
I still carry the mental model. The agent does not know that the org-level caller has always been slightly wrong, or that the PayPal IPN handler has a history of silent failures, or that the asset pipeline has been sloppy since the last deploy refactor. That knowledge does not compress. But with the agent handling the legwork, a day that used to cost a full day of context thrash plus a vague worry that something was missed comes in around half a day, with receipts.
AI pairing earns its keep on the days when a single production bug is really three bugs in a trench coat: bad data, wrong scope, and deploy mechanics that would have undone the fix by Tuesday.