Context Engineering

In one sentence

Context engineering is the discipline of deciding what an AI coding agent gets to see and use at each step of a task: the instructions, the relevant slice of the codebase, the tool definitions, the tests, and the feedback from running the code, so the agent has enough grounding to produce work that can be trusted and checked.

Origin

The phrase moved into common use in mid-2025. On June 18, 2025, Shopify CEO Tobi Lütke described it as the art of providing all the context for a task to be plausibly solvable by the model, and Andrej Karpathy amplified it a week later, calling it the delicate art of filling the context window with just the right information for the next step. Anthropic formalized the idea in a September 2025 engineering post, framing it as curating and maintaining the smallest useful set of tokens during inference. The term itself is older, prompt engineers used it as early as 2023, but 2025 is when it became the standard frame for building agents.

Why it replaced prompt engineering as the frame

Prompt engineering treats the problem as writing one better instruction. That framing fit chatbots, where a single well-worded request produced a single answer. Coding agents work differently. They run for many steps, inspect files, call tools, execute commands, and react to what they observe. Across a long task the wording of the opening prompt matters far less than what information enters the model's attention at each turn.

Most agent failures now trace back to context, not to the underlying model. An agent that writes a broken change usually did so because it never saw the interface it was calling, the convention the repo follows, or the test that would have caught the mistake. Context engineering treats that as the thing to design, the entire information environment around the instruction rather than the instruction alone. It is closer to systems work than to writing.

The kinds of context

A coding agent draws on several distinct sources, and each has to be assembled deliberately:

• Instructions and policy. The task itself, plus standing rules: coding conventions, architectural constraints, and files like CLAUDE.md or AGENTS.md that state how this repository expects work to be done.
• Repository knowledge. The relevant files, types, and prior implementations. The hard part is selection: showing the agent the slice that matters without flooding the context window with the whole tree.
• Tools. The actions the agent can take, defined so it knows what each does and when to reach for it. The Model Context Protocol (MCP) is the common way to expose tools to an agent.
• Tests and specifications. Executable statements of what correct behavior looks like, which the agent can read before it writes and run after.
• Runtime feedback. What actually happened when the code ran: compiler errors, failing assertions, screenshots, traces. This is the highest-signal context because it reflects reality rather than the model's guess about it.

Verification as context

The most valuable context is often the feedback that tells an agent whether its work is correct. A specification describes intended behavior; a passing or failing test reports what the code truly does; a screenshot of a rendered page shows whether a UI change actually looks right. Feeding these back into the loop turns a guess into a grounded next step.

This is where Shiplight fits. Shiplight is a verification layer that installs into the coding agent as an MCP server and gives it eyes and hands in a real browser. When the agent finishes a change, it can call /shiplight verify to confirm the UI looks right, use /shiplight create-yaml-tests to walk the app and author E2E tests, and rely on /shiplight fix to reproduce failures and root-cause them. The results, browser observations and test outcomes, become context the agent acts on. Tests written from intent and kept in the user's own git repo double as durable, machine-readable statements of correct behavior that every later task can read.

Where context engineering fits

Context engineering is a design activity that spans the whole agent workflow, not a one-time setup step. It governs what goes into the prompt, how the codebase is retrieved, which tools are exposed, and how runtime feedback is routed back to the model. Teams that get it right spend their effort on the information pipeline rather than on rewording prompts, and treat tests and real-browser verification as first-class context rather than an afterthought.