Attention dilution

Four hours into a good session, the work is still good. Nothing has broken, nothing looks wrong, and the last three files came back faster than the first three. Somewhere in those last three files a rule stopped being followed. Not the important-sounding rules, which are stated loudly enough to survive anything, but the particular ones: the data access that belongs in a service layer and has quietly moved into a component, the list that is supposed to virtualize and is now a scroll view again, the import that was pinned to one package and has drifted back to the one the rest of the world uses.

This is the part that is worth naming precisely, because the intuitive worry is the wrong one. A long session does not degrade toward error. It degrades toward the generic. The constraints that make a codebase yours are a few hundred words of local peculiarity competing against the enormous mass of convention a model was trained on, and as a conversation lengthens and its context fills with the residue of everything already done in it, the local peculiarity thins and the convention reasserts itself by sheer weight. Two of our engineering research records reached that conclusion independently from practice, in different stacks, without citing each other. The published literature on long contexts is adjacent rather than identical, measuring how reliably a model retrieves what sits in the middle of a long input rather than how faithfully it obeys a rule stated at the top, and we hold the claim at that grade deliberately.

What makes the drift dangerous is that it produces the most reviewable code in the world. Conventional code is what a reviewer’s eye is trained to accept. An error announces itself by failing; convention announces nothing, because it looks like every example in every tutorial, and the reason your project forbids it is a paragraph of reasoning that lives in a file nobody reopened. Architectural drift is therefore not a sequence of bad decisions. It is a sequence of ordinary decisions accumulating in a direction nobody chose, which is the same mechanism that runs under context loss, arriving here on a clock instead of across a repository.

The remedy is unglamorous to the point of embarrassment, which is probably why it gets skipped. Start a fresh session for each feature or fix, and clear the old one on merging so that yesterday’s half-abandoned plan is not still shaping today’s suggestions. Feed the subsystem the task actually needs rather than everything available, since a diluted context is not a richer one. Keep the standing constraints in a file that gets reloaded at the top of every session rather than in a conversation that has to remember them, because a file does not get tired and a context window does. And treat a session that has started arguing with its own constraints as finished, regardless of how much momentum it seems to have.

The deeper point is about where a project’s identity is kept. Everything specific about how you build lives in the difference between your way and the common way, and that difference is exactly the part of a context that thins first. Write it down, reload it often, and the work stays yours.