# Context engineering for coding agents

https://gitmir.com/context-engineering · updated 2026-10-07

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

1. **The part the task lands on** — The rule, customer path, feature or record the request is about — named in the product's own terms.
2. **What depends on it** — Everything the change reaches, including parts in other areas that share no word with the request.
3. **The commit it is current to** — So the agent knows whether the picture matches its branch, instead of trusting a snapshot.
4. **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](https://gitmir.com/benchmarks)
- [What AI costs your team today](https://gitmir.com/ai-cost)

## 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. https://gitmir.com/products/intelligence
- **GitMir Vibe** — Puts that model in the agent you already use, over MCP, with a check of each change before it is committed. https://gitmir.com/products/vibe
- **GitMir GMM-1** — A model that works through specifications, codebases and data larger than an ordinary context window. https://gitmir.com/products/gmm

## Questions

### What is 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.

### What is the difference between context engineering and prompt engineering?

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.

### Why does Claude Code run out of context on a large codebase?

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.

### How do I reduce tokens per task without losing accuracy?

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.

### Is a bigger context window the answer?

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](https://gitmir.com/mcp-server)
- [CLAUDE.md and AGENTS.md from your code](https://gitmir.com/claude-md)
- [Context is what you pay for](https://gitmir.com/blog/context-is-what-you-pay-for)
- [Reduce AI token costs](https://gitmir.com/blog/reduce-ai-token-costs)
- [Benchmark 001](https://gitmir.com/benchmarks)
