Patrick Debois: context is the new code

AI coding is starting to look less like typing and more like briefing. That is the core of Patrick Debois’s new argument. The code generator is no longer the main bottleneck — the bottleneck is everything the model needs to know before it can generate the right thing. Debois is calling that shift “context is the new code,” and he is treating it less like a slogan than a workflow problem. ### What does he mean by “context”? He means the stuff senior engineers carry around in their heads and teams scatter across files, chats, and habits — architecture decisions, coding conventions, business rules, past incidents, repo-specific instructions, and all the little constraints that tell you not just what to build, but how to build it here. A human new hire can absorb that over time. An agent starts cold every session. ### Why is that suddenly the hard part? Because the models can already produce a lot of code. But useful code depends on hidden local knowledge. Debois’s point is that software teams spent decades building discipline around source code — version control, review, tests, CI/CD, production observability — while the prompts, rules files, and memory that drive agents are still often handled like scraps taped to the wall. ### What broke in the old mental model? The old assumption was that the scarce thing was turning a developer’s intent into working code. Debois says that assumption is breaking because agents now write features, fix bugs, and scaffold services. So the scarce thing shifts upstream. It becomes the translation job — taking implicit organizational knowledge and making it explicit, structured, and current enough for a literal-minded machine to act on. ### So what is the new lifecycle? He proposes a Context Development Lifecycle, or CDLC, with four stages: Generate, Evaluate, Distribute, and Observe. Basically, context should move through a loop instead of living as stale setup text. Teams create or capture context, check whether it actually improves outputs, distribute the good versions across workflows, and then observe what happens in real use so the next version gets better. ### Why borrow so much from DevOps? Because Debois sees a strong parallel. DevOps took operational knowledge that used to be informal and wrapped process around it until delivery became repeatable. He thinks context needs the same treatment. Not identical tools, but the same seriousness — versioning, peer review, pipeline checks, and shared ownership instead of one person’s secret prompt file. ### What is the “context flywheel”? It is the compounding loop behind the whole idea. Better context gives agents better outputs. Better outputs create better observations about what worked and what failed. Those observations improve the next round of context. Debois’s claim is that the teams who get that loop spinning first may build a real moat, because they are not just buying a better model — they are accumulating organizational memory in reusable form. ### Does a bigger context window solve this? No — and that is one of the more useful parts of the framing. More tokens help with capacity, but they do not fix stale instructions, conflicting rules, missing provenance, or low-quality retrieval. A bigger suitcase does not help if you packed the wrong things. That is the difference between “more context” and “better context.” This last sentence is an inference from context. ### What should teams do with this? Treat prompts, memory files, repo guidance, and agent rules as first-class engineering artifacts. Measure whether they help. Review them. Retire them when they drift. And make the feedback loop visible. The bottom line is simple — if agents are becoming teammates, then context is becoming infrastructure. Teams that still manage it like a hack are probably leaving the biggest gains on the table.