Context, Construction and Reconstruction

Notes on a way of working with coding agents · September 2026

I have been a developer for over twenty years, and I no longer read the algorithms. I no longer have the capacity for that if I need it for what matters more to me: the architecture, the structure, the question of whether a design will hold up under the next three requirements. I leave the rest to be checked — by agents, against each other, in a process that grew out of practice and whose rationale I only found afterwards. These notes are an attempt to write it down.

Context and the decision log

A coding agent has no memory. What it has is the session history: instructions, answers, files it has read, test results, its own reasoning. Over the course of a task, these form a context that extends beyond the code — which alternative was rejected, where an edge case appeared, how a gap in the specification was filled. You can no longer recover that from the code alone. Code is what remains when you throw away the context.

That is why I never clear the context. Reviews, questions and corrections always go back into the session where the work was built. This runs counter to the usual advice: clear sessions often, cut tasks into chunks that need no context. That advice is sound, but it addresses a different pattern of work: contexts made up of detours, pages of tool output and failed debugging attempts that stay in the window and continue to exert an influence. A context made up of decisions does not get worse as it grows longer. It gets denser. And since around autumn 2025, models have been recognising a wrong turn within minutes rather than hours; the detours that remain in the context are brief and marked as discarded — information, not noise.

The quiet adversary is compaction. It records what changed and loses the why, because a summary cannot know which rationale will be needed later. The agent that follows thinks it is the same one; it is a new one with a good summary. The safeguard is not to clear the context but to preserve it: during the work, I have the agent record important decisions in a file in the project — the chosen solution, the reasons, the rejected alternatives, the open questions. Anthropic describes preserving architectural decisions as a goal of compaction and supplements it with persistent working notes. In my experience, the notes are the more reliable of the two.

Intent and implementation

The loop is: decide what is to be built — let the agent build autonomously — review — have it make corrections. The what belongs to me, the how to the agent. Where the boundary lies shifts with each model. Whether a queue belongs at a particular point was an architectural decision I had to specify a year ago; today the agent sees it for itself. My job is to stay above that rising line.

I begin every task with the same question: “How would you solve this?” The answer tells me, before a single line of code exists, whether my intent has landed and what assumptions the agent brings. A misunderstanding costs two sentences at this point; after the build, it costs a round of review and refactoring. And the question makes the how the agent’s own design. It is not building to instructions; it is building its proposal, which I have approved or corrected. The rationale is then explicit in the context, not merely implicit in the code — and it is the first entry in the decision log.

This determines where I put in effort and where I do not. There is structure that compensates for current model weaknesses: prompt chains, hand-crafted roles, scaffolding around the model. It becomes obsolete with the next model, and I have stopped investing in it. And there is structure that preserves intent — goals, constraints, reasons. That does not become obsolete, because no model, however good, knows what I wanted if it is not written down anywhere. Directing rather than structuring is a bet that the models get better every month. So far, it has won every month.

Review and reconstruction

The coder’s self-check is followed by a review from a different model — in my case, Claude against Codex. The objections go back to the coder, who responds. Its corrections or its defence go back to the reviewer. I decide whatever remains unresolved.

What surprised me about this process is that the coder does not capitulate. I had expected it to accept review points because they sounded competent. Instead, it refers to reasons discussed during implementation that the reviewer does not know, and concedes where it has none. The result is distinctly better than when I let the reviewer implement its own suggestions. My explanation is context: capitulation happens when an agent is asked to defend code it did not build itself — a fresh session, “here is a diff and a review, work through the points.” It then has no rationale of its own for any decision, and the review is the only opinion in the room. The coder in its own context meets each objection with knowledge the reviewer lacks. When the reviewer does the fixing, the asymmetry runs the other way: it sees the symptom, not how it arose, and its fixes are locally correct and globally incoherent. I cannot say from experience whether context alone explains the difference. I can say that the difference is there.

The same applies to subagents. The main agent knows what a subagent built only from its final report. Its defence in a review holds only for what was created in the main context.

And at the end of the loop, I do not need the code. I need the dialogue. An objection and a response to it can be judged in seconds: a structural objection or a matter of taste, convinced or merely conceding. That is the level where my attention still sits. The dialogue does not prove that every local error has been found; where a disputed claim depends on actual behaviour, a test has to settle it. But local errors are what the loop catches. Architecture is global, and no agent sees it from within a single task.

Model handwriting and switching models

The reviewer is a different model, preferably from a different family. Two instances of the same model have correlated blind spots; what one finds plausible, the other does too. Switching models does not guarantee an independent check — even different models sometimes miss the same thing — but it reduces the overlap.

There is another effect I observe but cannot prove: a model reconstructs code more easily when it wrote that code itself. Not because it remembers — it remembers nothing — but because the code is in its own dialect: module boundaries, naming, error handling, level of abstraction, everything where the model would put it itself. It can read its own handwriting with its eyes closed.

Research offers limited support for this. In 2024, Panickssery, Bowman and Feng showed that models recognise their own summaries at above-chance rates and favour them in evaluations. The study examined summaries, not code; it does not establish a better understanding of self-generated code, and Chen and colleagues point out in 2025 that a preference for one’s own answers can only count as bias after controlling for their actual quality. The handwriting thesis therefore remains a hypothesis. Its flipside, however, is well established and more important in practice: a model reading its own code tends to consider it correct because it looks familiar. Fluency feels like correctness. That is precisely why the reviewer must read someone else’s handwriting.

From this I derive a rule that looks asymmetric: I change the coder only when I have a reason. I change the reviewer precisely because I do not need one. Continuity with the coder is already justified by the preserved context; whether handwriting also helps across sessions is the open hypothesis — and it would be no reason to keep a demonstrably better model away from the project.

What remains

Taken together, this is a bet that every investment in the how is lost and every investment in the what pays off. Goals, constraints and the reasons for decisions must remain accessible as models and tools change; everything else is allowed to change.

And what remains of my role, once you subtract the typing, is pretty much this: the person who knows what is to be built, asks how the other would do it, reviews the result — and recognises when the how is no longer their concern. This is the division of labour between a client and a craftsperson who trust each other. The fact that it works with agents surprised me less than the fact that I had to stop reading the code to make it work.