Imagine asking a coding agent to make a small website. The goal is clear, the folder is almost empty, and there are few decisions to remember. You describe what you want, the agent writes the files, and the first version works. This is the experience that makes coding by conversation feel remarkable. It is also the least demanding moment in the life of the project.
The trouble does not start because agent-assisted coding suddenly stops working. It starts because the successful first build becomes a second build, then a redesign, then a series of fixes. Each round leaves something behind: a decision, an exception, a temporary workaround, an instruction, an abandoned approach. The project grows a history, while the agent still has only a limited working window in which to understand the next request.
Iteration changes the job
At first, the goal and the current state are nearly the same thing. After several rounds of work they separate. The current code reflects old goals as well as new ones. A plan may describe what was intended before the latest change. A progress note may say what happened without preserving why. Instructions accumulate, because adding a warning feels safer than deleting one. A fresh session can see the artifacts, but it may not see the reasoning that made them sensible.
This is especially costly if you do not inspect every line. You depend on the agent to surface the moments when a choice, a risk, or a change of scope needs your judgment. A missed checkpoint can turn a small misunderstanding into several rounds of confident work in the wrong direction. The central problem is no longer generating code. It is keeping context, state, guidance, and judgment coherent while the project keeps changing.
Why the obvious fixes are not enough
A project instruction file is a good place for a small set of stable rules. It becomes less useful when it also has to hold temporary state, detailed methods, old decisions, safety boundaries, and the explanation for every unusual workflow. The whole file gets loaded when only a small part is relevant. Old guidance stays because nobody is sure whether it is safe to remove. Rules that contradict each other can survive long after the situation that produced them.
Skills improve this by making guidance modular, but modularity is only one part of the problem. A growing skill collection still needs reliable routing. It also needs ownership, maintenance, and a way to retire components that no longer earn their place. Skills alone do not preserve the state of the current job, clean up superseded work, or guarantee that a required checkpoint happens.
You can also rewrite a long process prompt at the start of every session. That makes your memory the workflow engine, so the process changes slightly every time. For a small project none of this may matter: one instruction file and a few well-chosen skills can be the simpler and better setup. The case for more discipline appears only when recurring drift and re-explanation become a real cost.
The Coldstart loop
Coldstart is an operating discipline around Claude Code. It does not make the model smarter. Its current implementation is specific to Claude Code, although some of its principles may transfer to other coding agents.
The loop begins by preparing one finishable problem. A new session starts from a small pointer to the active plan and an exact list of material to read. Detailed guidance is loaded when the task calls for it, rather than every method living in the always-present instructions. Project knowledge is kept in governed files, while reusable capabilities live on a separate routed shelf.
Some boundaries should not depend on the agent remembering a paragraph. Checks and lifecycle automation can make required steps less optional. Other boundaries cannot be reduced to code: the human still decides at the seams involving risk, intent, outward action, and meaningful changes of scope. The loop is designed to end with verification and a bounded handoff. Superseded work is removed when that is safe, or explicitly queued when the cleanup needs a later judgment. The next session begins from that durable state instead of reconstructing the project from chat history.
Commands fit into this loop as stable entrances to repeated workflows. Their value is not magical shorthand. A preparation command can shape one unit of work consistently, a resume command can load its state, a close command can check the result and leave the next handoff. You still supply the goal and the judgment. The command stops the surrounding method from being reinvented every time.
Why the parts depend on one another
This is one operating discipline rather than a bag of features, because each answer creates the need for the next. A limited working window favours narrow work units. Narrow units require durable state between sessions. Durable state requires rules for where files belong, how long they live, and who owns them. Routed knowledge requires checks for reachability, duplication, and uncontrolled growth.
More autonomous execution makes reliable human checkpoints more important, not less. Repeated iteration creates a need to classify divergence, recover from a bad direction, and let superseded components die. And claims about the harness create a need for measurement that can expose a failure rather than merely report success. Remove any one of these relationships and the pressure moves somewhere else: into a bloated handoff, a crowded instruction file, a forgotten rule, or an ever-growing catalog.
What can honestly be claimed
The repository contains many of these structural mechanisms, along with checks and deliberately defective cases meant to show that the checks can fail. That supports concrete claims about what the harness contains and what selected tests exercise. It does not prove that Coldstart improves general productivity, or produces better code than a simpler setup.
The limits matter. On the recorded evaluation, the routed capability map ties a simple word-matching baseline rather than beating it. Its case rests on structure, provenance, eligibility, and governed growth, not on demonstrated ranking superiority. The product is mostly built but has not completed public cutover. Existing-project adoption, knowledge migration, and platform verification all still include open work. Coldstart is best understood as a reasoned and partly tested approach whose user outcomes still need experience and evidence.
The practical test
The other pages in this group ask the questions hidden inside the loop. How much context is useful? What belongs in one session? How should state survive a fresh start, and how should knowledge be stored without becoming a new source of clutter? When should guidance be routed, when should a rule become a check, and how should a project change course without leaving abandoned work behind? What can the harness measure, how can the method adapt, and what does adoption actually cost?
Those questions lead to a simple fit test. If a project is short, its rules are stable, and the person steering it can easily recover context, Coldstart's ceremony may cost more than it saves. If the work spans many sessions, and drift, forgotten decisions, and re-explanation are already expensive, a governed loop may be worth the discipline it asks of both the agent and the human.
Next
Every claim on this site is held to a published policy. That policy is the next page. Continue with Claims and limits.
How current this page is
To ask whether a claim on this page still holds, or to report one that does not, write to [email protected]. The date above is when the page was last checked against the product, not when it was written.