Your agent context needs a development lifecycle
The New Stack Ankit Jain
Agent prompts and rules are acting like code now, but most teams still don’t test or track them. That’s why one model update can quietly break a whole coding workflow.
Based on reporting by The New Stack, Ankit Jain — read the original for the full story.
Summary, retelling and take written by AI under human oversight; images are AI-generated illustrations. How we work · Report an error
Skills, agent configs, prompt instructions, and rules files are no longer just helper text. They shape what coding agents build, how they make decisions, and which conventions they follow or ignore. In practice, they’re software. In practice, most teams still treat them like scratch notes.
That mismatch is the point of Patrick’s Context Development Lifecycle, or CDLC. The framework isn’t about stuffing more tokens into a prompt. It’s about managing the quality of the context itself: whether a skill is current, whether the model responds the way it should, and whether the system is wasting context on things the model already knows.
CDLC has four phases. Generate is the part people already do: write the skill, set up the prompt, define the rules. Evaluate is the missing discipline. That means checking syntax, running scenarios, testing across model versions, and seeing whether the trigger words actually activate the right behavior. Distribute is shipping, ideally with versioning, discoverability, access control, and a registry instead of a Slack paste. Observe is production monitoring: whether the skill is used, whether developers keep overriding it, and how many turns it takes before someone steps in.
The complaint here is simple. Teams rush context into production and wait for the pain. Then a skill works on one model version and fails on the next, or it fires on the wrong question and gives confident nonsense. That is just regression testing failing in a new outfit. The source even points to Aviator’s Invariants, or the AI slop register, as the mirror image of skills: one catalog for what to feed the agent, another for the patterns the agent keeps getting wrong.
The scaling argument is sharper still. Patrick frames success with two metrics: human touch and reuse multiplier. Human touch asks how often a developer has to intervene. Reuse multiplier asks how many people benefit when one person improves a skill. A fix that helps only the author is 1x. A fix that lands in a shared registry and helps 50 developers is 50x. That’s the real business case for treating context like a governed asset, not a pile of clever prompts.
The playbook is familiar to any platform team: registry, access control, evaluation, security scanning, dashboards, ownership. The hard part is also familiar. Somebody has to own the skill after the original author moves on. Without that, the whole thing turns into orphaned repos with better branding. The final dream of zero-human-in-the-loop code generation is there, but the source is right to call it risky. Less babysitting only happens after a lot of boring infrastructure.
My take — AI-written commentary, not fact-checked reporting
This is one of those rare AI ideas that sounds obvious only after someone says it out loud. Treating prompts like software is boring, which is exactly why it might work. The industry has spent enough time pretending “just prompt harder” is a strategy; now it needs registries, tests, and ownership, not more wizardry.
Read more about this at: The New Stack