Using AI to find the root cause

When I get a production bug, I don’t directly ask an LLM for the solution.

I used to feel that asking “fix this issue” should save time.

But in real production debugging, that can easily send you into a loop.

The model may suggest 5 different fixes, then another 5 fixes, and suddenly you are trying changes without really understanding the problem.

So now I use it differently.

First, I try to understand the issue myself.

I check the flow, logs, recent changes, data, API behavior, and where the issue is happening.

Since I have been handling the same codebase for years, I usually have some educated guesses about what could have gone wrong.

Then instead of asking: “Give me the solution”

I ask: “Based on this context, what could be the RCA?”

That changes the whole conversation.

The LLM starts giving possible root causes instead of jumping directly to fixes. Then I go through each possibility one by one.

Most of the time, not every suggestion is correct. Sometimes even 70% of the suggested fixes are not the actual issue.

But that is fine.

Because the goal is not to blindly accept the answer.

The goal is to use it to think faster.

I filter out weak possibilities, add more context, correct its assumptions, and keep narrowing the problem.

Once the root cause starts making sense with the actual code, logs, and data, then I move toward the fix.

This has helped me save both time and tokens.

More importantly, it has helped me avoid random trial-and-error debugging.

Treat LLMs as assistants, not owners of the problem.

For production issues, the engineer still needs to understand the system, verify the assumptions, and take responsibility for the fix.

AI can speed up debugging.

But only if we ask better questions.