Prompt engineering for coding agents: Claude Code, Cursor, and the terminal
A coding agent has your repository and none of your reasons. It can read every file you have and still not know which of them you consider finished. Almost everything that goes wrong downstream is a missing constraint rather than a missing instruction.
What an agent cannot see
An agent working in your project can read the code, run the tests and follow imports. What it cannot recover from any of that:
- Which files are settled and which are scratch. A half-finished module and a load-bearing one look identical from the outside.
- Why something is written the way it is. The odd-looking workaround is indistinguishable from a mistake worth cleaning up — and it will get cleaned up.
- What you already tried. Without it you get the obvious fix you already ruled out, confidently.
- What “done” means here. Whether a change ships behind a flag, needs a test, needs a doc updated in the same commit.
Every one of those is a sentence you could have written and did not.
Write the brief, not the instruction
“Add caching to the API layer” is an instruction. It has one verb and no boundary, so the agent picks the boundary — and it will pick a bigger one than you meant, because a thorough answer looks better than a narrow one.
The brief version says the same thing and closes the gaps:
- Goal.Cut the dashboard’s p95 by caching the three read endpoints it calls on load.
- Context. They hit Postgres directly. The data is per-workspace and changes a few times an hour.
- Constraints. No new dependencies. Do not touch the write path. Keep the existing function signatures.
- Done when. The three endpoints serve from cache on a second load, and the existing tests still pass unmodified.
The constraints are the part that changes the outcome. Without them, an agent that adds a caching library, refactors the write path for symmetry and updates twelve call sites has done excellent work on a task you did not set.
The three surfaces behave differently
Terminal agents
An agent with a shell will act on what you said and then keep going. Be explicit about scope and about what it may run. “Read-only until I say otherwise” is a sentence worth keeping in your fingers, and so is naming the directory you mean.
Editor chat panes
The pane usually has your open file and your selection, and nothing about the three files that matter. Say which files are in scope. Selection is an implicit argument that is right about half the time.
Plain chat
No repository at all, so context has to be carried in — and the failure mode is confident code against an API version you are not using. Give it the version and a real snippet of your surrounding code, or budget for a round of correction.
Ask for depth only where it pays
Extended reasoning is worth real time on questions with a genuine fork in them: root-causing something intermittent, choosing between two designs you will live with, planning a migration. It is worth nothing on a task with one obvious path, and you pay for it in latency on every request where you asked for it out of habit.
The useful test: could a competent colleague answer this without pausing? If yes, do not ask for deep reasoning. If they would need to go and look at something first, do.
Context that should not be retyped
Some of the brief is different every time — the goal, the specific bug. Most of it is not. Your stack, your conventions, which directory is which, the fact that you never want a new dependency added quietly: that is the same in every prompt you write this month, and typing it every time is the reason people stop typing it.
Yappr keeps that half. Tell it what you are building, once, and it reads every dictation against that — which sidebar you meant, spelled the way your repository spells it — so the brief that arrives is about the part you actually had to think about. What it does not do is paste those facts into the prompt: the agent has the repository in front of it, and telling it again what it can already read is cost without information.