Context is the New Code

This is the first article in "The Meta-Engineer," a three-part series examining how AI is reshaping the identity and skill set of software engineers.

Sometime in mid-2025, a shift began among engineers building production AI systems. The previous two years had been dominated by a single idea, that the key to getting good results from a language model was learning to talk to it well. Entire job titles sprang up around the skill. Courses, certifications, and prompt libraries proliferated. And for a while, the idea held. Careful phrasing did produce better outputs. But as AI coding tools evolved from autocomplete assistants into autonomous agents, the engineers working with them found that "prompt engineering," however refined, was no longer sufficient. The tasks they faced, getting an agent to navigate a 100,000-line codebase, maintain architectural consistency across sessions, and avoid repeating past mistakes, had little to do with crafting a clever sentence. They needed something more systematic. The emerging answer is context engineering, a discipline that treats the entire informational environment surrounding an AI agent as a designed artifact ^[1].

The distinction is more than semantic. Prompt engineering focuses on the instruction itself, the text sent to a language model. Context engineering encompasses everything the model sees at inference time, from system prompts and retrieved documents to session memory, tool definitions, and the structure organizing all of it ^[1]. If prompt engineering is writing a memo to a new employee, context engineering is designing the entire onboarding program, complete with reference materials, reporting lines, institutional knowledge, and decision-making protocols. The memo matters, but it cannot compensate for a badly designed information environment.

The need for systematic context design became especially visible as coding agents moved from autocomplete tools to autonomous systems capable of multi-step reasoning. An agent that only completes the next line of code can function adequately with a short prompt. An agent that independently creates a feature branch, writes an implementation spanning multiple files, runs tests, diagnoses failures, and iterates until the build passes needs far more than an instruction. It needs to understand the project's technology stack, its conventions for error handling and logging, its test infrastructure, which directories contain which types of code, and the architectural rationale behind structural decisions that might otherwise look arbitrary. Providing all of this reliably, economically, and in the right format at the right time is a design problem, and it is the problem that context engineering exists to solve.

A Discipline Takes Shape

A comprehensive survey covering over 1,400 research papers formalized this field, establishing a taxonomy that decomposes context engineering into three foundational components ^[1]. The first, context retrieval and generation, addresses where relevant information comes from, whether through search over documents, tool calls to external APIs, or synthesis from prior interactions. The second, context processing, covers how that information is filtered, compressed, and structured for relevance. The third, context management, deals with the ongoing challenge of maintaining context within a model's context window, the maximum amount of text it can consider at once, across multi-step interactions. Each stage introduces its own design decisions and failure modes, and the survey reveals that treating any single stage in isolation produces fragile systems.

From Craft to Maturity Model

Just as a well-organized notebook helps a researcher locate the right reference at the right moment, context engineering structures the informational landscape an AI agent draws from. A separate framework proposes a four-level maturity pyramid for what it calls "agent engineering" ^[2]. At the base sits prompt engineering, the craft of writing individual queries. Above it sits context engineering, the design and management of the entire informational environment. The third level, intent engineering, encodes organizational goals and trade-off hierarchies into agent infrastructure, moving beyond operational instructions to strategic alignment. At the top, specification engineering creates machine-readable corpora of corporate policies enabling multi-agent systems to operate autonomously at scale. Each level subsumes the one below it as a necessary foundation ^[2].

The same framework proposes five quality criteria for evaluating engineered context ^[2]. Relevance means the agent receives only what pertains to the current task. Sufficiency means nothing critical is left out. Isolation, especially important in multi-agent architectures where multiple AI sub-agents collaborate on different parts of a task, ensures each sub-agent's context does not leak into another's. Economy demands minimum token expenditure for maximum informational value. Provenance requires that every element of context be traceable to a verified source. Most teams operating at the prompt engineering level address one or two of these criteria at best, and typically only by instinct rather than by design.

"Whoever controls the agent's context controls its behavior; whoever controls its intent controls its strategy; whoever controls its specifications controls its scale."

— Vishnyakova, 2026

The gap between this vision and current practice is wide. An exploratory survey of 74 software professionals across six countries found that prompt usage in software engineering remains "largely ad hoc," with prompts refined through trial-and-error, rarely reused, and shaped more by individual heuristics than standardized practices ^[3]. Most organizations are still at level one of the maturity pyramid. The knowledge to do better exists, but the institutional habits have not caught up.

A related line of work pushes further by arguing that prompts should be treated not as informal text but as first-class software artifacts, subject to the same lifecycle of requirements engineering, design, testing, and versioning as traditional code ^[4]. That paper describes the present state as a "promptware crisis," an echo of the original "software crisis" of the 1960s that gave rise to software engineering as a discipline. The parallel is illuminating. Early software development was also trial-and-error, driven by individual skill rather than systematic method. It took decades of accumulated failures, ballooning complexity, and hard-won professional norms to establish the field. Context engineering may be at a similar inflection point, the moment before a craft becomes a discipline.

The Artifacts Practitioners Actually Build

