The bottleneck moved

Coding agents write features now. They fix bugs, scaffold services, and open pull requests that a reviewer can plausibly approve. Whether that is a good development is a separate argument, and a real one. It is also not the argument most teams are having on a Tuesday morning. The question in front of them is narrower and more awkward: why does output quality vary so much between two engineers using the same tool on the same repository?

For about thirty years we built methodology on the assumption that the hard part was getting a correct idea out of somebody’s head and into running software. Waterfall, agile, DevOps, platform engineering: different answers to one problem, which was throughput from intent to production. That assumption has weakened. Typing is no longer the slow step. Describing is.

Patrick Debois named the shape of this in February 2026 and called it the Context Development Lifecycle, or CDLC. His one-line version:

Context is the new bottleneck, not code.  Patrick Debois, February 2026

Figure 1. The pipeline did not get shorter. The narrow part moved one step to the left.

Two caveats before going further, because the field is moving fast enough that confident claims age badly.

The vocabulary has not settled. By May 2026 Debois noted that other authors had already rewritten his four stages as five and as seven, which is roughly what happens just before a term stops belonging to whoever coined it. Treat the stage names as a way to organise work rather than as a standard to comply with.

And the underlying idea is old. Tom Klaasen traced it back to Peter Naur’s 1985 essay on programming as theory building, which argued that the durable product of programming is a shared understanding of the problem, with source code as a partial record of it. That argument was available for forty years and mostly ignored. Agents did not create the problem. They made ignoring it expensive inside a single sprint, which turns out to be the only timescale that changes behaviour.

What context actually is

Context is not the prompt. It is everything sitting in the window at the moment the agent decides what to do: system instructions, repository conventions, the task description, files it pulled in, output from commands it ran, and every turn of the session so far.

The last two categories are the interesting ones, because nobody writes them. They arrive.

Figure 2. Most of an agent’s working context is not authored. It accumulates during the session, and it competes for the same attention as the parts you wrote deliberately.

Jarosław Wasowski describes a failure that will be familiar to anyone who has watched an agent work for half an hour. It runs a grep, gets eight files back, and edits the fourth one. The fourth was not the file that needed changing. It sat in the middle of a list, inside a window already more than half full of raw tool output, and it was read with degraded attention. Nothing in the model broke. The context had quietly gone bad, and stayed bad until an alert fired at two in the morning.

He calls this context debt. The comparison to Ward Cunningham’s technical debt holds, with one difference that matters: technical debt is incurred by a decision somebody made, and context debt accumulates on its own, while nobody is doing anything at all.

The part you can govern breaks into three kinds, and they behave differently.

Figure 3. Three kinds of context, with different owners and very different decay rates.

Business context is the row that gets skipped, and it has the worst failure mode of the three. Technical context goes stale when somebody refactors, which at least leaves a commit behind. A compliance rule or a contract term can change with no commit anywhere near your repository, and the agent will go on applying the old one with complete confidence and no visible symptom.

Where most teams are today

An honest inventory of a well-run team in 2026 usually looks like this. There is a rules file somebody wrote three months ago and nobody has opened since. There is an AGENTS.md or CLAUDE.md copied from a blog post and lightly edited. There is a Slack thread where a senior engineer explained the authentication flow once, in reply to a question, in a channel that has long since scrolled. There is a wiki page that may or may not describe the code as it exists.

None of it is versioned in any useful sense. None of it is tested. Nothing detects when two pieces of it contradict each other. And there is no way to answer the simplest question you would ask of any component: is this helping?

Applied to source code, that description would be a crisis. Applied to context, it is normal.

The four stages

The CDLC is a loop, not a phase. Running it once produces a slightly better set of instructions. Running it repeatedly is where the return actually comes from, for reasons covered further down.

Figure 4. The four stages. Generate and Observe are the ones teams skip, in that order.

Generate

Generating context means making implicit knowledge explicit, at a level of detail that works for a reader who takes everything literally and has no social instinct to ask a follow-up question. That is harder than writing documentation for a colleague, because a colleague fills gaps by guessing well.

The obvious approach is to capture everything, and it is wrong. SFEIR borrows the medallion pattern from data engineering and applies it to knowledge, which is the most practical framing I have seen: raw stays read-only, bronze is cleaned and attributed, silver is the reviewed layer that agents actually read, and gold holds the regenerated artifacts.

