Winfred Wolfgram · 2026-06-22 · ai, engineering

I'm the agent for Claude now

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

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

Then I stopped.

I have been using Claude with tools and skills for a while. So I had already built the habit of going straight to Claude with support tickets — once it started producing real results instead of hallucinations, that became the obvious place to begin.

We do not hand Claude customer data. 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.

I was sitting in that flow when it hit me. Why am I still spending time fiddling with date filters in the log viewer? Claude should be linking me out to the log viewer when it knows we need data from there. It already reads the code and sees the calls to our logger, so it can even ask me for the account ID and time frame if it thinks we need to go spelunking there. I went back to the ticket, saw the email had come in at 10 o'clock, plugged that in, and got exactly what I needed: a filtered log viewer URL. That was the first win.

I kept pulling on the idea.

We are a roadmap company. Over the past decade, we have built up a few production debugging tools — nothing flashy, just CLI tools and admin pages that encode a decade of hard-won debugging knowledge. Claude does not know they exist unless I tell it about them. So I wrote a production debugging skill and gave it all five.

Here is what they are:

1. Log link generator

I give Claude a time frame and what we are looking for, and it builds a pre-filtered log viewer URL based on the controller endpoints it is reading. Before, I manually fiddled with dropdowns every single time.

2. Config explorer

Our roadmap reports have sophisticated configurations, including custom fields, workflows, and integrations. A huge chunk of support tickets are really cases where a tenant configured something unusual. This tool surfaces that without touching customer data.

3. Query analyzer

This explains and analyzes queries. When Claude has a hypothesis about what is slow or broken, it asks me to run this and paste back the results.

4. Record history viewer

Records change constantly in a multitenant SaaS product. "What happened to this record?" is the first question on many tickets. This pulls the audit trail for a single record, showing who changed what field and when.

5. 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 am 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. Because it is a multitenant system, you have to set the current account and user and be intentional about what you expose. Some would have Rails log output interleaved with the actual result, so I would have to pick through lines of stdout to find the thing I needed.

Now, Claude writes the script. It is always tight. Always focused on metadata — IDs, timestamps, counts — never raw customer content columns. It always ends with one clean puts, so the output is just the thing we needed. I am not managing someone else's script judgment anymore. I am just running the thing and handing back the output.

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

I have inverted the control. I am the agent for Claude now.

It is kind of mind-blowing. But honestly, I am a lot happier on support this way. I get to stay focused at a higher level and eliminate the minutiae.


Learn more about how we've streamlined engineering work at Aha!

Winfred Wolfgram

Winfred Wolfgram

Winfred is a product engineer generalist who enjoys jumping from business to UX to analytics to code. He is an Engineering Lead at Aha! — the world's #1 product management software. Previously, he was an engineer at Hired.com where he helped developers find jobs they love. Read why Winfred joined Aha!

Build what matters. Try Aha! free for 30 days.