Originally published at heycc.cn. This is a mirrored copy — the canonical version is kept up to date at the source.

Prompt Engineering for AI Coding Assistants in 2026

Prompt engineering for AI coding assistants is no longer about clever phrasing. In 2026, tools like Claude Code and Cursor are agentic: they read your files, run commands, write changes, and loop until something looks done. The prompt is no longer a question you ask once. It is the steering input to a process that can touch dozens of files autonomously. Getting it right is the difference between a session you can walk away from and one where every mistake waits for you to notice it.

What the vendor docs never do is sit next to each other. Anthropic publishes its best practices, Cursor publishes theirs, and nobody shows that "add tests for foo.py" and "add tests for auth.ts" are corrected for the same reason on both tools. That juxtaposition is the actual point of this piece, not a rehash of either vendor's guide on its own: if a technique below shows up as a quote from both Anthropic and Cursor independently, that's the signal the technique is a real constraint of agentic prompting, not one vendor's house style. If you already know Claude Code specifically, this article isn't trying to out-cover the single-tool Claude Code best practices writeup — go there for the deep dive on that one tool, and come here specifically for the cross-vendor evidence that the same techniques hold on Cursor too. For the persistent-rules angle in depth, see how to write Cursor Rules; for the full tool comparison, see best AI coding assistants of 2026.

The shared constraint behind both playbooks

The pillar article covers this in depth, so the short version will do here: Anthropic's Claude Code best-practices documentation states that most best practices derive from a single constraint — "Claude's context window fills up fast, and performance degrades as it fills." Every message, every file the agent reads, and every command output lands in that window, and as it fills the model starts forgetting earlier instructions and making more mistakes.

What is worth adding is the lens, because it is what makes the rest of this article cohere: almost every technique below is, at root, a way to protect that budget. Specificity reduces corrections, which means less polluted context. Verification closes the loop without you feeding more turns into the window. Lean persistent files keep per-request overhead down. Hold that one constraint in mind and the two vendors' advice stops looking like two checklists and starts looking like one strategy.

The cross-vendor synthesis: vague vs. specific, side by side

Both Anthropic and Cursor independently land on the same first principle: precise prompts need fewer corrections. Cursor's agent best practices put it directly — Cursor states that "the agent's success rate improves significantly with specific instructions." Anthropic frames the same idea as "the more precise your instructions, the fewer corrections you'll need."

Neither doc puts its examples next to the other vendor's. This table does, and that juxtaposition is the point — it shows the shape of a good prompt is identical across tools, which is the strongest evidence that the principle is real and not vendor marketing:

Vague prompt	Specific prompt	Source
"add tests for foo.py"	"write a test for foo.py covering the edge case where the user is logged out. avoid mocks."	Anthropic
"add tests for auth.ts"	"write a test case for auth.ts covering the logout edge case, using the patterns in __tests__/ and avoiding mocks."	Cursor
"fix the login bug"	"users report that login fails after session timeout. check the auth flow in src/auth/, especially token refresh. write a failing test that reproduces the issue, then fix it."	Anthropic
"implement a function that validates email addresses"	"write a validateEmail function. example test cases: [e-mail] is true, invalid is false, user@.com is false. run the tests after implementing."	Anthropic

Notice the pattern across all four: name the file, name the scenario, name the constraint, and — crucially — name a check the agent can run. The vague versions are not wrong English. They simply leave the agent guessing about scope, which it fills with assumptions you then have to correct. Each correction is another round trip that pollutes the context window, which is exactly the budget you are trying to protect.

Always give the agent a way to verify its work

This is the highest-leverage habit, and it is the verification half of the budget thesis. Anthropic's tip is verbatim: give Claude "a check it can run: tests, a build, a screenshot to compare." In the body of the same page Anthropic expands the list — a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot compared against a design — so "a linter" and "a build exit code" are documented elaborations, not part of the one-line tip.

The reasoning is mechanical, not aspirational: the agent stops when the work looks done. Without a check, "looks done" is the only signal available, and you become the verification loop. Give it something that returns pass or fail and the loop closes on its own — the agent runs the check, reads the result, and iterates until it passes. That is the loop closing inside the agent's turn instead of bouncing back to you and consuming more context.

Concretely, your prompt should end with a verifiable acceptance criterion. "Make the dashboard look better" becomes "implement this design [screenshot], take a screenshot of the result, compare it to the original, list the differences, and fix them." "The build is failing" becomes "the build fails with this error [paste error]. Fix it, verify the build succeeds, and address the root cause — don't suppress the error." If you cannot describe how to verify a task, that is a signal the task is underspecified, not that verification is optional.

Explore, then plan, then code, then commit

Letting an agent jump straight to coding produces code that solves the wrong problem. The pillar covers this four-phase workflow in full, so here is the compressed version and the part that matters for prompting. Anthropic prescribes a workflow built around plan mode, which exists to "separate exploration from execution":

1. Explore — in plan mode, the agent reads files and answers questions without making changes ("read /src/auth and understand how we handle sessions and login").
2. Plan — ask for a detailed implementation plan ("I want to add Google OAuth. What files need to change? Create a plan."). In Claude Code you can press Ctrl+G to open the plan in your editor and revise it before the agent proceeds.
3. Implement — switch out of plan mode and let it code against the plan, writing and running tests.
4. Commit — ask it to commit with a descriptive message and open a PR.

