Prompt Engineering for AI Coding Agents

What is prompt engineering?

Prompt engineering is the practice of writing and refining the instruction you give a model — its wording, structure, examples and output format — so the model does what you actually meant. It operates on one thing: the message you send, plus whatever system prompt sits above it. That definition sounds narrow, and it is. It's also, for a long time, been enough. In a single-turn chat, your prompt is the input: get it right and you get a good answer, get it wrong and no amount of retrying helps. An entire craft grew around that, and most of it is sound. Then coding agents arrived and quietly changed the arithmetic. An agent doesn't answer once — it plans, reads files, runs commands, reads the results, and goes again, twenty or thirty times. On each of those turns it re-reads everything that came before. Your carefully-worded instruction is still there, still doing its job, now representing perhaps 2% of what the model actually sees. I build token-reduction tooling, so I look at this from an unusual angle: I spend my week measuring what agents read. The consistent finding is that prompt quality decides whether the agent understands the task, and context volume decides what it costs and how reliably it finishes. Those are different problems, and the industry spent five years getting very good at the first one.

Does prompt engineering still matter for coding agents?

Yes — it's been demoted, not deleted, and the distinction matters because plenty of people have concluded the opposite. A vague instruction produces a wrong result no matter how clean your context is. "Fix the auth bug" sends an agent exploring half your repository; "the JWT refresh in auth/session.ts returns a stale token after the first renewal — find why" sends it to one file. That's prompt engineering doing exactly what it always did, and on an agent it pays twice: once in a better answer, once in the twenty files it didn't need to open. What changed is the ceiling. Once your instruction is unambiguous, further polishing returns very little, while the context around it keeps growing on every turn. Past that point, effort spent rephrasing is effort not spent on the thing that's actually compounding. The honest summary: prompt engineering is table stakes you get right once per task. It is not where the remaining leverage lives.

Which prompt engineering practices still hold?

The ones that reduce ambiguity survive. The ones that were compensating for a model's weaknesses mostly haven't. Be specific about the target, not just the goal. Name the file, the function, the symptom. Every unit of precision in the instruction is a unit of exploration the agent doesn't have to do — and exploration is the expensive part. State the constraints up front. "Don't change the public API", "keep it in TypeScript, no new dependencies". Constraints stated at the start cost a sentence; discovered at review, they cost a rewrite and every token that produced it. Ask for a plan before the edit on anything non-trivial. A plan is cheap to read and cheap to correct. A wrong twelve-file refactor is neither. This is the single highest-value habit I'd keep from the prompt-engineering era. Give an example when the format matters. If you want a specific commit-message style or test structure, one example beats three paragraphs of description. This is the old few-shot instinct, and it still works. Keep the system prompt stable. This one crosses over into cost: prompt caching only pays when the prefix is byte-identical across turns, and a cache read runs at roughly 10% of a fresh input token. A CLAUDE.md you edit mid-session defeats the cache and gets re-billed at full price — see how a bloated CLAUDE.md inflates your bill. What has aged badly: elaborate role-play preambles ("you are a senior staff engineer with 20 years..."), threats and bribes, and long lists of generic quality exhortations. Modern models don't need to be talked into competence, and every token of ceremony is re-read on every turn of the loop.

Why doesn't better prompting fix a big token bill?

Because the prompt is a fixed cost and the context is a growing one, so optimising the prompt improves the smaller number while the larger one keeps compounding. Here's the mechanism in one paragraph. On turn one the model reads your instruction plus the system prompt — call it 2,000 tokens. On turn two it reads that again, plus the file the agent opened. On turn twenty it reads all of it again: every file, every command output, every word it has already written. A 6,000-token file read early is billed on every subsequent turn. Your instruction, meanwhile, is still 2,000 tokens — now a rounding error against a 120,000-token window. Trimming a prompt from 2,000 tokens to 1,500 saves 500 tokens per turn. Not reading a 6,000-token file you didn't need saves 6,000 per turn, from that turn onwards. Both are real; they aren't the same order of magnitude. This is also why "be brief" is such a common piece of bad advice. It targets output, which is the small, expensive-per-token direction. The bill is dominated by input — the payload re-sent every turn. Brevity on output barely moves it. The context window is where the money is.

How is context engineering different?

