# The Half-Life of AI Scaffolding AI scaffolding does not throw an error when it expires. Once the model outgrows the gap it was built to cover, the useful question is not whether it still runs, but what disappears when we remove it. ## Metadata - HTML: https://glenzli.com/en/notes/half-life-of-ai-scaffolding/ - Markdown: https://glenzli.com/en/notes/half-life-of-ai-scaffolding.md - Collection: Notes - Language: en - Published: 2026-07-16 - Updated: 2026-08-17 - Tags: ai, agent, workflow, context, maintenance ## Content I recently reset an AI scaffolding repository almost to zero. One commit removed more than ten thousand lines of code, tests, and documentation. The repository had grown an entire toolchain around project knowledge: inventory the codebase, decide what deserved documentation, build and query the knowledge base, track source changes, review code and tests, manage migrations, and conduct retrospectives. It eventually acquired a CLI, specifications, release machinery, and a large test suite of its own. This was not another round of simplification. I removed the machinery. What remains is a handful of templates and four short skills. They record why the project exists, which constraints are stable, where facts live, and where a human decision is required. The model can read the source for module layouts, interfaces, and call graphs. Deleting it felt less like a surprise than an overdue appointment. Finally. I have always assumed that general-purpose AI scaffolding would have a short life. Useless structure gets in the way immediately. Useful structure lasts only until the model or runtime absorbs the capability it supplied. I kept the system modular for that reason. Not to extend its life, but to make each layer bypassable, measurable, and removable. Ten thousand lines are gone. The project survived. So did the parts that mattered. ## Obsolescence Is Quiet Ordinary software usually leaves evidence when it ages. A dependency goes unmaintained. An interface is deprecated. Tests start failing. AI scaffolding can expire without making a sound. If the model cannot find relevant files, we prescribe a reading order. If long context overwhelms it, we force summaries before detail. If it misses checks, we assign several review roles. If its reasoning drifts, we add another instruction about sources, assumptions, and unsupported claims. Those interventions often worked. They grew out of real failures. Then the model begins doing the same work on its own. The old workflow does not retire. It still runs, and the model still produces good results while carrying it. The credit remains attached to the scaffold long after the model has learned to stand without it. I watched the same thing happen to a collection of reasoning-correction prompts. They existed because models would confidently follow a typo, treat commands inside reference material as instructions, or forget the scope and date of the question. I kept each prompt narrow: point out the trap, then let the model correct itself. Their ideal future was never endless expansion. It was deletion. Eventually I added paired tests, comparing runs with and without the prompts. The tests could not prove that every failure mode had vanished. They did show that the bundle no longer deserved a permanent place in daily use. I archived it as an experiment. That was success. The knowledge-base repository reached the same point later. Private project history still mattered. The generic workflow wrapped around it did not. The two repositories raise one question: > Does it still run, or does it still help? Those are different claims. ## Remove It and Measure When a skill launches, people demonstrate how well the model performs with it installed. Months later, the base model has improved. The same skill still produces a good result, so the result continues to appear on the skill's balance sheet. Few people remove it and rerun the baseline. The better question is: > How much worse is the model without it now? Without a deletion test, improvements in the model keep becoming achievements of the scaffold. A workflow no longer needs to add value. It only needs to avoid causing obvious damage. [SkillsBench](https://www.skillsbench.ai/skillsbench.pdf) uses paired evaluation for exactly this reason. A skill should explain not only what happens when installed, but what is lost when removed. The results are untidy. Skills help overall, yet some tasks regress under redundant or conflicting guidance. Broad, exhaustive instructions can underperform shorter, focused ones. That matches my experience. A general skill that improves a wide range of tasks is probably covering a recognizable weakness in the model. Once that weakness disappears, so does the reason for the layer. Specialized skills often have a clearer job. They add domain knowledge, concrete constraints, or verification methods. General skills either stay small and solve one problem, or compromise across so many situations that they become bland. Trying to cover everything is a reliable way to reach nothing in particular. Model and runtime capabilities keep absorbing work that once required application-level orchestration. When I wrote this essay, OpenAI had just added programmatic tool calling and multi-agent collaboration for [GPT-5.6](https://openai.com/index/gpt-5-6/) in the Responses API. The model name will age quickly. That is the point. Treat it as a timestamp, not a foundation. Release notes can tell us when to retest. Only our own tasks and baselines can tell us when to delete. ## Keep What Cannot Be Rebuilt Removing process does not mean removing knowledge. A project should still tell its next maintainer why it exists, which directions were tried and abandoned, what must not be changed casually, and where important facts came from. Documentation should help a model locate truth, not rehearse how to read the source. The reset repository now keeps a minimal project skeleton: purpose and non-goals, stable constraints, sources of truth, validation methods, and boundaries that require human confirmation. It does not restate classes, interfaces, modules, and call graphs. Those change quickly, and a model can recover them from the current code. I no longer ask documentation to speak for the source. I ask it to preserve what the source cannot say. The same distinction changed a separate long-context project. Early versions prescribed how models should route, summarize, expand, and organize information. Later, most of that disappeared. The protocol now keeps one plain idea: history should live in addressable, sourced, revisable Pages. An authorized model can decide how to search and read them. Models may no longer need a protocol to teach them how to turn pages. They still cannot read a page that was never preserved or made available. Saving context and scripting how a model uses context are different responsibilities. The first needs infrastructure. The second can thin out as models improve. My current rule is simple: > Do not keep restating what current source and tools can reconstruct. Preserve the intent, history, responsibility, and boundaries they cannot recover. Better models reduce choreography. They do not preserve our history or assume our final judgment. ## Built to Be Removed The deleted structures were not mistakes from birth. Most grew from real failures and performed useful transitional work. People like building reusable wheels. The effort makes permanence feel deserved. But AI lowers the cost of making a thing; it does not make durability cheap. A wheel still has to survive another project, another team, another environment, and years of compatibility and maintenance. Often the honest object is a crutch for the current model. When the capability arrives, put the crutch down. Not every temporary fix needs to join the BIG PICTURE or be promoted into "valuable institutional knowledge." I will keep building AI workflows. People need to work this month even if next month's model may erase the problem. I will also leave room for deletion. The layer should be bypassable. Its effect should be measurable. Removing it should not injure the project underneath. I will keep scaffolding small, not because I expect it to live longer, but because I want to remove it cleanly when the model crosses the gap. Permanent tenure is off the table. ## Related Repositories - [Dev Skeleton](https://github.com/glenzli/dev-skeleton): the minimal project-skeleton method retained from the knowledge-base scaffolding. - [LLM Prompt Evals](https://github.com/glenzli/llm-prompt-evals): general-purpose prompts and evaluation experiments that are no longer actively maintained. - [Paged Context Protocol](https://github.com/glenzli/paged-context-protocol): a user-owned Page space across sessions and projects; the current protocol retains persistence and access semantics, while the earlier fixed routing and summarization workflow has been archived.