If the agent cannot tell which instruction matters, adding five more instructions is not help. Good context points at the code and facts that decide the task.
The goal is relevance, not volume
A coding agent works from a limited view of your project: files it has read, instructions it has received, commands it has run and notes it has retained. Huge instructions can crowd out the current task and hide the one constraint that changes the implementation.
Start every task with a pointer to the relevant code, a description of the user-facing outcome and any constraint that cannot be inferred. Ask the agent to inspect before editing. Let source code answer questions about what the project currently does; let an explicit facts file answer stable project or brand information. When two sources disagree, state which one is authoritative.
Do not paste the entire repository into a prompt. Give the agent a path and an investigation question, then check whether it read the owner of the behaviour before proposing a change.
Keep durable instructions short and specific
A repository instruction file is useful for stable rules: how to run the app, where content lives, what patterns are accepted, what tests matter and which data is private. It is not the right place to narrate every prior task. Long historical files decay and create conflicts.
Write instructions so an agent can act on them. 'Keep changes localized to the blog renderer' is clearer than 'be careful'. 'Do not invent personal measurements; link the source for release claims' changes how writing is researched. Include examples when a convention is hard to infer.
Move detailed material beside the work that needs it. A schema belongs near the data type. A brand facts file can be linked from the content workflow. A long optional process can be a separate skill or guide instead of loading in every coding task.
A context loop for a focused change
Give the task, ask the agent to inspect the current behaviour, and have it state the specific files and constraints it found. Resolve any mistaken assumption. Then let it make the smallest coherent change. At the end ask what it changed, why, and what evidence verifies it.
Use file paths, symbols, exact output and errors rather than saying 'the thing doesn't work'. If a task spans an unfamiliar system, ask for a map before asking for a fix. If a narrow function is already known, point directly to it. This reduces wasted exploration and gives you a chance to catch a false starting point.
For expensive context, summaries should preserve decisions and important evidence, not chronological chatter. A useful handoff says what must remain true, what has changed, where relevant code lives and what is still unknown.
The agent's summary is not the verification
An agent saying 'done' does not prove the feature works. Run the relevant command, inspect the diff and try the user path that motivated the change. For content, open the actual page and confirm titles, links, images and citations render. For a data change, verify the key invariants against the source.
Ask for evidence with each completion statement. A passing type check shows the types are consistent, not that a feature is usable. A screenshot shows one state, not every boundary case. Match the verification to the failure that would matter.
Context engineering improves the chance that an agent does useful work. Accountability remains with the person deciding that the work is ready.
FOLLOW THE EVIDENCE
Sources & further reading
Process note: AI tools assisted with research and drafting. Sources are linked so you can inspect the evidence. Unless an essay says otherwise, it does not claim hands-on testing or independent reproduction.
