It’s Monday morning. There’s a message from the tester in Teams: “Registration is returning a 500 since the last deployment.”

You open the logs and see a NullReferenceException with a stacktrace three layers deep. Somewhere in the validation logic of the RegistrationService. A PR was merged Friday afternoon that extended the registration flow with a company name field. Tests were green. But in production, things are broken.

Now the detective work begins.

The old way

You open the stacktrace and start opening files. RegistrationService.cs — 200 lines. RegisterUserCommand.cs — the request model. RegisterUserValidator.cs — the FluentValidation rules. UserMappingProfile.cs — the AutoMapper config.

You read, scroll, compare. After twenty minutes you have a hunch. You open ChatGPT, copy the relevant code snippets — three messages, because it doesn’t fit in one — and ask: “Can you see what’s going wrong here?”

ChatGPT says: “It looks like a null check is missing. Try adding a null-coalescing operator.” Technically not wrong, but it’s a band-aid. The real cause is somewhere else.

After an hour you’ve found it. The new CompanyName field is in the command, but not in the AutoMapper profile. The mapping fails silently, the validator receives an unexpected null object, and throws an exception.

With Claude Code

Same bug. Different approach.

You open your terminal in the project and start Claude Code. You paste the stacktrace and say:

“The registration endpoint is returning a 500 after the last deployment. Here’s the exception.”

That’s it. No copying files, no building context. Claude Code takes it from here.

It reads the code itself

Claude Code follows the stacktrace like a map. It opens RegistrationService.cs and sees where the exception originates. It reads RegisterUserValidator.cs and sees that the validator expects a property that’s null. It opens UserMappingProfile.cs and finds the problem: the new CompanyName field is missing from the mapping.

No generic advice about null checks. The actual root cause, found by reading the code — not by guessing.

It fixes and verifies

Claude Code proposes the fix: extend the mapping in UserMappingProfile.cs.

CreateMap<RegisterUserCommand, User>()
    .ForMember(dest => dest.Email, opt => opt.MapFrom(src => src.Email))
    .ForMember(dest => dest.Name, opt => opt.MapFrom(src => src.Name))
    .ForMember(dest => dest.CompanyName, opt => opt.MapFrom(src => src.CompanyName));

After your approval, it modifies the code and runs dotnet build. Compiles. Then dotnet test. All tests green — including the existing registration tests that now also cover the new field.

If the class you’re fixing has no tests at all, this is the moment to let Claude write the first ones. A fix you can’t re-run is a fix that comes back.

It’s 9:15 AM.

Why this is faster

The difference isn’t in the fix itself. The fix is one line. The difference is in everything that comes before it.

With the old way, you spend most of your time gathering context. Opening files, reading code, connecting the dots, copying relevant snippets into a chat window. That’s the tedious, time-consuming part — and exactly the part Claude Code eliminates.

Claude Code reads your codebase. It follows the stacktrace through your files, from endpoint to service to mapping. It doesn’t need to guess which files are relevant, because it can simply open them. And because it knows your entire project — especially if you have a good CLAUDE.md file — it also understands how your team does things.

When it doesn’t work

Let’s be honest: Claude Code isn’t a silver bullet for every bug.

Bugs that originate outside the code — a wrong environment variable, a full database, a DNS change that hasn’t propagated yet — Claude Code can’t help much with those. It reads code, not infrastructure.

And some bugs are inherently difficult, even for AI. Race conditions, timing-related issues, bugs that only occur under specific load — those require a different kind of investigation than reading code.

The rule of thumb I follow: if the cause is in the code, Claude Code can find it. And that’s the vast majority of bugs you encounter as a developer.

Next stacktrace, try this

Next time production throws something at you, resist the reflex to start opening files. Open Claude Code in the repo, paste the exception, and say what the user was doing. Nothing more — no pointing at the file you suspect, no “I think it’s in the validation.”

Then read the first thing it says back. If it names a file you hadn’t opened yet and the reason holds up when you check it, you just skipped the twenty minutes you’d normally spend getting to that same sentence. If it comes back with something generic instead, your stacktrace didn’t carry enough — and that’s a logging problem, not an AI problem.

What stays yours either way is the last call: judging whether the fix is actually correct.