While the academic literature establishes frameworks and taxonomies, a parallel development is happening in practice. Developers working with agentic coding tools like Claude Code, Codex, and Cursor have begun creating a new category of software artifact, configuration files that serve as persistent, structured instructions for AI agents. Files named CLAUDE.md, AGENTS.md, and .cursorrules are essentially "READMEs for AI," machine-readable documents that encode project-specific knowledge an agent needs to operate effectively within a particular codebase.

Several empirical studies have examined what developers actually put in these files. An analysis of 328 CLAUDE.md files from popular GitHub projects found that 72.6% specify application architecture, making it the most common concern, followed by testing instructions, development guidelines, and project overviews ^[5]. A separate study of 253 Claude Code manifests confirmed consistent structural patterns, typically one main heading with several subsections, dominated by operational commands, technical implementation notes, and high-level architectural descriptions ^[6]. The shallow structure is not a sign of immaturity. It appears to reflect what agents actually need, a flat, scannable set of instructions rather than deeply nested documentation.

Scaling Across Tools

Just as a growing organization eventually needs written policies that work across departments rather than relying on informal tribal knowledge, the expanding ecosystem of AI coding tools needs configuration standards that work across platforms. The broadest study to date examined 2,923 GitHub repositories and identified eight distinct configuration mechanisms spanning a spectrum from static context files to executable integrations ^[7]. Context Files, simple Markdown documents like CLAUDE.md and AGENTS.md, dominate the landscape. More advanced mechanisms such as Skills (structured packages with executable resources) and Subagents remain only shallowly adopted, with most repositories defining just one or two configuration artifacts. AGENTS.md has emerged as a de facto interoperable standard, recognized across multiple tools ^[7]. The picture is of an ecosystem in its early days, where the simplest approach, a well-written Markdown file, is doing the heavy lifting.

These files are not just documentation. A controlled study of 10 repositories and 124 pull requests found that the presence of an AGENTS.md file was associated with a 29% reduction in median agent runtime and a 17% reduction in output token consumption, while maintaining comparable task completion behavior ^[8]. The researchers hypothesize that agents spend less time on exploratory navigation when they have explicit project context, needing fewer planning iterations and fewer repeated calls to the model. In practical terms, a well-crafted context file can cut both the time and cost of an agent session by roughly a quarter.

Yet adoption remains strikingly low. A study of open-source software projects found that only about 5% of surveyed repositories have adopted any context file format ^[9]. This is a field where the early adopters are seeing real gains, but the vast majority of projects have not yet begun to invest in structured agent context. The parallel to early version control adoption, or early unit testing adoption, is hard to miss. A practice that starts as optional among a skilled minority tends to become standard once enough teams experience the cost of not doing it.

What Goes In, and Why It Matters

The content of these files reveals something important about what developers have learned through experience with agents. Architecture specifications dominate because agents without architectural context tend to generate code that works in isolation but violates the system's structural assumptions. A microservices project with strict domain boundaries, for example, will see an unconstrained agent casually import across those boundaries, creating coupling that takes hours to untangle. An agent working without knowledge of a project's event-driven architecture might implement a synchronous function call where an asynchronous message was expected, producing code that compiles but behaves incorrectly under load. The agent has no way to infer architectural intent from the code alone. Architectural decisions are often conventions enforced by humans rather than patterns enforced by compilers.

Testing instructions appear frequently, and a recent empirical study reveals exactly why. An analysis of over 1.2 million commits across 2,168 repositories found that coding agents are significantly more likely to add mock objects to tests than human developers ^[10]. Specifically, 36% of agent commits that modify test files introduce mocks, compared with 26% for human-authored commits. The study also found that 23% of commits made by coding agents add or change test files, compared with only 13% by non-agents, and that 68% of repositories with agent test activity also contain agent mock activity ^[10]. Repositories created more recently showed even higher proportions of agent-generated test and mock commits, suggesting the trend is accelerating as agent adoption grows. Mock objects, which substitute simplified stand-ins for real system components during testing, are easier for agents to generate automatically but less effective at validating how components actually interact. Tests that mock everything pass reliably but verify very little about the real system's behavior. The researchers explicitly recommend including guidance on mocking practices in agent configuration files ^[10].

Developers have independently arrived at the same conclusion. Anti-mock instructions appear in CLAUDE.md files across many projects, a concrete example of the feedback loop between agent output and human judgment. The chain of reasoning behind such an instruction is worth unpacking. Someone had to encounter the problematic tests, recognize the pattern of excessive mocking, diagnose that the agent was reaching for mocks as the path of least resistance, and then encode a corrective instruction that prevents recurrence. That entire chain, from recognizing a quality problem to articulating a rule that addresses its root cause, is precisely the kind of reasoning that context engineering formalizes.

