An agent asked for a dropdown writes a dropdown. It does not check whether your project has one, because nothing told it to look and nothing gave it a way to look. That is the entire mechanism behind the most common complaint about agent-written interfaces, and it is a tooling problem rather than a model problem.
Why it happens
Three reasons, and none of them is that the model is careless.
Generation is the default action. Given a request and no tools, writing code is the only move available. A model with no catalogue cannot choose from one.
Your codebase is not in context. An agent sees the files it has opened. In a repository of two thousand files, the button it needs is usually not among them, and searching for it costs tokens and time that nothing is asking it to spend.
Naming defeats search even when it tries. Your component is ActionButton, the request said "call to action", and the grep for "cta" returns nothing. This is why a search that only matches names fails on exactly the components most worth reusing.
What actually stops it
A catalogue it can query. MCP turns "write a dropdown" into "search dropdowns, show four, install one". The agent stops inventing because choosing is now cheaper than writing.
Your own components in that catalogue. The high-value half in an existing codebase, and the team registry guide covers it: a private registry the agent can read means it installs your button.
An instruction that costs one line. "Check for an existing component before writing one" in a rules file or a prompt. Weaker than a registry, free, and better than nothing.
A conventions file that names things. Where components live, what the tokens are called, which primitives to prefer. It does not give the agent a catalogue, but it gives its search a chance.
The cost of not fixing it
The duplicate is not the expensive part. The expensive part is what a duplicate does over time: two components that drift, so a fix lands in one; two focus treatments on one screen; a design change that has to be made four times and gets made three; and a codebase where nobody can answer which button is the real one.
That cost is not visible in the pull request that created it, which is why it accumulates.
The honest limit
A catalogue does not make the agent's judgement good. It will still install a dialog where a page belonged, a carousel where a list belonged, and a tooltip carrying information that touch users will never see. The review checklist is the pass that catches those, and it is a person's job.
What a catalogue changes is narrower and worth having: the component is real, its dependencies are declared, someone has looked at it, and it is probably the one your project already uses.
Where else to look
The honest list, because the answer is not always us:
| Source | Best for | Trade-off |
|---|---|---|
| 21st MCP | Making choosing cheaper than writing | Installs need a membership |
| A team registry | The agent finding your components, not just any | Somebody has to publish them |
| A rules or conventions file | One line that changes the default behaviour | Instructions, not a catalogue |
| Code search in the agent | Finding what exists, when the names cooperate | Naming is exactly what defeats it |
Taking one
Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:
That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.
Frequently asked
- Why does a coding agent write a new component instead of reusing one?
- Because generation is the only move available without tools, your codebase is not in its context, and even when it searches, naming defeats it: your component is ActionButton and the request said call to action. None of that is carelessness, and all of it is fixable with tooling.
- What actually stops duplicate components?
- A catalogue the agent can query, so choosing becomes cheaper than writing; your own components inside that catalogue, so it installs your button; and, failing both, one line in a rules file telling it to check before writing. The first two are what change behaviour rather than intention.
- What does a duplicate component actually cost?
- Not the file. Two components drift, so a fix lands in one of them; two focus treatments appear on one screen; a design change has to be made four times and gets made three; and nobody can say which button is the real one. None of that is visible in the pull request that created it.
- Does a catalogue fix agent judgement?
- No. It will still install a dialog where a page belonged and a tooltip carrying information touch users never see. What changes is narrower: the component is real, its dependencies are declared, somebody has looked at it, and it is probably the one your project already uses.