Cursor offers the same discipline through Plan Mode, toggled with Shift+Tab from the chat input, where the agent researches the codebase, asks clarifying questions, and writes a plan you can edit before building. The cross-vendor takeaway: both tools give you a dedicated read-only research phase, and both treat the plan as an editable artifact, not a black box.

Planning has a cost, so it is not always worth it. Anthropic's rule of thumb: planning is most useful when "you're uncertain about the approach, when the change modifies multiple files, or when you're unfamiliar with the code being modified." The sharpest version of the heuristic is verbatim Anthropic: "If you could describe the diff in one sentence, skip the plan." A typo fix, a log line, a rename — just ask for it directly. Cursor's docs echo the inverse for the hard cases: "for larger changes, spend extra time creating a precise, well-scoped plan," because the hard part is figuring out what change to make.

Let the agent find files; point to patterns, not whole style guides

A common instinct is to manually tag every relevant file. Cursor advises against overdoing it: "You don't need to manually tag every file in your prompt. Cursor's agent has powerful search tools and pulls context on demand." The agent uses grep and semantic search to find relevant code even when your prompt doesn't contain the exact words. Manual tagging is still useful when you know the exact location, but dumping the whole repo into context is the opposite of helpful — and, again, it is the context budget you are spending.

The same logic applies to conventions. Rather than pasting an entire style guide, reference a canonical example already in the codebase. Anthropic's example: "look at how existing widgets are implemented... HotDogWidget.php is a good example. Follow the pattern." One real file teaches the agent more, and cheaper, than a thousand words of abstract rules.

Keep persistent context lean

Both tools support always-on instruction files — CLAUDE.md for Claude Code, rules in .cursor/rules/ for Cursor. These are powerful because they give the model persistent project memory. They are also expensive, because anything that loads every session is overhead you pay on every request. Cursor's own behavior makes the cost concrete: an Always-Apply rule (alwaysApply: true) is, in Cursor's words, "applied to every chat session" — so its tokens ride along with every turn whether or not they are relevant. Anthropic is blunter about the failure mode: "Bloated CLAUDE.md files cause Claude to ignore your actual instructions."

The test Anthropic gives for every line is worth taping to your monitor — it is verbatim: "Would removing this cause Claude to make mistakes? If not, cut it."

Put it in persistent rules	Keep it out
Bash commands the agent can't guess	Anything it can learn by reading code
Code style that differs from defaults	Standard language conventions it already knows
Test runners and how to invoke them	Detailed API docs (link instead)
Branch/PR etiquette	Information that changes frequently
Non-obvious gotchas and env quirks	"Write clean code" and other self-evident slogans

If the agent keeps ignoring a rule you wrote, the file is probably too long and the rule is getting lost in the noise. Treat the rules file like code: prune it regularly and test whether changes actually shift behavior. For Cursor specifically, the four rule types and when to reach for each are covered in the Cursor Rules companion piece.

Correct early, and know when to start over

The last technique is the cheapest and the most ignored: course-correct the moment you see the agent drifting, rather than letting a wrong approach accumulate. Press Esc to stop Claude mid-action with context preserved, or tell it "undo that." But the deeper move is knowing when correction is no longer worth it. Anthropic's rule: if you have corrected the agent more than twice on the same issue, the context is now cluttered with failed approaches — run /clear and restart with a sharper prompt that incorporates what you learned. A clean session with a better prompt almost always beats a long session with accumulated corrections.

This closes the loop back to the thesis. Corrections are tokens. Failed approaches are tokens. A reset is the bluntest possible way to reclaim the budget, and sometimes it is the right one. Everything in this guide — specificity, verification, planning, lean rules, early correction — is a different lever on the same constraint: keep the agent's working memory focused on the task and free of noise.

Which quote came from where

Because the whole article rests on direct quotes, here is the attribution, re-verified on 2026-07-16. Everything sourced to Anthropic — the context-window constraint, the verification-check tip, plan mode's "separate exploration from execution," the Ctrl+G plan-edit shortcut, the one-sentence-diff heuristic, the bloated-CLAUDE.md warning, and the "would removing this cause mistakes" test — is verbatim from Anthropic's Claude Code best-practices page. The Cursor quotes — success rate improves with specific instructions, Shift+Tab Plan Mode, "you don't need to manually tag every file" — are verbatim from Cursor's agent best-practices guide and Plan Mode docs. One distinction matters: the "applied to every chat session" phrasing for Always-Apply rules is from Cursor's Rules documentation, but the "every token in every request" framing is a paraphrase, not Cursor's words. The techniques carry no pricing or version numbers because none are needed for them to hold.

Sources

• Claude Code best practices — Anthropic — the source for the context-window constraint, the verification-check tip, the Explore/Plan/Implement/Commit workflow, plan mode, the one-sentence-diff heuristic, the validateEmail/foo.py/login-bug/HotDogWidget.php examples, and the CLAUDE.md guidance.
• Agent best practices — Cursor — the "success rate improves with specific instructions" quote, the auth.ts test example, and the "don't manually tag every file" guidance.
• Plan Mode — Cursor docs — confirmation of Shift+Tab Plan Mode and the research-then-plan workflow.
• Rules — Cursor docs — Always-Apply rules being included in every chat.
• Best AI coding assistants of 2026 — the pillar comparison this playbook sits under.
• Claude Code best practices, explained — the single-tool deep dive on the workflow summarized here.
• How to write Cursor Rules — the persistent-rules companion piece.