--- title: "What You Lose When the Agent Does the Repetition" slug: "what-you-lose-when-agent-does-repetition" language: "en" date: "2026-10-27T19:54:58.935Z" updated: "2026-10-27T19:54:58.000Z" description: "Anton Sten built a design system and realised he could not reconstruct it from memory. What AI removes is not the output but the residue." canonical: "https://fix.slopit.io/what-you-lose-when-agent-does-repetition/" tags: ["design", "ai", "craft", "systems"] --- Anton Sten has spent months building a design system. Last week, on a call, he realised he could not reconstruct it from memory. Not the reasons — he knows why the important decisions were made, where options were deliberately reduced, which exceptions are real. But the inventory: every component property, every state, every file. That would need looking. His essay about it is the best thing I've read on what AI actually changes about craft, because it doesn't argue about output quality. It argues about residue. ## Repetition was the documentation Sten's old proxy for depth was recall. If you built the whole system by hand, repetition did some of the documenting for you: you knew where everything lived because you had put it there, several times. The knowledge wasn't written down anywhere. It didn't need to be, because it was in the person who did the work. Now an agent applies the rule across dozens of components. Sten defines it, checks the result, moves on. The system gets built faster, and the accidental memorisation that came from doing every step yourself doesn't happen. Katie Langerman told him that design system work she did in four months would previously have taken a year. That's the trade in one sentence: a year of your life converted into four months, minus the thing a year of repetition used to install in your head. ## The optimistic reading is mostly right Sten's turn is that this might not be a loss. If the system has to be legible to an agent, naming has to make sense without him standing next to the file. Component descriptions have to say what something is for, not just what it's called. Patterns that lived in someone's head have to become actual rules, because an agent can't reliably work from "you know what I mean." That's real. Documentation stops being the thing you write after the system is finished and becomes part of the system. Buzz Usborne, whose Help Scout work prompted the conversation, found the same thing from the other direction: making a system work well with AI required more structure and discipline than the team could have maintained by hand. So the system becomes more explicit, and the person carries less of it. Sten says he'll take that trade. ## What the inventory was actually for I think he's right, and I think the trade is more expensive than the essay admits — for a reason that has nothing to do with documentation. Recall wasn't only storage. Knowing every component property meant you could feel when something was off. Not "this violates rule 4.2" — a pre-verbal sense that a screen was wrong, because you knew the shape of normal. The designer who has built the thing forty times notices a regression in a screenshot before they can articulate why. Written rules don't reproduce that sensor. They encode the cases someone thought to write down. The exceptions that are "mostly history," the component that technically supports a property nobody should use, the two variants that look alike but do different jobs — Sten lists these as things an experienced designer picks up by osmosis. Osmosis is exactly what four months of agent work doesn't provide. ## The maintenance trap There's also a quieter risk in the phrase "the system knows more about itself." A system only knows more about itself if someone keeps teaching it. Documentation that is part of the system has to be maintained at the same rate as the system, or the knowledge hasn't moved from a head into the artefact — it has moved from a head into a stale file. Sten says as much when he asks whether someone new can understand why the system is shaped the way it is. That question has a maintenance budget attached, and teams are historically bad at paying it. Agents raise the cost of stale docs, because agents follow them literally. A human reads an outdated example and asks. An agent reads it and ships it. ## The part that survives The distinction Sten draws at the end is the one worth keeping: he still needs to understand why the system works, when a new use case is genuinely different, when an abstraction is stretching too far, when the documented rule should change rather than be enforced harder. What he needs less of is the inventory. That's the actual shift. The job moves from holding the system to holding the model of the system. Inventory knowledge was never the valuable part — it was the by-product of a process that happened to produce understanding as a side effect. Remove the process and you have to acquire the understanding deliberately, which is harder and less fun than absorbing it by doing the work forty times. Sten ends on "if the trade is that the system knows more about itself, I think I'll take it." Fair. But the trade isn't automatic, and it isn't free: someone still has to know what matters well enough to write it down, and keep writing it down after the novelty wears off. *Source: [The system I no longer know by heart — Anton Sten](https://www.antonsten.com/articles/the-system-i-no-longer-know-by-heart/).*