Prompt patterns that actually work for coding agents
A coding agent is only as good as what you point it at. The gap between developers getting real work out of these tools and developers fighting them is rarely the model — it's the prompt, the context, and the loop around them. This is a field guide to the patterns that hold up, each with a concrete before-and-after. Most of them come straight from the people who build the agents, and most of them are things good engineers already do to each other.
The one constraint everything follows from
Before any specific pattern, understand the thing they all serve: context is a finite, degrading resource. Anthropic's own guidance is blunt about it — as a model's context window fills up, "performance degrades," and Claude may start "forgetting earlier instructions or making more mistakes."[1] The company's context-engineering write-up names the phenomenon "context rot": as the number of tokens grows, "the model's ability to accurately recall information from that context decreases."[4]
The practical maxim that follows is worth taping to your monitor: aim for "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."[4] Every pattern below is, at bottom, a way to raise signal and cut noise. A vague prompt is noise. A bloated instructions file is noise. A 40-file exploration you didn't need is noise. Keep that lens and most prompting decisions answer themselves.
Point at examples, not adjectives
The single highest-leverage change most people can make is to stop describing what they want in adjectives and start pointing at concrete things: files, patterns, symptoms, success criteria. A model can infer intent, but "it can't read your mind."[1] The precision you skip in the prompt, you pay back in corrections.
Anthropic's best-practices guide is built around exactly these swaps. A few, adapted from its examples:[1]
| Instead of | Write |
|---|---|
| "add tests for foo.py" | "write a test for foo.py covering the edge case where the user is logged out. avoid mocks." |
| "add a calendar widget" | "look at how existing widgets are built — HotDogWidget.php is a good example — and follow that pattern. build from scratch without new libraries." |
| "fix the login bug" | "users report login fails after session timeout. check token refresh in src/auth/. write a failing test that reproduces it, then fix it." |
The common move is replacing a category ("tests", "a widget", "the bug") with a location and a shape. "Reference existing patterns" deserves special emphasis: existing code is the most information-dense specification you own, and "follow the pattern in HotDogWidget.php" carries more usable signal than any paragraph of prose about your house style.[1] When you find yourself reaching for an adjective — "make it consistent", "clean this up", "more robust" — stop and find the file that already embodies what you mean.
Explore and plan before you let it code
One of the most effective and least intuitive moves is to explicitly forbid the agent from writing code at first. Letting it jump straight to an implementation "can produce code that solves the wrong problem."[1] The recommended loop is four phases — explore, plan, code, commit — where the first two happen before a single line is written: have the agent read the relevant files and answer questions, then produce a written plan you can edit, and only then implement.[1]
This isn't just folklore. When OpenAI tested inducing an explicit plan-and-reflect step on the SWE-bench Verified coding benchmark, the pass rate rose by 4% from that one addition alone.[2] Planning surfaces the misunderstanding while it's still cheap to fix — in a paragraph of plan, not in 300 lines of confidently wrong code.
The honest counter-pattern matters just as much: planning has overhead, and small, well-scoped changes don't need it. Anthropic's guidance draws the line cleanly — "If you could describe the diff in one sentence, skip the plan."[1] Plan when you're uncertain about the approach, when the change spans multiple files, or when you don't know the code. Renaming a variable is not a planning occasion.
Give it a way to check its own work
An agent "stops when the work looks done," and without something it can actually run, "looks done" is the only signal it has — which quietly makes you the verification loop, catching every mistake by hand.[1] The fix is to hand the model a check that returns a real pass or fail: a test suite, a build, a linter, a screenshot to compare against. Then the loop closes on its own — the agent does the work, runs the check, reads the result, and iterates until it passes.[1]
In prompt terms, that means folding the verification into the ask:
| Instead of | Write |
|---|---|
| "implement a function that validates email addresses" | "write a validateEmail function. test cases: user@example.com → true, invalid → false, user@.com → false. run the tests after implementing." |
| "the build is failing" | "the build fails with this error: [paste]. fix it, verify the build succeeds, and address the root cause — don't suppress the error." |
Two habits sharpen this further. Prefer tests you wrote, because they encode your understanding of the problem rather than the model's guess at it. And demand evidence over assertion — "the test output, the command it ran and what it returned"[1] — because reading evidence is faster than re-running everything yourself. The rule compresses to five words worth remembering: if you can't verify it, don't ship it.
Before you accept a rewrite: when an agent regenerates a whole file, don't trust your eyes to catch what changed — paste the old and new versions into the diff checker and read the actual delta. It runs entirely in your browser, so nothing you paste ever leaves your machine.
The three reminders that make agents persist
When you move from a chat assistant to an autonomous agent — one that runs tools in a loop until a task is done — a small set of standing instructions makes a measurable difference. OpenAI's GPT-4.1 prompting guide distills them to three, and reports that together they raised the model's SWE-bench Verified score by close to 20%.[2] Paraphrased, they are:
- Persistence. Tell it not to hand control back early: "keep going until the user's query is completely resolved before ending your turn."[2] Without this, agents tend to stop halfway and ask whether they should continue.
- Use your tools, don't guess. "If you are not sure about file content or codebase structure... use your tools to read files and gather the relevant information: do NOT guess or make up an answer."[2] This is the single most effective line against hallucinated APIs and imagined file contents.
- Plan and reflect around tool calls. The optional planning reminder — the same +4% from earlier — asks the model to think before each action and reflect on the result after.[2]
Two mechanical notes from the same guide that quietly matter. Newer models tend to follow instructions "more literally" than older ones, so unequivocal directives beat hints you hope it infers.[2] And in a long prompt, repeating the key instructions at both the top and the bottom measurably helps.[2] If your agent frames edits as diffs, prefer a search/replace format with clear delimiters over one that leans on line numbers, which models get wrong.[2]
If you're building the agent rather than just prompting it, the biggest lever is often the tools themselves. Anthropic found that switching its file tools from relative to absolute paths "eliminated this failure mode completely," and states the principle plainly: "tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts."[3]
Persistent context, and knowing when to keep it loose
For anything you do more than once, stop re-typing the same context and write it down where the agent reads it automatically. Claude Code loads a CLAUDE.md file at the start of every session for exactly this — build commands, style rules, gotchas the model can't infer from code.[1] But the guidance comes with a sharp warning that people ignore at their peril: keep it short. "Bloated CLAUDE.md files cause Claude to ignore your actual instructions." The test for every line is "Would removing this cause Claude to make mistakes?" If not, cut it.[1] This is context rot again — a persistent-context file is only useful while it stays high-signal. The same "right altitude" applies: specific enough to guide behavior, flexible enough not to hardcode brittle logic.[4]
Two more session habits pay off constantly. Course-correct the moment you see drift rather than letting a wrong turn compound; and when you've corrected the same thing twice, clear the context and restart with a better prompt, because "a clean session with a better prompt almost always outperforms a long session with accumulated corrections."[1]
Finally, the limitation on all of this. Precision is a tool, not a religion — sometimes a loose prompt is the right call. When you're exploring, "what would you improve in this file?" can surface things you'd never have known to ask.[1] The deeper point is a division of labor: across real usage, people make roughly 70% of the planning decisions but only about 20% of the execution decisions.[5] Your job is to decide clearly what to build and how you'll know it worked; the patterns here are all in service of communicating that decision without noise. Get the intent and the check right, and you can afford to leave the how open. That, and not any single magic phrase, is what prompting a coding agent well actually is — and it starts with the humility to add complexity "only when it demonstrably improves outcomes."[3]
Sources
- Anthropic — Best practices for Claude Code (official documentation), accessed July 2026
- OpenAI — GPT-4.1 Prompting Guide, accessed July 2026
- Anthropic — Building Effective AI Agents (engineering blog), accessed July 2026
- Anthropic — Effective context engineering for AI agents, accessed July 2026
- Anthropic — How Claude Code is used in practice (research), accessed July 2026
Related: Using AI to write code: what actually works · Diff checker · Why Toolkit runs in your browser