Project overviews also appear frequently, and their function is subtler than it first appears. An agent that knows it is working on a distributed event-processing system written in Rust makes different choices than one operating under the assumption that it is working on a standard web application. The overview is not there for the agent's curiosity. It establishes the interpretive frame within which every subsequent instruction and code change should be understood. Without that frame, the agent optimizes locally, generating code that satisfies the immediate request. With it, the agent's local decisions become more likely to cohere with the system's global design intent. Software projects accumulate unstated assumptions over time, assumptions about performance targets, deployment environments, backward compatibility requirements, and acceptable trade-offs between code clarity and runtime efficiency. A human developer absorbs these assumptions gradually through code review, team conversations, and debugging sessions. An agent has none of that ambient context. The project overview and its associated configuration files are the only mechanism for transmitting what would otherwise require months of socialization.

The First Signs of Compression

The configuration files described above are brand new, barely a year old as a widespread practice. They represent a distinctly human contribution, the product of engineering judgment, project-specific knowledge, and hard-won experience. And yet, there are already early signs that the same systems these files were designed to guide are learning to generate and refine similar artifacts autonomously.

The ACE (Agentic Context Engineering) framework treats context not as a static human-authored artifact but as an "evolving playbook" ^[11]. Through a modular cycle of generation, reflection, and curation, ACE accumulates, refines, and organizes strategies without any labeled training data, relying instead on natural execution feedback. In practice, the generation phase creates new strategy elements from recent task experiences. The reflection phase evaluates which strategies contributed to successes or failures. And the curation phase integrates promising strategies into the evolving playbook while pruning elements that have proven unhelpful. What distinguishes ACE from simple prompt optimization is the cumulative, structured nature of the updates. Rather than rewriting the entire context on each iteration, the framework makes targeted additions and modifications, preserving the accumulated knowledge that prior iterations have validated ^[11].

ACE demonstrated a 10.6% improvement over strong baselines on agent benchmarks and 8.6% on domain-specific financial reasoning tasks ^[11]. On the AppWorld leaderboard, ACE matched the top-ranked production-level agent on the overall average and surpassed it on the harder test-challenge split, despite using a smaller open-source model.

The ACE researchers identified two failure modes that plague simpler, static approaches. Brevity bias is the tendency for iterative optimization to collapse rich context into short, generic summaries that strip away domain-specific heuristics. Context collapse occurs when iterative rewriting gradually erodes important details over time ^[11]. ACE addresses both with structured, incremental updates guided by a "grow-and-refine" principle that preserves detailed knowledge rather than compressing it. The framework argues, counterintuitively, that large language models are actually more effective with long, detailed contexts than with tight summaries. Unlike humans, LLMs can autonomously distill relevance from comprehensive inputs, so stripping context down may sacrifice the edge-case knowledge that separates correct output from output that merely compiles.

This is proto-self-context-engineering. The artifacts that feel novel and distinctly human today, the carefully authored CLAUDE.md files and AGENTS.md specifications that encode project architecture and testing conventions, are already beginning to be optimized by the very systems they were written to guide.

The Automation Ladder

There is a pattern worth noticing, and it recurs so reliably across the history of software that it probably qualifies as structural rather than coincidental. Every major abstraction layer eventually got formalized, stabilized, and then partially or fully automated.

In the 1950s, programmers encoded instructions in raw machine language, addressing memory registers by number. Compilers eliminated that work. In the decades that followed, programmers managed memory by hand, tracking every allocation and deallocation. Garbage collectors eliminated that work. By the 1990s, developers wrote boilerplate business logic from scratch for every project, implementing authentication, database access, and request routing by hand. Frameworks and libraries eliminated most of that work. Entire product categories, e-commerce, content management, analytics, became platforms. And in the last three years, code generation itself has undergone a dramatic shift. What began as autocomplete suggestions in IDEs evolved into autonomous agents capable of creating features, writing tests, and issuing pull requests with minimal human direction.

Context engineering sits at the latest step on this ladder. It feels like the domain of uniquely human judgment, and for now, in most practical settings, it is. Designing the right information environment for an AI agent requires understanding the project, its architecture, its failure modes, and its quality standards in ways that demand genuine expertise. The decision to include anti-mock instructions in a CLAUDE.md file, for instance, reflects not just a knowledge of testing patterns but a judgment about what "good" means for that particular codebase. That judgment currently lives in human heads.

But the ACE framework demonstrates that at least the refinement of context, the iterative improvement of playbooks based on execution feedback, can be automated today. The generate-reflect-curate loop does not need labeled data. It does not need a human reviewing each iteration. It learns from the natural consequences of its own decisions, and it demonstrably outperforms static, human-authored baselines on agent benchmarks.

A question the remaining articles in this series will explore, is where will the ladder lead? If agents can learn to refine their own context, and the orchestration patterns that coordinate multi-agent work are themselves being learned by self-improving systems, what remains durably human? Professional developers are already shifting from writing code to designing context. If context design itself begins to compress, as the evidence tentatively suggests, the next shift may not be upward to a higher rung on the same ladder. It may be toward a different kind of work entirely.

As the evidence from practitioner studies, scaled infrastructure projects, and self-improving agent systems will suggest across this series, has less to do with any particular abstraction layer and more to do with the nature of the work itself. Humans persist wherever meaning is still underdefined. That edge moves, and it moves fast. But it does not disappear, because the world keeps generating new ambiguity faster than systems can resolve it.