Can an Agent Change Your Design System? The Harder Question Is Who May.

Checks are getting better at telling you whether an AI agent can make a change to your design system. What they can't tell you is who has the authority to decide that the change should happen at all, and most teams haven't named anyone.

‍

A column published on Design Systems Collective on October 8, Shane P Williams's "September 2026 in review", collects a month of practitioners' experiments with agents and design systems. Most of them are about better validation. The part I keep returning to is a question underneath all that work: when an agent proposes a change to something every team depends on, whose decision is it?

Three questions that sound like one

The column credits Pegah Ahmadi with a useful split. Can an agent make a given change? Should it make it this way? And may it decide it at all?

The first question is technical: does the change pass the validator, does it compile, does it use real tokens. The second is about quality and convention: does it follow the patterns the system already uses. Both can be automated, and both are improving quickly.

The third is different in kind. It asks about authority. An agent can pass the first two checks and still redefine a shared component for every team that uses it, because nothing in the checks asks who was entitled to make that call.

Better checks make the third question louder

One contributor quoted in the column, Sylvia Z, makes the point that a strong check enforces a bad rule as faithfully as a good one. I think that's right, and it has a consequence: as checks get more rigorous, who writes the rules matters more, not less.

The column also describes a validator that turned out to have been passing work it never actually checked, which its author found, fixed and documented along with 105 known gaps. That story is encouraging, because the gaps were found. It's also a reminder that a check is only as trustworthy as the person who owns it.

Why small teams don't feel this yet

The author notes that most of the month's strongest examples came from individuals or very small teams, where the person building is also the person deciding. In that setting the authority question answers itself.

It stops answering itself when there are dozens of feature teams, each with its own agents and its own deadlines. At that size, "the person who built it decided" becomes "whoever got there first decided", and nobody can say afterwards who was responsible for the shared result.

What that looks like in practice

When I started on Cohere Commerce, two separate component libraries had built up from different contributors. Components looked different from screen to screen, engineering was implementing the same element in several ways, and every new feature added inconsistency rather than resolving it. I rebuilt the design system from scratch and replaced both libraries with one.

I wouldn't claim that case was about agents, because it wasn't. But it's what a system looks like when many people can change shared things and nobody is responsible for the whole. Agents make that situation faster to reach, because more people can produce more changes in the same amount of time.

What I'd write down this week

The column's own proposal is a forum that filters proposed changes and a named role with the final say, and the author says plainly that it's untested. I'd start smaller, with decisions that cost almost nothing to make:

None of this needs new tooling. It needs someone to decide that the decisions have an owner.

If an agent proposed a change to your most-used component tomorrow, would anyone on your team know whose call it was?