Context Is the New Code

What happens when the reusable artifact you maintain is an instruction rather than a function? Patrick Debois introduces this as an exploratory direction: he increasingly requests changes from a coding agent instead of editing code himself. The next step is to turn existing helpers into skills, so context does more than generate code—it becomes the reusable workflow.

Consider onboarding developers whose agents live in Python, Node.js and different packaging ecosystems. Encoding every combination requires many branches and helpers. Debois describes replacing that approach with a skill whose procedure is straightforward:

1. Identify the user’s package manager.
2. Identify the surrounding ecosystem.
3. Carry out the appropriate onboarding steps with the user.

He reports that this handled more variation than their coded helpers could reasonably cover. The reusable asset is the procedure for discovering and adapting to the environment, rather than a fixed implementation for every environment.

The analogy starts with DevOps. In 2009, Debois asked what would happen if operations looked more like development; collaboration and deployment practices followed from taking that question seriously. Applying the same move to context raises a maintenance question: if instructions now influence what gets built, how should teams develop them consistently?

A context development lifecycle follows the familiar infinity loop. Generate context, evaluate it, distribute it to colleagues or other parts of the organization, then observe whether it works. Those observations feed adaptation and regeneration. Writing the first instruction is only the beginning; maintaining its usefulness closes the loop.

Context creation begins with ordinary prompting. Debois asked an agent when his AI Engineer talk was scheduled, and it fetched the website and found the session. The request worked with identity information he had already supplied: the agent knew he was Patrick. Even a short request depends on the information surrounding it.

Repeated requests become reusable instructions. Files such as AGENTS.md give those instructions a recognizable home; Debois contrasts that emerging convention with CLAUDE.md. Library documentation supplies another kind of context. When a model is uncertain whether an API belongs to version two or version three, retrieving documentation for the relevant version—preferably in an agent-friendly form—can guide generation toward the library actually in use.

Retrieval extends beyond documentation. MCP can bring in material from GitLab, GitHub and Slack, while the ticket describing a task is itself context. Spec-driven development adds a further transformation: write a specification, let the agent break it into a plan, then work through the resulting step-by-step prompts. Context can therefore be authored, retrieved or generated from another piece of context.

Change two lines in CLAUDE.md: do you know what behavior changed? Switch coding agents: do those same instructions still work? These are regression questions. Evals are familiar in AI engineering, but Debois wants them applied to the context used for everyday coding, rather than treating a plausible-looking edit as sufficient validation.

The first layer resembles linting. A skill validator can check that required metadata exists and that a description stays within the format’s permitted length. These checks establish structural validity before asking whether the instructions produce useful behavior.

The next layer resembles Grammarly: can the agent understand what the author means? A two-word instruction may omit too much to act on. Asking a model to assess the context can expose implicit assumptions, incomplete requirements or missing details. Debois finds voice coding helpful here because speaking makes him more expansive than typing with two fingers; the practical benefit is fuller instructions, not merely faster input.

A behavioral eval needs a rule, a task and an observable expectation. Debois’s example puts a company convention in AGENTS.md: every API endpoint must use the awesome prefix. Given a request to add an endpoint that saves a user, the expected generated path is /awesome/user.

The instruction can be expressed directly in the repository’s Markdown:

# API conventions

Every API endpoint must use the `/awesome` path prefix.

The user’s task need not repeat the convention; applying the repository context is the behavior under test.

An LLM judge can inspect the generated code and decide whether the endpoint starts with /awesome. A regex is sufficient for this particular rule, as Debois acknowledges; the judge illustrates how a broader criterion could be evaluated. Without the company instruction, there is no reason to expect that arbitrary prefix. The eval checks whether local knowledge actually affected the artifact.

The same suite can reveal differences when switching between Gemini and Copilot. Context that works with one coding system may need adjustment for another. Collecting these checks creates something like unit tests for context: criteria for generated application code, infrastructure as code and configuration files, all checked repeatedly against the conventions they should obey.

Finding /awesome/user in a file does not establish that the endpoint works. Give the judge tools and a sandbox, and it becomes an agent capable of running the application and issuing a request. For a local service accepting a JSON user record, that test could include:

curl --fail-with-body --show-error \
  --request POST \
  --header 'Content-Type: application/json' \
  --data '{"name":"Ada"}' \
  http://localhost:3000/awesome/user

The local address and record make the request concrete; the important change is from inspecting generated text to exercising the running system. A full scenario must assess whether the response and resulting behavior meet the task’s requirements.

Versioning makes those scenarios more useful. Select a repository commit, supply a particular piece of context and run the scenario to ask whether that context made a difference. Commit instructions alongside code so the evaluated input can be identified. Once tests produce feedback about failures or missing requirements, a code action can use that feedback to propose a context revision. Evaluation supplies a target for improvement instead of relying on another round of unguided wording changes.

Tests and optimization naturally suggest CI/CD, but agent evaluations do not always produce the same result on successive runs. A single pass or failure can make the pipeline difficult to interpret and failures difficult to reproduce. Debois proposes an illustrative procedure: run an eval five times and count how many runs succeed. A case might succeed in all five runs, while another varies; that observation describes the trials rather than guaranteeing future reliability.

