An AI coding agent uses your component library only as far as it can see it. It reads the files nearest the task, follows imports it happens to open, and copies the patterns it finds there. If the right Button is three folders away, or two components share a name, it will often write markup and styles from scratch. Agents reuse reliably when the system is handed to them explicitly: which components exist, what they are for, which tokens they use, and what not to do.
What an agent actually reads
Coding agents such as Claude Code, Cursor and Codex work from a context window: the task, the files they choose to open, search results, and any rules or documentation you provide. They do not hold a model of your whole repository. Reuse depends on whether the right component is in that window when the code is written.
- Nearby files: the agent imitates the code next to the change, including its mistakes.
- Search: it finds a component if its name matches what it searched for.
PrimaryButton,BtnandCTAare three different searches. - Rules files and docs:
AGENTS.md,CLAUDE.mdor Cursor rules, if they exist and are current.
Why reuse breaks down
The common failure is not that agents ignore libraries; it is that libraries are ambiguous. In Saer's scan of Lunary, the founder's production app, the shared Button is used 538 times, and 164 of those call sites pass a class or style that restates or overrides something the Button already sets. Fifteen component names are defined in more than one file. An agent that copies a neighbouring call site copies the override too. See the full scan.
Saer does not know which of those lines a person or an agent wrote. The point is that this is the evidence the next agent reads.
What helps
- Know what exists. Inventory the components and where each is used, including duplicates and unused ones.
- Remove ambiguity. Merge or rename duplicates so one search finds one answer.
- Hand it over explicitly. Give the agent a short, current reference: components, their purpose, their variants, and the tokens they rely on.
- Check the result. Scan after the agent writes code, and treat new raw values and overrides as review comments.
What Saer does about this
- Colour (in the beta): finds hard-coded colours that equal a token, near-misses and dead tokens, so you can see what an agent copied.
- Components: an inventory of every React component and use site, duplicate names, variant sprawl, one-off overrides and unused components.
system.json: a machine-readable record of the system Saer found, which you can give an agent today.saer mcp: a local MCP server that gives Claude Code, Cursor and Codex your components, hooks and tokens, recommends what to build a task from, and checks the agent's own changes.
- A published benchmark of agent output with and without Saer: a first round has run; results are published with their full method once reviewed.
Every capability and its state: what Saer checks.
See it on your own codebase.
Request early access