Context Engineering for Coding Agents: A Practical Guide

A model's output is a function of its weights and its context window, and you only control one of them at inference time. Context engineering is the discipline of controlling it well: deciding which instructions, which code, which history, and which retrieved material occupy the window, and, just as deliberately, what stays out. The goal is an agent that sees exactly what the task requires and nothing that misleads it.

The term broke into the mainstream in mid-2025. Shopify CEO Tobi Lütke publicly argued it was a better name than “prompt engineering” for the real skill, providing an LLM with the full context a task needs, and Andrej Karpathy endorsed the framing, noting that serious LLM applications are mostly context-filling machinery around the model. The label stuck because it named what practitioners were already spending their time on, and by 2026 it is standard vocabulary in vendor docs, engineering blogs, and job listings.

Prompt engineering assumed the prompt was the whole input, which was true when you pasted a function into a chat box. Coding agents broke that assumption. An agent working in your repo gets most of its information by reading the repo: it explores files, greps for symbols, reads your CLAUDE.md, runs commands, and accumulates a long tool-call history. Your prompt is a few hundred tokens steering a window filled with hundreds of thousands.

At that ratio, wordsmithing the prompt is polishing the doorknob on a house you have not built. What decides agent output quality is whether the window contains the right conventions file, the right spec, the relevant modules, and clean history, or a stale doc, an accumulated wrong turn, and three files that look relevant but are not. That allocation problem is context engineering, and it is a systems skill, not a phrasing skill, which is why it sits at the center of agentic engineering rather than beside it.

For coding agents specifically, the practice reduces to six levers. Pull them in this order, they run roughly from cheapest to most structural:

1. 1

   Durable project context (CLAUDE.md / AGENTS.md)

   A short file the agent reads every session: build and test commands, conventions, boundaries. This is the context that should never need repeating. Keep it accurate and terse, and generate a solid starting version with the free AGENTS.md / CLAUDE.md generator.
2. 2

   Task context (a spec with acceptance criteria)

   Per task, the highest-value context is a written spec: scope, files, acceptance criteria, exclusions. It tells the agent what done means and tells the reviewer what to review against. The full practice is spec-driven AI development.
3. 3

   Context hygiene (compaction and fresh sessions)

   Long sessions accumulate dead weight: abandoned approaches, resolved errors, exploratory reads. Compact when history grows stale, and prefer a fresh session per story over one marathon session, a clean window plus a good spec beats a cluttered window with perfect memory.
4. 4

   Isolation (subagents and worktrees)

   Keep unrelated work out of each other's windows. Subagents give exploratory work its own context that returns only conclusions; git worktrees give parallel tasks separate directories and branches so one agent's changes never appear in another's view. The mechanics are in parallel agents with git worktrees.
5. 5

   Retrieval (MCP for what the repo can't tell it)

   Some context lives outside the codebase: database schemas, API docs, issues, browser state. MCP servers let the agent pull it on demand instead of you pasting it in, and curating which servers are worth their context cost is itself a context decision: MCP servers for AI coding.
6. 6

   Context-window economics

   Current Claude models ship 1M-token windows (Fable 5, Opus 4.8, and Sonnet 5 as standard; Haiku 4.5 has 200k), big enough for a large repo plus specs. A big window is not a license to fill it: irrelevant content still competes with relevant content for the model's attention, and every token has a price. Relevance beats volume at every window size.

Bad context is worse than missing context, because the agent trusts what it is given. Three failure modes account for most ruined sessions:

You can pull all six levers by hand, and it is worth doing at least once to internalize them. AIDEN's contribution is making the per-task levers structural: every story on the board gets a spec drafted from the card and codebase analysis (task context, gated on your approval), its own git worktree (isolation), and a fresh agent session scoped to that story (hygiene). Your CLAUDE.md and MCP setup carry over unchanged, because AIDEN runs your existing CLIs. The result is that each agent starts every story with a clean, relevant window by default, not by discipline.

Context engineering answers one question: what should the agent see? It does not answer who approved the work, where parallel changes land, or how output gets verified and reviewed. Those belong to the surrounding discipline of agentic engineering, where context engineering is one of six core practices alongside specs, harnesses, isolation, verification, and review. The conventions layer that carries context rules across sessions, and the rest of the guardrails around a raw agent, is covered in the AI agent harness. Master the window first; it is the practice the others lean on.