Error budgets provide a way to express how much variation matters. Give critical test sets very little failure tolerance, while allowing more variation in less consequential cases. Context edits can change which tests succeed, so evaluate the pattern of results across the suite rather than treating every check as an ordinary deterministic test.

Checking context into a repository already distributes it: a colleague checks out the project and receives the instructions. Reuse across projects or teams calls for something closer to a library. Package the front-end guidelines or other shared conventions so each project can install the pieces it needs. A registry then answers the discovery question, as in the Tessl Skills Registry and skill marketplaces.

Discovery does not establish quality. Debois uses “99.9” as a rhetorical dismissal of skill quality, not a measured ecosystem statistic. His practical concern is that many published skills do not meet a useful standard when evaluated, even if reading them offers ideas. Teams may consequently want their own maintained registries.

The package contains more than a prompt. A skill can bundle instructions, scripts and documents; plugins can also include MCP integrations. Support across coding agents makes skills an emerging package-format convention for distributing these assets together.

Install multiple context packages and their instructions can conflict. A general front-end package might disagree with a React-specific package: dependency hell now includes incompatible guidance. Matching context-package versions to library versions helps keep the instructions aligned with the code they describe.

Published packages also introduce a trust problem. Debois points to OpenClaw as a moment when people became more aware of running strangers’ material on their laptops. His Snyk context-scanning example shows findings labeled Improper Credential Handling and Third-Party Content Exposure. These are flagged risks, not a claim that the scanner manages credentials or makes external content safe.

Provenance is the next question: who built the skill, how was it built and which model contributed? Debois proposes an AI SBOM analogy—a record of the origins and composition of the context package, extending the questions software teams already ask about their dependencies.

Maintaining context for other people creates an obligation beyond sharing a snippet over Slack: find out whether it still works for its consumers. Agent logs are one feedback channel. An individual developer can notice an agent’s mistake and add the missing instruction. Debois briefly compares that response to TDD, then qualifies the analogy—it is a reaction to a discovered problem, not necessarily a test-first process.

At organizational scale, look for repeated gaps. If multiple agents report that the same information is missing, author it once and distribute it to everyone. The improvement then reaches people who have not yet encountered the failure. Debois points to emerging log standardization as an aid to this feedback channel: logs can reveal both missing context and whether supplied context was actually used.

A correction on a generated pull request is also an opportunity to examine the context that produced it. Repeatedly arguing about the same omission in review fixes individual outputs; improving the originating instructions can prevent the next iteration from repeating it. Production adds evidence that review may miss, because the generated code must handle real inputs after approval.

Debois describes a wrapper-like tool that instruments code and sends it to production. When something fails, it identifies changed code and the input/output behavior that went wrong. That failure can become a test case, feeding a concrete regression scenario back into development. The loop connects observed behavior to a test and then to the context used for subsequent changes.

Runtime observation also needs to detect unexpected agent behavior. In a sandboxing experiment, Debois asked an agent to find useful ways to break out of the system. It used environment variables; after he removed a secret, it turned to memory files. The example motivates tracing what an agent accesses, rather than assuming its resourcefulness ends at the first restriction.

Execution isolation and instruction intake are different boundaries. Debois describes coding agents loading AGENTS.md and SKILL.md without an intervening restriction; the exact behavior depends on the agent and its trust configuration. His architectural concern is that sandboxing execution alone does not inspect the instructions being consumed. He proposes a context filter, analogous to a web application firewall, that examines incoming material for suspicious patterns and prompt injection.

The filter addresses an input path that execution isolation does not by itself validate.

Harness engineering brings these observations together: logs, traces and feedback explain how an agent behaves inside its operating environment. That information is useful for training, but also for running and improving an organization’s own agent workflows.

Two loops emerge. The inner loop is library authoring: create context and test it. The outer loop begins when somebody else uses that library: distribute it, observe whether it remains useful across consumers and feed that evidence into the next revision. Debois compares the continuing improvement process to a Sonar/CI/CD model for context.

Personal Markdown craftsmanship can grow into a team habit: when information is missing, add it to the maintained context. Across a team of teams, one correction can become reusable knowledge for everyone else. This is the organizational benefit of closing the loop rather than leaving each developer to rediscover the same conventions.

Debois’s closing analogy is an engine and its fuel. Models and coding agents are the engine; context is what the user supplies to it. He cannot directly change the underlying model he is given, but he can improve its context. Context is an engineering surface under the team’s control, and it deserves more than copying, pasting and hoping.

The audience question extends evaluation beyond code conventions. One attendee is building a system that scopes architectural problems into precise definitions, objectives and tests. Their proposed consistency check starts with a loose plan, runs independent attempts in parallel to sharpen it and compares the resulting definitions.

If the definitions diverge widely, the original plan may be too ambiguous: return to first principles or ask an architect to clarify it. If they agree, the attendee proposes proceeding downstream. Agreement is a signal of consistency, not proof that the shared interpretation is correct. The question is whether other unusual forms of context or evaluation could be useful beyond code and conventional evals.

Debois does not offer a specific solution to that architectural case. Instead, he identifies the cost hidden in the move from code to context: apparent savings in implementation can become time spent designing the right evaluations. There is no longer just one task prompt to get right; all the eval prompts require care too. Advanced practitioners build processes for constructing evaluations around their business cases. The engineering work shifts into defining what good behavior means and how to recognize it reliably.