Rubber-duck debugging a problem you cannot crack
The classic move — explain the bug out loud until the answer surfaces — works even better when the duck talks back. Debugging is one of the most common AI tasks, with nearly half of developers using it at least partially. But the goal here is a reasoning partner that helps you form and test hypotheses, not a tool that emits a patch you paste blind — 45% of developers say fixing AI-written code costs more time than it saves.
You are a calm senior engineer helping me debug by reasoning, not by handing me a patch. Act as a debugging partner: help me find the cause, and let me implement the fix. What I expected to happen: {{expected}} What actually happens (exact error, stack trace, or wrong output): {{actual}} Relevant code and environment: {{context}} What I have already tried: {{tried}} Do this: 1. Restate the problem in your own words so I can confirm you understand it. 2. List the most likely causes, ranked, each with the reasoning and a specific check I can run to confirm or rule it out. 3. Suggest the single next diagnostic step — a log line, breakpoint, or minimal experiment — before proposing any fix. 4. Only after we have localized the cause, suggest a fix and explain why it addresses the root cause rather than the symptom. Rules: - Do not guess at a fix before the cause is identified. If my information is insufficient, tell me exactly what to gather. - Base hypotheses on the error and code I provided; do not invent framework behavior, config, or line numbers. Say clearly when you are speculating. - Prefer the smallest change that fixes the root cause over a broad rewrite.
Fill in your details and the prompt updates live — then copy.
Restated: your endpoint returns 500 intermittently under load with a connection-pool-exhausted error, though it works locally. Most likely causes, ranked: 1. Connections not released on the error path — check whether the query's failure skips the release/close call. Reproduce and watch active connections. 2. Pool too small for real concurrency — log checkout and check-in counts per request. 3. A slow query holding connections open — check the database slow-query log. Next diagnostic: add a log on every acquire and release, then reproduce with about 20 concurrent requests before changing any config. I am speculating on cause 1 until the logs confirm it.
The full workflow
- Gather the exact error, stack trace, and a minimal reproduction before you start
- Paste sanitized code and logs — remove secrets, tokens, and internal hostnames
- Work through the ranked hypotheses, running each suggested check yourself
- Implement the fix by hand and add a test that reproduces the original bug
Watch out for
Logs and stack traces often contain secrets, tokens, internal URLs, and customer data — scrub them before pasting, and use an approved tool rather than a consumer account for anything proprietary.
A confident fix aimed at the wrong root cause is worse than no fix. Make the model localize the cause with evidence before you change anything, then reproduce the bug with a test so you know it is actually solved.
Models invent plausible framework behavior and config options. Verify any API, flag, or setting it references against the real documentation.
Where this comes from
Every use case on this site is grounded in real reports from working software developers — not invented by us.