Video summary

Context Is the New Code — Patrick Debois, Tessl

Main summary

Key takeaways

Technology

Overview: Context as the “New Code” for AI Agents

The talk argues that context is becoming the “new code” for AI coding agents. Instead of focusing primarily on writing and maintaining large codebases, teams should engineer reusable, testable, distributable context—such as instructions, documentation, specs, repository data, and tickets—that reliably guides agents.

Core framing: The Context Development Life Cycle

A software development lifecycle should have a counterpart for context, implemented as an iterative loop:

  1. Generate context
  2. Test context
  3. Distribute context
  4. Observe / feedback
  5. Adapt & regenerate context

This mirrors DevOps / CI-style thinking—shifting from agent/code output to how context is built and validated.

1) Generate: How Context Is Created

Key sources/forms of context mentioned:

  • Prompting / instructions
    • Using agent prompt files (e.g., agent.md, instructions, and sometimes claude.md).
  • Reusable prompt components
    • Standardized, modular “instruction” documents.
  • Pulling external documentation
    • Downloading library docs so the LLM generates code for the correct versions, reducing hallucinations.
  • Pulling context from systems
    • Extracting relevant information from GitHub/GitLab, Slack, and tickets during workflow.
  • Spec-driven prompting
    • Writing prompts as “specs” that agents can break into planning + step-by-step execution.

Example highlight

A demonstration where prompting auto-fetches information (e.g., generating a talk description from a website), illustrating how context assembly can be automated.

2) Test: Evaluating Whether Context Works (Agent Evals)

The speaker emphasizes that producing context isn’t enough—you must test how it affects agent outputs, because LLM behavior can be nondeterministic.

Testing approaches described

  • Format/spec validation (“linters”)
    • Validate context structure and constraints (e.g., “a skill must include a description of limited length”).
  • Understanding validation (Grammarly-like critique)
    • Ask an LLM to evaluate whether the written context is explicit/comprehensive enough for the agent.
  • Output conformance checks with “judge” LLMs
    • Example: require generated endpoints to use a URL prefix (e.g., /awesome/...) and ask a judge model whether the output follows the convention.
  • Unit-test-like suites
    • Run multiple automated rules and criteria repeatedly on context + generated artifacts.
  • End-to-end / execution tests (tool-using judge agents)
    • Provide the judge an execution tool and run in a sandbox (e.g., actually call the generated endpoint via curl).
    • Compare results across scenarios tied to a specific commit + context changes.
  • CI/CD integration + “error budgets”
    • Since evals can be nondeterministic, measure success rate across repeated runs.
    • Allow failures based on an error budget, rather than requiring “pass once.”

Key message

Treat context testing as first-class engineering—because context changes can silently degrade agent performance.

3) Distribute: Packaging Context for Reuse

The talk recommends moving from one-off context to reusable distribution mechanisms.

  • Check-in to repos
    • Zero-friction sharing when context lives in source control.
  • Context libraries / packages
    • Package context as “skills” that include instructions plus scripts/docs and dependencies.
  • Registry / discovery
    • A marketplace/registry model for installing context packages.
    • Caution: many public skills may be inconsistent quality, so teams may need internal standards/evals.
  • Dependency/versioning risks
    • Expect “dependency hell” (e.g., conflicting React/package contexts).
    • Use versioned packages and version-mirrored distributions tied to library versions and context versions.
  • Security scanning
    • Scan context packages for secrets/credential mishandling.
    • Introduce an AI SBOM concept—metadata describing how a packaged skill was built (e.g., model used, build provenance, etc.).

4) Observe: Feedback Loops for Context at Scale

Once teams share context libraries, they need observability and feedback.

Feedback sources described

  • Agent logs
    • Capture missing-context errors and recurring failure patterns.
    • Use log-driven insights to decide when to create or improve shared context.
  • PR feedback loops
    • Treat PR failures/rejections (when context-enabled generation is involved) as signals to improve context.
  • Production instrumentation
    • Instrument real behavior of generated code in production.
    • Feed failures back into test cases and context improvements.
  • Security / behavior tracing
    • Sandbox agents can be evasion-prone; by default they can load agent.md / skill.md.
    • Introduce a context filter (analogous to a WAF) to block prompt injection patterns.
  • Enterprise observability
    • Mentions “harness engineering”-style observability: logs, traces, and safe reruns.

Two-layer improvement model

  • Individual loop: solo crafting of markdown (create/test/iterate).
  • Organizational loop: when a library is used by others, feedback informs maintenance and improvements—creating a flywheel across teams.

Practical Tooling Vision (Referenced)

  • Mentions Tessel / Tessl as a place to try implementations of these ideas (skills/context packaging, eval/testing pieces).
  • Mentions AI DevCon in London (content curation context).

Main Speakers / Sources (as mentioned)

  • Patrick Debois (primary speaker)
  • Tessl / Tessel (mentioned as a product/implementation context)
  • References/stand-ins: Claude (prompt file naming), Gemini, Copilot, and tools/approaches like OpenAI / “open claw” and Snyk-style scanning
  • SBOM concept
  • Harness engineering

Original video