The Wrong Way to Use AI for Debugging (And the Mental Model That Actually Works)

Same AI tool. Same codebase access. Same staging incident. Three experienced engineers spent hours and couldn't find the root cause. I found it in about 20 minutes — and I barely knew what half the tools did.

This isn't a story about juniors being better than seniors. It's about a mental model for AI collaboration that anyone can use — and why the "obvious" way most people use AI actually holds them back.

The Incident

A message hits the team Slack channel:

"Staging is broken. We're investigating."

The error:

alembic current ERROR: Can't locate revision identified by 'ba29cdc8739d' FAILED: Can't locate revision identified by 'ba29cdc8739d'

alembic current ERROR: Can't locate revision identified by 'ba29cdc8739d' FAILED: Can't locate revision identified by 'ba29cdc8739d'

Enter fullscreen mode

Exit fullscreen mode

For context: Alembic is a database migration tool for Python. Every migration has a unique revision ID. The staging database thought it was on a revision that didn't exist in the codebase. Someone had run a migration from code that was never merged.

How the Investigation Went — The Usual Way

Three experienced engineers jumped on it. They had full access to everything — cloud console, audit logs, staging servers, the database. They also all used Claude.

Engineer A told Claude to check audit logs for FetchCredential calls — looking for who fetched the database password recently. Nothing unusual. Only the application's own containers had accessed the credentials.

Engineer B checked the staging server for evidence of someone checking out the wrong branch. Nothing.

Engineer C asked Claude to trace the revision through git history. Claude found it had been renamed in a later commit and concluded the rename caused the issue. This was wrong — the rename happened after the problem started. But it sounded plausible, so it consumed investigation time.

This is worth pausing on. Engineer C's Claude gave a confidently wrong answer, and it ate up time. This is exactly what the Harvard/BCG "Jagged Frontier" study warns about — AI users can perform worse than non-AI users when they trust plausible-sounding but incorrect AI output.

After a few hours: "We know what broke, but we can't figure out who did it or when."

How I Investigated — A Different Way

I'm a backend engineer with about 11 months of experience. I genuinely don't know how audit logs work. I couldn't tell you what an application container is. Here's what happened:

I told Claude: "Staging is broken, can you look into it? Pull the latest release branch and check."

That's it. No specific method. No "check audit logs." I didn't know what to check.

Claude confirmed the revision didn't exist on any main branch. It traced git history and found it only existed on one feature branch. It checked who had commits on that branch — one developer.

Then it hit the same walls everyone else did:

• SSH into the staging server → connection failed (IP had changed)

• Cloud logs → auth token expired

• Managed PostgreSQL logs → couldn't find the revision ID in any log file

Dead end. Same place the other engineers were stuck.

The Moment That Changed Everything

I said:

"Is there a smarter way to find this?"

One sentence. That's all it took.

Claude stopped looking for who accessed the system and started looking for what the migration left behind in the database itself.

It read the migration source code and noticed the INSERT statement used NOW() for the created_at column. That means the timestamp in the database isn't hardcoded — it's the exact moment the migration actually ran.

SELECT config_type, created_at FROM app_config WHERE config_type IN ('FeatureAlpha', 'FeatureBeta');

SELECT config_type, created_at FROM app_config WHERE config_type IN ('FeatureAlpha', 'FeatureBeta');

Enter fullscreen mode

Exit fullscreen mode

config_type | created_at -------------------+-------------------------------  FeatureAlpha | 2026-03-31 22:40:25.477889+00  FeatureBeta | 2026-03-31 22:40:25.477889+00

config_type | created_at -------------------+-------------------------------  FeatureAlpha | 2026-03-31 22:40:25.477889+00  FeatureBeta | 2026-03-31 22:40:25.477889+00

Enter fullscreen mode

Exit fullscreen mode

15:40:25 PDT on March 31st.

Then it checked the git log for that feature branch:

2026-03-31 15:41:20 -0700 — fix: rename migrations and split enum ALTER from seed INSERT

Enter fullscreen mode

Exit fullscreen mode

