A coding agent can produce a convincing first build and then become harder to steer after a few rounds of change. Nothing broke. The second request is usually smaller than the first. It is worth understanding why the work still gets harder, because every practice described in this group of pages exists to answer that pressure.
The first attempt begins under unusually favourable conditions. The goal is fresh, the folder is small, and there is almost no history to reconcile. After several changes, the agent is no longer solving only the visible feature request. It also has to recover earlier decisions, work out which instructions are still current, tell accepted work from rejected work, and fit the new change into a project whose files may tell different versions of the same story.
The first build has almost no history. Iteration turns context, decisions, and abandoned paths into part of the engineering problem.
That is Coldstart's working model of the problem, and it explains why a project can become difficult to steer even when the next code change looks small.
An ordinary example
Picture a small order app. In the first session you ask an agent to add a CSV export: put a download control on the orders page and include the fields already visible in the table. The agent finds a clear page, a clear data shape, and almost no conflicting history. It produces a convincing result in one pass.
Then the project changes. A customer reference is added to the table, but an old note still lists the original export fields. A new authorization rule says support staff can view orders but cannot export them. Someone considers moving large exports to a background job, then rejects that approach because the app is too small to justify the extra machinery. The handoff note was written before that decision and still says background export is planned.
Now you ask for one apparently modest improvement: add a date range to the export. The agent has to do more than add two inputs. It must decide which field list is authoritative, apply the newer authorization rule, avoid reviving the rejected job design, and notice that the handoff is stale. The code task is not necessarily harder than the original export. The accumulated project state is.
This example runs through the rest of these pages. It is deliberately small, because the point is that the difficulty does not come from the size of the feature.
The goal and the current state drift apart
On a first build, the stated goal and the current project are close together. There may be only one reasonable interpretation of what should exist. Iteration separates them. The code holds the results of old goals, while the new request adds exceptions, revisions, and constraints.
That creates a reconciliation job. The agent needs to understand not only what you want now, but which parts of the existing project are deliberate. A workaround can look like a bug. A temporary choice may have quietly become a dependency. A rejected option may still appear in a plan or a comment. Without the reasoning behind those artifacts, a fresh session can make a locally sensible edit that moves the project in the wrong direction.
If you steer the work without reading every line, this raises the cost of a missed decision. When the agent fails to surface the authorization conflict in the order app, several rounds of polished implementation can follow before the mistake becomes visible.
More context is not the same as better context
The obvious response is to give the agent everything: the full chat, every plan, all progress notes, and a growing instruction file. That solves one danger by creating another.
Too little context can hide a constraint or cause old research to be repeated. Too much can place the current rule beside stale plans, duplicated summaries, long test output, and unrelated advice. The right fact may be present but hard to distinguish from the noise. Coldstart calls this dilution, and it is a different problem from simply reaching a token limit.
A smaller working window can still be poor if it is dense with contradictions. A larger one can be fine if every source in it is current and relevant. Prompt count and window percentage therefore cannot diagnose the problem on their own. The practical target is useful context: enough current intent, evidence, decisions, code, and verification to do this job accurately, without loading the entire history of the project.
Artifacts preserve results more easily than reasons
Projects are good at retaining visible outputs. The code records what was built. A checklist records that a task was completed. A progress note records that a session ended. None of those artifacts automatically preserves why one path was chosen and another rejected.
That missing reason is what hurts during iteration. In the order app, the absence of a background job could mean nobody considered scale, or it could be the result of a deliberate decision to keep the system simple. The same files support either story. If the decision is not stored somewhere findable, a later agent may confidently recreate work the project already decided not to own.
Chat history is a weak answer, because a new session may not receive it and a summary of it is selective. Compaction can help a single conversation continue, but it is not perfect memory and it is not a verified project handoff. Durable project state has to make current decisions and rejected paths findable without asking the next session to reconstruct them from old dialogue.
Every round can enlarge the steering surface
Iteration adds more than code. It adds instructions, exception lists, plan entries, temporary files, verification output, and warnings written after earlier mistakes. Adding another note usually feels safer than deciding whether an older note should be replaced. Over time, several plausible sources can claim authority over the same decision.
This is how a successful project becomes harder to steer while each individual request stays reasonable. The agent spends more of its working window choosing among artifacts before it can act. The person steering has more seams to notice, each one a place where intent or scope needs judgment. If neither side closes old paths cleanly, the project's history becomes part of every new task.
Coldstart's answer is not to erase history. It is to shape what the next session has to carry: one bounded problem, a small resume pointer, durable homes for decisions, guidance loaded on demand, checks that are not optional, and an explicit close. The other pages in this group take those one at a time. This page is only about the pressure that makes them worth the trouble.
What this does not claim
This explanation is a working model, drawn from Coldstart's own early failure patterns and the design response to them. It is not a universal law about every model, project, or long conversation. A wrong edit can come from stale model knowledge, an unclear goal, weak verification, or an ordinary implementation mistake rather than context pressure. Coldstart has also not shown that its method improves general productivity or code quality.
The fit test matters. A short project with stable rules may be served better by one instruction file and a few focused skills. The extra ceremony becomes worth considering only when recurring drift, rediscovery, and missed handoffs are already costing you something.
Next
The next question is what to do when the plan itself turns out to be wrong. Continue with Changing course without leaving a mess.
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.