How to Get Design-Consistent Output From a Coding Agent

Why the default output looks anonymous

Ask an agent for a settings page and you get a settings page. Reasonable spacing, sensible hierarchy, components that work, and an aesthetic that belongs to no product in particular.

That is not a failure. It is the correct output for the input it received. With no information about your system, the model produces something near the average of everything it has seen, and the average of all interfaces is a competent generic interface.

The mistake teams make next is to describe their design in the prompt. It works for one screen. It decays immediately, because the description lives in whoever typed it, drifts between team members, and omits the rules nobody thinks to state until a reviewer objects to a violation.

So the durable fix is not a better description. It is making the design system something the agent reads rather than something it is told.

The four things to ground

Tokens, as code. Colors, spacing scale, type ramp, radii, shadows, breakpoints, in the actual file the build uses. An agent reading a token file produces values that are correct by construction. An agent reading a description of your palette produces values that are approximately correct, which is worse than wrong because it survives review.

Components, discoverable. The most valuable standing instruction in a design-aware setup is to search for an existing component before writing a new one, and to extend rather than duplicate. Most inconsistency is not wrong styling. It is a fourth button implementation that looks close enough to pass.

Patterns, written down. How a form reports errors. Where a primary action sits. What an empty state contains. How loading is represented. These are decided once and then live in the heads of two or three people, which is precisely the knowledge an agent cannot infer and reviewers enforce anyway.

Prohibitions. What you never do. No shadows on flat surfaces, no more than two font weights, never a modal for a destructive action. Negative rules are compact, high signal, and almost never written down anywhere a tool can read.

The iteration loop that works

Design work with an agent goes well when it is structured like code review rather than like commissioning.

Start from a reference in your own product. "Match the structure of the account settings page" produces better results than any description, because it points at something concrete that already encodes your decisions.

Constrain the surface. One screen or one component per pass, with the states named explicitly: default, loading, empty, error, and whatever your domain adds. Naming states is where most of the value is, since generated interfaces are consistently strong on the happy path and thin everywhere else.

Review against the tokens rather than against taste. Did it use scale values, or arbitrary numbers? Did it reuse the component, or produce a near-copy? Those are checkable, and checkable review is the kind that survives a busy week.

Then keep what you learned. If a phrasing or a reference consistently produces good output, that belongs in your written rules rather than in one person's habits.

Make the system retrievable, not repeated

Once the rules exist, the remaining question is how they reach the agent.

Pasting them into every session works and is expensive: the same material bought on every request, in every session, by everyone on the team, and stale the moment the design system changes without someone remembering to update the paste.

RDK handles this layer. Files from local vaults, docs, and code are indexed as encrypted private chunks, and agents search those chunks before querying a model. Your token definitions, component conventions, patterns, and prohibitions get retrieved when a task touches them and cost nothing on the turns that do not. Token spend drops 80 to 90 percent on this kind of repeated, reference-heavy work because the answer is retrieved instead of regenerated.

Stacked retrieval sets the proportions: a private index over your own material answers 40 to 65 percent of queries, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent. For design work specifically, almost everything an agent needs to know is in the first bucket, because it is your system and nobody else has documented it.