Patrick Debois argues that as AI coding agents become more capable, the decisive factor is increasingly context rather than code alone. Context should be managed with a lifecycle similar to software: generate it, evaluate it, distribute it, observe how it performs, and improve it over time.
1. Opening: who has used an AI coding agent?
The talk opens with Debois asking who in the room has used AI coding agents and jokingly welcoming those who have not. He frames the talk as a work-in-progress idea: "Context Is the New Code," or a context development lifecycle.
The roughness is part of the point. AI practice is moving quickly, so teams need ways to reason about context even before the field feels fully settled.
2. Why context became the new code
Development is shifting from directly writing every line of code to guiding agents with prompts, rules, examples, documents, and reusable knowledge. This is the world often described as vibe coding.
Two changes matter. First, context is constantly being created: instructions, memories, tickets, docs, and workflows. Second, some logic that used to require code can become reusable context, such as a skill that tells an agent how to detect a package manager, inspect an ecosystem, and guide onboarding step by step.
In that sense, context is no longer just a prompt. It is a product and team asset.
3. The context development lifecycle: Generate, Evaluate, Distribute, Observe
Debois connects the idea to DevOps. Just as DevOps asked what operations would look like if treated more like development, the AI era asks what context would look like if treated more like code.
The proposed loop has four parts: generate context, evaluate it, distribute it across teams and tools, observe its real-world behavior, and then feed the learning back into the next version.
4. Generate: how context gets made
Context starts with ordinary prompts, but quickly expands into reusable files, project instructions, skill packages, downloaded documentation, tickets, Slack conversations, GitHub or GitLab history, and other traces of work.
The talk mentions agent.md-style reusable instruction files, current library documentation to reduce hallucinations, and spec-driven development where a prompt becomes a specification that an agent can break down into a plan.
The main idea is that context generation should become intentional and repeatable, not just ad hoc prompt writing.
5. Evaluate: context also needs tests
Changing a few lines in an instruction file can materially change an agent's behavior. Debois argues that teams should not treat those changes as "looks good, ship it." Context needs tests.
Evaluation can start with lint-like checks: required fields, description length, or package format. It can then move toward comprehension checks, rule-following tests, LLM judges, and end-to-end tests where a judge has tools and can run the result in a sandbox.
Because LLM outputs are nondeterministic, context evals should not always be single pass/fail gates. Running multiple trials and thinking in terms of success rates or error budgets can be more realistic.
6. Distribute: shipping context to teams and organizations
Once context is useful, it needs to be shared. Checking it into a repository is the simplest path: colleagues get the same instructions when they check out the project.
For reuse across projects, context needs packaging, registries, and discovery, much like libraries. Skills and marketplaces are early examples, but Debois is blunt that many shared skills are low quality. They may still be useful as learning material.
Packaging also brings familiar problems: dependency conflicts, provenance, security scanning, and the need to know who created a context package and with which model. Context may need its own version of an SBOM.
7. Observe: use logs and production feedback
When other people start using shared context, teams need to know whether it still works. Agent logs can reveal repeated missing information. If many agents ask for the same missing detail, that detail should become shared context.
Pull request feedback is also context feedback. Instead of arguing about the same mistake repeatedly, teams can ask what context caused the agent to produce that change and improve it for the next run.
Production failures are even stronger feedback. A broken change, its input, and the incorrect output can become a future test case. Observability and tracing also matter because agents may inspect environment variables, memory files, or other unexpected surfaces.
8. Conclusion: the fuel matters as much as the engine
The talk's conclusion is that the model is the engine, but context is the fuel. Better models help, but durable performance comes from better context: tested, shared, observed, and continuously improved.
Teams that treat context as a first-class asset will get more reliable results from coding agents than teams that treat prompts as disposable text.
9. Q&A: what about more exotic context?
In the Q&A, Debois discusses more unusual forms of context beyond plain text: logs, runtime signals, traces, generated artifacts, and tool outputs. The boundary of "context" keeps expanding as agents become more integrated with development environments.
The important question is not whether something looks like a prompt. It is whether it helps the agent make better decisions and whether the team can evaluate and maintain it.
Closing
The practical roadmap is clear: stop treating context as a one-off prompt. Treat it like an engineering asset with a lifecycle, tests, distribution, observability, and continuous improvement.