Featured image of post Claude Code Has No Magic: Context Engineering Becomes the Real Work Behind Coding Agents

Claude Code Has No Magic: Context Engineering Becomes the Real Work Behind Coding Agents

Coding agents hinge on context.

The Event

The Event

Daisy Hollman, a senior engineer on Anthropic’s Claude Code team and a former long-time participant in the C++ standards community, used a recent NDC Copenhagen talk to explain how Claude Code plugins, context primitives and internal multi-agent workflows are designed. Her central message was simple: Claude Code is not magic. Its usefulness comes from careful engineering around tools, context and feedback.

The pressure point is the context window: the fixed amount of text a model can inspect when predicting the next token. A token is the model’s basic unit for processing text. According to the talk, frontier context windows were already around 1 million tokens in late 2024 and February 2025, and they remain roughly at that level today. Model capability has advanced much faster than that limit, making context selection a full-time engineering problem as agents begin to work on monorepo-scale software tasks.

From Chatbots to Coding Agents

From Chatbots to Coding Agents

Hollman described the path from chatbots to agents as a gradual expansion of tool use. Early large language model applications followed a turn-by-turn pattern: a human wrote a message, the model answered, and the loop repeated. In 2024, tool calling changed that pattern by letting the model ask a computer to perform an action, read the result, and decide what to do next.

Coding agents such as Claude Code, Codex and Cursor are agents equipped with the tools programmers normally use: file editing, shell commands, compilation and CI-related operations. The underlying mechanism is surprisingly primitive. The model emits structured JSON; the harness runs the requested tool; the result is appended back into the model’s context; and the loop continues.

Claude Code’s editing tool illustrates the point. It is essentially a find-and-replace interface over files: the model supplies a filename, an old string and a new string. The old string must match byte-for-byte, and multiple matches must be handled explicitly. Hollman argued that the impressive behavior comes not from a hidden editor but from the model’s ability to perform precise text operations and learn from tool feedback.

She also cited two indicators of how quickly agent capability has been improving. A METR chart, described as an “agent Moore’s law,” suggested that the task duration a model can complete with a 50% success rate had been doubling about every four months, although the trend became less clear earlier this year. Mozilla Foundation also reported in April that its latest-model usage fixed more security vulnerabilities and defects than the total repaired in the previous 15 months.

Customization Means Access to Knowledge

Customization Means Access to Knowledge

Why customize a general model at all? Hollman’s answer was practical: if Claude cannot do everything a software engineer can do, it cannot fully collaborate with that engineer. Professional software engineering is not confined to source code. Decisions live in team chat, CI systems, monitoring dashboards, internal documents and design records.

That makes customization less about fine-tuning and more about bridging the gap between public model knowledge and private team knowledge. Relevant context includes codebase conventions, internal APIs, institutional memory, project-specific terminology and changes that occurred after a model’s training cutoff. Hollman framed this as in-context learning: changing the text supplied to the model, not the model weights.

Claude Code’s post-tool-use hooks are one concrete mechanism. A hook is a script or rule that runs when a specific event occurs. After an edit, the system can immediately attach type-checking results, lint output or rule violations to the tool response. This acts like the red squiggle in an IDE: it warns the agent at the moment of error, rather than waiting for a later compile or test run.

Why Plugin Design Is Hard to Scale

Why Plugin Design Is Hard to Scale

The context window is both the customization surface and the scarce resource. System prompts, tool definitions, CLAUDE.md files, Skills, file contents and tool results all compete for the same space. As tasks become more complex, teams cannot simply dump every document, file and rule into the model. They must decide what enters context and when.

This is why plugin abstractions matter. Different mechanisms can connect external tools and knowledge to an agent, but always-loaded tool descriptions, rules and documents can crowd out the workspace the model needs for the actual task. Skills take a lazier approach: a short description is visible first, while fuller instructions are expanded only when needed.

Hollman therefore emphasized hooks as the more scalable primitive: if a condition does not match, nothing is injected; when it does match, only the relevant information enters context. Good plugin design is not about permanently giving the model more material, but about providing the right feedback at the right moment.

What Comes Next

The Claude Code story points to a broader shift in software engineering. Better base models matter, but production-grade coding agents also depend on knowledge access, low-noise feedback loops and disciplined context management. Context windows and human attention are hard constraints.

Hollman’s forward-looking claim was that the key 2026 transition will be from “putting information into the model” to “getting useful information out to the user.” In practice, teams will need agents that know when to surface a warning, when to stay quiet, and how to operate inside existing engineering workflows. Claude Code has no magic; it shows that the next discipline is teaching agents how to do software engineering, not merely asking them to write code.