ProductOS

The AI Debugging Prompt Pack: 20 Prompts to Find Bugs

By Shreyash Singh·14 min read·AI Engineering in Production

Most debugging sessions start with a symptom. The ones that end fast start with a hypothesis.

⏱️ Read time: 14 minutes. Use time: every time something breaks.


Why This Exists

Something is broken. You don't know where. You've been staring at it for 45 minutes, and you've already tried the first three things that came to mind. This is where most developers and PMs lose hours they didn't have.

The problem isn't intelligence. It's process. Debugging without structure is just guessing with extra steps. You isolate the wrong layer, fix the wrong thing, and introduce a new bug while closing the first one. The cycle continues.

Teams that debug well do something different. They form a hypothesis first. They ask what changed before they ask what's wrong. They use AI not as an answer machine but as a thinking partner that forces them to articulate the problem clearly. Articulating a bug clearly is often 60% of solving it.

This prompt pack is the structure you reach for when something goes sideways. It covers bug diagnosis, root cause analysis, regression tracing, error interpretation, and the conversations you need to have with AI tools to stop guessing and start finding.


How to Use This

  1. Match the prompt to the phase you're in. Prompts 1-5 are for orientation ("what is even happening"). Prompts 6-11 are for diagnosis ("where is the bug"). Prompts 12-16 are for root cause and fix. Prompts 17-20 are for preventing it from happening again.
  2. Paste your actual code, error, or log. These prompts are skeletons. They only work when you fill in the brackets with real context. Vague inputs return vague outputs.
  3. Use the output as a hypothesis, not a verdict. AI will suggest a cause. Your job is to test it, not just apply it.
  4. Run prompts sequentially when stuck. If prompt 1 doesn't resolve it, move to prompt 2. The pack is designed to narrow the problem progressively.

The 20 Prompts 🔍

Phase 1: Orientation (Prompts 1-5)

Use these when you don't fully understand what's broken yet.


Prompt 1: The First Description

When you can't even articulate the bug clearly, start here. Forcing language onto a problem exposes assumptions.

Open Prompt 1
I'm going to describe a bug I'm seeing. I want you to do two things:
1. Restate the bug back to me in precise technical language.
2. List the 3 most likely root cause categories based on my description.

Here's what I'm observing: [describe the symptom, what you expected vs. what happened, and when it started]

Don't suggest fixes yet. I want to understand the problem better before jumping to solutions.

Prompt 2: The Error Message Translator

Error messages are written for compilers, not humans. Use this when you have an error but don't know what it's actually telling you.

Open Prompt 2
Here's an error message I'm seeing:

[paste full error message and stack trace]

Explain this error in plain English. Tell me:
1. What went wrong (in one sentence a non-expert could follow)
2. What the most likely cause is
3. What layer of the stack this is happening in (database, API, frontend, auth, etc.)
4. What I should look at first

My tech stack is: [list your stack]

Prompt 3: The Before/After Diff

Most bugs have a birthday. Something changed. This prompt finds it.

Open Prompt 3
Something broke. I need to figure out what changed that caused it.

