How to Prompt Claude for Code

Article summary

Claude is strong at code when you give it (1) the relevant file, not the whole repo; (2) the constraint up front (language version, library limits, public API to preserve); and (3) a clear "do this, return that" instruction. Iterate in 2–4 turns rather than writing one massive prompt. Push back on its first answer when it overengineers.

Claude has been one of the stronger code-assistant models for the past year. The prompts that get the most out of it look different from generic chatty prompts. Three things matter most.

1. Give it the relevant context, no more

The pattern that works:

I want to add a "soft delete" flag to the User model and have all queries default to excluding soft-deleted users.

Here is the model file:
[paste users.py]

And the query helpers that need to change:
[paste query_helpers.py]

Constraints:
- Python 3.12, SQLAlchemy 2.x
- Do not change the public API of query_helpers
- Backward-compatible: existing reads must keep working

Return a unified diff against both files.

Notice the discipline: only the two files that need to change. Constraints stated. Output shape specified. Claude does well with this kind of prompt.

What does not work: pasting your entire src/ directory and asking "what should I do about soft deletes?" Claude will try to be helpful and will spread its attention too thin.

2. State the minimum

Claude has been post-trained to be helpful, which sometimes shows up as overengineering. A vague prompt produces a 200-line refactor when you wanted a 5-line patch. To prevent this:

"Make the minimum change to X."
"Do not refactor unrelated code."
"Do not add tests in this turn."
"Do not add new dependencies."

These constraints sound restrictive but they make Claude's output much more reviewable.

3. Iterate in 2–4 turns

Code prompting works better as a conversation than as a one-shot. The pattern:

Turn 1: explain the goal, paste context, ask for a plan or a small diff.
Turn 2: react to what came back ("that works but you changed the function signature — keep it the same and use a wrapper instead").
Turn 3: ask for tests or for handling of a specific edge case.

Claude handles correction well when you point at the specific thing. "Your diff added an is_deleted column but missed the default. Add default=False, nullable=False." is much better than "this is wrong, try again."

What to push back on

Imports it did not need. Claude sometimes adds a defensive import "just in case." Strike it.
Try/except wrappers around code that cannot raise. Common overreach.
Renamed variables in your codebase. It will sometimes "improve" a name. Tell it to keep names unless asked.
Suggested follow-up refactors. Helpful in a planning conversation, noise in an implementation one. Tell it to skip them.

The general shape: give Claude tight scope, accept the first answer as a draft, push back specifically. That is what gets the best output, every time.

Frequently asked questions

Should I paste the whole repo?

No. Paste only the file you want changed plus the function signatures of anything it calls. Whole-repo dumps make Claude average across too much context and increase the chance of irrelevant suggestions. If you genuinely need cross-file awareness, use a tool-using setup that reads the repo on demand.

Should I ask for a diff or a full file?

Diffs when the change is small and you can review easily. Full file when there are too many small edits to track as a patch or when you want a clean replacement. For new files, always full file.

How do I stop Claude from overengineering?

State the constraint up front: "make the minimum change to fix X. Do not refactor unrelated code. Do not add error handling for cases that cannot happen." Claude responds well to explicit minimums; it will overengineer when given vague scope.