Your support team should be writing code

I shipped a small search fix. Search was looking inside each record’s ID, a long string of letters and numbers, and treating a partial match as a result. A few characters could bring back records that had nothing to do with what someone was looking for.

The change was to require an exact match when searching by ID. An engineer reviewed and approved the pull request, and I merged it.

There wasn’t much code to change. The useful part was following the behavior far enough to explain why those records appeared, then taking the fix through review. I could do more than file a ticket describing search as confusing.

Taking an investigation into the code

Support spends a lot of time understanding a problem well enough to help the customer in front of us. We reproduce it, look at the relevant data, and work out what they can do while it’s unresolved.

With code access, that investigation can sometimes continue into a proposed fix. The code owner has something concrete to evaluate, along with the reproduction and diagnosis.

They still have work to do. A small diff can change behavior in places I haven’t considered. They can ask for changes, want more testing, or prefer to solve the problem somewhere else. Preparing a pull request doesn’t settle those questions.

A later floorplan performance issue made that especially clear.

A smaller fix after review

A support engineer filed a ticket about a customer’s slow floorplan page. I had a pull request up that afternoon.

The page was making a separate request for each camera when it could fetch that information together. I changed it to batch the requests and cache repeated lookups. My initial proposal also included changes to how the page redrew as someone moved around the floorplan.

The engineer who owned the page found the main bottleneck: the uploaded floorplan was an unusually complicated vector file. The browser had a huge number of individual shapes to render. The request pattern was wasteful, but fixing it wasn’t going to explain or solve all of the slowness.

The reviewer also wanted more testing before taking the riskier rendering changes. I split those out so the smaller request and caching change could move forward on its own. That version merged. The separate rendering changes didn’t ship.

The customer ended up with a simpler floorplan file, and we shipped the request and caching changes. Support and the partner reported that the page felt much better. There were several changes involved in getting there.

The review changed what shipped. I had found something worth changing, and the engineer responsible for the page helped narrow the fix while identifying the larger cause.

Where the agent helps

Coding agents have made this kind of work more approachable for me. I can ask one to find where a function is used, follow data through an unfamiliar part of the application, or explain an existing test. That gives me a way to keep going when I’d otherwise be stuck learning the codebase.

I still have to understand the result well enough to evaluate it. An agent can make a convincing change to the wrong part of the problem. The floorplan investigation is a good reminder to keep checking what is actually making the customer’s experience worse.

Getting support codebase access gave us a way to contribute this work through the existing review process. It also made the handoff more useful: engineering could review a proposed change rather than start every investigation again.

The search fix was small and landed after approval. The floorplan fix got smaller during review. In both cases, I could stay involved through the change instead of ending my part at the bug report.