Closing the Loop: Let Support Ship Small Bug Fixes

A page almost nobody used had gotten slow. The code was doing work proportional to the square of the data even though one pass would have been enough. It was easy to miss at first, then got worse as the data grew.

The bug affected too few customers to compete with engineering’s roadmap.

A support engineer with access to the codebase used an agent to trace the cause and write a fix. In about an hour, they had a patch ready for engineering to review. The same investigation used to take an afternoon that nobody could justify spending on this page. At the time, codebase access still wasn’t standard across the team.

Why this bug sat

Support usually finds a bug, writes it up, and files a ticket. Engineering triages it with everything else.

That works for urgent bugs. Plenty of medium-priority bugs get fixed eventually too. At the bottom of the backlog, the answer is usually “not now.” The customer gets a workaround and the ticket stays where it is.

Filing the ticket wasn’t the problem. There just wasn’t any engineering time for it.

What changed when support brought a PR

The usual request sounds like this:

We found a bug. Can you reproduce it, find the cause, write a fix, test it, and ship it?

For a low-priority bug, that is easy to defer.

The new request was:

We found a bug. Here is the reproduction, the cause, and a PR with a test. Can you review it?

The PR still goes through normal engineering review. The code owner can reject the approach, ask for changes, or decide the fix is riskier than it looks. Tests still need to pass. Support doesn’t need production access or a shortcut around the contributor workflow.

What the agent was useful for

Technical support people could submit fixes before agentic coding. A few did. The slow part was learning an unfamiliar codebase well enough to find the right code and change it safely.

An agent can find callers, trace the data, explain an existing test, and draft a patch. The person driving still has to decide whether the diagnosis is right.

That requires understanding the symptom and the expected behavior. The support engineer needs to read a stack trace, query the data, and tell user error from a product bug. Otherwise the agent can write a convincing patch for the wrong problem.

The search bug

One search bug returned unrelated records while a customer typed. “Search is weird” was the visible symptom. The query was also matching UUID fields, so a few keystrokes could collide with the hexadecimal characters in a record ID.

A support engineer who can follow that query can give engineering a precise reproduction and diagnosis. With code access and normal review, they may be able to write the fix too.

Some companies can stop there. A useful diagnosis may be enough, even if support never ships PRs.

For teams that want to go farther, the setup can stay boring: a local checkout, tests, and the same PR review everybody else gets. Support does the investigation and drafts the patch, then the code owner decides whether it ships.