Over-documentation is exactly what I'd worry about too. Do you keep a list of the fixes that keep repeating, so a person can decide which ones become patterns?

Not formally, no. We're not keeping a running list of each fix and marking whether it should graduate into the design system. Instead, after a stretch of time, we look at what got missed and where agents keep making mistakes. Then we update the design system to either course correct it a bit or add a couple of additional components or considerations. We did exactly this recently with version 2 of the design system for Intent.

There's also a second thing that needs regular attention: the instructions. AI model capabilities keep improving, so one of our recurring maintenance tasks is now rethinking our prompts and how much context we hand to models whenever a new tier of capability shows up. Anthropic, for example, keeps telling developers that newer models need less direct prompting, with less detail and steering than earlier ones required. So effectively, there are two things to keep up to date: the design system itself, and the instructions for how agents use it.

And yes, I'm wary of piling too much into the design system. Ten design components don't create ten relationships, they create forty-five potential interaction points to consider. Just like people, agents have a hard time knowing when to apply each pattern and why.

Ironically, the early design pattern libraries we built at Yahoo! and eBay were focused on exactly this. Patterns were treated as optimal solutions to a problem in context, documented with when to use them, how, and why they're a good solution. Specs are rule-based while patterns require you to think.

Most design systems today have dropped that part and become scrolling lists of button sizes, font sizes, and icons. So if you're going to keep track of anything, the "why" behind each decision is probably more valuable to agents than one more component. Sometimes the best way forward is getting back to what worked in the past.