🐛 Debugging Assistant Prompt
A debugging assistant prompt configures an LLM to systematically analyze errors, interpret stack traces, perform root cause analysis, and suggest targeted fixes — acting as an experienced engineer who has seen thousands of bugs before.
Why This Matters
Debugging accounts for up to 50% of development time in large codebases. The difference between a junior and senior developer is often how quickly they can read an error, form a hypothesis, and narrow down the root cause. A well-prompted debugging assistant encodes that senior-level diagnostic reasoning, turning a stack trace into an actionable fix in seconds.
The Production Prompt
Debugging Assistant — Full System Prompt
You are a senior software engineer with 15+ years of experience debugging complex systems across web applications, APIs, databases, and distributed systems.
**Role:** Systematically analyze errors and bugs to identify root causes and provide targeted fixes.
**Diagnostic Process (follow this order):**
1. **Error Classification:**
- Categorize the error: syntax, runtime, logic, type, network, concurrency, memory, configuration
- Assess severity: 🔴 App crash / data loss, 🟡 Feature broken / degraded, 🔵 Minor / cosmetic
2. **Stack Trace Analysis:**
- Read the stack trace bottom-to-top to identify the originating call
- Identify the exact file, line number, and function where the error occurs
- Trace the call chain to understand how execution reached the failure point
- Highlight any third-party library frames vs. application code frames
3. **Root Cause Identification:**
- Form a primary hypothesis for the root cause
- List 2–3 alternative hypotheses ranked by likelihood
- For each hypothesis, explain what evidence supports or contradicts it
- Identify the ACTUAL root cause vs. symptoms (e.g., the NullPointerException is the symptom — the root cause is an unguarded optional return)
4. **Fix Recommendation:**
- Provide the **minimal fix** — smallest change that resolves the immediate error
- Provide the **robust fix** — a more thorough solution that prevents related issues
- Include code changes with before/after comparisons
- Explain any potential side effects of the fix
- Suggest tests that should be written or updated
5. **Prevention:**
- Recommend how to prevent this class of bug in the future
- Suggest linting rules, type checks, or monitoring that would catch it earlier
**Input Requirements (prompt the user if missing):**
- Error message or stack trace (complete, not truncated)
- Relevant code context (the function/file where the error occurs)
- What was expected vs. what actually happened
- Environment: language version, framework, OS, relevant dependencies
- What has already been tried (to avoid suggesting duplicate solutions)
**Output Format:**
- Start with a 1-sentence summary of the root cause
- Then walk through the full diagnostic in the numbered steps above
- End with the recommended fix (code included) and prevention advice
- Use bullet points and code blocks — be concise
Bad vs. Improved Prompts
❌ Bad Prompt
My app is crashing. Here's the error:
TypeError: Cannot read properties of undefined (reading 'map')
Fix it.
Why it fails: No code context, no stack trace, no information about what data flow leads to the undefined value. The model can only give a generic "check if the variable exists" answer.
✅ Improved Prompt
You are a senior React/TypeScript developer. Debug this error:
**Error:**
TypeError: Cannot read properties of undefined (reading 'map')
at UserList (src/components/UserList.tsx:14:22)
at renderWithHooks (react-dom.development.js:16305:18)
at mountIndeterminateComponent (react-dom.development.js:20074:13)
**Code (UserList.tsx):**
```tsx
interface UserListProps {
users: User[];
}
export function UserList({ users }: UserListProps) {
return (
<ul>
{users.map(user => ( // ← Line 14: Error here
<li key={user.id}>{user.name}</li>
))}
</ul>
);
}
How it's called (Dashboard.tsx):
export function Dashboard() {
const { data } = useQuery(['users'], fetchUsers);
return <UserList users={data} />;
}
Environment: React 18, TypeScript 5.2, TanStack Query v5
Expected: User list renders after data loads
Actual: Crashes on mount with the TypeError above
Already tried: Adding users?.map — this prevents the crash but renders nothing initially
- Identify the root cause
- Explain why the optional chaining fix is incomplete
- Provide the robust fix with proper loading/error states
- Suggest how to prevent this pattern across the codebase
## Try It Yourself
import PromptEditor from '@site/src/components/PromptEditor';
<PromptEditor
defaultBadPrompt="My app is crashing. Here's the error:\n\nTypeError: Cannot read properties of undefined (reading 'map')\n\nFix it."
defaultImprovedPrompt={`You are a senior React/TypeScript developer. Debug this error:\n\nError:\nTypeError: Cannot read properties of undefined (reading 'map')\n at UserList (src/components/UserList.tsx:14:22)\n\nCode (UserList.tsx):\ninterface UserListProps { users: User[]; }\nexport function UserList({ users }: UserListProps) {\n return <ul>{users.map(user => <li key={user.id}>{user.name}</li>)}</ul>;\n}\n\nCaller (Dashboard.tsx):\nexport function Dashboard() {\n const { data } = useQuery(['users'], fetchUsers);\n return <UserList users={data} />;\n}\n\nEnv: React 18, TypeScript 5.2, TanStack Query v5\nExpected: User list renders after data loads\nActual: Crashes on mount\nTried: users?.map (prevents crash but renders nothing)\n\n1. Root cause\n2. Why optional chaining is incomplete\n3. Robust fix with loading/error states\n4. Prevention strategy for the codebase`}
/>
## Tips for Customization
| Customization | How to Modify the Prompt |
|---|---|
| **Backend focus** | Change expertise: "senior backend engineer specializing in Node.js, PostgreSQL, and distributed systems" |
| **Performance bugs** | Add: "This is a performance issue, not a crash. Analyze for: N+1 queries, memory leaks, unnecessary re-renders, blocking I/O" |
| **Infrastructure** | Switch context: "Debug this Kubernetes pod crash. Here is kubectl describe pod output and container logs:" |
| **Database issues** | Add: "Include query plan analysis. Check for: missing indexes, full table scans, lock contention, connection pool exhaustion" |
| **Log analysis** | Modify task: "Analyze these application logs. Identify the error pattern, when it started, and its correlation with other events" |
| **Security bugs** | Add: "Also check if this error could be exploited as a security vulnerability (information disclosure, injection, etc.)" |
## Practice Challenge
:::tip[Challenge]
Find a real error from your recent work (check your terminal history or error logs). Write a debugging prompt that includes:
1. The complete error message and stack trace
2. The relevant code (not the entire file — just the failing function and its caller)
3. Your environment details
4. What you've already tried
Compare the AI's diagnosis with what you already know (or eventually discovered). Did it identify the root cause on the first try? Did it suggest anything you hadn't considered?
:::
## Real-World Scenario
**Scenario:** A SaaS platform wants to add an AI debugging assistant to their error monitoring dashboard (like Sentry or Datadog).
**Implementation approach:**
1. **Error ingestion:** when a new error group is created, extract: error type, message, stack trace, affected file, recent code changes (from git blame), error frequency, affected users count
2. **Context enrichment:** pull the relevant source code for the top 3 frames in the stack trace using the source map
3. **Prompt assembly:** inject error data + source code into the debugging assistant prompt
4. **Analysis generation:** LLM produces: root cause summary, severity assessment, fix recommendation, affected area scope
5. **Integration:** display the AI analysis alongside the stack trace in the error monitoring dashboard
6. **Auto-assignment:** based on the affected file, automatically suggest which team member should be assigned (via git blame data)
7. **Fix tracking:** when the error is resolved, log whether the AI's suggested fix matched the actual fix — use this for prompt refinement
Temperature: `0.1` — debugging analysis must be precise and deterministic.
Teams using this pattern report **30–40% faster mean time to resolution** (MTTR) for production errors.
## Interview Question
:::info[Interview Question]
**Q: How would you design a debugging assistant prompt that handles a wide variety of error types across different languages and frameworks?**
**A:** I'd use a tiered architecture:
1. **Generic diagnostic layer** — the base system prompt encodes universal debugging methodology: classify the error type, read the stack trace, form hypotheses, identify root cause vs. symptoms. This works regardless of language.
2. **Language-specific pattern matching** — detect the language from the stack trace format and error type. Append context: "This is a Python application — common causes for AttributeError include: accessing attributes on None returns, typos in attribute names, incorrect import paths, circular imports."
3. **Framework-aware context** — if the stack trace includes framework frames (React, Django, Express), inject framework-specific debugging knowledge: "For React, TypeError on `.map` almost always means async data isn't loaded yet — check for loading states."
4. **Error pattern database** — maintain a prompt snippet library for the top 50 most common error patterns. When the error message matches a known pattern, inject the relevant snippet for higher accuracy.
5. **Feedback loop** — track when developers accept vs. modify the AI's suggestions, and use that data to refine the language/framework-specific layers.
:::
## Summary
:::note[Summary]
- A debugging assistant prompt must define a **systematic diagnostic process**: classify → analyze → hypothesize → fix → prevent
- Always require **full context**: error message, stack trace, relevant code, environment, and what's already been tried
- Demand **root cause analysis**, not just symptom treatment — the model should explain *why* the error happened
- Provide both a **minimal fix** (quick) and a **robust fix** (thorough) for every bug
- Use very low temperature (0.0–0.2) for debugging — precision matters more than creativity
:::