Context engineering controls everything the model reads on a turn — files, tool output, transcript history, tool schemas — rather than just the instruction. Same discipline of deliberate input, one scope wider. The practical difference shows up in what you optimise. Prompt engineering asks "what should I say?". Context engineering asks "what should the model see, in what form, in what order?" — and in an agent session the answer to the second question is a thousand times larger than the answer to the first. The four levers that actually move it:

Retrieve, don't read. Point the agent at a symbol rather than a file. Semantic code search returns the relevant 200 tokens instead of the whole 6,000-token file.
Filter tool output. A failed test run can emit 15,000 tokens of which about fifty matter. Output filtering keeps the failing assertion and drops the rest.
Read structure before bodies. Hand the model signatures and exports first; let it open a body only when it needs one. That's context compression applied to code.
Load tools lazily. Every connected MCP server advertises its schemas on every turn, used or not. Deferring that until a tool actually fires removes a standing tax.

None of these is a prompting trick, which is the point. Context engineering vs prompt engineering works through the split in detail, and context engineering for AI coding agents is the full discipline.

How do you apply this without micromanaging every session?

You automate the levers, because the techniques only work if applied consistently and humans are unreliable under deadline. The manual route is honest and it works: write precise instructions, ask for plans, keep CLAUDE.md stable, pipe noisy commands through something terse, start a fresh session per task, disconnect MCP servers you're not using. If you'll actually do that every day, you don't need to buy anything, and I'd rather say so than pretend otherwise. Tokenade exists for the days you won't. It applies semantic retrieval, output filtering, structure-first reads and lazy MCP loading automatically inside Claude Code, Cursor, Codex, Copilot and Windsurf, with a dashboard showing measured savings rather than asking you to take the effect on faith. It's source-available under MIT, so you can read exactly what it does to your context before trusting it with a session, and the free tier is enough to see whether the numbers move on your own work.

What goes wrong (anti-patterns)

Treating prompt engineering as the whole job. It's the part with the most written about it, which makes it feel like the frontier. On an agent it's the opening move, not the game. Rewriting the prompt to fix a cost problem. If your bill is high, the prompt is almost never why. Measure what the agent read before rewriting what you said. Ceremonial preambles. Role-play framing, capability affirmations and generic quality demands are re-read on every turn for the life of the session. They're a recurring charge for a one-time reassurance. Editing CLAUDE.md mid-session. Every edit breaks the cached prefix and re-bills the whole thing at full price. Stabilise it, then leave it alone. Confusing brevity with efficiency. Asking the model to answer briefly trims output. Your bill is input. These are different ends of the meter.

Frequently asked questions

Is prompt engineering a dying skill?

No, but it's stopped being a specialism. It's becoming what knowing how to write a good bug report is — a baseline professional skill rather than a job title. The part that's genuinely fading is the folklore layer: incantations, threats, elaborate personas. The part that's durable is precision about what you want, which was never really about models.

What's the difference between a prompt and context?

The prompt is what you write; the context is everything the model reads, which includes your prompt plus the system prompt, file contents, tool output, tool schemas and the accumulated transcript. In a chat those are nearly the same thing. In an agent session the prompt is a small fraction of the context, which is why the two need separate names.

Does prompt engineering reduce token usage?

Marginally and indirectly. A precise instruction prevents wasted exploration, which genuinely saves tokens — that's a real effect, and worth having. But shortening the prompt itself saves a fixed amount per turn, while the context grows turn over turn. Precision helps; brevity in the instruction barely registers.

Should I learn prompt engineering or context engineering first?

Prompt engineering, because it's smaller, transfers everywhere and you can't skip it. Then look at what your agent actually read to satisfy your instruction — that's where the surprises are, and measuring agent token usage shows how to see it.

Do these practices apply to Cursor, Copilot and Codex too?

Yes. The prompting advice is model-flavoured at most, and the cost mechanics are agent-agnostic: every tool that re-reads its transcript each turn has the same compounding problem. How to reduce AI coding agent token usage covers the cross-agent version.

See also:

Context engineering vs prompt engineering — where the two disciplines split.
Context engineering for AI coding agents — the full discipline this hands off to.
How a bloated CLAUDE.md inflates your bill — the system-prompt side, costed.
How to reduce AI coding agent token usage — the six levers, cross-agent.
Measuring agent token usage — how to get your own baseline.