A backlog written by the person inside the work does not stay true. It rots one honest session at a time: each entry was accurate the day it was written, and then the work moved, and the entry did not. Mine had accumulated across weeks of sessions in the local coding lab, and by early July it contained a banner in capital letters, HIGHEST PRIORITY, whose own stated trigger condition had already come true and been dealt with. The most emphatic line in the file was a lie. So were quieter parts: items that were already done, items superseded by later decisions, and a whole organising frame (“make the model write valid diffs”) that a recent architectural change had made obsolete by construction.
None of this was visible from inside. Every session that touched the file trusted it, because the file is exactly the thing you consult so you don’t have to re-derive the state of the project. That is the trap: the backlog’s whole job is to be believed, and nothing in the daily loop ever audits it.
What I tried: fresh context, explicit distrust
The audit that worked was almost embarrassingly simple. After a merge closed out a work stream, a planning pass ran with a different model in a fresh session, and the instruction that mattered was not “plan the backlog” but the clause in front of it: verify the repo state independently before believing a single line of the file. Read the code, the test counts, the merged PRs, the decision log. Then read the backlog, and disposition every item against what you actually found.
Fresh context is the active ingredient. A session that has been living inside the project shares the project’s assumptions, including the stale ones; it reads HIGHEST PRIORITY and feels urgency, not suspicion. A fresh reader with verification instructions reads the same line and asks “is this still true?”, which is the one question the file cannot answer about itself.
The pass produced stale-item dispositions and a genuinely different plan, and some of its findings were strategy, not housekeeping: retire the obsolete framing entirely; promote a composed review-and-refactor loop from speculative to next; re-scope one work item from “generalise the paths” to “make the silent degradation visible”; drop a planned hunt for a latent bug after a grep proved the five suspect writers never parsed the field in question. Two items the archive said were open turned out to have been resolved many sessions earlier.
What worked: a rewrite with rules, not just a cleanup
Deleting stale lines only resets the rot clock. The rewrite that came out of the pass changed the file’s grammar so staleness has fewer places to hide:
Every item is tagged either plan-first or implementation, so “we should think about X” can never masquerade as “X is ready to build”. Everything lives under NOW, NEXT, or LATER, and every LATER item carries an explicit trigger: the named condition under which it becomes relevant, in checkable terms, not vibes. A banner with a trigger can be audited in one glance; a banner in capital letters cannot.
And nothing was destroyed. The entire pre-rewrite file went verbatim into an archive, with its own banner naming the items that read as open there but were actually resolved. The history stays inspectable; the working file stays trustworthy. Those are different jobs, and one file was doing both badly.
The part worth stealing
You do not need an AI model for this, though it makes the fresh-context part cheap enough to actually do. Hand your backlog to any reader who was not inside the work, tell them to trust the repository over the prose, and ask them for dispositions, not impressions. The uncomfortable prediction, which held here: the loudest line in your file is the most likely to be stale, precisely because its loudness made everyone stop reading it critically.
What Next
Backlog Management for One Human and Several Artificial Interns
Earlier in this pillar: where the backlog conventions came from, and why one human plus several agents needs written state at all.