How to Write AI Debugging Prompts for Bugs That Only Happen Sometimes

Some bugs are easy to reproduce.

You click a button, the application crashes, and the same failure happens every time.

Intermittent bugs are different. The application may fail once every twenty requests, only under heavy load, only after a particular sequence of actions, or only on one environment.

These bugs are also where a poorly designed AI debugging prompt can become dangerous.

If you simply paste the error message into an AI assistant and ask, "What's wrong?", you may receive a confident-looking explanation based on incomplete evidence.

A better approach is to make the AI behave more like an investigator.

Instead of asking it to immediately guess the cause, give it the symptoms, environmental conditions, reproduction pattern, logs, and known facts, then ask it to rank hypotheses and identify what evidence would confirm or eliminate each one.

Why Intermittent Bugs Need a Different Prompt

A deterministic bug often gives you a relatively simple debugging path:

1. Reproduce the failure.
2. Inspect the failing code.
3. Identify the incorrect behavior.
4. Apply a fix.

An intermittent bug may not provide that luxury.

You might instead have:

• A failure that occurs only occasionally.
• Incomplete logs.
• Multiple possible causes.
• Different behavior between development and production.
• Timing-dependent failures.
• Race conditions.
• External service failures.
• Resource exhaustion.

That means the debugging problem is partly about collecting and interpreting evidence.

Your prompt should reflect that.

Don't Start With "Find the Bug"

A common debugging prompt looks like this:

Find the bug in this code. It sometimes crashes.

The model has almost no information about when the failure occurs.

It may identify something suspicious, but suspicious code isn't necessarily responsible for the observed failure.

Instead, establish the investigation context first.

The application occasionally crashes while processing concurrent requests. The failure occurs roughly once every 50–100 requests and cannot currently be reproduced reliably in development.

That single addition changes the nature of the investigation.

1. Describe the Symptom, Not Your Theory

When debugging, developers often include their own theory in the prompt.

For example:

I think this is probably a threading problem. Find where the race condition is.

This can anchor the investigation around an assumption that may be wrong.

A better approach is to describe the observed behavior:

The same record occasionally receives an incorrect value when multiple requests are processed at approximately the same time. The issue disappears when requests are processed sequentially.

Now the AI can consider concurrency as one hypothesis without being told that it is definitely the answer.

This distinction matters:

Observation: What happened.

Hypothesis: Why you think it happened.

Keep them separate.

2. Describe How Often the Bug Happens

Frequency is valuable evidence.

Compare:

It happens sometimes.

with:

It occurs approximately once every 50–100 requests under normal traffic and becomes noticeably more frequent during load testing.

The second description suggests that timing, concurrency, resource limits, or load-dependent behavior may deserve investigation.

You don't need perfect statistics.

Even an approximate frequency can be useful.

3. Describe What Makes the Bug More or Less Likely

This is one of the most useful pieces of information for intermittent failures.

Tell the model what conditions appear to influence the problem.

For example:

• More frequent under high traffic.
• Only observed on production servers.
• Doesn't occur when debugging slowly.
• Appears after several hours of uptime.
• More common with large requests.
• Occurs only when a third-party API is slow.

These observations help narrow the search space.

4. Give the AI a Timeline

For sequence-dependent bugs, a timeline can be more informative than a large code dump.

For example:

10:02:14 — User submits request.
10:02:14 — Application creates job.
10:02:15 — Worker begins processing.
10:02:15 — Database record is updated.
10:02:16 — External API returns successfully.
10:02:16 — Worker attempts second update.
10:02:16 — Incorrect state is observed.

Now the model has a sequence of events to reason about.

This can be especially valuable for:

• Async applications
• Background jobs
• Message queues
• Distributed systems
• Database transactions
• Event-driven applications

5. Include What You Know Is Not Causing the Problem

Negative evidence can be useful too.

For example:

The issue has not occurred when the database connection is unavailable. It has also not occurred during single-user testing.

This doesn't prove that those systems are unrelated, but it gives the investigation more constraints.

Think of debugging evidence in three categories:

• Observed: Things that definitely happened.
• Not observed: Conditions where the failure hasn't appeared.
• Unknown: Things you haven't tested yet.

Keeping these categories separate prevents assumptions from being mistaken for facts.

6. Ask for Competing Hypotheses

Instead of asking:

What is causing this?

ask:

Based only on the supplied evidence, generate the five most plausible hypotheses. Rank them by how well they explain the observed behavior.

This encourages the AI to consider alternatives.

For each hypothesis, ask it to provide:

• Supporting evidence
• Contradicting evidence
• What information is missing
• A test that could confirm or eliminate the hypothesis

This is much more useful than receiving one confident explanation.

7. Make the AI Distinguish Evidence From Assumptions

Add an explicit instruction:

Do not treat assumptions as established facts. Clearly label statements that are inferred rather than directly supported by the supplied evidence.

This is especially important when the prompt contains incomplete logs or a partial codebase.

For example:

The function appears to be called concurrently.

is very different from:

The function is confirmed to be called concurrently by multiple worker threads.

The first is a hypothesis. The second is evidence.

8. Ask for the Next Most Valuable Test

When the cause isn't known, the best next step isn't necessarily a code change.

It may be an experiment.

Ask:

What single additional test or observation would provide the most useful information for distinguishing between the top two hypotheses?