Figure 5. Refining knowledge through tiers rather than dumping it. The finished artifact is regenerated, never hand-edited.

The rule that makes the pattern work is the one people break first: you do not edit the finished artifact. You correct the tier it came from and regenerate, so the next person inherits the fix instead of rediscovering the problem six weeks later.

Format matters more than it should. Work on the ACE framework out of Stanford and SambaNova, published in late 2025, formalised why modular context outperforms one large file: when each convention is a discrete unit with a declared scope, it can be retrieved selectively and updated without disturbing anything else. Claude Code’s scoped rules are an implementation of the same idea, where a rule for shell scripts loads only when the agent touches a shell script. Anything you can keep out of the default load is attention you get back.

Evaluate

Debois asks why anyone would ship untested context when they would not ship untested code, and the question is harder to dodge than it looks. Evals are the tests. The pipeline shape is familiar. The rules inside it are not.

Figure 6. Evals behave like tests in structure and unlike tests in almost every other respect.

Seven complications come up in practice, and most teams discover them in this order.

1. Language models produce different output on repeated runs, even at temperature zero, so a single trial cannot gate anything. Define an error budget in advance, run at least five trials per scenario, and prefer a binary result to a granular score, because scores invite argument about whether 6.5 is worse than 7.
2. Eval quality matters as much as context quality. A suite of shallow scenarios that always pass provides confidence and nothing else.
3. Ownership needs deciding before the first failure, not after. Whether a non-passing eval blocks a release is not purely an engineering call, and product and standards people should be in that conversation.
4. Not every eval belongs on every commit. Fast checks while someone is iterating, the full suite before merge. Layering it this way also makes eval-driven context development possible: write the scenario first, then write the context that satisfies it.
5. Real failures beat invented ones. The scenarios worth keeping come from things that actually broke. Vercel’s open eval work converts observed gaps into targeted scenarios, and wiring agents to a tracing tool closes that loop without anyone having to remember to do it.
6. Context goes stale for reasons that have nothing to do with you. A new agent version ships, or a shared skill changes upstream, and behaviour moves while your code and your context sit untouched. Ordinary CI catches dependency changes because the build breaks. This breaks nothing, so run evals on a schedule rather than only on commits.
7. Adding an instruction does not simply add behaviour. It shifts behaviour you were not testing, in ways nobody can predict from reading the diff. Hamel Husain’s framing is the useful one: treat evals as a monitoring layer rather than a coverage target, because no suite will ever capture every interaction between instructions.

There is an eighth, which is Goodhart’s law wearing a lanyard. Optimise against a vendor benchmark and you will get a better benchmark score. The only evals worth tuning for are the ones you wrote about your codebase and your conventions.

SFEIR states the standard more bluntly than I would, and it is a good line to argue with: a failing eval is the same thing as a specification you never wrote down.

Distribute

Once context is worth having, other teams want it, and the mechanism most organisations reach for is copy and paste. That works until the fourth copy, at which point nobody can say which version is correct and every one of them has drifted differently.

Figure 7. Distribution has the same problems as any package registry, including the uncomfortable one.

The comparison to dependency management is not decorative. Context should be published, versioned, pinned, deprecated and scoped, for the same reasons libraries are. It also inherits the supply chain problem, and inherits it in a sharper form: a library is code you run, while context is instruction to a system that decides what to do. Signed, attributable context packages will stop sounding paranoid about six months after the first public incident.

Observe

Observation is where most of this falls down, because it requires reading traces that nobody is assigned to read. It is also where the useful material is. Production tells you what the context missed, in a way that no amount of internal review will.

Figure 8. Four failure shapes, each with a different fix. Conflicts are the ones teams find hardest to resolve, because resolving one means somebody’s rule gets deleted.

The distinction between the four matters because the fixes point in opposite directions. A gap means write something. Drift means regenerate something. A conflict means make a decision and remove the losing rule, which is organisationally harder than it sounds. Noise means take correct, well-written guidance out of the default load, which people resist because it feels like deleting work.

Why the loop compounds

A single pass through the four stages produces a modest improvement, and if that were the whole return the effort would be hard to justify. The argument for the CDLC is the second derivative.

Figure 9. The first pass is worth doing. The tenth is where the gap between teams becomes hard to close.

The mechanism is straightforward. Better context produces better agent output. Better output makes the remaining failures sharper and more specific, because the obvious ones are gone. Sharper failures make better eval scenarios. Better scenarios produce better context. By the tenth turn the team is not simply getting better answers from the agent; the humans have absorbed the conventions they were forced to write down, and they are coding differently too.

