Context loss

The usual account of why a system decays is a moral one. Somebody cut a corner, somebody was rushed, somebody did not know better. The account has the advantage of suggesting a remedy, which is better people, and the disadvantage of not surviving contact with the cases. An engineer adds one argument to a cached function, an options object where a plain value used to go. It compiles, the types check, the tests pass, and the cache silently stops hitting from that day forward, because every call now constructs a fresh object and the cache is keyed on identity. Walk that change backwards looking for the careless moment and there is not one. The engineer could not see the cache’s key strategy from where they stood. Neither could the reviewer.

The same shape recurs with different materials. A reusable hook for dismissing a popup attaches a single listener to the document, which is correct, and a hundred instances of that popup across an application attach a hundred listeners that all fire on every click anywhere, which is a different program than anyone wrote. A coupon check goes into a checkout function long enough that no living person reads it end to end, and work that used to run in parallel now waits in line behind it. Somebody memoizes a property access that was already instant, and the bookkeeping costs more than the operation it protects. In each case the information that would have prevented the mistake existed somewhere in the repository, the version history, or the head of a person who has since left. It was simply not present where the decision happened.

That is the whole mechanism, and it is anatomical rather than professional. Working memory holds something on the order of four to seven chunks, the range running from Miller’s 1956 estimate to Cowan’s tighter modern one, and thirty years of expertise buys bigger chunks rather than more slots. A modern codebase grows exponentially in dependencies, state machines, asynchronous flows, and caching layers. The practitioner talk this argument comes from puts the mismatch in an image we did not expect to meet in an engineering setting, because this program already runs on it. You cannot hold the design of the cathedral in your head while laying a single brick. The failure is not that anybody stopped caring about the cathedral. It is that the cathedral has never once been visible from the scaffold.

Which changes what a remedy looks like. If decay were a competence problem the answer would be hiring and training, and organizations have tried that for decades against a steadily rising tide. If it is a context problem the answer is logistical, and the work is manufacturing the presence of the right information at the moment of the decision, in a form a reviewer can act on. This is where a model earns its place, and not by being clever. It applies the same scrutiny to the ten thousandth file as to the first and does not tire before a release, which are not intellectual virtues but the absence of a body. An engineer at Vercel spent years on performance work and, by the talk’s account, distilled some four hundred pull requests into a structured rules repository built to be queried by agents, which is the discipline stated exactly. The order of operations is the catch, since a pattern has to exist before anything can enforce it, and no model will infer a rule from a codebase that applies it inconsistently.

So the honest reframe is also the encouraging one. Nothing about the people has to change, and the thing that does have to change is a thing that can be built.