TL;DR: 30 AI prompts for debugging, organized by stage: reading a stack trace, reproducing it reliably, bisecting the change that caused it, forming a falsifiable hypothesis, and eight more stages through to the post-mortem. Every prompt requires the model to state its hypothesis and the evidence that would disprove it before proposing a fix.
What makes an AI debugging prompt actually work, instead of just guessing?
Paste an error message into a chat window and ask what's wrong, and you'll get an answer almost immediately — confident, fluent, and quite often for the wrong bug. A language model has no built-in way to distinguish "I can see this is the cause" from "this is the most common cause of errors that look like this," and nothing in its output signals which one you got.
Every prompt below does one thing differently: it requires the model to state a hypothesis and name the evidence that would prove it wrong, before proposing a fix. That costs nothing extra to paste, and it buys you the ability to tell "I found it" from "this is my best guess." If you already know our 35 AI prompts for code review, debugging, and refactoring, think of this as the deep end of just its debugging pass: thirty prompts, one per stage, from a raw stack trace to a written post-mortem.
What's the right first prompt when you're staring at a stack trace?
Read the whole trace before you read the error message. The line where the exception was thrown is often just where the bad state finally became visible — the actual bug is frequently several frames up, in whatever passed the wrong value in or called something out of order.
1. Decode the stack trace before touching any code
Use when you have a trace and no idea yet which frame is worth investigating.
Role: Engineer reading a stack trace for the first time, before writing any fix.
Context
- Error message: [PASTE VERBATIM]
- Full stack trace: [PASTE THE WHOLE THING, every frame]
- Language/runtime/framework: [and versions]
- What you were doing when it happened: [the action, request, or command]
Task
Walk the trace from the top frame down and explain what each frame tells us,
without proposing a fix yet.
Rules
- Say which frame is "where it broke" (the throw) versus which frame is
"where it went wrong" (the frame that likely passed bad state or called
something incorrectly) — these are often different frames.
- Mark every frame from a library or framework as "not our code" and don't
speculate about bugs inside it unless the trace gives specific evidence.
- Say what additional information (a variable's value, a preceding log line)
would confirm or rule out each candidate frame.
- Do not propose a fix. That's a separate step.
Output
Frame-by-frame read · most likely originating frame, with reasoning ·
what to paste next to confirm it.
2. Find the frame that actually matters
Use when the trace is long and mostly framework noise, and you need to know where in your own code to look.
Role: Engineer separating your code from the framework's code in a trace.
Context
- Full stack trace: [PASTE IT]
- Your code's file/module naming pattern: [e.g. "src/app/*", "com.company.*"]
- Framework/library in use: [name and version]
Task
Identify the first frame, reading top-down, that is inside your own code.
Rules
- List every frame that belongs to the framework or a third-party library
and say why it's unlikely to be the fault, unless the trace gives a
specific reason to suspect it.
- For the first frame in your own code, say exactly what it was doing when
the exception propagated through it.
- If no frame is in your own code, say so explicitly rather than guessing at
one — that's a real, useful answer, not a failure.
Output
Frame classification (yours vs framework) · the frame to start investigating ·
what it was doing at the point of failure.
How do you get AI to help you reproduce a bug reliably?
Get the bug to happen on command before anything else — even an unreliable repro beats a report that says "sometimes."
3. Turn a one-off crash into a reliable repro
Use when the bug happened once (a bug report, a log, a monitoring event) and you need steps that trigger it again.
Role: Engineer building a reliable reproduction from a single occurrence.
Context
- What happened: [the error/report, one occurrence]
- Everything known about that occurrence: [user action, input, timing, environment]
- What you've tried to reproduce so far: [steps tried, and whether they worked]
- Relevant code path: [paste the function(s) involved, if known]
Task
Propose the smallest set of reproduction steps most likely to trigger this
again, ranked by how confident you are in each.
Rules
- Rank candidate repro steps by confidence and say what evidence supports
each ranking — don't present a list as if all options are equally likely.
- Call out any step that depends on timing, load, or a race, and flag it as
"may need several attempts" rather than presenting it as deterministic.
- If the known facts aren't enough to build a repro, say exactly what
additional detail would let you build one.
Output
Ranked repro attempts with confidence and reasoning · missing information
that would improve the ranking · a fallback step if the top guess fails.
4. Isolate the minimal reproduction
Use when you can already trigger the bug, but only inside a large, slow, or noisy setup.
Role: Engineer cutting a large reproduction down to the smallest one that
still fails.
Context
- Current repro steps: [paste them, even if slow or complicated]
- What you suspect is essential vs incidental: [your best guess, or "unsure"]
- Constraints: [framework, test harness, or data you're stuck with]
Task
Propose what to strip out of the current repro while keeping the failure.
Rules
- Propose removals one at a time, in the order you'd actually try them, not
as a single "remove everything unnecessary" instruction.
- For each proposed removal, state what you'd expect if that piece was
incidental (bug still happens) versus essential (bug stops) — this is the
falsifiable part.
- Stop suggesting removals once you'd be guessing rather than reasoning from
the code or behavior described.
Output
Ordered removal steps · expected result at each step · the point where
further isolation needs to be tested, not reasoned about.
5. Reproduce an environment-specific bug locally
Use when the bug shows up in one environment (staging, a teammate's machine, a specific OS) and not in yours.
Role: Engineer isolating what's actually different about the environment
where the bug reproduces.
Context
- Environment where it fails: [OS, runtime version, config, data]
- Environment where it doesn't: [same details]
- Error/behavior: [paste it]
- Known differences already checked: [list them, even if ruled out]
Task
List the environment differences most likely to explain the gap, ranked by
plausibility given what's already been ruled out.
Rules
- Don't re-suggest anything listed as already ruled out — treat that list as
binding, not as a starting point to re-derive.
- For each candidate difference, say what you'd expect to observe if it's
the actual cause, so it can be checked rather than assumed.
- Separate "difference that could plausibly cause this specific symptom"
from "difference that exists but probably isn't related" — list both,
labeled.
Output
Ranked candidate differences with the check for each · differences noted
but judged unrelated, and why.
How do you prompt AI to bisect the change that broke it?
Once you can reproduce it, the next question is what changed — a code diff, or the config flip and dependency bump people forget to list.
6. Find the commit that introduced the bug
Use when you know it used to work and now it doesn't, and you have a range of commits to search.
Role: Engineer running a manual bisect with AI narrating the reasoning.
Context
- Behavior when it worked: [describe or paste output/logs from a known-good state]
- Behavior now: [paste the error/output]
- Commit range to search: [oldest known-good SHA, newest known-bad SHA]
- Commits in range (messages, or diffs if short enough): [paste what you have]
Task
Rank the commits in this range by how likely each is to have caused the
regression, based only on what's in the diffs/messages provided.
Rules
- Base the ranking on what each commit actually touches relative to the
failing behavior, not on commit message tone or how "risky" a change
sounds in the abstract.
- Name the specific bisect step (which commit to test next) that narrows
the range fastest, not just a full ranked list.
- If nothing in the provided commits looks related, say that plainly
instead of picking the least-unlikely one and presenting it as a finding.
Output
Ranked suspects with reasoning tied to the diff · the next commit to test to
bisect fastest · confidence that the cause is even in this range.
7. Narrow a regression that isn't a code diff
Use when nothing changed in the code but something still broke — config, a feature flag, a dependency, a data migration.
Role: Engineer bisecting a regression that might not be a code change at all.
Context
- What changed around the time it broke: [deploys, flag flips, config
changes, dependency bumps, data migrations — list everything, even things
that seem unrelated]
- Timeline: [when it last worked, when it was first noticed broken]
- Behavior: [paste the error/symptom]
Task
Rank the listed changes by plausibility as the cause, and say what's missing
from the timeline that would narrow it further.
Rules
- Treat every item in the change list as a candidate, including ones that
"shouldn't" matter — that assumption is usually where the real cause hides.
- For the top candidate, state what evidence would confirm it (a log line,
a metric, a flag state) rather than asserting it's the cause outright.
- If the timeline has a gap wide enough to hide the real trigger, say so
and name what would close it.
Output
Ranked candidates with confirming evidence for each · timeline gaps to
close · what to check first.
How do you make AI state a hypothesis instead of guessing at a fix?
This is the habit that separates a debugging prompt from a fix-generator. A model asked directly for a fix will produce one whether or not it found the cause; a model required to state a hypothesis and its falsifying evidence has to show reasoning you can check against your own code. You're running the manual version of self-consistency: sampling more than one line of reasoning and keeping what survives, instead of trusting the first plausible answer.
8. State a falsifiable hypothesis before proposing any fix
Use when you have an error, some code, and a genuine unknown about the cause — the default prompt for a bug you haven't diagnosed yet.
Role: Engineer diagnosing a bug, not yet fixing it.
Context
- Error: [PASTE VERBATIM]
- Stack trace: [FULL TRACE]
- Relevant code: [the function(s) involved, not the whole file]
- What changed recently: [diff, deploy, or "nothing recent that we know of"]
- What you've already ruled out: [list it, even briefly]
Task
Propose your leading hypothesis for the root cause. Do not propose a fix yet.
Rules
- State the hypothesis in one sentence, then the specific evidence in what
I've pasted that supports it, and separately, what evidence would prove
it wrong.
- Label every claim as "visible in the code/trace I pasted" or "my inference
based on similar bugs" — never blend the two into one sentence.
- If two hypotheses are equally supported by what's here, present both and
say what would distinguish them.
- Do not re-suggest anything in "already ruled out."
Output
Hypothesis · supporting evidence (labeled fact vs inference) · falsifying
test · a second hypothesis if the first isn't clearly stronger.
9. Test a hypothesis against evidence you already have
Use when you already have a hypothesis and want it checked against what you know, before running anything new.
Role: Engineer checking a hypothesis against existing evidence, not
inventing new evidence.
Context
- Hypothesis: [state it in one sentence]
- Everything you already have: [logs, code, prior test results, past
incidents — paste all of it, not a summary]
Task
Check whether the hypothesis holds up against what's provided.
Rules
- Go through the evidence piece by piece and say "supports," "contradicts,"
or "doesn't bear on this" for each — no evidence gets silently skipped.
- If nothing here confirms or denies it, say the hypothesis is untested by
current evidence rather than treating silence as support.
- If the evidence contradicts the hypothesis, say so plainly and don't try
to rescue it with a secondary explanation unless that explanation is also
checked against the evidence.
Output
Evidence-by-evidence verdict · overall status (confirmed / contradicted /
untested) · what new evidence would resolve it if untested.
10. Rank competing hypotheses when more than one fits
Use when two or three explanations are all plausible and you need to know which to chase first.
Role: Engineer choosing which of several plausible causes to investigate
first, not picking a winner by feel.
Context
- Candidate hypotheses: [list each one]
- Everything relevant you have: [code, trace, logs, timeline]
- Cost of investigating each: [rough — cheap check vs expensive repro]
Task
Rank the candidates by (a) how well they fit the available evidence and
(b) how cheap they are to test, and recommend an investigation order.
Rules
- Separate "fits the evidence best" from "cheapest to check" — a weaker
hypothesis worth ruling out first because it's a five-minute check is a
legitimate answer, say so explicitly.
- For each candidate, name the one test that would most cleanly eliminate
it.
- Flag any pair of hypotheses that aren't actually mutually exclusive — more
than one root cause is a real, if less convenient, outcome.
Output
Ranked hypotheses with fit and cost noted separately · recommended
investigation order · elimination test per candidate.
What prompt helps AI read the unfamiliar code around the failure?
If the failing code isn't yours, use these two prompts to build a contract before touching anything. For the fuller method, see Using AI to Understand an Unfamiliar Codebase — paste interfaces, not whole files, so you don't burn context window on code that isn't near the failure.
11. Understand a function you didn't write before you touch it
Use when the failing code is unfamiliar and you need its contract, not a paraphrase.
Role: Engineer building a working model of a function before changing it.
Context
- Function/module: [paste it]
- Its signature's dependencies: [types, interfaces, or structs it takes/returns]
- One or two callers, if you have them: [paste them]
Task
Explain what this function actually guarantees to its callers, and what it
assumes about its inputs.
Rules
- Separate what the code guarantees (visible in what I pasted) from what
you'd guess it's meant to do based on naming or similar patterns
elsewhere — label each explicitly.
- Flag any input state the function assumes but doesn't check, and any
output state a caller might assume that the function doesn't actually
promise.
- If a caller isn't pasted, say what you can't verify about how this
function is actually used, rather than inferring a typical caller.
Output
Contract (guarantees + assumptions, labeled fact vs guess) · unchecked
assumptions worth flagging · what's unverifiable without more context.
12. Trace the call path into the failing function
Use when you know which function failed but not how execution actually got there.
Role: Engineer tracing the path into a failure point through code, not memory.
Context
- Failing function: [paste it]
- Entry point or trigger: [request handler, event, CLI command — whatever
starts the chain]
- Intermediate code, if known: [paste what you have; say what's missing]
Task
Trace the most likely path from the entry point to the failing function,
naming each step.
Rules
- Mark each step in the trace as "shown in what I pasted" or "inferred from
typical structure" — do not present an inferred step as confirmed.
- Where the pasted code has a gap (a function called but not shown), name
exactly what's missing rather than assuming its behavior.
- Note any point where the path could branch (a conditional, a callback, an
async boundary) that could mean execution didn't actually go the way the
trace assumes.
Output
Step-by-step path (labeled fact vs inference) · gaps that need more code
pasted · branch points that could invalidate the trace.
Which AI prompts catch concurrency and timing bugs?
Race conditions and deadlocks are where "looks right, runs wrong" bites hardest — the code reads correctly in isolation and only fails under a specific interleaving.
13. Reason about a suspected race condition
Use when a bug looks timing-dependent — intermittent, worse under load, gone when you add a log line.
Role: Engineer reasoning about a possible race condition from what's
visible, not asserting one exists.
Context
- Symptom: [describe the intermittent behavior]
- Shared state involved: [variables or resources touched by more than one
thread/process/request]
- Code for each concurrent path: [paste all paths that touch the shared state]
- Synchronization already in place: [locks, atomics, or "none"]
Task
Identify whether the pasted code has an actual unsynchronized access to
shared state, and if so, what interleaving would trigger the bug.
Rules
- Point to the specific lines where two paths touch the same state without
a shared lock — don't declare "there's a race condition" without naming
the exact access.
- Describe the specific interleaving (which operation from which path has
to happen between which lines of the other) that would produce the
symptom.
- If the pasted code looks properly synchronized, say so — "adding a log
line changed the timing" is itself evidence worth taking seriously, not
proof of a race the code doesn't show.
Output
Specific unsynchronized access, if found · the interleaving that triggers
it · verdict if the code appears sound, with what to check next.
14. Find a deadlock from a thread or goroutine dump
Use when the process is hung and you have a dump of what every thread is doing.
Role: Engineer reading a thread/goroutine dump to find a deadlock, not
speculating about one.
Context
- Full thread/goroutine dump: [paste it, every thread, not just the
suspicious-looking ones]
- Locks/mutexes/channels used in this code: [name them and what they guard]
- Relevant code for the threads involved: [paste it]
Task
Identify whether the dump shows a genuine cycle (thread A waits on what
thread B holds, and vice versa) or something else entirely.
Rules
- Name the exact threads and the exact locks/resources forming the cycle,
quoting the relevant lines from the dump.
- If it's not a cycle — one thread just running slowly, or waiting on
external I/O — say that plainly instead of forcing a deadlock narrative
onto a dump that doesn't show one.
- Note any lock ordering visible in the code that would prevent this cycle
in other call paths, since that's relevant to the fix.
Output
Cycle (or its absence), quoting the dump · threads and locks involved ·
lock-ordering fix, scoped to what the cycle actually shows.
15. Diagnose a bug that only happens under load
Use when everything works at low traffic and breaks only once real concurrency shows up.
Role: Engineer diagnosing a load-dependent failure, distinguishing capacity
limits from concurrency bugs.
Context
- Symptom under load: [errors, timeouts, corrupted data — be specific]
- Approximate load where it starts: [requests/sec, concurrent users, or
"unknown"]
- Resources involved: [connection pools, queues, caches, shared state]
- Behavior at low load: [confirm it's genuinely absent, not just less
frequent]
Task
Distinguish whether this looks like resource exhaustion (a fixed-size pool
or queue hitting its limit) or a concurrency bug (shared state handled
incorrectly under simultaneous access), based on what's provided.
Rules
- State which category fits better and name the specific evidence — a pool
size, a queue depth, unsynchronized shared state — not a general
impression.
- If both are plausible, say so and name the cheapest check that would
distinguish them, such as raising a pool size as a test, not a fix.
- Flag if the described symptom is actually consistent with "less frequent,
not absent" at low load, since that changes the diagnosis.
Output
Likely category with supporting evidence · distinguishing check · what's
still unknown from the information given.
What's the right AI prompt for a memory or resource leak?
Leaks are slow-motion bugs: the symptom shows up hours after the cause, so the prompt works backward from a growth curve, not from one moment in time.
16. Find what's holding a reference too long
Use when memory grows over time and you suspect something isn't being released, but don't yet know what.
Role: Engineer tracing an unreleased reference, not guessing at "a leak
somewhere."
Context
- Symptom: [memory growth pattern — steady, stepped, tied to a specific action]
- Suspected area: [a cache, a listener registration, a closure, a collection
that only grows — whatever you suspect, even loosely]
- Relevant code: [paste it]
- Lifecycle: [when this data should actually be released — end of request,
session, process]
Task
Identify anything in the pasted code that's added to but never removed
from, or held longer than its stated lifecycle implies.
Rules
- Point to the specific collection, cache, or registration and the code
path that adds to it, then say whether a corresponding removal exists in
what was pasted.
- If no removal path is visible, say that plainly rather than assuming one
exists elsewhere — that's the actionable finding.
- Distinguish "this will leak under the stated lifecycle" from "this is
fine if X is true" and name what X is.
Output
Candidate leak sites with add/remove evidence · missing removal paths ·
what depends on an assumption you can't verify from this code alone.
17. Diagnose a resource leak that isn't memory
Use when you're running out of file handles, database connections, or sockets, not RAM.
Role: Engineer tracing a non-memory resource leak (handles, connections,
sockets, threads).
Context
- Resource type and symptom: [what's running out, and the error you get
when it does]
- Code that acquires this resource: [paste every acquisition path]
- Code that releases it: [paste it, or say "none found"]
- Error handling around acquisition: [paste it — this is usually where
leaks hide]
Task
Check every acquisition path for a release that's guaranteed to run, even
on the error path.
Rules
- For each acquisition, state explicitly whether the release is guaranteed
(try/finally, defer, a context manager) or conditional on the happy path
only.
- An acquisition with a release only in the success path is a leak on
every error — say so directly rather than "this could be improved."
- Note any acquisition inside a loop or retry, since those leak per
iteration, not just once.
Output
Acquisition-by-acquisition verdict on guaranteed release · confirmed leak
paths · which ones only leak on error, and therefore hide well in testing.
18. Read a memory profile or heap snapshot diff
Use when you have two heap snapshots, or two points in time, and need to know what grew.
Role: Engineer reading a heap diff to find what's actually accumulating.
Context
- Heap diff / profile output: [paste the top entries by retained size or
count delta]
- What happened between the two snapshots: [an action repeated N times, or
time elapsed under normal use]
- Code for the types/objects that grew most: [paste it, for the top 2-3
entries]
Task
Explain what the diff shows growing, and connect the top entries to a
specific retention path in the code, if the code supports that.
Rules
- Work from the actual entries in the diff, not from generic causes of
memory leaks — general causes only matter if they match what's actually
listed as growing.
- For each top entry, say what in the pasted code would explain that
specific type or object being retained, or say the code provided doesn't
explain it.
- Rank entries by retained size multiplied by growth rate relative to the
repeated action, not by raw count alone — a huge one-time allocation
isn't a leak.
Output
Top growing entries with retention explanation, where supportable · entries
that don't map to anything in the code provided · recommended fix target.
What's the prompt for a test that only fails sometimes?
The temptation is to retry a flaky test until it's green. These two prompts are for the five minutes before you do that.
19. Diagnose an intermittently failing test
Use when a test fails occasionally in CI and passes on rerun, and you want to know why before you mark it flaky and move on.
Role: Engineer diagnosing an intermittent test failure, not dismissing it.
Context
- Test code: [paste it]
- Code under test: [paste the relevant part]
- Failure output: [paste it from an actual failed run, including any
assertion diff or timeout message]
- Failure rate: [roughly how often, if known — "1 in 20 CI runs" beats
"sometimes"]
Task
Identify what in the test or the code under test could produce this
specific failure only some of the time.
Rules
- Look for concrete non-determinism first: unseeded randomness, real timers
or sleeps instead of controlled ones, unordered collections asserted in
order, shared state between tests, network or filesystem calls.
- For each candidate cause, say what evidence in the failure output
supports it, rather than listing generic flaky-test causes that don't
match this failure.
- If the failure output doesn't contain enough to narrow the cause, say
what additional run, with what logging or seed, would.
Output
Candidate causes ranked by fit to the actual failure output · what to add
to narrow it further · whether this looks like the test or the code under
test.
20. Distinguish a flaky test from a real bug hiding behind it
Use when you're tempted to just retry the test until it passes and move on.
Role: Engineer deciding whether an intermittent test failure is safe to
dismiss as "flaky."
Context
- Test and what it's asserting: [paste it]
- Code under test: [paste it]
- Failure history: [how often it fails, and whether failures cluster around
specific changes, times, or environments]
Task
Assess whether this failure is more consistent with test infrastructure
noise (timing, environment, test isolation) or with a real, intermittent
bug in the code under test.
Rules
- State the specific evidence pointing each way — don't default to
"probably flaky," which is the answer that requires no further evidence
and is therefore easy to reach for without justification.
- If the test asserts something that would matter in production (data
correctness, a race condition, a resource limit), weight that toward
"worth investigating" even if it fails rarely.
- Name the one experiment that would resolve the ambiguity: running it N
times under load, adding an earlier assertion, or logging state at the
point of failure.
Output
Verdict with supporting evidence · the resolving experiment · risk of
marking it flaky and ignoring it, if the evidence leans toward a real bug.
How do you diagnose a performance regression with AI?
The trap is a model reasoning about what "usually" causes slowdowns instead of what your profile actually shows.
21. Find what got slower and why
Use when something used to be fast and now isn't, and you need to know where the time actually went.
Role: Engineer diagnosing a performance regression from measurements, not
intuition about what "feels slow."
Context
- Metric that regressed: [latency, throughput, CPU — whatever's measured,
with before/after numbers]
- What changed in the window this regressed: [deploys, config, data volume,
dependency versions]
- Profiling data, if you have it: [paste it — even partial]
- Code for the hot path, if known: [paste it]
Task
Propose the most likely cause of the regression, tied to what actually
changed in that window, and say what profiling data would confirm it.
Rules
- Prefer an explanation tied to a listed change over a generic guess, unless
the guess is actually supported by something in the code or profile
provided.
- State explicitly what would be true in the profiling data if this
explanation is correct, so it's a checkable prediction, not a story.
- If no profiling data is provided, say that's the actual blocker to
confirming anything, and name exactly what to capture.
Output
Leading explanation tied to a specific change · the checkable prediction ·
what data to capture if none exists yet.
22. Read a profiler flame graph or trace diff
Use when you have a before/after profile and need to know what to act on, not just where the widest bars are.
Role: Engineer reading a flame graph or trace diff, correcting for the
obvious visual trap.
Context
- Profile/flame graph data: [paste the top functions by self-time and by
total time, before and after]
- What changed between the two profiles: [code change, load level, data
size]
Task
Identify which functions actually got slower (higher self-time) versus
which only appear larger because something below them got slower.
Rules
- Separate self-time increases from total-time increases explicitly — a
function with unchanged self-time but a wider bar just has a slower
callee, and blaming it wastes the investigation.
- Rank the actual self-time regressions by how much they contribute to the
overall regression, not by visual width alone.
- If the profile doesn't include self-time data, say that's needed before
a specific function can be blamed.
Output
Ranked actual self-time regressions · functions that only look worse due to
a callee · what additional profiling granularity would help.
23. Rule out the obvious performance suspects before the deep dive
Use when you want to spend five minutes eliminating common causes before committing to a profiling session.
Role: Engineer running a fast pre-check before a deep performance
investigation.
Context
- Symptom: [what got slower, roughly how much]
- Code for the affected path: [paste it]
- Recent changes: [anything, even unrelated-seeming, in this window]
Task
Check the pasted code against the most common, cheaply-verified causes of
this kind of regression, and say which are ruled in, ruled out, or need a
runtime check to know.
Rules
- Check only what's actually verifiable from the code pasted, such as an
added query inside a loop, a removed cache, or a call that used to be
asynchronous — don't pad the list with causes the code can't confirm or
deny.
- For anything you can't rule out from code alone, name the specific
runtime check that would settle it in minutes.
- If nothing obvious turns up, say so directly — that's the signal to move
to profiling rather than keep guessing.
Output
Ruled in / ruled out / needs-runtime-check, each with reasoning · fastest
path to a deep dive if the quick check comes up empty.
What do you do when the bug only happens in production?
Production has scale, real data shapes, and users doing things nobody scripted a test for. These three prompts are for when staging and local both refuse to reproduce it.
24. Diagnose a bug that won't reproduce outside production
Use when staging and local both work fine and only production shows the failure.
Role: Engineer diagnosing a production-only failure by finding what's
actually different about production, not by re-testing the same repro.
Context
- Symptom in production: [error, behavior, paste real log lines if you
have them]
- Confirmed working elsewhere: [staging, local — say what was actually
tested]
- Known differences between production and elsewhere: [scale, data shape,
config, third-party services, feature flags — list everything, even
things assumed irrelevant]
Task
Rank the known differences by how plausibly each explains this specific
symptom, and name what's missing from the comparison.
Rules
- Don't default to "it's probably scale" without tying it to a specific
mechanism, such as a timeout, a pool limit, or a batch size, that the
symptom is consistent with.
- If real data shape differs between environments, treat that as a
first-class candidate, not an afterthought.
- Say explicitly what you can't assess without production-safe access to
logs or a sanitized data sample.
Output
Ranked differences with mechanism tied to the symptom · what production
access or data would resolve the top candidate.
25. Correlate an incident with a deploy or config change
Use when something broke around a known time window and you have a list of what shipped.
Role: Engineer correlating an incident timeline with what actually shipped.
Context
- Incident start (as best known): [timestamp or window]
- Deploys/config changes/flag flips in the surrounding window: [list with
timestamps]
- Symptom: [what broke, paste any error/metric evidence]
Task
Rank the listed changes by proximity and plausible relevance to the
symptom, and name the gap between "close in time" and "actually related."
Rules
- Timestamp proximity alone is not evidence of causation — say explicitly
what mechanism would connect a given change to this specific symptom, or
flag the correlation as unconfirmed.
- If two changes are both plausible, say so rather than picking one to seem
decisive.
- Note if the incident start time itself is uncertain, since that changes
which changes are even in scope.
Output
Ranked changes with plausibility and mechanism, or "correlation only, no
mechanism yet" · uncertainty in the incident start time, if relevant.
26. Build a hypothesis from logs and metrics alone
Use when you can't reproduce the issue at all and all you have is what production already recorded.
Role: Engineer building the best available hypothesis from passive
evidence, being explicit about its limits.
Context
- Logs: [paste relevant lines, with timestamps]
- Metrics/dashboards: [describe or paste what you have]
- What triggered the investigation: [an alert, a customer report, a metric
anomaly]
Task
Propose the hypothesis best supported by the logs and metrics provided, and
state its confidence given that it's untested by direct reproduction.
Rules
- Cite the specific log line or metric behind every claim — no hypothesis
gets stated without a pointer to the evidence that suggests it.
- State explicitly that this is unconfirmed without a repro, and name what
additional logging would move it from hypothesis to confirmed.
- If the available logs don't actually cover the failure point, a common
gap, say so — that's itself an actionable finding.
Output
Hypothesis with cited evidence · confidence given no repro · logging gap,
if one exists, and what to add.
How do you check dependency and version issues before blaming your own code?
Something breaks right after an upgrade, and it's tempting to assume the library changed. Make the model prove that from the actual changelog, not from memory.
27. Diagnose a break caused by a dependency upgrade
Use when something broke right after a dependency, library, or runtime bump, and you need to know if the upgrade is actually the cause.
Role: Engineer diagnosing whether a dependency upgrade caused this specific
failure.
Context
- What was upgraded: [package/runtime, old version to new version]
- Error/behavior since the upgrade: [paste it]
- Code that uses the upgraded dependency: [paste the relevant calls]
- Changelog/release notes, if you have them: [paste the relevant entries —
don't ask the model to recall them from memory]
Task
Connect the specific failure to a specific documented change in the
dependency, using only the changelog text provided.
Rules
- Do not assert what changed in the dependency from memory or general
pattern — work only from changelog/release-note text you were given, and
say plainly if none was provided.
- If the pasted changelog doesn't mention anything matching the symptom,
say the upgrade isn't confirmed as the cause rather than assuming it is
because of the timing.
- If a breaking change is confirmed in the changelog, quote the exact
wording and connect it to the exact line in your code that's affected.
Output
Confirmed connection, quoted changelog plus affected line, or "not
confirmed by the material provided" · what changelog section to go find if
none was pasted.
28. Check for a known issue before assuming your own code is at fault
Use when the failure looks like it could be a bug in a library or platform you depend on, not your integration with it.
Role: Engineer checking whether a failure is a known issue upstream before
spending time on your own code.
Context
- Symptom: [error, exact message, and version of the dependency involved]
- Your usage: [the exact call or pattern that triggers it]
- Anything you've found so far: [an issue tracker link, a changelog entry —
paste the actual text, not a summary of it]
Task
Assess whether the pasted material actually documents this as a known
issue, versus whether it's your own integration.
Rules
- If you weren't given a real source (an issue, a changelog, a doc page),
say plainly that you can't confirm a "known issue" and should not invent
one — a plausible-sounding issue number is worse than no answer.
- Where a source was pasted, quote the specific text that does or doesn't
match this symptom, rather than summarizing it as "yes, known issue."
- If it isn't a known issue by the evidence given, redirect to checking
your own usage against the dependency's documented contract.
Output
Verdict grounded in pasted material only · quoted match, if any · next
check if unconfirmed.
What's a good AI prompt for writing the post-mortem?
The bug is fixed. What you write next either makes the team faster, or becomes a document nobody trusts.
29. Write a blameless post-mortem from the incident timeline
Use when the bug is fixed and you need a write-up that explains what happened without turning into a blame document.
Role: Engineer writing an incident post-mortem, focused on the system and
the decisions available at the time, not the individual who acted on them.
Context
- Timeline: [detection, escalation, diagnosis steps, fix, resolution — with
timestamps]
- Root cause: [the confirmed cause, not a suspected one]
- What was known at each decision point: [what information responders
actually had, not what's obvious in hindsight]
Task
Write a post-mortem: summary, timeline, root cause, contributing factors,
and what made it hard to catch or diagnose sooner.
Rules
- Describe decisions in terms of what was knowable at the time they were
made — hindsight makes every delayed diagnosis look avoidable, and that's
not a fair account of what happened.
- Attribute causes to gaps in the system, such as a missing alert, unclear
ownership, or absent logging, rather than to a person's judgment, unless a
process gap is truly the honest description.
- Keep the root cause section to what was actually confirmed, separate from
contributing factors that made it worse or harder to find.
Output
Summary · timeline · confirmed root cause · contributing factors ·
detection and diagnosis time, and what would have shortened each.
30. Extract the prevention items that actually get done
Use when the post-mortem is written and you need action items that survive contact with next quarter's roadmap.
Role: Engineer turning a post-mortem into action items scoped enough to
actually ship.
Context
- Post-mortem: [paste the summary, root cause, and contributing factors]
- Team capacity reality: [roughly how much remediation time actually gets
protected after an incident, if you know]
Task
Propose prevention items, each scoped to be completable in a single
sprint, ranked by how much of the contributing-factor list each one closes.
Rules
- Reject open-ended items such as "improve monitoring" or "add more tests"
and rewrite each as a specific, checkable deliverable, such as "add an
alert on X crossing Y threshold."
- Tie every item back to a specific contributing factor from the
post-mortem — an item with no traceable factor is scope creep, not
prevention.
- Flag any item that's really a rewrite or an infrastructure project in
disguise, since those need their own planning, not a post-mortem action
item slot.
Output
Ranked, scoped action items tied to specific contributing factors · items
flagged as needing separate planning rather than a sprint slot.
Which debugging stage matches your symptom?
| Symptom | Start here | Prompts |
|---|---|---|
| You have an error and a stack trace, nothing else | Reading a stack trace | 1–2 |
| It happened once and you can't trigger it again | Reproducing reliably | 3–5 |
| It used to work; something changed | Bisecting a change | 6–7 |
| You have a theory but no way to check it | Forming and testing a hypothesis | 8–10 |
| The failing code isn't yours | Reading unfamiliar code | 11–12 |
| Intermittent, worse under load, gone once you add a log line | Concurrency and timing | 13–15 |
| Memory or a resource climbs and never comes back down | Memory and resource leaks | 16–18 |
| A test fails sometimes and passes on rerun | Flaky tests | 19–20 |
| Same feature, slower than it used to be | Performance regressions | 21–23 |
| Works everywhere except production | Production-only failures | 24–26 |
| Broke right after an upgrade | Dependency and version issues | 27–28 |
| It's fixed; you need the write-up | Post-mortem | 29–30 |
Where can an AI genuinely not help you debug?
It cannot run your code, watch a debugger, or read your logs and metrics unless you paste them in. Every prompt above works from what you give it, and it will fill any gap with something plausible rather than an honest "I don't know" — the same mechanism behind AI hallucination generally, covered in depth in why ChatGPT makes things up rather than re-derived here. In debugging, that shows up as a hypothesis stated with the same fluent confidence whether it's grounded in your trace or in a pattern from a million similar bugs. That's why every prompt above asks for labeled evidence and a falsifying test — it's the only way to tell which kind of confidence you're looking at.
How does Prompt Architects fit into a debugging workflow?
Prompt Architects doesn't run your code, read your repository, or watch your terminal. It's a prompt-enhancement platform, not a debugger: a web app, browser extensions, and an MCP server. What it's good for here is not letting the thirty prompts above evaporate the moment you close this tab.
Save the ones you reuse most, such as the falsifiable-hypothesis prompt or whichever stage matches your stack's usual failure mode, to a prompt library with your language, framework, and "already ruled out" fields set up as reusable variables. Over MCP, those same saved prompts run inside Claude Code, Cursor, and Codex CLI — the tools that can also execute the repro and check the hypothesis against real output, the tool-enabled case from the section above. There's a free plan, 5 prompt enhancements a day, forever, per our FAQ; current pricing for unlimited use and the full library starts at $4.99/mo at the time of writing.
Save the five or six prompts you'll actually reuse, fill in your stack once, and run the hypothesis prompt before you touch a fix on the next bug that shows up confident and wrong.
Free Chrome Extension
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An Account