The incentive structure is the part I find most convincing, and it is the real parallel with DevOps. DevOps worked because it aligned the goals of two groups that had been pulling against each other, not because anyone bought a better deployment tool. The same alignment shows up here. An engineer who writes better context gets better output immediately and personally, which is enough reason to do it. Every other team that touches the same service gets the benefit as a side effect, whether or not the author cared about them. Cooperation falls out of self-interest, which is the only kind that survives a reorganisation.

Mapping it onto the lifecycle you already have

The most common objection to the CDLC is that it looks like a second lifecycle bolted onto a delivery process that is already carrying more ceremony than it can hold. That objection is fair when the work is organised as a separate programme with its own board and its own team, which is how it usually gets proposed.

It works better as a column of work attached to each phase you already run. Each phase generates a particular kind of context, and each phase has a natural moment to evaluate, publish and observe it.

Figure 10. The four stages, applied phase by phase. None of these cells is a new meeting.

Two rules keep this from turning into overhead.

First, context work belongs to the phase, not to a context team. The moment there is a group whose job is writing everyone else’s conventions, the conventions stop matching the code, because the people who know are not the people writing. This is the documentation failure mode with a new name, and it is the single most likely way for a CDLC initiative to fail politely over eighteen months.

Second, the artifact a phase produces should be the artifact the next phase’s agent needs. If design produces a decision record that no agent reads, design has produced documentation, which is fine but is a different activity. A useful test: delete the artifact and see whether the next agent run gets worse. If it does not, you wrote it for a human audience, and you should be honest about that rather than counting it as context work.

The review phase deserves particular attention, because it is where the highest-value context is generated for free and then thrown away. A review comment you have written twice is a rule you have not written once. Treating repeated comments as a backlog of missing context turns the most tedious part of code review into the input for the next pass of Generate.

What good context looks like

Volume is the easiest property of context to measure, which is why teams measure it and then optimise the wrong thing. A useful set of criteria comes from a 2026 paper by V. V. Vishnyakova on context engineering for corporate multi-agent systems, which proposes five: relevance, sufficiency, isolation, economy and provenance.

Figure 11. Five questions worth asking of any line of context, and the shape of the trade-off underneath them.

The trade-off runs against intuition, and the intuition is expensive. More context is not monotonically better. Attention is a budget rather than a container, and every token in the window competes for it, so precision falls as the window fills and material buried in the middle gets the worst of it.

This is also the answer to the most common objection to the whole framework, which is that context windows keep growing and will eventually make curation unnecessary. The capacity constraint does relax. The attention constraint does not relax at the same rate, and neither does the problem of a compliance rule that changed without telling anyone. Giving an agent everything you have is closer to giving a new hire read access to the entire codebase on their first morning and calling it onboarding. Volume was never the difficulty. Relevance and freshness were.

A maturity ladder

Maturity models deserve most of the scepticism they attract, and this one is useful only for locating yourself, not for planning a two-year transformation. The rungs are ordered because each one depends on the one below it. Evaluating context you cannot version is not possible in any meaningful sense, since you cannot say what you evaluated.

Figure 12. Six positions. Most teams that have adopted agents at all are at level one and believe they are at level three.

Level	What exists	The tell that you are here
0  Ad hoc	Context lives in chat sessions and in people’s heads.	Every session starts cold and someone re-explains the same architecture.
1  Written down	A rules file exists in the repository.	Nobody has changed it in months and nobody can say whether it helps.
2  Versioned	Context is reviewed in pull requests like any other change.	You can name who added a line and what problem it was meant to solve.
3  Evaluated	Scenarios gate changes, with an error budget rather than a pass gate.	Someone has removed a rule because the evals showed it was making things worse.
4  Distributed	Shared context is published, pinned and deprecated.	A second team consumes your conventions without forking them.
5  Observed	Production traces set the context backlog.	Failures reach the eval suite without anyone remembering to file a ticket.

Debois has a diagnostic question that cuts through the self-assessment problem faster than the table does. You have invested in models, in agents, in tooling and in infrastructure. What have you invested in the context that makes any of it work? Teams that cannot answer are usually at level one, whatever they would like to report.

Anti-patterns

These are cheap to recognise and awkward to admit, which is a reasonable definition of an anti-pattern.

