Every seven weeks or so, each engineer takes a week of support rotation at Aha! This last one, I caught myself doing something dumb.

A ticket came in. I clicked over to our production log viewer, narrowed the time range, started piecing together the request path so I could find the hit, pull the data, figure out what happened. Same thing I’ve been doing for years.

And it stopped me — wait. I’ve been using Claude with tools and skills for quite a while now. I’d already gotten into the habit of going straight to Claude with support tickets. That became obvious early on, once it started giving real results and not hallucinating. Of course you go straight to Claude now.

We don’t hand it customer data, to be clear. We pull pieces out of the ticket, generalize them, and describe the situation. No security gap. But the muscle memory is there: ticket comes in, open Claude, start describing.

So I’m sitting in that flow and it hits me — why am I taking all this time to fiddle with log filter date inputs? Claude should be linking me out to our log viewer when it knows we need data from there. It’s already reading the code and seeing the calls to our logger, so it can even ask me for account id and timeframe if it thinks we need to go spelunking there. I go back to the ticket, see the email came in at 10 o’clock, plug that in — here’s your filtered log viewer URL. That was the first win.

Then I kept pulling on it.

We’re a roadmap company. Over the past decade we’ve built up five or six production debugging tools — nothing fancy, just CLI and admin pages that encode a decade of “here’s how you actually debug this.” Claude doesn’t know they exist unless I tell it about them. So I wrote a production debugging skill and handed it all five.

Here’s what they are:

Log link generator. I give it a timeframe and what we’re looking for, it builds the pre-filtered log viewer URL based on the controller endpoints it’s reading. Before, I was manually fiddling with dropdowns every single time.

Config explorer. Our roadmap reports have really sophisticated configuration — custom fields, workflows, integrations. A huge chunk of support tickets are actually “this tenant configured something unusual.” This tool surfaces that without touching customer data.

Query analyzer. Explains and analyzes queries. When Claude has a hypothesis about what’s slow or wrong, it asks me to run this and paste back the results.

Record history viewer. Multi-tenant SaaS means records are changing constantly. “What happened to this record?” is the first question on many tickets. This pulls the audit trail for a single record — who changed what field, when.

Deployer console script generator. This one changed things the most. Before, if a ticket needed actual production Rails console work, the engineer would write something improvised and hand it to me — I’m one of a handful of deployers with production access. The scripts were all different shapes. Some would leak customer data in the output without the author realizing it. Since it’s mult-tenant, you have to set the current account and current user, and be intentional about what you expose. Some would have Rails log output interleaved with the actual result, so I’d have to pick through lines of STDOUT to find the thing I needed. Now Claude writes the script. It’s always tight. Always focused on metadata — IDs, timestamps, counts — never raw customer content columns. Always ends with one clean puts so the output is just the thing we needed. I’m not managing someone else’s script judgment anymore. I’m just running the thing and handing back the output.

So now when Claude is working through a ticket, it asks me to do these things. I go to the logs, copy-paste, hand it back. It asks for a config dump. I run the tool, hand it back. It asks me to check a query plan. Same thing. It asks for a record history. Same thing.

I’ve inverted the control. Now I’m the agent for Claude.

Kind of mind-blowing. But honestly — I’m a lot happier on support this way. I get to stay focused at the high level and eliminate the minutae.