Where product design is going

The agent edits the standard it follows

Context engineering is the craft skill everyone is naming this year, and the advice to treat the file your agent reads as infrastructure holds up. The people furthest along aren’t writing that file. They describe what they want, let the agent edit, and grade the rules on whether the output looked better.

The context file an agent reads is a design spec, so a change to it needs a name and a date on it, and the field’s own research on power users shows that change going unread.

Tanner Kohler published the maintenance version of context engineering at Nielsen Norman Group on October 9. The markdown files your agent reads are infrastructure, so they should be short, findable and audited when your work changes. His summary line is that your agent is only as powerful as its context library.

I’d sign all of it. The trouble shows up in the same article, in how the people furthest along actually maintain those files.

They aren’t writing the file

Kohler’s participants rarely typed into their context files at all. They described what they wanted and let Claude do the editing, often across many files in one go. They “rarely checked what Claude had changed”, and judged the result by whether the output got better. Some had global files the agent created without their knowledge. Plenty couldn’t find their own files when they went looking. One library held more than 2,700 of them.

The study underneath that article is worth reading on its own. Kate Moran and Sarah Gibbons ran sessions in June with seven nontechnical people running agentic systems at work. One of them went digging and found a boundaries.md file holding the security and privacy rules for their system. Claude had written it and had been maintaining it. They authorized it after the fact.

Most of the time I will just click “yes” for things that [it] asks me, even if I don’t understand what it means

Participant, Vibe Architects, NN/g, June 2026

That’s a security story in the article. For a design leader it’s a document-control story, and the document happens to be ours.

That file is a spec

Design teams have been handed this exact file and told it’s the new deliverable. Call it DESIGN.md, call it the rules file, call it the system’s instructions for agents. It holds the usage guidance, the sentence that says when not to use the component. That’s the half a machine-readable design system drops first. Whatever ends up in it decides what the generated screens look like for every person who runs the agent after you.

So it’s a spec, and design already knows how a spec behaves when nobody owns it. Somebody adds a paragraph in a review. It contradicts itself by the second quarter. The team stops reading it and goes back to asking the one person who knows what the standard really is.

The loop runs backwards

The part I’d flag hardest isn’t that the agent edits the file. It’s that the edit gets graded on the output.

The rule exists to decide whether the output is right. Grade the rule by the output and the direction reverses. The work the agent produced becomes the evidence for the rule the agent wrote. In a crit you’d catch that in a second. The same author brings the work and the standard it should be held to, and the standard shows up second.

None of this is the tool misbehaving. Anthropic’s documentation is direct about what these files are. Claude “treats them as context, not enforced configuration”. If you want an action blocked no matter what the model decides, the docs send you to a hook. The same page splits its two memory systems on one question, which is who writes it. CLAUDE.md is written by you. Auto memory is written by Claude. The power users in the study rubbed out that line and kept the filename.

What decays

Kohler’s other piece, from October 2, says where this lands. Systems built with nothing forcing a priority turn into what Foote and Yoder called a big ball of mud. One holds up fine until “accumulated complexity makes the system difficult to direct, diagnose, or reconstruct”. One participant lost 45 minutes pulling the wrong files out of an unsorted folder. Another couldn’t rebuild their own system. A third said it in three words: “The systems decay.”

Kohler’s prescription is that “the discipline that matters most is not tidier folders but periodic reflection”. That’s right, and on its own it isn’t enough. Reflection needs something to reflect on. What’s missing isn’t a tidy folder. It’s a record of what changed and who decided it.

A name and a date

When a team brings me screens an agent built, I ask who made the last change to the file the agent read. I want a name and a date.

“The agent suggested it and the output looked better” is a real answer, and it’s the finding. It means the standard moved and no designer was in the room when it did. Then the screens in front of me only tell me the agent agreed with itself.

When I ran the agent audit across the whole Best Egg library, I wrote the crawler’s rules myself. The audit runs again on the first of every month. That setup has one property I’d now call the whole point. When a number moves, either the files changed or a rule changed. I can tell which, because changing a rule is something I did on purpose and wrote down.

A design system ships with an owner, a version history and a note about what changed. That isn’t ceremony. It’s the only reason somebody who wasn’t in the room can hold work to it a year later.

The file that tells the agent how to use that system does the same job now, across more screens and with no changelog. In the study, nearly every participant assumed someone else must be doing this more cleanly. Seven people, and each one believed the clean version of this was sitting in somebody else’s folder.

Sources

  1. Context Libraries: How AI Power Users Manage Context Engineering, Tanner Kohler, Nielsen Norman Group, October 9, 2026. Qualitative findings on how expert agent users maintain the markdown files and connections their agents read, including one library of more than 2,700 files.
  2. Vibe Architects: Agentic Vibe Coders, Kate Moran and Sarah Gibbons, Nielsen Norman Group, June 19, 2026. Sessions with seven nontechnical people running agentic systems at work, including the boundaries.md file one participant authorized after the agent had written and maintained it.
  3. The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile, Tanner Kohler, Nielsen Norman Group, October 2, 2026. Applies Foote and Yoder's big ball of mud to agent systems built without scarcity, and names periodic reflection as the discipline that matters.
  4. How Claude remembers your project, Claude Code documentation. States that memory files are context and not enforced configuration, and splits CLAUDE.md from auto memory on who writes it.
  5. Agentic design system audit and remediation, the Best Egg library. I wrote the crawler's rules and the audit runs again on the first of every month.