Your Agent Context Needs a Development Lifecycle: The CDLC Framework

Skills, agent configurations, prompt instructions, and rules files. These artifacts now determine what your coding agents produce. They shape every line of code your agents write, yet nobody treats them that way. Teams write a skill, commit it to a repo, and never test whether it still works after a model update. Agent configurations are copied and pasted across teams without versioning. Rules files drift out of sync with the codebase they describe. When something breaks, the signal is a developer noticing weird output and complaining on Slack. The question: if context is the new code, what is its software development lifecycle?

1. CDLC: Treating Context Like Code

Patrick coined a framework for what’s missing: the Context Development Lifecycle (CDLC). The CDLC is not about context window management or fitting more tokens into a prompt. It’s about managing the quality of the pieces that go into the context window. Is a skill up to date? Does the model actually react to it correctly? Are you providing context the model already knows? The CDLC has four phases that map directly onto what we already do with code. Generate is where everyone starts: writing skills, building prompt configurations, setting up agent rules — the equivalent of writing code, and where most of the time goes today. Evaluate is testing: checking linting and syntax, and at the sophisticated end, running scenarios — load a skill, ask a specific question, check whether the agent produces the expected result, across models and versions. Distribute is shipping: from committing to a repo to publishing to an installable registry with versioning, discoverability, and access controls. Observe is production monitoring: is the skill being used, is it producing the right results, how many turns before a developer intervenes?

// The CDLC framework: if context is the new code, it
// needs a software development lifecycle. Four phases map
// directly onto what we already do with code.
const CDLC = {
  "generate": "write skills, prompt configs, agent rules",
  "evaluate": "test: scenario runs, trigger words, model
                versions, token waste",
  "distribute": "ship: commit to repo -> installable registry
                 with versioning and access controls",
  "observe": "monitor: usage, results, interventions, overrides"
};
// Maturity curve mirrors software engineering: teams
// generate and distribute first, skip evaluation, ship to
// production, and wait to see what happens.

2. Why Teams Skip Evaluation

The maturity curve here is identical to what happened with software development practices over the past two decades. Organizations generate and distribute first. They skip evaluation entirely. They ship skills to production — meaning to the developers using them — and wait to see what happens. It’s directly comparable to teams skipping test-driven development: they don’t know the pain, so they go immediately to production. The pain arrives when a skill works on one model version but breaks on the next, or when it triggers on the wrong question and gives a developer confidently wrong instructions. When a convention the skill enforced was correct six months ago, but the codebase has since moved on — these are the same failure modes we see in untested code: regressions, false positives, stale assumptions.

// A TDD loop for context: write the skill, write the
// scenario, check the output, iterate. This scenario test
// loads a skill, asks a specific question, and verifies
// the agent produces the expected result.
async function testSkill(skillName, question, expected) {
  const skill = await loadSkill(skillName);
  const output = await runAgent({ skill, question });
  const pass = output.includes(expected);
  await recordResult({ skillName, question, pass });
  return { skillName, pass, output: output.slice(0, 120) };
}
// Test across models and versions. Check whether you are
// writing in context the model already knows (token waste).
// Verify the skill activates on the right trigger words.

3. Two New Metrics: Human Touch and the Reuse Multiplier

Patrick frames the scaling question using two metrics that sit atop traditional DORA measures. The first is human touch: how often does a developer need to intervene in a given agent workflow? Every intervention is a signal that context is missing or wrong. Reducing human touchpoints is a direct measure of how autonomous your agentic coding loop actually is, and it’s often correlated with cost, since more turns mean more agent spend. The second is the reuse multiplier: how many developers benefit when you improve a single skill? If one developer fixes a skill and only they benefit from it, that’s 1x. If that fix goes into a shared registry and 50 developers get it, that’s 50x. A developer who optimizes their own agent loop gets better individual results, but the improvement stays with them: when they fix a skill, nobody else benefits; when they discover a failure mode, nobody else learns from it. The ROI is 1x.

// Distribution maturity: pasting a skill into Slack is
// not distribution, the same way emailing a .jar file is
// not dependency management. A registry gives you
// versioning, discoverability, and access controls.
{
  "registry": {
    "skills": [
      { "name": "refactor-early-returns", "version": "2.3.1",
        "models": ["claude-sonnet-5", "gpt-5.6-terra"],
        "triggers": ["refactor", "early return"],
        "owner": "platform-team" }
    ],
    "publish": "git push -> CI validates scenarios -> tag",
    "install": "agent picks latest compatible version"
  }
}
// When one developer fixes a skill, the fix goes into the
// shared registry and 50 developers get it -- that is the
// reuse multiplier in action.

4. Invariants and the AI Slop Register

Every codebase has patterns that AI consistently gets wrong: convention blindness, hallucinated APIs, cargo-cult code, over-engineering. At Aviator, these are called Invariants, or the AI slop register. Both the skill register and the AI slop register exemplify the same underlying principle at both ends of the development lifecycle: catalog your engineering standards and feed them to agents. Before code generation, that means skills. At code review, it’s a catalog of patterns AI consistently gets wrong in your codebase. The slop register informs automated checks that catch what slipped through. You cannot scale code quality by asking humans to review more carefully. You scale it by investing in the guardrails that codify your standards at both ends.

5. Code Walkthrough: Tests, Registry, and Tracking

The code blocks in this post unpack the framework. Block one is the CDLC four-phase map: generate, evaluate, distribute, observe. Block two is a TDD loop for context: write the skill, write the scenario, check the output, iterate — tested across models and versions. Block three is distribution maturity: from committing to a repo to an installable registry with versioning, discoverability, and access controls. Block four tracks human touch: record the workflow, turns before intervention, reason, and timestamp. Block five computes the reuse multiplier: when a fix lands in the shared registry, the number of benefiting developers is the multiplier.

// Human touch: how often does a developer need to
// intervene in a given agent workflow? Every intervention
// is a signal that context is missing or wrong.
async function trackIntervention(run) {
  return {
    workflow: run.workflow,
    turnsBeforeIntervention: run.turns,
    reason: run.reason,       // wrong output | missing context
    correctedBy: run.developer,
    timestamp: new Date().toISOString(),
  };
}
// Reducing human touchpoints is a direct measure of how
// autonomous your agentic coding loop actually is -- and
// it correlates with cost, since more turns mean more
// agent spend.

6. What to Do Next

Treat context as a first-class engineering artifact. Step one: put your skills and rules files under version control in a repo, even simple git tags. Step two: write scenario tests for your three highest-frequency skills and run them automatically on every model upgrade. Step three: add a human-touch counter to every agent workflow and treat it as your autonomy north-star. Step four: catalog failure modes developers discover into an AI slop register and automate the checks. The key to scaling is not making humans try harder; it is codifying standards into guardrails so every improvement compounds across the organization through the registry.

// The reuse multiplier: how many developers benefit when
// you improve a single skill? If one developer fixes a
// skill and only they benefit, that is 1x. If the fix goes
// into a shared registry and 50 developers get it, 50x.
function reuseMultiplier(fix) {
  const affected = registry.consumersOf(fix.skill);
  const solo = fix.keptLocally ? 1 : affected.length;
  return { skill: fix.skill, multiplier: solo };
}
// The failure modes are the same as untested code:
// regressions, false positives, stale assumptions. A skill
// works on one model version but breaks on the next, or
// triggers on the wrong question and gives a developer
// confidently wrong instructions.