Figure 13. Sorted by the stage that produced them. Several of these coexist happily in the same repository.

Two are worth expanding on, because they are the ones that survive longest.

The god file is the natural end state of a context file that nobody is allowed to delete from. It starts as a page of conventions, absorbs every correction anyone has ever needed to make, and ends up as several thousand lines loaded on every single request. The damage is not only the tokens. It is that no one can attribute behaviour to any particular line, so the file becomes unfalsifiable, and unfalsifiable artifacts do not get improved. The fix is scoping rather than deletion: most of what is in there is correct, and simply does not need to be present for most requests.

Eval theatre is the more dangerous one, because it looks like maturity. A large suite of scenarios that always pass tells you nothing about your context and produces a green dashboard that makes the question feel settled. The diagnostic is simple. When did a change to your context last cause an eval to fail? If the answer is never, the suite is measuring whether the model still works, not whether your context does.

What is still unresolved

Anyone presenting this as a settled methodology is selling something. Several parts of it are genuinely open.

• Tooling and methodology are waiting on each other. Ruslan Vlasyuk raised this on the original thread and nobody has a good answer: you cannot adopt a lifecycle when the tools do not exist, and nobody builds tools for a methodology nobody follows. The current escape route is that the first two stages need almost no tooling, so teams can start there.
• Self-tuning context is arriving faster than the review practices for it. Agents that rewrite their own instructions based on what worked are already shipping. Nobody has settled who reviews that diff, or what it means for an artifact to be authoritative when it edits itself between reviews.
• Business context has an ownership problem that no amount of engineering discipline solves. The people who hold it are furthest from the repository and have no reason to learn a pull request workflow, and every proposal to route around that ends with an engineer transcribing a policy they do not understand.
• The cost side is thinly evidenced. There is very little public data on what running a full CDLC costs a team per sprint, which makes it hard to argue for against a backlog. Most of the current evidence is practitioner reports, and practitioner reports are written by people for whom it worked.

Where to start

The version of this that succeeds is small and unglamorous. Three moves, in order, none of which needs a platform team or a budget line.

8. Pick one failure your agents repeat. Write the eval scenario before you write the context, run it five times to see how variable it is, then write the smallest instruction that moves the pass rate. You now have one tested rule, which is more than most organisations have.
9. Move context into review. Put the file in the repository, require a pull request, and record why each line exists. History and authorship are what make later deletion possible, and deletion is most of the work in year two.
10. Wire in one source of production signal. Traces from a single service are enough to start turning real failures into scenarios, which is what keeps the loop running once the initial enthusiasm has gone.

None of that requires believing that agents will write most of the code, or that this particular four-stage framing will be the one that lasts. It requires treating one markdown file as a component with an owner, a version and a test, once, and seeing whether the next run goes better.

Sources

Patrick Debois, The Context Development Lifecycle: Optimizing Context for AI Coding Agents (February 2026)  https://jedi.be/blog/2026/context-development-lifecycle/

Patrick Debois, CI/CD for Context: Same Pipeline, Different Rules (March 2026)  https://jedi.be/blog/2026/cicd-for-context/

Patrick Debois, The Context Flywheel: Winning on Context, Not Models (February 2026)  https://jedi.be/blog/2026/context-flywheel/

Patrick Debois, Two Weeks After ‘Context Is the New Code’ at AIE London (May 2026)  https://jedi.be/blog/2026/two-weeks-after-context-is-the-new-code/

Jarosław Wasowski, Managing Agent Context at Every Stage of the SDLC: CDLC and SDD (April 2026)  https://medium.com/@wasowski.jarek/managing-agent-context-at-every-stage-of-the-sdlc-cdlc-sdd-cecd0d575064

SFEIR, CDLC concept page and the medallion approach to knowledge production (2026)  https://www.sfeir.com/concepts/cdlc/

V. V. Vishnyakova, Context Engineering: From Prompts to Corporate Multi-Agent Architecture, arXiv 2603.09619 (2026)  https://arxiv.org/abs/2603.09619

Aurimas Griciunas, State of Context Engineering in 2026 (March 2026)  https://www.newsletter.swirlai.com/p/state-of-context-engineering-in-2026

Packmind, Context Engineering Best Practices for AI-Powered Dev Teams (April 2026)  https://packmind.com/context-engineering-ai-coding/context-engineering-best-practices/

Peter Naur, Programming as Theory Building (1985)