Best Claude Prompts for Coding

A developer once spent two hours debugging a flaky test, convinced the issue was in the test setup. It wasn't. The AI-generated fix she'd applied the day before had solved the problem she'd asked about, but introduced a subtle race condition in a different function that the fix had touched unnecessarily. The fix was technically correct for the specific function she'd asked about. The problem was the prompt never said to leave other code untouched.

This is a specific, real failure mode for AI-assisted coding. The prompts below are built around preventing it.

Before: The Weak Prompt

Fix the bug in this function.

Three problems. It doesn't specify what "the bug" is -- which forces Claude to infer from the code, which may or may not be correct. It doesn't constrain scope -- Claude may "fix" the stated issue but change related code that seemed relevant. And it provides no behavioral specification -- so Claude can't tell whether the fix is correct against what the function is actually supposed to do.

Why It Fails

A vague fix prompt produces a fix that is coherent from Claude's perspective but not necessarily correct for your system. Claude sees the code you pasted. It doesn't see the rest of the codebase, the tests that depend on this function, the data contract other services expect, or the specific conditions under which the bug manifests. It fills those gaps with reasonable assumptions -- and reasonable assumptions are wrong often enough to cause real problems in production code.

The scope problem is more insidious because the changes often look helpful. Claude might "clean up" a related function while fixing the one you asked about, or adjust an import that it noticed was slightly different from convention. Each of those changes individually seems fine. Together, they create a diff that's hard to review and may introduce subtle issues with functions you weren't thinking about.

After: The Improved Prompt

There's a bug in this function: [paste code]

The bug: [describe the specific behavior that's wrong -- e.g., "this returns None when called with an empty list instead of returning an empty list"]
Expected behavior: [what it should do]
How to reproduce: [specific inputs that trigger the bug]

Constraints:
- Only change code within this function -- do not modify the function signature, calling code, or related functions
- If fixing this requires changing something outside this function, stop and tell me what needs to change and why, so I can decide whether to do it
- After the fix, explain in one sentence what caused the bug

Here are the tests this function needs to pass: [paste tests if you have them]

What this does: The "stop and tell me" instruction is the most important element -- it converts Claude from an agent that silently modifies scope into one that surfaces scope decisions explicitly, keeping you in control of what changes and what doesn't.

Breaking Down Each Element

The reproduction steps aren't just good debugging practice -- they help Claude generate a fix that's actually correct for the triggering condition rather than a fix that looks correct in general. "Returns None when called with an empty list" produces a different and more targeted fix than "has a bug somewhere."

The test requirement at the end is optional but valuable: if you have tests, pasting them gives Claude a verifiable definition of "correct" to work against rather than its own inference. This dramatically reduces the chance of a fix that passes your manual check but fails edge cases the tests already cover.

⚡ Pro tip: For any fix that touches logic with financial, security, or data-integrity implications, always add: "After writing the fix, identify the top two ways this change could introduce a new bug in adjacent code -- not theoretical, specifically in this codebase given what I've shown you." This forces an adversarial review of the fix itself before you ship it.

Three Real Scenarios

A backend engineer working on a payment processing service used the scope-constraint prompt format specifically for a rate-limiting bug -- the previous AI-assisted fix had worked but had silently changed how failed payment events were counted, which only surfaced in the monthly reconciliation a week later. Explicit scope constraints on subsequent fixes meant each change had a reviewable, bounded diff.

A data engineer debugging a Spark job used the reproduction-steps format to get Claude to correctly identify that the issue was a type coercion that only occurred for a specific combination of column types -- a bug the generic "fix this" prompt had missed entirely because it only saw the function in isolation rather than the specific data shape that triggered the failure.

A frontend developer used this approach for a React state bug that manifested only in a specific sequence of user interactions. Writing out the reproduction steps in the prompt format ("user clicks X, then Y, then Z, and the component renders W instead of V") turned out to clarify the bug so precisely that she understood the root cause herself before Claude had even finished the response.

Variations for Different Contexts

Architecture decision prompt:

I'm deciding between [option A] and [option B] for [specific technical problem].

Context: [describe system, scale, team size, existing tech stack]
My constraints: [performance requirements, cost, maintainability concerns]

Don't tell me "it depends" without then actually making a recommendation. Give me your best call for this specific context, explain the top risk with your recommended option, and tell me what would change your recommendation.

What this does: Forbidding "it depends" without a follow-through recommendation forces Claude to take a position rather than hedging -- which is what you actually need when making a real technical decision.

Three Real Scenarios

A backend engineer working on a payment processing service used the scope-constraint prompt format specifically for a rate-limiting bug -- the previous AI-assisted fix had worked but had silently changed how failed payment events were counted, which only surfaced in the monthly reconciliation a week later. Explicit scope constraints on subsequent fixes meant each change had a reviewable, bounded diff.

A data engineer debugging a Spark job used the reproduction-steps format to correctly identify a type coercion that only occurred for a specific combination of column types -- a bug the generic "fix this" prompt had missed entirely because it only saw the function in isolation rather than the specific data shape that triggered the failure.

A frontend developer used this approach for a React state bug that manifested only in a specific sequence of user interactions. Writing out the reproduction steps in the prompt format ("user clicks X, then Y, then Z, and the component renders W instead of V") turned out to clarify the bug so precisely that she understood the root cause herself before Claude had finished the response.

A Documentation Prompt for Code You're Handing Off

Write documentation for this function/module: [paste code]

Audience: [e.g., "a developer joining the team who's familiar with Python but hasn't seen this codebase"]
Include: what it does (one sentence), the inputs and outputs with types and expected ranges, any non-obvious behavior or edge case handling, and one concrete usage example.

Do NOT include: implementation details that would make the docs need to change if the implementation changes -- document the interface, not the internals.

What this does: The instruction to document the interface rather than the internals is a discipline that senior engineers apply automatically but junior engineers and AI-generated docs often violate -- implementation-level documentation becomes incorrect or misleading the moment the code is refactored, while interface-level documentation stays accurate much longer.

Save and Reuse This

The core pattern here -- specify the bug precisely, constrain the scope explicitly, require flagging before scope expansion -- works across languages and bug types. Once you have built the version that fits your team conventions (naming your test framework, your review standards, your scope norms), it is worth keeping as a shared template for claude prompts for coding across your team. A stored, tested prompt used by five developers catches five times as many scope surprises as a custom prompt written fresh each time.

The documentation prompt is particularly worth standardizing -- not because documentation takes a long time to write, but because it gets skipped under deadline pressure more consistently than almost any other development practice. A 90-second prompt run before closing a PR is a lower barrier than a separate documentation task on the backlog, and the output is accurate to the current implementation rather than written from memory three sprints later. Encoding this as a standard step in your team's PR process, rather than an optional extra, is the practice that actually produces documentation that stays useful over time.