How to prompt a coding agent for code changes

You end up with a code change you can review in minutes and merge the same day. The agent delivers exactly what you asked for, no surprises. To get there you write prompts that set constraints, name the files in scope, ask for a plan before a change, and demand stated assumptions.

Start with a plan the agent can’t ignore

Before the agent writes code, ask it to write a plan first. The plan should list the files it will change, the functions it will touch, and the order of changes. Put that plan in the prompt as a numbered list. That lets you catch wrong turns before any code runs.

Weak prompt: ask for a feature

Add a cache layer to the API so it serves stale responses when Redis is down. Use a short TTL and a fallback to a local cache if Redis is unreachable. Make sure the change is backward compatible.

Strong prompt: ask for a plan then the change

Write a plan first. The plan must include the files you will change, the functions you will touch, and the order of changes. After you write the plan, implement the change exactly as planned. Do not deviate from the plan without asking.

Constraints. Use a TTL of 30 seconds for stale responses. If Redis is unreachable, fall back to a local in-memory cache sized at 1 MB. Keep all endpoints backward compatible by reusing existing response shapes. Do not change the public API contract.

The agent must follow the plan or stop and ask before proceeding.

Name the files in scope

Tell the agent which files to read and which to change. Put the file list in the prompt so the agent can’t miss it. That prevents it from inventing files that don’t exist or editing the wrong ones.

• Only read and change the files in the list. Do not create new files without asking.
• If you need to read a file not in the list, ask first and wait for confirmation.

When the agent knows the exact files, it can surface scope overlaps early. Overlap warnings arrive when an agent claims work, which the five tools each contribute to in a different way.

Set constraints instead of adjectives

Describe what the code must do, not how good it should feel. Performance targets, API contract versions, library choices, and memory budgets are the moves that actually matter. Adjectives like “clean”, “elegant”, or “idiomatic” leave the agent guessing and you reviewing rewritten code.

• Use a memory budget of 512 MB for the cache. Do not exceed it.
• Keep the response time under 100 ms for 95% of requests. If you can’t meet it, ask before proceeding.
• Use Redis 7.2 and the official client library. Do not use other libraries.

When the agent can’t meet a constraint, it stops and asks. That prevents silent performance regressions and forces you to renegotiate the budget before the change ships.

Demand stated assumptions

Ask the agent to list its assumptions before it writes code. Put a section in the prompt titled “Assumptions”. That surfaces mismatches early, when they’re cheap to fix. Without this, assumptions live in the agent’s private session and only surface at PR review, when mistakes are expensive.

1. 01List every assumption you are making about the codebase and the environment.
2. 02If any assumption is wrong, stop and ask for clarification before proceeding.

For example, if the agent assumes the API contract changed, it will edit the wrong endpoints. Stating assumptions prevents that. When assumptions are wrong, the agent stops and waits for you to correct them. That turns the prompt into a mini-spec you can review line by line.

Put it all together: a working prompt template

Use this template for any code change. Fill in the blanks and the agent delivers a change you can review in minutes.

1. 01Write a plan first. The plan must include the files you will change, the functions you will touch, and the order of changes. After you write the plan, implement the change exactly as planned. Do not deviate from the plan without asking.
2. 02Constraints. Use a TTL of 30 seconds for stale responses. If Redis is unreachable, fall back to a local in-memory cache sized at 1 MB. Keep all endpoints backward compatible by reusing existing response shapes. Do not change the public API contract.
3. 03Only read and change the files in the following list: src/cache/redis.ts, src/cache/local.ts, src/api/handlers.ts. Do not create new files without asking.
4. 04Assumptions. List every assumption you are making about the codebase and the environment. If any assumption is wrong, stop and ask for clarification before proceeding.

Paste the prompt into your agent. It will write a plan, list assumptions, and then implement the change. You review the plan and assumptions first, then the diff. The change ships the same day.

Why this works

These moves turn a vague instruction into a mini-spec. Constraints replace adjectives, the file list prevents scope creep, the plan forces the agent to think before it codes, and stated assumptions surface mismatches early. Without them, the agent produces a change you still have to rewrite before it can ship.

For larger tasks, you need shared context so agents don’t work in private sessions. Concord keeps context in one place so every agent sees the same plan, constraints, and assumptions. Overlap warnings arrive when an agent claims work, which the five tools each contribute to in a different way.

If you run multiple agents, shared context prevents them from stepping on each other. You avoid merge hell and rework. That’s why agents working together needs a shared workspace, not just faster prompts.

I’m Alex Choi, AI Engineer. The mistakes I catch at PR review are the ones the agent never surfaced as assumptions.