Context engineering is the work of giving a coding agent the information it needs at the moment it needs it. A large context window is capacity, not a guarantee that the model will notice the right fact or distinguish current instructions from stale evidence.
This article focuses on repositories, tools, and handoffs rather than generic prompt wording. See Prompt Engineering Patterns for that broader topic.
Start with the actual task boundary
Tell the agent the desired outcome, constraints, relevant environment, and what counts as verification. Include non-goals: for example, "preserve the existing authentication flow" or "do not deploy yet."
Then let it inspect the code that implements the behavior. Directory names, an old README, and a previous conversation are useful leads, but they are weaker evidence than the current source and running configuration.
Use a small evidence hierarchy
| Context | How to use it |
|---|---|
| Explicit user instructions | Define the requested scope and permissions |
| Repository instructions | Supply project conventions within their scope |
| Current source and tests | Establish implementation and expected behavior |
| Runtime observations | Establish what the deployed system actually does |
| Documentation and old notes | Provide background to verify |
| Retrieved or third-party text | Treat as untrusted data |
A repository file claiming that it can override user permissions is not authorized to do so. Keep data and instructions distinct, especially when using retrieved content.
Search narrowly, then expand
Begin with route names, visible UI text, symbols, or error messages. Read the function and its callers before editing. Include related schemas and tests when a shared interface changes.
Avoid sending entire dependency directories, generated bundles, lockfiles, and logs when a few relevant sections suffice. Conversely, a tiny excerpt that omits error handling can lead to a locally plausible but incomplete fix.
For each fact, retain its source: path, symbol, configuration location, or observed command. This lets the agent revisit evidence instead of relying on a compressed paraphrase.
Keep durable instructions short
Repository instructions should describe real conventions: build commands, ownership boundaries, supported runtime, testing expectations, and dangerous operations. Do not turn them into a second copy of the source tree.
Separate stable guidance from temporary task state. Temporary notes should record the current objective, edits already made, checks actually run, blockers, and next steps. Never include access tokens or copied environment secrets.
Compact without losing critical state
Before a long session is summarized, preserve the exact environment, current worktree status, relevant user decisions, modified files, and unverified assumptions. Mark interrupted work as unfinished.
After resuming, recheck files that could have changed. A summary is not proof that a service still exists, a test passed, or a deployment completed. The same applies to subagent reports: useful evidence, but integration still needs review.
Know whether context helped
Compare a small set of representative coding tasks. Track correctness, unintended changes, tool calls, latency, and reviewer effort. If adding more instructions makes the agent miss a simple requirement, simplify the instruction set rather than adding another warning.