Patrick Debois used a QCon London 2026 presentation, “Context Is the New Code,” to argue that the real challenge in AI-assisted software development is not just generating code, but managing the context that makes coding agents useful, repeatable and safe. His case was simple: if teams already apply software engineering discipline to code, they should do the same for context — treating it as an artifact that can be generated, evaluated, distributed and observed.
Context as a software artifact
Debois framed the talk around a familiar DevOps idea: just as operations became more like development under DevOps, context now needs a lifecycle of its own. He described the “Context Development Life Cycle” as a loop of generating context, evaluating it, distributing it and observing how it performs in real use. In his view, this is not the same as context engineering inside a model prompt window; it is about the broader body of instructions, documentation, rules, specs and signals that an AI agent uses to do work.
That includes familiar files and formats, such as CLAUDE.md and the emerging AGENTS.md standard, but also codebase documentation, library guidance, microservice instructions, product specs and organizational knowledge. Debois said teams are already acting as “context engines” when they keep refining prompts and instructions, but that approach does not scale well unless the context itself is curated as a reusable product.
Generating context with the right sources
In the “generate” phase, Debois highlighted several ways teams are now creating reusable context. One is writing rules and instructions in shared formats that can be reused across tools and agents. Another is pulling in dependency-specific guidance from tools that understand libraries and versions, so the agent receives documentation and best practices tailored to the exact technology stack in use.
He also pointed to connectors that surface context from places engineers already use, such as Slack or internal sources, and to more structured task definitions that look closer to product requirements or task specifications than a casual prompt. Debois emphasized that the human role shifts from writing everything manually to curating context so the agent has access to the most accurate and current material.
Testing context like code
Debois spent much of the presentation on the idea that context should be tested. He compared this to the way teams validate code with unit tests, integration tests and end-to-end checks. For context, the equivalents include benchmarks such as SWE-bench, but also custom evals built around a team’s own workflows, repositories and agents.
He described several layers of evaluation:
- Linting-style checks for structured context, such as verifying syntax and required metadata.
- LLM-as-a-judge feedback to assess whether context is clear, concise and effective.
- Task-based evals that measure whether a skill or instruction set actually helps an agent complete a real job.
- Repo-specific end-to-end tests that verify the context works in the target codebase, not just in a synthetic setup.
He said this is especially important because context is non-deterministic. A setup that works once may fail later, and some evals will pass while others do not. That makes the process more like managing risk than certifying a binary “good” or “bad” result. Debois said teams may need to rely on error budgets, business judgment and guardrails to decide what is safe enough to ship.
Packaging and sharing context across teams
For distribution, Debois argued that copying instructions into Slack is not enough. Instead, he said context should be packaged and versioned like a library, then distributed through registries and package managers. In this model, a team can publish a reusable set of rules, a skill or a context bundle, and other teams or agents can install it at a specific version.
He noted that this is where standardization matters. As major AI coding tools converge on common formats for instructions and skills, context becomes more portable across systems. But packaging alone is not enough: Debois warned that marketplaces filled with untested skills or markdown files do not guarantee quality. He stressed the importance of documentation, versioning, testing and maintenance, much as teams would expect from any trustworthy software dependency.
Security is part of distribution too. Debois mentioned the risk of malicious skills and the need for scanning, provenance and bill-of-materials-style tracking. He described tools and approaches that record who created a context artifact, when it was created and how it was produced, so teams can trust what they are installing. He even suggested a more complete transaction log of changes as a useful backstory for both humans and agents.
Observability and feedback in production
The final phase in Debois’s cycle was observation. He said context should not stop at evals; teams need to learn from production use as well. That means capturing failures, logging how agents behave and feeding those lessons back into the next version of the context. He cited examples of agents doing self-reflection or post-mortem style analysis, then using the results to improve future behavior.
He also discussed a “context firewall” idea: not just watching network activity, but inspecting what files or information an agent is loading and using. His point was that observability should cover more than code execution or logs. It should also tell teams whether the agent is consuming the right context and whether it is drifting into unsafe or unexpected behavior.
Debois linked that to a broader feedback loop in which production data becomes new context. If a failure happens, the lesson learned should be captured and distributed so the same mistake does not recur. In that sense, observability is not just a monitoring concern; it is part of the context flywheel.
The human role does not disappear
Debois did not frame the future as pure agent autonomy. Instead, he described different management styles for agents, from heavy micromanagement to looser oversight where agents can work independently unless they hit a conflict or risk threshold. His view was that autonomy is not the goal in itself; the real question is knowing when to apply it.
He also suggested that the role of the developer is shifting. Engineers may become more involved in writing tests, documenting behavior, packaging knowledge and deciding which context should be shared across teams. In his telling, that is not a downgrade but a broader engineering role — one that includes operations, quality assurance, product judgment and data stewardship.
Why context may become the moat
Debois closed by arguing that a company’s advantage may not come from code generation alone. The differentiator could be the right context: business knowledge, team practices, standards, constraints and lessons learned. Coding agents are the engine, he said, but context is the fuel. Without the right fuel, the engine underperforms.
He left the audience with open questions about where the discipline goes next: chaos engineering for context, context analytics, A/B testing for instructions and the eventual equivalent of GitHub or Kubernetes for this new layer. For now, his message was more practical than speculative: if AI agents are going to write more software, teams will need to manage the context around them with the same rigor they apply to code.
Source: Original report
Was this helpful?
Explore more: Software Testing Services More AI & Automation Tech News
Last Modified: September 30, 2026 at 10:34 pm
2 views