Here's what I know:
- It was working as of: [date/deployment/commit]
- It stopped working when: [date/deployment/commit, or "I don't know"]
- What changed between those two points (that I know of): [list changes, or "unknown"]
- The symptom: [describe what's broken]

What questions should I be asking to isolate what change caused this? And based on what I've told you, what's your best hypothesis about the source?

Prompt 4: The Reproduction Steps Tightener

If you can reproduce a bug consistently, you can fix it. This prompt helps you build a clean reproduction path.

Open Prompt 4
I'm trying to reproduce a bug reliably. Here are the steps I currently use to reproduce it:

[list your current reproduction steps]

The bug: [describe]
How consistently it reproduces: [always / sometimes / rarely]
Conditions where it seems worse or better: [describe, or "unknown"]

Help me:
1. Tighten these reproduction steps to the minimum needed
2. Identify variables I should control or isolate
3. Suggest conditions that might make this reproduce more consistently

Prompt 5: The Scope Narrower

When the bug could be anywhere, this prompt cuts the search space in half.

Open Prompt 5
I have a bug and I'm not sure which layer it's in. Here's what I know:

Symptom: [describe]
Stack: [frontend / backend / database / auth / third-party API / other]
What I've already ruled out: [list]
What I haven't checked yet: [list, or "I don't know where to start"]

Give me a systematic checklist, ordered by likelihood, of where to look first. For each item, tell me how to confirm or rule it out quickly.

Phase 2: Diagnosis (Prompts 6-11)

Use these when you know roughly where the bug lives but not exactly what it is.


Prompt 6: The Code Reviewer

You suspect a specific function or block. This prompt gives it a proper examination.

Open Prompt 6
I suspect this code is causing a bug. Review it and tell me:
1. Any logic errors you can see
2. Edge cases this doesn't handle
3. Assumptions this code makes that might not hold
4. Any conditions under which this would fail silently

The bug I'm seeing: [describe symptom]
Expected behavior: [describe]

Code:
[paste code block]

Prompt 7: The Log Interpreter

Logs tell a story. Most people read them looking for the obvious. This prompt reads between the lines.

Open Prompt 7
Here are logs from around the time the bug occurred. I want you to:
1. Identify the sequence of events leading up to the failure
2. Highlight any anomalies even if they don't look like errors
3. Tell me what's missing that should be there (missing log entries can be as telling as errors)
4. Give me your best hypothesis about what caused the failure

Logs:
[paste logs]

Context: [describe what the system was doing, what the expected flow is]

Prompt 8: The API Debugger

When the problem is at the boundary between your code and an external service.

Open Prompt 8
I'm debugging an issue with an API call. Here's everything I have:

Request:
[paste request, including headers if relevant, with sensitive keys redacted]

Response:
[paste response or error]

Expected behavior: [describe]
Actual behavior: [describe]

Tell me:
1. Is the request malformed in any way?
2. Does the response indicate a server-side problem or a client-side problem?
3. What should I check next?
4. Are there common gotchas with this type of API call I might be missing?

Prompt 9: The State Trace

For bugs that only happen after a sequence of actions, state is usually the culprit.

Open Prompt 9
I have a bug that seems to depend on application state. It only happens under certain conditions, not all the time.

Here's what I know:
- When it happens: [describe triggering conditions]
- When it doesn't happen: [describe conditions where it works fine]
- Relevant state at the time of failure: [paste or describe state/variables]
- What the code expects the state to be: [describe]

Walk me through how state could cause this discrepancy. What state mutations should I trace? What's the most likely state-related cause?

Prompt 10: The Race Condition Hunter

Timing bugs are the hardest to catch. Use this when the bug is intermittent and order-dependent.

Open Prompt 10
I have an intermittent bug that I suspect might be a race condition or timing issue.

Symptoms: [describe, including how often it happens]
Relevant code (async operations, event handlers, concurrent processes): [paste]
Environment: [describe: serverless, multi-threaded, single-threaded, browser, etc.]

Help me:
1. Evaluate whether this is likely a race condition
2. Identify the specific points where timing could cause this
3. Suggest how to test the hypothesis
4. If it is a race condition, what are the standard approaches to resolve it?

Prompt 11: The Data Bug Finder

When the bug isn't in the code but in what the code is receiving.

Open Prompt 11
I think I'm dealing with a data bug. The code looks right, but the output is wrong.

Here's a sample of the input data: [paste sample]
Here's what the code produces: [paste output]
Here's what it should produce: [describe]
The transformation logic: [paste code or describe]

Help me figure out:
1. Is the input data well-formed or does it have issues?
2. Are there specific data values or shapes that would cause this code to fail?
3. Where should I add validation or normalization?

Phase 3: Root Cause and Fix (Prompts 12-16)

Use these when you've located the bug and need to understand it deeply before fixing it.


Prompt 12: The Five Whys Driver

Surface fixes fix surface symptoms. This prompt pushes to the actual cause.

Open Prompt 12
I found a bug. I want to understand the root cause before I fix it, because I don't want to create a new bug or fix the same thing in six places.

The bug: [describe]
The immediate cause I found: [describe what you found]
The fix I'm considering: [describe]

Run a five-whys analysis with me. Start from the immediate cause and help me trace it back to the root. For each layer, tell me what question to ask next.

Prompt 13: The Fix Evaluator

You have a fix in mind. Before you apply it, pressure-test it.

Open Prompt 13
I have a fix for a bug. Before I apply it, I want to pressure-test it.

The bug: [describe]
My proposed fix: [paste code or describe approach]

Tell me:
1. Does this fix the root cause or just the symptom?
2. What edge cases could this fix break?
3. Are there other places in the codebase where the same bug might exist?
4. What's the safest way to apply this change?
5. What should my test cases cover to validate this fix?

Prompt 14: The Side Effect Scanner

Every fix changes something. This prompt finds what else that change might touch.

Open Prompt 14
I'm about to make this change to fix a bug:

[paste the change you're making]

Context on the system: [describe what this code does, what depends on it]

Before I apply it, help me identify:
1. What else could this change affect?
2. What assumptions does this change make that other parts of the system might violate?
3. What should I test beyond just the bug I fixed?
4. Is there a safer, more targeted way to make this change?

Prompt 15: The Minimal Fix Builder

Sometimes you write a 40-line fix when a 3-line fix would do. This prompt finds the smallest safe change.

Open Prompt 15
I have a fix that works, but I think it's more complex than it needs to be.

The bug: [describe]
My current fix: [paste code]

Help me find the minimal change that resolves this bug correctly. I want:
1. The smallest change with the fewest side effects
2. No loss of correctness
3. A brief explanation of why the simpler version is sufficient

Prompt 16: The Regression Test Writer

A bug you've fixed once should never come back. This prompt turns your fix into a test.

Open Prompt 16
I just fixed a bug. I want to write a regression test so it never ships again undetected.

The bug: [describe]
The fix: [paste]
My testing framework: [describe]

Write a regression test that:
1. Would have caught this bug before the fix
2. Confirms the fix is working correctly
3. Covers the edge cases around this bug
4. Is isolated enough to run fast

Phase 4: Prevention (Prompts 17-20)

Use these after the fix to make your codebase harder to break.


Prompt 17: The Post-Mortem Generator

If a bug was bad enough to cost real time, write it up. This prompt makes post-mortems fast and useful.

Open Prompt 17
I just resolved a significant bug. Help me write a short, useful post-mortem.

The bug: [describe]
How it was found: [describe]
Time to resolve: [duration]
Impact: [describe: users affected, features down, data issues, etc.]
Root cause: [what you found]
The fix: [describe]

Structure this as:
1. What happened (2-3 sentences)
2. Why it happened (root cause, not just the immediate cause)
3. How we found it
4. What we fixed
5. What we're changing to prevent recurrence

Keep it under one page. Make it useful for someone who wasn't involved.

Prompt 18: The Error Handling Auditor

Most bugs that go undetected do so because error handling was too loose. This prompt finds the gaps.

Open Prompt 18
I want to audit this code for error handling gaps.

[paste code]

Tell me:
1. Which errors or exceptions could occur here that aren't currently caught?
2. Where is failure silent when it should be loud?
3. Where is failure loud when a graceful fallback would be better?
4. What logging should be added to make future debugging faster?
5. What's the most dangerous failure mode here?

Prompt 19: The Input Validation Hardener

A surprising number of bugs come from code that trusts inputs it shouldn't. Use this to find the gaps.

Open Prompt 19
I want to harden this code against bad inputs.

[paste function or module]

It currently receives: [describe what inputs it gets and from where]
It currently validates: [describe any existing validation]

Help me:
1. List every input assumption this code makes
2. Identify which assumptions could be violated in production
3. Suggest validation logic for the riskiest inputs
4. Flag any inputs where failing loudly is better than a silent default

Prompt 20: The Bug Pattern Spotter

After fixing a bug, the same pattern often exists elsewhere. This prompt finds it.

Open Prompt 20
I just fixed a bug and I want to find every other place the same pattern is hiding.

The bug I fixed: [describe the symptom]
The root cause: [describe the underlying pattern, not the specific line]
The fix: [paste]
My codebase: [describe stack, rough size, and how it's organized]

Help me:
1. Describe the abstract pattern behind this bug, independent of the file it happened in
2. Give me specific search terms, grep patterns, or structural signatures to find other instances
3. List the places in a codebase like mine where this pattern usually hides
4. Rank what you find by blast radius, so I fix the dangerous ones first
5. Suggest a lint rule, type change, or convention that would make this whole class of bug impossible going forward

Why We Built This

At ProductOS, we think the expensive part of debugging isn't the fix. It's the 45 minutes of guessing before you have a hypothesis worth testing. Every prompt here exists to shorten that gap by making you say the problem out loud, precisely, before you touch the code.

This pack is one slice of a larger idea. The context behind a product decision should still be there when the thing you built breaks. Most teams lose it somewhere between the spec and the stack trace, and debugging becomes archaeology. It doesn't have to be.

If any of this lands and you want to see it in action, we're at productos.dev. No pressure. The pack stands on its own.

If you'd rather have humans plus AI run this for you on a real product today, that's what 1Labs AI does.


Built by Heemang Parmar, Founder & CEO of ProductOS. 10+ years in product, 150+ builds. Also runs 1Labs AI, an AI product development agency.