A year of AI coding / 07
Giving coding agents the right context
Useful context engineering starts with current, discoverable project knowledge and a way to distinguish authoritative instructions from incidental text.
By Grafty team · · 3 min read
Written in .
There are two authentication guides in a repository. One describes the current middleware. The other belongs to a migration that was abandoned six months ago. Both use the same terminology, and the older one is more detailed.
Giving an agent both documents does not necessarily make it better informed. It can make an obsolete design look like a valid alternative. Adding more context is not a substitute for maintaining the information itself.
Cursor's January 6, 2026 article on dynamic context discovery described loading relevant information as needed rather than including every available detail upfront. The engineering article discusses retrieving files, history, skills, and tool information. We think that approach puts a useful responsibility back on the repository: important knowledge has to be findable and interpretable.
Open full-size diagram Make the current answer easy to identify
Suppose an agent needs to determine how an internal reporting app restricts queries to the current user's department. Useful context includes the active authorization middleware, a representative query, and a test that rejects access across departments.
A long architecture document may explain the intention, but the implementation and tests establish what the system currently does. If they disagree, the task may need clarification before code generation continues.
We would keep short entry points for common questions. Where does authentication happen? How are database migrations run? Which commands verify a change? Link to the current material rather than copying it into several documents. Put obsolete plans somewhere their status is unmistakable.
Good names help too. A directory called old-auth-experiment is less likely to be mistaken for current guidance than one called auth-v2 after the team has reverted to the original implementation. Humans benefit from the same cleanup.
Open full-size diagram Retrieval needs boundaries
An agent finding relevant text does not mean that text should be treated as an instruction. Source code, issue comments, logs, and imported documents can contain arbitrary content. Some of it may be wrong or deliberately misleading.
A search result from a support ticket should not be able to authorize a production deployment. The system needs a distinction between project guidance, user instructions, and data being inspected. Tool permissions still have to hold even when retrieved content tells the agent to ignore them.
Access control also applies before retrieval. If a developer is allowed to work on one internal application, an agent acting for that developer should not automatically receive all organizational documents. A larger context window is not a reason to widen the data boundary.
For hosted inference, teams need to examine what retrieved content enters the provider request. Running the repository search on an internal server does not, by itself, keep the selected source snippets inside the network. The execution location and the inference location are separate decisions.
Check context with an unfamiliar task
One useful test is to give an agent a task in an area it has not worked on and inspect the evidence it uses. Does it find the active code path? Does it notice a deprecated document? Can a reviewer trace the implementation decision to a current source?
If the answer is no, adding another page of general instructions may not help. Improve the entry point, remove the contradiction, or make the relevant test easier to discover.
We would rather maintain a small amount of clear, authoritative context than carry a large collection of instructions nobody trusts. Agents can retrieve information quickly. Deciding which information deserves to guide the work is still an engineering responsibility.