Context engineering for coding agents
What an agent is given decides what it gets right. Most agents fill their window with files and still miss the rule that matters, because it sits where no search for the task's words reaches.
In short
Context engineering is deciding what goes into a model's context at each step: instructions, tool results, files, history and facts. For coding agents the hard part is not the size of the window but what fills it — whole files read to find one rule, while the rule a change breaks sits in another area. Giving the agent the connected business logic a task touches, instead of the files, is what GitMir measures. In Benchmark 001 — one repository, fifty engineering questions, the same AI model and settings for every system — answers built on GitMir's model scored 92% against 78% for the strongest alternative, lost 8% of the score to errors and omissions against 22%, and used 8.4K tokens of context per question instead of 27.4K.
How you ask matters less than what the model has
Prompt engineering is the wording of a request. Context engineering is everything the model has when it answers: the rules file, the files an agent opened, tool results, the conversation so far and anything retrieved for it.
An agent that works through many steps rewrites its own context at every step. After the first few, the wording of the original request matters less than what the agent chose to read — and what it never found.
Full of files, missing the rule
Files, not facts
To learn one rule the agent reads whole files, and on a large product the files that matter do not fit.
Compaction keeps what looked important
When the window fills, a summary keeps what seemed central to the task. The constraint in another area rarely survives it.
Search finds similar words
Retrieval returns what resembles the task. The rule the change breaks often shares no word with it, so it is not returned.
Instructions go stale
A rules file describes the product on the day it was written. The agent cannot tell which lines stopped being true.
The connected part of the product a task touches
- The part the task lands on
The rule, customer path, feature or record the request is about — named in the product's own terms.
- What depends on it
Everything the change reaches, including parts in other areas that share no word with the request.
- The commit it is current to
So the agent knows whether the picture matches its branch, instead of trusting a snapshot.
- A check after the change
What the change touched and what it left out, before the commit lands.
Less context, more correct answers
In Benchmark 001 — one repository, fifty engineering questions, the same AI model and settings for every system — answers built on GitMir's model scored 92% against 78% for the strongest alternative, lost 8% of the score to errors and omissions against 22%, and used 8.4K tokens of context per question instead of 27.4K. The same run cost $0.07 a question against $0.19 and took 4.8 s against 9.6 s.
On Supabase Studio, the slice of the product one task needs measured 210 to 2,247 times smaller than the 30.5 MB of source an agent would otherwise search (4,688 files).
Every system, every number, and how to repeat it →What AI costs your team today →
Context engineering, done once for the whole product
GitMir Intelligence
Builds the model of the product from your code once and keeps it current with every push.
GitMir Vibe
Puts that model in the agent you already use, over MCP, with a check of each change before it is committed.
GitMir GMM-1
A model that works through specifications, codebases and data larger than an ordinary context window.
Asked about context engineering
Deciding what goes into an AI model's context at each step — instructions, tool results, files, history and facts — so that it has what the task needs and little else.
Prompt engineering is how a request is worded. Context engineering is everything the model has when it answers. For agents that work through many steps, the second decides most of the result.
It rebuilds how the product works by reading files, and on a large codebase the files that matter do not fit. When the window fills it compacts, and the rule in another area is what tends to be lost. Giving it the connected part of the product instead of the files keeps the context small and the rule in it.
Give the agent the connected facts a task needs rather than the files that contain them. In Benchmark 001 — one repository, fifty engineering questions, the same AI model and settings for every system — answers built on GitMir's model scored 92% against 78% for the strongest alternative, lost 8% of the score to errors and omissions against 22%, and used 8.4K tokens of context per question instead of 27.4K.
A bigger window holds more files; it does not tell the model which rule connects them, and every extra token is paid for on every step. What fills the window matters more than its size.
Read next
An MCP server for your codebase →CLAUDE.md and AGENTS.md from your code →Context is what you pay for →Reduce AI token costs →Benchmark 001 →
More guides
CLAUDE.md and AGENTS.md →MCP server →Architecture diagram from code →Change impact analysis →Spec-driven development →PRD template →Business rules extraction →All guides →
Give your AI the business logic of your product
Connect a repository and ask it in plain words — 10,000 credits to start, no card.