---
title: "The system I no longer know by heart"
description: "When an agent does much of the production work, I stop knowing the design system by heart. The knowledge has to move out of my head and into the system."
date: "2026-10-27T00:00:00.000Z"
canonical: "https://www.antonsten.com/articles/the-system-i-no-longer-know-by-heart/"
---

Last week I had my first proper call with [Buzz Usborne](https://buzzusborne.com/), which is slightly strange because I've known him for a long time. We'd never actually sat down and talked before. Buzz had recently written about [rebuilding Help Scout's design system to make it legible to LLMs](https://buzzusborne.com/work/designing-with-ai/), so we spent a lot of the call comparing notes on what changes when AI starts doing a meaningful share of the production work.

At one point we landed on something I hadn't really articulated before: I don't know every part of the design system I've been building by heart.

I've spent months making decisions about it. I know why the important things work the way they do, where we deliberately reduced options, which exceptions are real, and which ones are mostly history. But if you asked me to reconstruct every component property or remember exactly how a particular state is wired, I would need to look.

That used to be a fairly good proxy for how deeply I'd worked on something. If I built the whole system manually, repetition did some of the documentation for me. I knew where everything lived because I'd put it there, often several times. We'd both noticed a similar tradeoff: the system can become more structured and explicit while the person building it carries less of the detail in their head.

AI changes that relationship. A lot of the production work now happens through an agent. I can define the rule, have it applied across dozens of components, check the result, and move on. Katie Langerman said on [a recent episode of Complementary](https://podcasts.apple.com/us/podcast/88-how-ai-impacts-design-systems/id1671376839?i=1000798047590) that the design system work she's done in the last four months would probably have taken a year before AI. The system gets built faster, but I don't get the same accidental memorization that came from doing every step myself.

The surprising part is that I'm not sure this is a loss.

The system itself is probably more explicit because of it. Naming has to make sense without me standing next to the file. Component descriptions need to say what something is for, not just what it's called. Patterns that used to live in someone's head have to become actual rules because an agent can't reliably work from "you know what I mean."

[I've written before](/articles/the-building-was-never-the-hard-part/) about how design systems increasingly need to work for humans and agents at the same time. I'm noticing another consequence of that now: some of the knowledge has to move out of the designer and into the system.

That sounds obvious when you say it like that. Katie put it well on the same episode: the reasoning behind a token "can't just be in your head." Of course a good system shouldn't depend on one person remembering everything. But a lot of systems do, especially while they're being built. There is always someone who knows that this component technically supports a certain property but nobody should use it, or that these two variants look similar but have completely different jobs, or that the example in the documentation is outdated and the real pattern lives somewhere else.

Humans are surprisingly good at carrying that kind of mess. A team can work around gaps in the system for years because the people closest to it know where the gaps are. Agents make those gaps more visible because they don't have the same informal context.

If the rule isn't written down, the agent has to infer it. If two components overlap, it doesn't necessarily know which one the team prefers. If a design system contains the right components but no guidance on how they should be composed, an agent can use every component correctly and still produce a bad screen.

That has pushed me to think about documentation differently. It isn't the thing you do after the system is finished so someone else can understand it. Increasingly, it is part of the system itself.

The same applies to examples, constraints, and composition rules. A component definition tells you what the component can do. It doesn't necessarily tell you when it belongs on a page, what it should sit next to, or which technically valid combinations are actually good product decisions. Those are the kinds of things an experienced designer often picks up by osmosis.

If we're serious about agents working inside our systems, we have to decide how much of that judgment can be made explicit. I don't think all of it can.

There is still a difference between following the system and understanding the product. An agent can know that one type style is for reading and another is for UI labels without knowing whether a screen has become too dense. It can follow the documented card pattern without noticing that the information architecture underneath it is wrong.

And I still need to understand why the system works the way it does. I need to know when a new use case is genuinely different, when an abstraction is starting to stretch too far, or when the documented rule should change rather than be enforced harder. What I seem to need less of is the inventory in my head.

That distinction feels important because there is a version of craftsmanship where knowing every detail is part of the value. I still recognize that feeling. I like knowing a file well enough that I can almost navigate it without looking, and there is comfort in having the whole thing in your head.

But that kind of knowledge doesn't transfer particularly well.

A system that only feels coherent because its designer remembers the exceptions is not really coherent. It is being held together by familiarity. Buzz's post gets at the other side of this: making a system work well with AI required more structure, more discipline, and more documentation than the team could realistically maintain by hand. The machine needed the parts that humans had previously been filling in for each other.

I'm increasingly interested in whether someone new can understand why the system is shaped the way it is, and whether an agent can make a reasonable choice without having to infer the unwritten history behind it.

That raises the bar in a useful way. It forces naming to carry intent, documentation to be current, and patterns to explain more than their pixels. It also exposes places where what we call a system is really just a collection of components plus the memory of the people who built them.

I still find it slightly strange that I can spend this much time on a design system and not know every piece of it from memory. But if the trade is that the system knows more about itself, I think I'll take it.