Every React project has a standard.
The question is not whether one exists. The question is who defined it.
For a long time I did not think about this. I opened a session, wrote a prompt, reviewed the output, moved on. The project grew. The codebase grew. And somewhere along the way I realized that the standard GitHub Copilot had been applying was not mine. It was whatever made sense to the AI in that moment, in that session, with whatever context it had available.
Different sessions. Different decisions. Different output. A standard that looked like no standard at all.
What an invented standard actually looks like
It does not announce itself.
It looks like a components folder where similar things are structured slightly differently. A project where naming is consistent in some files and improvised in others. State that lives in hooks in one feature and inline in the UI in another.
Nothing is dramatically wrong. Everything is slightly off. And slightly off at scale becomes very expensive very fast.
That is what GitHub Copilot invents when there are no rules to follow. Not bad code. Just a different standard every session. And different standards do not compose. They accumulate.
The moment I understood what was actually happening
I was looking at two components in the same project built two weeks apart.
Same feature area. Same developer. Same AI tool. Completely different structure. Different naming pattern. Different approach to state. Different way of handling the same kind of UI interaction.
Neither was wrong. Both were exactly what GitHub Copilot decided made sense at the time. And together they made the codebase harder to read, harder to extend, and harder to hand off.
What I did instead
I stopped expecting GitHub Copilot to infer my standard from context and started defining it explicitly.
One of the first rules I added to my system was for component structure:
All React components must:
1. Use functional declarations, not arrow functions.
2. Destructure props in the function signature.
3. Place types in a separate types.ts file within the component folder.
That one rule alone changed how every component looked coming out of a session. Not because the prompt changed. Because the rule was always there.
From there I kept building. Architecture rules. Naming rules. TypeScript discipline. Accessibility standards. Written down. Applied to every session. Every project. Every prompt.
The first thing that changed was the consistency. Components started looking like they came from the same project. The second thing that changed was the speed. Less correction. Less back and forth. Less time explaining to the AI what the project standard was because the standard was already there before the session began.
Your project has a standard right now
Whether you defined it or not.
If you have been working with GitHub Copilot without rules, the standard is whatever the AI decided across every session so far. It is in the codebase already. Distributed across files. Inconsistent in ways that are easy to miss until they are not.
The question now is whether you define the standard going forward or keep letting the AI invent it one session at a time.
The prompt does not matter. The rules do.
A defined standard does not require better prompts. It requires rules that exist before the prompt is written.
Define your standard once. Apply it everywhere. Stop letting the AI invent it for you.
Want to see where your React project is missing a defined standard?
I built a free 24 point checklist that helps you find exactly that. The gaps where GitHub Copilot has been inventing your standard instead of following one.
Get the React AI Clean Code Checklist — Free
And if you want the full rule system — architecture, typing, accessibility, state, and more:
Top comments (1)
I am curious. Has anyone else caught this in their own projects? You look at two components built weeks apart and they follow completely different patterns. Same project, same AI tool, just different sessions. How are you keeping your React AI output consistent right now?