Debugging: From Stack Trace to Root Cause and Fix

Debugging is where AI can save the most time, and where it can do the most damage. A good AI-assisted debugging session finds the root cause in minutes. A bad one wraps the problem in a try/catch and moves on. The difference is the evidence you give it and the questions you ask.

Give it evidence, not just the error

A message like "NullReferenceException, help" invites a guess. Give the AI what you would give a senior colleague:

.NET 9 ASP.NET Core API, EF Core 9.
Error (full exception and stack trace):
"""
[paste]
"""
The method at the top of our code in the stack trace:
"""
[paste the method]
"""
What I know:
- It started after yesterday's deploy (diff of the relevant file below).
- It only happens for orders created through the mobile app.
- It does not happen locally.
[paste diff]

The stack trace tells it where. The code tells it what. "What changed" and "when it happens" are often the fastest route to why.

Ask for hypotheses, ranked

Instead of "fix this", ask:

List the 3 most likely root causes, ranked. For each, tell me what
evidence would confirm or rule it out, such as a log line, a breakpoint
or a query. Do not write a fix yet.

This keeps you in control. You test the top hypothesis, report back ("the customer is null for mobile orders because CustomerId is 0"), and the AI narrows down from real data.

Reproduce before you fix

Ask the AI to help you write the smallest reproduction:

Write an xUnit test that reproduces this bug: an order created with
CustomerId = 0 should make OrderService.CreateAsync throw an
ArgumentException, but currently causes a NullReferenceException later.

A failing test proves you understand the bug, and it stays in the suite so the bug cannot come back silently.

Watch for symptom fixes

Be suspicious of AI fixes that:

• wrap code in try/catch and log or swallow the exception
• add ?. or ! to silence a null warning without asking why it is null
• add a retry or a delay to make a timing problem "go away"
• change a test's expected value so it passes

Ask directly:

Does your fix address the root cause or only the symptom? What would
still be wrong if we shipped it?

Common .NET problems AI is good at spotting

• NullReferenceException from an EF navigation property that was not loaded (missing Include, or lazy loading not enabled)
• InvalidOperationException: A second operation was started on this context instance from concurrent use of one DbContext
• Deadlocks from .Result or .Wait() on async code
• ObjectDisposedException from using a scoped service after the request ended, for example in a fire-and-forget task
• Time zone bugs from mixing DateTime.Now and DateTime.UtcNow

Ask "Could this be one of the common causes of this exception in ASP.NET Core?" and give it the code to check.

Using logs

Paste the relevant log lines with secrets and personal data removed: tokens, connection strings, emails and customer names. Ask:

Here are the logs around the failure. Build a timeline of what happened,
and point out anything unusual just before the error.

After the fix

• Run the reproduction test and the full test suite.
• Ask the AI: "Where else in this code could the same bug exist?" and check those places.
• Write a short note in the pull request: cause, fix, how it was verified.

Practice task

Take a bug you fixed recently (or introduce one on purpose in a branch). Give the AI only the exception message first, then the full evidence package. Compare the quality of the two answers. Write a failing test for the bug before applying the fix.

Key takeaways

• Give the full exception, the relevant code, what changed and when it happens.
• Ask for ranked hypotheses with ways to confirm each, not an immediate fix.
• Reproduce with a failing test before fixing.
• Reject fixes that only hide symptoms, and look for the same bug elsewhere.