Table of Contents
You ask Claude for a function. It hands back forty clean-looking lines, with comments and everything. You paste it in, hit run, and the terminal fills with red.
So you paste the error back. Claude apologizes, rewrites half the file, and now something that used to work is broken too.
If that loop sounds familiar, the problem usually isn’t Claude. It’s that Claude had to guess your language version, your framework, your folder structure and your rules, and it guessed wrong.
Learning to prompt Claude for coding comes down to removing those guesses. Once you do, the code that comes back fits your project instead of a generic one.
In this post, I’ll show you the five things every coding prompt needs, a full prompt you can copy and adapt, and a debugging prompt that stops Claude from rewriting code you didn’t ask it to touch.
Why Claude Gives You Code That Looks Right but Breaks
Claude writes code the way it writes everything else. It predicts what a sensible answer looks like based on what you gave it.
Give it one sentence and it fills the gaps with the most common choices. That means popular libraries, older syntax, and an environment that might look nothing like yours.
Say you type “write a function that uploads a file to S3.” Claude has to decide on the language, the SDK version, how credentials are handled, whether it’s sync or async, and what happens on failure. You decided none of that, so Claude decided all of it.
Anthropic’s own guidance on this is blunt: Claude responds well to clear, explicit instructions. Coding is where that matters most, because a wrong assumption doesn’t just read badly. It crashes.
What to Include When You Prompt Claude for Coding
You don’t need a long prompt. You need the right five pieces of information, and you can write them in about two minutes.
The environment. Name the language and version, the framework, and anything unusual about where the code runs. “Python 3.12 with FastAPI” prevents a whole category of errors that “Python” doesn’t.
The goal in plain words. Say what the code should do and why it exists. A sentence about the purpose often changes the solution Claude picks.
The constraints. This is where most people stop short, and it’s the most valuable part. Tell Claude what it can’t do: no new dependencies, no breaking the existing function signature, no deprecated methods.
The input and expected output. One real example beats three paragraphs of description. Show what goes in and what should come out.
The format you want back. Do you want the full file, only the changed lines, or an explanation first? If you don’t say, you’ll get whichever Claude feels like.
Miss any one of these and you’ll feel it in the output. Cover all five and you’ll notice the first draft is usually close.
A Complete Coding Prompt You Can Copy and Adapt
Here’s what those five pieces look like when they’re put together. This one asks for a new API endpoint, which is a common job.
I'm adding a feature to an existing FastAPI app running on Python 3.12. It uses SQLAlchemy 2.0 with PostgreSQL and Pydantic v2 for validation. All our route handlers are async.
Write a POST /orders endpoint that creates an order for a logged-in user. The request body contains a list of product IDs with quantities and an idempotency key. If the same idempotency key is sent twice, the endpoint must return the original order instead of creating a duplicate.
Constraints:
- Do not add any new dependencies.
- Use type hints on every function.
- Return a 409 status only if the idempotency key exists but belongs to a different user.
- Keep the database logic in a separate function so it can be tested without the HTTP layer.
Example request body:
{"idempotency_key": "abc-123", "items": [{"product_id": 42, "quantity": 2}]}
Before writing any code, list the assumptions you're making about my database schema. Then give me the full endpoint, the database function, and three pytest tests that cover a new order, a repeated key, and a key that belongs to another user. Add a short note at the end flagging anything I should double-check.
Notice the last paragraph. Asking Claude to list its assumptions first is one of the most useful habits you can build.
If one of those assumptions is wrong, you catch it in ten seconds instead of after reading a hundred lines of code. You correct it, and Claude writes the real thing with accurate information.
How to Prompt Claude to Debug Code Without a Full Rewrite
Debugging is where Claude’s helpfulness can backfire. Give it a broken function and it’ll often “improve” the whole thing, which means new bugs and a diff you can’t review.
The fix is to tell Claude exactly what you want fixed, what to leave alone, and what order to work in.
Below is a Node.js function that's supposed to return the total price of a cart after applying a percentage discount. It returns NaN when the cart contains an item with no price field.
<code>[paste the function here]
</code> <error> Input: [{name: “Mug”, price: 12}, {name: “Gift wrap”}] Expected output: 12 Actual output: NaN </error> First, explain in two or three sentences what is causing the bug. Then give me the smallest possible change that fixes it. Do not refactor, rename variables, or change the function’s signature. Show only the lines that changed, with a line above each one saying what it does. If you think a larger refactor would help, mention it in one sentence at the end and wait for me to ask.
The “explain first” instruction forces Claude to find the real cause before writing a fix. That alone catches many wrong guesses.
The “smallest possible change” line is what protects the rest of your code. Without it, you’ll often get a rewrite you have to untangle.
Using XML Tags and Examples to Keep Long Coding Prompts Organized
Once your prompt includes code, error messages, requirements and sample data, it gets crowded. Claude can mix up which part is an instruction and which part is just pasted material.
That’s where XML tags come in. Anthropic’s documentation says they help Claude read complex prompts without confusion, especially when instructions, context, examples and inputs are all mixed together.
You saw this in the debugging prompt above, where the code and the error each sat inside their own tags. You can do the same for requirements, existing files, or style rules.
Examples work the same way. The docs suggest wrapping examples in their own tags and including three to five of them for best results. If you want Claude to match your naming style or your test format, paste two or three real samples from your codebase and tell it to follow them.
This is also the quickest way to get code that looks like your team wrote it. Describing your style takes paragraphs, and showing it takes ten lines.
Common Mistakes When You Prompt Claude for Coding
Most disappointing results trace back to the same handful of habits.
Leaving out the version. Libraries change their APIs often. If you don’t name the version, Claude may use syntax that was fine two years ago and fails today.
Pasting an error without the code. The error message tells Claude what broke, not why. Give it both, plus the input that triggered it.
Asking for everything at once. A prompt for a full app with auth, payments and a dashboard gets you shallow code in every area. Break big jobs into pieces and build them one at a time.
Accepting the first answer without testing it. Claude can write code that reads perfectly and still fails on an edge case. Run it, and ask Claude to write tests so the edge cases show up early.
Not saying what to leave alone. If a function works, tell Claude not to touch it. Otherwise it may decide to improve things you never mentioned.
How to Get Better Code Through Follow-Up Prompts
The first response is rarely the last. Think of it as a draft you’re about to review together.
A few follow-ups pay off almost every time. Ask Claude to review its own code for bugs and edge cases, and you’ll often get a short list of real issues. Ask for error handling on the parts most likely to fail, like network calls and file reads.
Ask it to explain any line you don’t understand, too. You’ll maintain this code, so you should know what it does.
If you find yourself rebuilding the same kind of prompt every week, with the same environment details and the same rules, that’s a sign you should save it as a template. The JSON Prompt Mastery for Claude product gives you 70+ pre-built structured prompts organized by business workflow, so you run the prompt and get the output without rebuilding the structure from scratch.
Make Specific Prompts a Habit
Claude writes good code when it knows your environment, your rules and what finished looks like. Most of the “bad code” people complain about is Claude filling in blanks that a few extra lines would have closed.
Start with the five pieces: environment, goal, constraints, an example, and the format you want back. Add the assumptions check and the “smallest possible change” rule, and you’ll spend far less time pasting errors back and forth.