A fresh agent session picks the stale comment over the code that contradicts it

A comment and the line below it enter the context window as the same kind of thing: text the repository asserts. Nothing in the file marks the comment as older than the code, and nothing marks it as unverified. The code has a checker in the compiler and the tests. The comment has no checker at all. That is why the `let a = b + 1` edit survives a green build while the line above it still says `make a equal to b` ^[3]. According to the post, a second session then opens that file, finds the comment is the only statement of intent while the code is merely an observation of behaviour, and puts the code back ^[4].

Ranking stated intent above observed behaviour is what I want an agent to do most of the time. The post's own framing is that neither model was bad at coding, and that a stale comment made the reasonable move the wrong one ^[14]. That is the useful part of the argument: more context normally helps, and contradictory context does not, so adding more of it makes the problem worse ^[8].

For that result to transfer to a real repository, several things have to hold at edit time. The session cannot see the file's git history. No test asserts the new behaviour. The comment is the only written statement of intent. The reviewer skims. The post concedes most of this, listing git history, tests, a ticket and a human as things real agents have, with a parenthetical asking whether you do in fact have tests ^[15]. That parenthetical is the load-bearing assumption in the whole design.

The multi-session chain is where the mechanism gets expensive. A stale comment is read as intent, an agent writes a test that matches the old behaviour, docs are generated, and a later agent sees comment, test and docs agree and reverts the code with confidence ^[7]. Three pieces of evidence, one incorrect ancestor. The post calls that shared-error propagation, and the accounting holds: if the test was derived from the comment, the independent agreement count is one, not three ^[7].

The scale is small and stated plainly: two files, four models, ten runs each, on an Inspect AI task, with local models through Ollama and the Claude models through the API at no more than a few pennies a run ^[9]. Multiply it out. Two files by four models by ten runs is 80 runs, and each run is two turns, so 160 model calls ^[16]. The post names the three outcomes it classifies, fixing the comment, reverting the code, or leaving the contradiction alone ^[11], and publishes no counts for any of them ^[12]. It does not tell you which model reverts most often, or how often any of them does.

What the mechanism points at is a scope rule, not a documentation policy. If a comment above the changed line asserts an invariant or an access boundary, that comment is inside the change set, and an instruction forbidding you to touch it is an instruction to ship a file that lies. The cost is review noise on every narrow edit. Set against the authorisation example, where the comment still claims admin-only after the condition widened to admit authenticated users ^[5], I will pay it.