01One line about a stale list took the AI back to the storage behind it
In September 2026, the operator noticed that the list of recent news items on the site's front page had fallen behind the news itself. What went to the AI was the symptom alone. No instruction about which file to open, and no guess at the cause.
The answer that came back was not about display. The list was not being loaded when a page opened. The same list had been written into every page of the site as a copy. The daily job that produced the news articles was running. The job that rewrote those copies was not on the automatic schedule, so it only ran when someone ran it by hand. It had been idle for days.
What a reader saw as staleness came from the way the information was held, not from any delay. The pattern worth taking from this is one sentence. State the symptom precisely and AI can work back to the layer that caused it — but only if repairing it, explaining it, and making the same drift impossible are asked for as three separate things.
02Most stale displays are a sign that the same content lives in two places
Information looks out of date for one of two reasons. Either it is simply slow to arrive and will settle by itself, or a copy of the content sits somewhere else and only one of the two has been brought up to date.
The second kind never settles. Until something rewrites the copy, the old side stays old. This list was the second kind.
That split is the part a working professional needs to hold. When a screen feels out of date, have the AI decide which of the two it is before it touches anything. The question that settles it is plain: is the original already current? If it is, the problem is a copy left behind, and no amount of waiting will fix it.
03A copy goes stale quietly, and the reader is the one who notices
When a copy is left behind, nothing breaks. The text is well formed. The dates line up. Only the content is old.
That quiet is the difficulty. Broken things announce themselves; stale things do not. Here too, the person who noticed was the operator, reading his own site. Nothing in the system raised a hand.
So staleness is worth finding early, and finding it early means giving up on human attention as the detector. The only reliable move is to change the shape of the thing so that copies follow the original whenever it changes.
04Pick a single place to edit the content, and have the rest point at it
Software practice has known this for a long time. Hunt and Thomas wrote in The Pragmatic Programmer that every piece of knowledge should have a single, unambiguous, authoritative representation within a system. On the data side, the arrangement in which each element is edited in only one place is known as a single source of truth, and the ideal version keeps no copies at all, only references back to the master.
Real systems cannot delete every copy. Holding a copy to make a page render quickly is ordinary engineering. So draw the boundary instead. If a copy exists, the original is the only thing anyone edits, and the copy is read-only. And the step that rebuilds the copy when the original changes belongs in the machinery, not in someone's memory.
| What to look at | A copy that stays safe | A copy that goes stale |
|---|---|---|
| Where editing happens | Only in the original | In the original and the copy |
| What triggers a rebuild | Runs automatically when the original changes | Someone remembering |
| How staleness is found | Original and copy are compared | A reader notices |
| Cost of a correction | Fix the original, everything follows | Chase one copy at a time |
05Revisions to promotional material drift in exactly the same shape
This happens daily in material review. A package insert is revised. One sentence about dosing changes. That sentence already sits as a copy inside detail aids, slide sets, comparison tables, internal question-and-answer files and printed leaflets.
The original changes; the copies do not change themselves. Every revision therefore creates the work of counting which pieces of material carry that sentence and following all of them. The one that is missed remains in circulation, saying something the approved labelling no longer says.
What helps here is not sharper reviewing but a different way of holding the content. Stop transcribing revisable statements into each piece of material independently, and keep a register of which material draws on which statement in the original. Then, when a revision is announced, the list of things to follow is determined mechanically rather than recalled. Building that register, and comparing the wording before and after a revision, is work an AI can take. The judgement about whether a claim is still supportable stays with a person.
06The job producing content was running; the job distributing it was not
Go one level down into the cause. The job that produced each day's articles was running. The job that pushed the result into the list embedded in every page was not. They were two separate jobs, and only the first had been registered on the automatic schedule.
On Unix-like systems, the mechanism that starts work at a given time is called cron, and each job is registered as a line in a table. A job that is not written in that table never starts on its own, however important it is. That was the hole.
Holes of this kind appear when the producing side and the distributing side are built at different times. When the list was first embedded, rebuilding it by hand was enough, because nothing else was automatic. Later, when article generation moved onto a schedule, moving the distributing step along with it was left undone. Nobody made a wrong decision. The hole opens anyway.
One more thing in the AI's answer is worth noting. It wrote that it had itself run two checks — that the list was now current, and that the rebuild script worked correctly in the bare environment a scheduled job runs in — and that one thing remained unverified: that at the scheduled hour the two jobs would run through in sequence. It also gave its reason for not verifying that: the daily job calls an outside service, and it chose not to trigger it on its own initiative. Have the AI separate what it verified from what it expects to be true by construction. When the defect is a hole in the machinery, that separation is the protection.
07From tomorrow, ask for the symptom, the cause, the prevention and the gaps separately
Four steps.
Write the symptom in countable terms
Which screen, which part, and as of when the content stopped moving. Do not write the repair. If you do, the AI repairs that one spot.
Make it name the cause first
Is the original already current, or has a copy been left behind? Get the answer before any file is touched.
Ask for a shape that cannot drift again
Correcting today's values leaves next week open. Ask from the start for copies that follow the original when it changes.
Have verified and unverified listed apart
What was actually run and observed, what should hold by construction, and what waits for the next scheduled firing.
Anthropic's guidance for Claude Code says to give the symptom, the likely location and what "fixed" looks like, and to address the root cause rather than suppress the error. The same guidance says to give the model a check it can run before the work counts as done. A list that only a reader's eye can catch is precisely the case where that check has to be built.
- When content looks out of date, the cause is either a delay in arrival or a copy left behind. Make the AI answer which one before it changes anything.
- If a copy must exist, edit only the original and put the rebuild step into the machinery. A rebuild that depends on memory will eventually be forgotten.
- Have the AI list the repair, what it verified, and what it did not verify as three separate things. Holes in the machinery survive in the unverified part.
The ability this asks of the user is not diagnosis. It is the ability to describe visible staleness accurately, without mixing in a proposed repair. Given an accurate symptom, AI can work back from the display to the way the content is distributed. Deciding what then moves into the machinery remains the work of the person who wrote the line.
- Hunt, A., Thomas, D. Don't repeat yourself. Wikipedia (on the principle from The Pragmatic Programmer). https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- Wikipedia. Single source of truth. https://en.wikipedia.org/wiki/Single_source_of_truth
- Wikipedia. Cache invalidation. https://en.wikipedia.org/wiki/Cache_invalidation
- Wikipedia. Cron. https://en.wikipedia.org/wiki/Cron
- Anthropic. Best practices for Claude Code. Claude Code Docs. https://code.claude.com/docs/en/best-practices