Context Is the New Code — Patrick Debois, Tessl
Patrick Debois argues that as AI coding agents become more capable, the context that drives them—prompts, rules, and memory—needs its own engineering discipline, akin to how we manage code. He introduces the Context Development Lifecycle (Generate, Evaluate, Distribute, and Observe) to make context a shared, repeatable, and improvable part of software delivery, creating a flywheel effect where better context leads to better agent output and continuous improvement.
Drawing a parallel to the DevOps movement’s question, “What if ops looked more like dev?”, the central thesis is to ask, “What if context is the new code?”. This reframes the ad-hoc nature of prompt engineering into a structured, disciplined practice. As developers shift from writing code to “vibe coding with prompts,” the context provided to AI agents becomes the primary lever for influencing outcomes. This includes not just prompts but also reusable “skills” and workflows that transform complex coding tasks into manageable, context-driven instructions.
To manage this new paradigm, a Context Development Lifecycle is proposed, mirroring the familiar software development lifecycle. It consists of four key phases:
1. Generate
This is the creation phase, which developers are most familiar with. It evolves in sophistication:
- Human Prompting: The basic act of typing instructions to an agent.
- Reusable Instructions: Storing prompts in files like
agent.mdfor consistency and reuse, a practice becoming a de-facto standard. - External Documentation: Pulling in documentation from libraries and tools to provide the LLM with up-to-date information, preventing hallucinations about versions and features.
- Integrated Sources: Fetching context from various tools like GitLab, GitHub, Slack, and ticketing systems to inform the agent’s task.
- Specification-Driven Development: Writing high-level specifications that an agent breaks down into a detailed plan and step-by-step prompts.
2. Evaluate: Testing the Context
Once context is created or modified, it must be tested to understand its impact. Simply hoping for the best (“YOLO”) is insufficient. Evaluation for context can be modeled after traditional software testing levels:
- Linting: Simple validation against a specification. For example, ensuring a skill’s description meets length requirements or format constraints.
- Semantic “Grammarly”: Using an LLM to evaluate the context itself for clarity, completeness, and verbosity. It provides feedback on whether the context is well-formed enough for an agent to understand and act upon effectively.
- Assertion & Unit Tests: Verifying that the code generated by the agent adheres to specific rules defined in the context. For example, if the context states, “All API endpoints must use the
/awesomeprefix,” an eval would check if the generated code for a new endpoint follows this rule. This can be done by having another LLM judge the output. - End-to-End Tests: Empowering the evaluating LLM with tools to run the generated code in a sandbox. Instead of just checking the code statically, the agent can execute it (e.g., make a
curlrequest to the new endpoint) to validate its real-world behavior. - CI/CD for Context: Integrating these evaluations into a CI/CD pipeline. Due to the non-deterministic nature of LLMs, tests must be run multiple times. Success is measured not by a single pass/fail but by success rates and “error budgets” to account for variability.
3. Distribute: Packaging and Sharing Context
To scale the use of context beyond a single developer, we need mechanisms for distribution, similar to software libraries.
- Version Control: The simplest method is checking context files into a Git repository.
- Packages & Registries: For broader reuse across teams and projects, context can be bundled into packages (e.g., “skills”) and published to a registry or marketplace. This allows for discovery and dependency management.
- Dependency Hell: As with code, context packages can have dependencies, leading to potential conflicts that must be managed.
- Security: Published context must be scanned for vulnerabilities, such as credential exposure or malicious scripts, using tools analogous to Snyk.
- AI SBOM: The concept of a Software Bill of Materials (SBOM) is extended to context, capturing metadata about how a skill was built, what models were used, and its overall provenance.
4. Observe: Gaining Feedback from the Real World
The lifecycle is a continuous loop, fed by observations of how the context performs in practice.
- Agent Logs: Analyzing agent execution logs provides a rich source of feedback, revealing where context was missing or misinterpreted. Standardized logging formats are emerging to facilitate this.
- Pull Request (PR) Feedback: Comments and requested changes on a PR are direct feedback on the context that generated the code. Instead of just fixing the code, the underlying context should be improved.
- Production Monitoring: Instrumenting AI-generated code in production. When a failure occurs, the system can capture the inputs and outputs, automatically create a new test case, and feed that back into the evaluation phase to prevent future regressions.
- Runtime Security: Agents must be observed for malicious or unintended behavior. This involves sandboxing their execution and using a “context filter”—analogous to a Web Application Firewall (WAF)—to inspect incoming prompts and context for injections or harmful patterns.
Ultimately, LLMs and coding agents are the engine, but context is the fuel. While developers have little control over the engine itself, they have total control over the fuel. By adopting a structured, engineered approach to the Context Development Lifecycle, teams can move from individual craftsmanship to a scalable, organizational flywheel that continuously improves the performance and reliability of AI-driven software development.