15:41:20 PDT — the commit that created that migration file. 55 seconds after it ran on the staging database.

Run migration → confirm it works → commit the code. And only one person had commits on the branch:

git log origin/develop..origin/feature/the-branch --format="%an" | sort -u

Enter fullscreen mode

Exit fullscreen mode

One name.

Why the Other Approaches Hit Dead Ends

Audit logs showed nothing because the developer likely had the database password cached in a local .env file from a previous session. No new FetchCredential API call = nothing in audit logs.

SSH logs showed nothing because the migration was run from a local machine connected directly to the database — not through the staging server.

The database itself held the answer the whole time. Nobody thought to ask it.

Two Mental Models for AI Collaboration

I want to be honest about something: this isn't a "framework" I invented. It's a pattern I noticed after the fact. And it might not work every time — this is one incident, not a controlled study. But I think the contrast is worth examining.

"Search this specific place"

Human: "Check audit logs for FetchCredential calls in the last 48 hours" AI: [runs the check] "No results found." Human: "OK..."

Human: "Check audit logs for FetchCredential calls in the last 48 hours" AI: [runs the check] "No results found." Human: "OK..."

Enter fullscreen mode

Exit fullscreen mode

The human picks the direction. The AI executes. When the direction is wrong, the investigation stalls — because the human has to come up with the next direction. Domain expertise can actually lock you in to familiar approaches.

"Find the answer, I don't care how"

Human: "Staging is broken, go look at it" AI: [investigates, hits wall] Human: "Is there a smarter way?" AI: [switches approach entirely — from access logs to database artifacts]

Human: "Staging is broken, go look at it" AI: [investigates, hits wall] Human: "Is there a smarter way?" AI: [switches approach entirely — from access logs to database artifacts]

Enter fullscreen mode

Exit fullscreen mode

The human sets the goal. The AI chooses the approach. When stuck, the human doesn't prescribe the next step — they push the AI to think differently.

The key difference isn't "vague is better than specific." It's about when you constrain the search space. If you lock into one investigation path too early — even a smart one — you might miss the angle that actually works.

A senior engineer who deliberately says "ignore what we've tried, what other evidence exists?" would achieve the same result. This isn't about experience level. It's about not anchoring too early.

The Honest Caveats

This is one incident. I don't know if this approach works consistently. Maybe I got lucky. Maybe the AI happened to know about NOW() timestamps and that's what made the pivot work. With a different bug signature, the same open-ended approach might have produced three more dead ends.

The senior engineers did valuable work. They systematically eliminated possibilities — wrong branch deployment, unauthorized access, CI pipeline issues. Their elimination narrowed the search space. I benefited from knowing what wasn't the cause.

"Not knowing" isn't universally an advantage. In this specific case, I couldn't over-specify because I didn't know the domain. But ignorance during incident response, when writing a fix, or in a post-mortem — that's a liability, not a feature. The narrow lesson is: when you have no strong hypothesis, keeping the AI's search space open is better than committing to a weak one.

The AI still did the technical work. Claude correlated timestamps, read migration source code, and ran git commands. That's precise, analytical work. The "open-ended" approach just meant I didn't prevent it from choosing which precise work to do.

The One Thing Worth Trying

If you're stuck debugging with AI and your current approach isn't working, try this before you give up:

Stop telling it where to look. Tell it what you need to know.

Instead of "check the logs for X" → try "we've checked A, B, C and found nothing. What other evidence might exist in the system?"

Instead of "grep for this function" → try "this endpoint is broken, investigate it."

It won't always work. But it costs you one sentence to try, and sometimes it unlocks an angle you wouldn't have thought of — because you literally couldn't have thought of it.

The breakthrough in my case took one sentence: "Is there a smarter way?"

That's not a philosophy. It's just a useful question.

The staging incident was resolved. The evidence was shared. The developer confirmed it was their machine.

And for the forensics nerds: if a migration uses NOW() in the INSERT, the created_at timestamp is your crime scene timestamp. Compare it with git log and you might find your 55-second smoking gun.