This turns the AI into an experiment-planning assistant.

For example, it might suggest:

• Adding a timestamp to specific events.
• Recording request identifiers.
• Increasing concurrency temporarily.
• Testing with a controlled delay.
• Comparing two runtime environments.
• Capturing the state immediately before failure.

You can then perform the test and feed the new evidence back into the investigation.

9. Use a Debugging Loop Instead of One Giant Prompt

Intermittent bugs are often better handled as an iterative investigation.

A useful loop is:

1. Describe the current evidence.
2. Generate competing hypotheses.
3. Choose the most informative test.
4. Run the test.
5. Add the new evidence.
6. Re-rank the hypotheses.
7. Repeat until the cause is sufficiently supported.

This is generally more reliable than putting every possible instruction into one enormous prompt.

10. Don't Ask for a Fix Until the Cause Is Supported

Once the AI proposes a likely cause, you may be tempted to immediately ask for a patch.

First ask:

What evidence would distinguish this suspected root cause from the next most plausible explanation?

If the answer identifies a test and the test confirms the hypothesis, then request the fix.

This reduces the risk of making unrelated changes based on a speculative diagnosis.

A Structured Intermittent-Bug Prompt

Here is a reusable template:

Role:
Act as a debugging investigator. Analyze the supplied evidence without assuming that my suspected cause is correct.

Observed symptom:
[Describe exactly what happens.]

Frequency:
[How often it occurs.]

Conditions:
[When it becomes more or less likely.]

Environment:
[Language, runtime, framework, database, operating system, deployment environment.]

Timeline:
[Relevant sequence of events.]

Logs:
[Relevant logs or error messages.]

Known facts:
[Facts confirmed through testing.]

Current hypotheses:
[Your theories, clearly labeled as hypotheses.]

Task:

1. Separate observations from assumptions.
2. Generate the most plausible competing explanations.
3. Rank them based on the available evidence.
4. Identify evidence supporting and contradicting each explanation.
5. State what information is missing.
6. Suggest the most informative next test.
7. Do not propose code changes until a likely cause has sufficient supporting evidence.

Example: A Race Condition That Hasn't Been Proven

Suppose an application occasionally assigns the wrong status to a job.

A weak prompt might say:

There is a race condition in this job-processing code. Find it.

This assumes the answer.

A stronger prompt would say:

The job status is occasionally incorrect when multiple jobs are processed simultaneously. The problem has not been reproduced during single-job testing. It becomes more frequent during load testing.

I suspect a race condition, but this has not been confirmed.

Analyze the supplied code and logs. Identify competing explanations, explain what evidence supports each one, and propose the smallest experiment that could distinguish a race condition from transaction or state-management problems.

The second prompt preserves the developer's useful observation without forcing the AI to accept the developer's theory.

Use Logs as Structured Evidence

If you have logs, don't simply paste thousands of lines into the prompt without explanation.

Give the AI the context needed to interpret them.

Each request has a unique request ID. Worker IDs identify the processing thread. Timestamps are in UTC. The suspected failure occurred between 14:32:08 and 14:32:09. Focus on interactions involving request ID 8472.

This gives the model a way to navigate the evidence.

If possible, remove irrelevant logs before submitting them. More information isn't always more useful.

Ask the AI to Identify Missing Instrumentation

Sometimes the correct conclusion is simply that the current logs aren't sufficient.

Ask:

Based on the current evidence, what information would you want logged next to distinguish the leading hypotheses?

The answer might identify missing information such as:

• Request IDs
• Thread IDs
• Transaction boundaries
• Queue timestamps
• State transitions
• Retry counts
• External API response times

This can be more valuable than another speculative code rewrite.

Keep the Final Fix Narrow

Once the root cause has strong evidence, change the debugging prompt.

For example:

The investigation indicates that the incorrect state occurs because two workers can update the same record between the read and write operations.

Implement the smallest change necessary to prevent this specific failure.

Do not refactor unrelated code, change the public API, rename variables, or introduce new dependencies unless required by the fix.

Explain why the change prevents the demonstrated failure and provide a test that reproduces the original problem.

Now the AI has a much narrower task.

What Not to Put in an Intermittent-Bug Prompt

Avoid filling the prompt with assumptions such as:

• "This is definitely a memory leak."
• "The database must be causing it."
• "There is obviously a race condition."
• "Just rewrite this function."
• "Optimize everything while you're there."

If these are theories rather than confirmed facts, label them as theories.

This preserves the value of your intuition without turning it into a false constraint.

The Evidence Ladder

A useful way to organize an AI debugging conversation is to move through four levels:

1. Symptom: What is happening?
2. Pattern: When does it happen?
3. Hypothesis: What could explain the pattern?
4. Verification: What test can distinguish the explanations?

Only after reaching the fourth level should you normally move toward a targeted code change.

Final Takeaway

Intermittent bugs are difficult because the evidence is incomplete and the failure may depend on timing, load, state, or environmental conditions.

AI can help, but only if the debugging prompt encourages investigation instead of speculation.

Describe the symptom without assuming the cause. Provide frequency, conditions, timelines, logs, and known facts. Ask for competing hypotheses and require evidence for each one.

Most importantly, ask what test would provide the most useful new information before asking the AI to rewrite your code.

For bugs that happen only sometimes, the best AI debugging prompt doesn't ask for a faster guess. It asks for a better investigation.