DEV Community

Cover image for Your React Codebase Has the Same Component Three Times. GitHub Copilot Built All of Them.
Avery
Avery

Posted on

Your React Codebase Has the Same Component Three Times. GitHub Copilot Built All of Them.

Most React projects start clean.

One Button component. One Card. One Input. Everything in its place.

Three months later the same project has three versions of the same Button. Different file names. Different props. Same purpose. Nobody planned it. Nobody noticed until the design changed and suddenly three places needed updating instead of one.

GitHub Copilot built all of them. One prompt at a time. Because nobody gave it a rule that said check before you build.

Why this keeps happening

GitHub Copilot does not scan your entire codebase before it generates.

It works with what is in context. What you show it. What it can see in the current file and the files around it.

If you prompt for a button component without pointing Copilot to the one that already exists, it builds a new one. Clean, functional, no errors. And completely redundant.

This is not a bug. It is the expected behavior of a tool that has no rule telling it to check before it builds.

The result is a codebase that grows in the wrong direction. More files. More components. More surface area to maintain. More places where a design change needs to happen three times instead of one.

The cost of duplicate components

At first it feels fine. Everything works. The app looks correct.

Then the design changes. You update the Button in one place. Two weeks later a developer finds the other two. They look different now. The codebase is inconsistent and nobody knows which version is the correct one.

Or a bug appears in a component. You fix it. The same bug exists in the duplicate. You find it three sprints later in production.

Duplicate components are not a style problem. They are a maintenance problem that compounds over time.

What changes when reuse is a rule

When your AI has a rule that says check what exists before building anything new, the behavior changes completely.

Copilot stops generating redundant components. It finds what already exists and extends it. One Button. One Card. One Input. Used everywhere. Changed in one place.

Not because the prompt was better. Because the rule was always there.

I have been working this way for several months. The components folder stays clean. Duplicates do not appear. When the design changes, it changes once.

That is what reuse as a rule looks like in practice.

The prompt does not matter. The rules do.

You cannot fix duplicate components by describing reuse in every prompt.

You will forget. The prompt will be short. The context will be missing. And Copilot will build a new one because nothing told it not to.

Define reuse as a rule. Make it impossible for your AI to build something new without checking what already exists.

Your codebase should grow in depth. Not in duplicates.


Want to see what those rules look like?

I packaged my first three React AI rules as a free PDF. The exact starting point for consistent, reuse-first AI output in every React project.

👉 Get My First 3 React AI Rules — free

And if you want the full system — rules across architecture, typing, accessibility, state, and more:

👉 Avery Code React AI Engineering System

Top comments (0)