A design system stops me paying for the same decision

One way to make an AI agent waste time is to ask it to solve a problem that the project has already solved somewhere else.

It may produce a perfectly reasonable button, popup, or list. The spacing works. The colors look intentional. The code is understandable. The problem is that it has introduced another answer to a question the product should answer consistently.

In June, my game work included adopting a canonical UI design system and bringing screens toward shared builders. That work matters beyond appearance. It changes the instructions I can give an agent.

Instead of asking it to create a reasonable screen, I can ask it to express a specific interaction using the established components and rules.

Repeated decisions create repeated disagreement

Many small design choices seem harmless in isolation. How much space belongs around a label? Which action is primary? How does a disabled control communicate its state? What happens when text is longer than expected?

If each screen answers those questions locally, I have to review them locally. If several agents work independently, they can each make coherent choices that become incoherent when combined.

A shared system reduces that decision surface. The agent still has to understand the task, but it can inherit the ordinary choices rather than reinvent them.

There is an organizational lesson here. A team becomes easier to coordinate when its shared decisions are accessible in the environment. It becomes harder when those decisions live in the memory of whoever happened to attend a meeting.

Documentation and code have to agree

A design document can describe the intended product while the implementation quietly teaches a different convention. An agent reading existing code may follow the implementation, even if the document says otherwise.

I want the written rules and shared builders to reinforce each other. The document explains the purpose and the exceptions. The builders make the standard path practical. Focused checks and visual review reveal where the contract stops holding.

This does not remove the need to inspect a screen. It gives the review a better starting point. I can spend more attention on whether the interaction makes sense and less on whether another local widget has drifted from the rest of the application.

Standardize what has earned it

There is a trap in the other direction. A shared component can accumulate every possible variation until changing it requires understanding half the product.

I do not want an abstraction simply because two things look similar. I want one when the shared behavior is clear enough to be owned and maintained together.

The useful boundary is often smaller than a universal component. Common structure and styling can be shared while the task-specific behavior stays close to the feature. That keeps the common path consistent without forcing unrelated interactions into the same model.

The return shows up in the next assignment

This kind of work rarely produces the most exciting screenshot in a progress update. It pays off when the next screen takes fewer decisions, when a correction improves multiple places, and when an agent finds the intended implementation before inventing another one.

I still need to choose what the interface should accomplish. The system makes it easier for that choice to survive implementation.

That is an important part of getting more from AI: make the decisions worth repeating durable, and leave the genuinely new decisions visible.