AI coding agents stay consistent across a product when they all start from the same sources: one shared instruction file, written design principles, a component library, design tokens, a set of agreed references, and a review step that checks new work against them. The problem isn’t any single agent. It’s that each session, tool and teammate fills gaps differently, and every gap is a place where the product slowly stops looking like one product.
Why consistency breaks down
One designer prompting one agent can hold the direction in their head and correct as they go. Add a second person, a different agent, or the same agent next week, and the context resets. Typical symptoms:
- Three slightly different empty states, each reasonable on its own.
- New components that duplicate existing ones with small differences.
- Spacing and type that follow the scale in some areas and not others.
- Features that feel like different products: one dense, one airy.
- The same correction given repeatedly, by different people, to different agents.
1. One shared instruction file
Put the rules every agent needs in version control, in one place. AGENTS.md is an open format that describes itself as “a simple, open format for guiding coding agents”, and many tools read it. Claude Code can read AGENTS.md directly, or a short CLAUDE.md can import it with @AGENTS.md, as the Claude Code memory docs describe. Either way, there’s one source rather than a copy per tool that drifts.
Keep it short and specific. Our guide to CLAUDE.md for UI design has a full example of the UI section; the same content works in AGENTS.md.
2. Approved design principles
Rules say what values to use. Principles say how to make the choices rules don’t cover: how dense, how much colour, when to use a table versus a list. Write them as short prefer and avoid pairs, agree them as a team, and treat changes like code changes.
# Product principles
- Prefer: answering the user's question in the first line of a page.
Avoid: dashboards that open with a grid of equal-weight cards.
- Prefer: hierarchy through weight and colour before size.
Avoid: more than five text styles on one screen.
- Prefer: one accent colour, reserved for the primary action and status.
Avoid: colour as decoration.
- Prefer: lists on mobile, tables on desktop.
Avoid: horizontal page scroll at any width.Import the file from your instruction file, or keep it in a skill if it’s long. The reasoning behind principles is covered in how to give AI coding agents better design taste.
3. A component library agents can find
Consistency is easiest when the right component is the obvious one. One folder, predictable names, an example page that uses them well, and an instruction to propose new components rather than create them. Review every new component as a team decision, not something one agent did in passing.
4. Design tokens with teeth
Tokens keep values consistent across contributors. Remove the defaults you don’t use so off-system classes don’t exist, and add a check that fails on raw values. Our design tokens guide has a tested setup for Tailwind v4 and a drift check.
5. Shared visual references
Principles describe; references show. Agree a small set of references for the product (with notes on what each one is for), store them where everyone and every agent can reach them, and retire ones that no longer represent the direction. Mixing a reference library with a design system has trade-offs, explained in design references vs design systems.
6. Shared tools, configured once
If one person’s agent can see Figma and the browser and another’s can’t, they’ll produce different work. Claude Code supports project-scoped configuration you can commit: MCP servers in .mcp.json (Claude Code asks each person to approve them before use) and plugins enabled in .claude/settings.json. Commit the configuration; each teammate still authenticates with their own account.
7. Review against the shared sources
Review is where drift is caught. Make it specific: does this use our components, our tokens, our principles? A reviewing agent in a fresh session is useful here, because it isn’t anchored to the reasoning that produced the change. Claude Code’s best practices describe this pattern of a separate reviewer checking work against a plan.
Review this branch against AGENTS.md and docs/design/principles.md.
Report: new components that duplicate src/components/ui, values
outside the token system, and any screen that breaks a principle
(quote the principle). Report only real violations.Add the automated parts to CI: type checks, the token check, accessibility checks and visual baselines for key pages.
8. A loop that improves the sources
When the same correction comes up twice, it belongs in the shared sources, not in another prompt. Agree who can change principles and instructions, and keep a short log of why. Over time the direction gets more precise and reviews get shorter.
Team-wide creative direction
Everything above can be done today with files in a repository and tools you already use. The weak point is usually the material that doesn’t fit neatly in a repository: references, the reasons behind them, and direction that spans several codebases.
That’s what we’re building Attuna for. Today, in development, Attuna organises creative direction by project: a brief, a direction, project rules, preferences and references that any agent supporting MCP over HTTP can read. Shared workspaces for teams are something we’re working on, not something that’s available yet.
Start small and make corrections stick
Consistency comes from shared sources and a review that uses them. Start with one instruction file and a principles document, add token checks and visual baselines, and make every repeated correction an edit to the shared sources.