Sunday
11 October 2026

AI agents work from files that people write, and those files go stale unless someone keeps them current. Four pieces from 9 and 10 October show teams writing these files and reviewing agent changes, but rarely naming the person who keeps the files true.

Tanner Kohler of Nielsen Norman Group (11 Oct · 01), a user-experience research firm, studied expert users who work with Claude, Anthropic's AI assistant, every day. Each participant kept a library of context files, which are written notes an AI agent reads before it starts a task. The libraries decayed. One participant used a file for months after it stopped matching how he worked. Another found a global file, probably made by the agent, that he had not known existed. Kohler found that the agent made most edits and people rarely checked them, so he recommends a regular audit in which a person approves the agent's suggested updates.

Rillet makes accounting software in which AI agents do bookkeeping work for more than 600 customers. Its two-person frontend team, led by software engineer Anthony Liang (11 Oct · 02), lost time gathering customer requests scattered across Linear tickets, Slack threads and conversations. Now customer success staff flag an issue and an AI agent collects the context. For safe, well-scoped changes, a coding agent drafts a spec, makes the change and opens a pull request. Liang reviews and merges each one. Vercel, the hosting company that sells the agent framework Rillet uses, wrote the account, and its figures, such as more than 800 tickets closed in four months, are self-reported.

Sean Goedecke (11 Oct · 03), a software engineer who writes essays about engineering work, argues that engineers paired with AI coding tools will outperform either alone for a decade or two. He compares this with chess, where human and computer teams led for about twenty years. He writes that most current agent errors are not ordinary bugs. They are misalignment with what the organisation wants, such as too much engineering in one place and too little in another. In his view, keeping work aligned with the organisation's goals is the leading candidate for lasting human value.

Matt Connor (11 Oct · 04), founder and chief executive of SSD Nodes, a server hosting company, describes coding agents that replace patterns they do not recognise while the tests still pass. In his example, an agent swaps a hand-written cache for Redis, a separate caching service. The service runs on one virtual server, where a simple in-memory map is faster. His remedy is a DESIGN.md file at the root of the code repository. It lists the rules that must stay true with their reasons, the alternatives already rejected, the risky boundaries and a vocabulary that maps code terms to business terms. He does not name an owner for the file, but he says to update it in the same commit that changes a decision.

Two of the pieces describe the files an agent reads, and two describe where agent work is checked. Connor's advice to update the file in the same commit makes the person who changes a decision responsible for recording it. The Nielsen Norman Group study shows what happens without that rule: agents write the files and nobody reads the changes. This issue infers, and none of the authors claims, that teams have assigned the review of agent output more firmly than the upkeep of agent instructions.

The Nielsen Norman Group participants managed personal libraries rather than team files, and the Rillet figures come from a vendor, so the evidence about teams is thin. A small team may also need no separate keeper, because the person who changes a decision is often the only person who knows it.