Patrick Debois: Treat Context Like Code to Keep AI Coding Agents Under Control

Patrick Debois, one of the figures behind the DevOps movement, used a talk published by InfoQ to push a blunt proposition: the hard part of running AI coding agents is not the model, it is the context you feed it. His argument is that context — the instructions, repository conventions, architecture notes and constraints that shape what an agent produces — deserves the same treatment as source code. Test it, version it, ship it through pipelines, scan it for leaks.

The framing matters because most teams currently handle agent context as a pile of prompts pasted into a chat window or a single sprawling instruction file. Debois's alternative borrows the tooling engineers already trust: continuous integration and delivery, package managers for distributing reusable context bundles, and security scanning to catch secrets or instructions that should never reach a third-party model. In his view, that stack is what lets a team scale from one developer experimenting with an agent to hundreds of agent runs a day without losing the plot.

Non-determinism is the practical problem underneath all of this. The same prompt can produce different code on different runs, which makes review, auditing and rollback harder than with ordinary commits. Debois's answer is to treat the context layer as the stable, testable artifact while accepting that the output will vary — writing checks that verify an agent's behavior against expected constraints rather than expecting byte-identical results.

There is an organizational payoff too. When context lives in versioned, reviewable packages instead of individual engineers' notes, it becomes institutional knowledge that survives staff turnover and onboarding. Debois frames this as long-term memory for engineering teams: the accumulated rules about how a codebase should be changed stop being tribal and start being maintained, like any other dependency.

The talk lands in a market where vendors are racing to sell agentic coding tools while customers quietly struggle with consistency and governance. Debois is not selling a product here; he is borrowing vocabulary from a discipline that already solved the distribution and trust problems for code. Teams that adopt the pattern will need to decide who owns the context repository, how changes get reviewed, and what happens when an agent ignores the rules anyway.

That last question is the one to watch. If context is code, then context has bugs, and someone has to be on call when an agent ships a change the context said not to make. Debois's talk sketches the pipeline; the operational discipline around it is still being written.