Prompt engineering for coding is the difference between an agent that ships a working pull request and one that quietly breaks something in production. We learned that the expensive way: one vague instruction in our own pipeline once minted 54 duplicate live pages before anyone noticed. These days a 16-agent Claude Code setup writes, translates, and publishes our content, and the prompts driving it look nothing like the 50-template lists on the first page of Google. Here are the 7 patterns we type every day, each with a real before-and-after.
Quick answer: Good coding prompts share one shape. You state the goal and the definition of "done," name the exact files in scope, force a plan before any edit, hand over the tests, and demand evidence instead of a "looks good." Do that and a modern agent (Claude Code, Cursor, GitHub Copilot) writes code that passes review the first time far more often. Skip it and you get confident, plausible slop.
The 7 patterns, in the order we reach for them:
- Task framing: goal, constraints, and "done" up front
- Context selection: name the files, fence off the rest
- Plan-first: make it propose before it edits
- Test-first: put the acceptance tests in the prompt
- Debugging: error plus repro plus expected, root cause before fix
- Refactor: change the structure, keep the behavior, show the diff
- Review: a checklist to grep against, plus evidence
Prompt Engineering for Coding vs. Config Files: What Goes Where
Config files and per-task prompts do different jobs, and conflating them is the most common mistake in this space. A CLAUDE.md or a .cursor/rules file is standing policy the agent reads every session: your stack, your naming conventions, your test command. A prompt is the specific job you hand it right now. Durable rules go in config; the task goes in the prompt.
Most "coding prompts" roundups blur this and tell you to paste a giant persona prompt into .cursorrules. That bloats the config the agent loads on every single task and still fails to frame the one job in front of it. Keep the two separate:
| Config file (CLAUDE.md, .cursor/rules) | Per-task prompt | |
|---|---|---|
| Holds | Standing rules: stack, style, test command, guardrails | The specific task: what to build or fix, right now |
| Loads | Automatically, every session | Once, when you type it |
| Changes | Rarely, reviewed like code | Every task |
| Example | "Run pnpm test before claiming done" | "Fix the tax rounding in cart.ts for orders over $1,000" |
If you want the config side done well, we cover it in depth in our CLAUDE.md best practices and Cursor rules guide. This article is the other half: the prompts you type fresh each time. Both sit under our broader prompt engineering guide if you want the fundamentals first.
Prompt Engineering for Coding: The 7 Patterns We Use Daily
Each pattern below has the weak version people actually type and the strong version that gets working code. The weak-to-strong gap is almost always the same move: replace a wish with a spec.
1. Task Framing: State the Goal, Constraints, and "Done"
Task framing means writing the goal, the constraints, and what "done" looks like before the agent touches a line. An agent optimizes for whatever you literally asked, so a fuzzy request earns a fuzzy patch. Name the file, the behavior you want, the acceptance check, and the things it must not change.
This is the pattern that cost us 54 pages. Our old translation instruction was basically a wish:
Weak: Re-translate this post into German and keep the brand names.Nothing in there says what a slug is allowed to do. So on a re-run, the agent "improved" the URL slug, and because a new slug means a new document, we ended up with two live German pages for the same post. Multiply across languages and old posts and you get 54 duplicates and a pile of duplicate-content exclusions. The fix was a spec, not a nicer wish:
Strong: Re-translate this post into German.
- If a German file already exists, copy its existing slug verbatim. Never
re-derive or "improve" it.
- Before creating any document, look up the existing one by its canonical
reference and reuse that record.
- If the slug you would generate differs from the live one, STOP and tell me.
A changed slug creates a second live URL for the same page.The strong prompt names the failure mode out loud. That single habit, saying what must not happen and why, is the single most valuable change most teams can make. We also end every task prompt with an explicit output contract ("your final message must report the word count, the validation score, and any files touched") so the agent knows what "done" produces, not just what to do.
2. Context Selection: Name the Files, Fence Off the Rest
Context selection means telling the agent exactly which files to read and which to leave alone, instead of letting it grep around and pack its window with noise. Anthropic's own guidance is blunt about the reason: the context window fills fast and quality drops as it fills, so most best practices exist to protect it (Claude Code best practices).
Weak: Fix the bug in the checkout flow.
Strong: Read only src/checkout/cart.ts and src/checkout/tax.ts. The tax
rounding is wrong for orders over $1,000 (it rounds each line item instead
of the order total). Fix the rounding. Do not touch anything outside
src/checkout/.We fence hard. A real line from our agent prompts reads: "do not write to url-mapping.json, pipeline.md, or config.json, and never touch any file outside your scratchpad directory." That one sentence has prevented more accidental damage than any amount of cleanup after the fact. When the task genuinely needs live docs or extra tools, we add them deliberately through MCP servers rather than hoping the agent stumbles onto the right file. And if any of that context comes from outside your repo, treat it as untrusted: see our note on prompt injection prevention before you paste a scraped page into a coding agent.
3. Plan-First: Make It Propose Before It Edits
Plan-first prompting makes the agent hand you an approach before it edits anything. In Claude Code, Plan Mode is a hard, enforced read-only state, not a polite "think first" the model can wander past, so it literally cannot write until you approve the plan. Separating research and planning from execution is the single practice Anthropic leans on most to avoid solving the wrong problem.
Weak: Add rate limiting to the API.
Strong: Before writing any code, give me a numbered plan: which middleware,
where the counters live, how you handle the 429 response and headers, and
which tests you'll add. Wait for my approval before editing.Why it works: the plan is cheap to read and cheap to correct. Fixing a wrong plan costs one sentence; fixing wrong code costs a review cycle. This pairs naturally with asking the model to reason step by step first (see chain-of-thought prompting), and it is the backbone of the multi-step Claude Code workflows we run for anything non-trivial.
4. Test-First: Put the Acceptance Tests in the Prompt
Test-first prompting puts the acceptance criteria into the prompt as concrete inputs and outputs, so the agent writes code against a target you defined rather than one it guessed. Paste the failing test, or a small table of expected results, and say "make this pass without editing the test."
Weak: Write a function to parse ISO 8601 dates.
Strong: Make this failing test pass without changing the test:
parseIso("2026-07-20T15:00:00Z") -> Date at that exact UTC instant
parseIso("2026-07-20") -> Date at 2026-07-20T00:00:00Z
parseIso("not-a-date") -> throws RangeError
parseIso("") -> throws RangeError
Return only the function and its imports.Concrete examples beat adjectives every time. "Handle edge cases" is a hope; four input-to-output rows are a specification the model can actually satisfy, and you can run them the second the code lands.
5. Debugging: Error, Repro, Expected, Root Cause Before Fix
A debugging prompt gives the agent the error text, the input that triggers it, and what you expected, then asks for the cause before any fix. Skip that and the agent patches the symptom, so the bug simply moves somewhere quieter.
Weak: This is throwing an error, fix it.
Strong: This throws on checkout. Here's the stack trace: [paste]. It happens
only when the cart has a discount code AND a gift card (repro: add both, then
check out). Expected: both apply, gift card last. Find the root cause and
explain it in one sentence before you change anything. Do not wrap it in a
try/catch that hides the error.The "explain the cause in one sentence first" line is doing real work. It forces the model to commit to a diagnosis you can sanity-check, instead of shipping a fix whose logic you never see. The "don't hide it in a try/catch" line closes the most common escape hatch.
6. Refactor: Change the Structure, Keep the Behavior, Show the Diff
A refactor prompt constrains scope hard: change the structure, keep behavior identical, and show the diff. Without a fence, agents "tidy" things you never asked about, and you lose the ability to review the change that mattered.
Weak: Clean up this file.
Strong: Extract the validation logic from submitOrder() into a pure function
validateOrder(). Keep every public signature and all behavior identical.
Change nothing else in this file. Show me a before/after diff and one line
on why each change is behavior-preserving.This is the flip side of the config-versus-prompt split from earlier: your standing style rules live in Cursor rules, but the scope of this refactor belongs in the prompt. "Change nothing else" is the phrase that keeps refactors reviewable.
7. Review: A Checklist to Grep Against, Plus Evidence
A review prompt hands the agent a checklist to grep against and demands evidence, not a verdict. "Looks good" is worthless; the command it ran and the output it got is not. Anthropic puts this plainly: have the agent show evidence (the test output, the command and its result) rather than assert success, because reading evidence is faster than re-verifying yourself.
Weak: Review my PR.
Strong: Check this diff against exactly these five items:
1. No secrets or API keys added
2. Every new function has a test
3. No behavior change outside src/checkout/
4. Error paths return typed errors, not strings
5. No console.log left behind
For each item, quote the line that satisfies or violates it. Then run the
test suite and paste the output. Do not say "done"; show me.Our own review gate is built exactly this way. Before an agent is allowed to report a post as published, it greps the draft against a banned-word list (a hard blocker, zero tolerance) and runs a query to confirm the document body is not empty. The agent does not get to claim success; it has to produce the check output. For reviewer roles you reuse a lot, promote the checklist into a saved persona, which is where system prompt examples come in.
Claude Code vs. Cursor vs. Copilot: Where Each Pattern Lives
All three major 2026 agents support every pattern above, but the surface differs. Claude Code leans on Plan Mode and subagents, Cursor on Agent mode and its Agents window, and GitHub Copilot on agent mode plus instruction files. Pick the tool your team lives in; the patterns port cleanly.
| Pattern | Claude Code | Cursor | GitHub Copilot |
|---|---|---|---|
| Standing rules | CLAUDE.md | .cursor/rules | .github/copilot-instructions.md, AGENTS.md |
| Plan-first | Plan Mode (enforced read-only) | Plan step in Agent mode | Preview plan before apply |
| Scoped/parallel work | Subagents, own context each | Agents window, worktree per agent | Cloud agent tasks |
| Path-scoped rules | Nested CLAUDE.md per directory | Rule globs | .instructions.md with applyTo |
A few current details worth knowing. Claude Code's Plan Mode is a genuine read-only lock, and its subagents each run in an isolated context with their own tools (subagents docs). Cursor's 2026 line added an Agents window that spins up parallel agents, each in its own git worktree (Cursor 2.0). GitHub Copilot's agent mode reads custom instructions from .github/copilot-instructions.md, plus path-scoped .instructions.md files with an applyTo field (Copilot custom instructions). If Cursor is your daily driver, see our post on using Cursor more efficiently.
How We Prompt Our Coding Agents at Techsy
We run a content pipeline as a team of 16 Claude Code agents: a researcher, a brief writer, a content writer, nine translators, a validator, and a publisher, coordinated through task messages. Two conventions from that system carry over to any coding team.
First, every task prompt ends with an output contract. The last line is always some version of "your final message must report X, Y, and Z." An agent that knows the exact shape of "done" wanders far less than one told only what to start.
Second, we never let an agent grade its own homework in prose. Generation and verification are separate steps, and the verification is a command with output, not an opinion. That separation of build and check is core to how Anthropic frames building reliable agents, and it is why our review gate greps and queries instead of trusting a "looks good."
This is also the day job. At Techsy we build AI agents and automation for B2B teams, and prompt discipline like this is most of what separates a demo from something you can put in front of a client. If you want a coding or agent workflow set up properly, our AI integration service is where we do exactly that, and you can book a free consultation to talk through your stack.
A Copy-Paste Prompt Template You Can Adapt
Here is the skeleton we start from for any non-trivial coding task. Delete the sections you don't need, but keep the order, because it mirrors the seven patterns.
GOAL
One sentence: what should be true when you're done.
CONTEXT
Read only: <exact files>. Ignore everything else.
Relevant facts: <constraints, versions, the bug's trigger>.
PLAN FIRST
Before editing, give me a numbered plan and wait for approval.
TESTS / DONE
Done means: <paste failing test or input->output rows>.
Don't change the tests.
CONSTRAINTS
Keep all public signatures and behavior identical unless stated.
Do not touch <files/areas>. Name any assumption you make.
OUTPUT
Show a before/after diff, run the tests, and paste the output.
Don't say "done"; show the evidence.Save it as a snippet, or better, split it: the standing constraints go in your config file, and the goal, context, and tests go in the prompt. That split is the whole point.
About the Author
Mert Batur Gurbuz is Co-Founder of Techsy.io, where the team ships AI agents, automation systems, and voice/SDR pipelines for B2B clients. He studies at the University of Birmingham and writes about the LLM tooling stack the Techsy team actually uses in production.
Credentials: Co-Founder, Techsy.io, University of Birmingham. Connect on LinkedIn.
Frequently Asked Questions
What is prompt engineering for coding?
Prompt engineering for coding is the practice of writing instructions that get an AI agent to produce correct, reviewable code. In practice it means stating the goal and definition of "done," naming the files in scope, forcing a plan before edits, supplying tests, and demanding evidence. It is closer to writing a spec than to writing a clever sentence.
How is it different from writing a CLAUDE.md or .cursor/rules file?
Config files hold standing policy the agent reads every session: your stack, conventions, and test command. A per-task prompt is the specific job you hand it right now. Put durable rules in config and the task in the prompt. Pasting whole task prompts into a config file bloats every session and still fails to frame the individual task.
What is the best prompt structure for AI coding agents?
Use labeled sections rather than one paragraph: GOAL, CONTEXT, PLAN, TESTS, CONSTRAINTS, and OUTPUT. Agents parse structured prompts more reliably than walls of text. State success criteria up front, give one to three concrete examples instead of adjectives, and specify the exact output format you want back.
How do I write a good debugging prompt?
Give the agent four things: the exact error or stack trace, the input that reproduces it, what you expected, and a request for the root cause before any fix. Add "explain the cause in one sentence before changing anything" so you can check the diagnosis, and "don't hide it in a try/catch" so it fixes rather than masks the bug.
Should I include tests in my coding prompts?
Yes, whenever you can. Pasting the failing test or a small table of input-to-output rows turns a vague request into a target the model can actually hit, and you can run the result immediately. Tell the agent to make the tests pass without editing them, so it can't move the goalposts to make its own code look correct.
Do these prompts work in Cursor and GitHub Copilot too?
Yes. The patterns are tool-agnostic. Claude Code exposes them through Plan Mode and subagents, Cursor through Agent mode and its Agents window with a worktree per agent, and GitHub Copilot through agent mode plus .github/copilot-instructions.md. The surface changes; task framing, context selection, plan-first, and evidence-based review do not.
How long should a coding prompt be?
Long enough to be a spec, short enough to stay focused. Reasoning quality degrades as the context fills, so favor structure over volume: a labeled, 150-to-300 word prompt with the right files and tests beats a rambling one. Move anything that applies to every task into your config file instead of repeating it.
How do I stop an AI agent from changing code I didn't ask about?
Fence the scope in the prompt. Say exactly which files it may edit, add "change nothing else," and require "keep all public signatures and behavior identical unless I say otherwise." For refactors, ask for a before/after diff with one line on why each change is behavior-preserving, so any unrequested edit is obvious in review.
Are copy-paste prompt libraries worth it?
As a starting point, sometimes. As a finished tool, rarely. A 50-prompt library gives you phrasing, but it can't know your files, your tests, or your constraints, which is where correctness actually lives. Learn the patterns, keep one adaptable template, and fill in the specifics of the task in front of you.