Most developers think about standards later.
First you get the project running. You set up the tooling. You write the first components. You figure out what the project actually needs before you start worrying about consistency and conventions.
By the time you think about standards, GitHub Copilot has already set one.
What happens in the first session
The first prompt you write sets a direction.
Copilot looks at what is in context, makes decisions about structure, naming, and patterns, and generates output based on those decisions. No rules exist yet. No conventions have been defined. So it invents them.
The component it generates in session one has a structure. A naming pattern. A way of handling props and state. That output becomes part of the codebase. And the next session builds on top of it.
Not because Copilot remembers what it did. Because the code is there and becomes part of the context for future generations. The invented standard quietly embeds itself into the project before you have had a chance to define one yourself.
Why the first session matters more than most developers realize
A standard defined early is easy to maintain. A standard that grows organically across sessions is almost impossible to clean up.
By session five, the project has patterns. By session ten, those patterns are everywhere. By the time the inconsistency becomes visible, it is distributed across enough files that fixing it means touching half the codebase.
The first session is the moment where the cost of no rules is lowest. It is also the moment where almost nobody thinks about rules because the project is still empty and everything still feels fine.
That is exactly when the standard should be defined. Before the first prompt. Before the first component. Before Copilot makes its first decision.
What defining a standard before the first session looks like
It does not have to be a long document. It does not have to cover every edge case.
A few rules are enough to change what the first session produces. Rules like these:
All React components must:
1. Use functional declarations, not arrow functions.
2. Separate UI and logic — no fetching inside components.
3. Place types in a separate types.ts file within the feature folder.
Three rules. Applied before the first prompt. And the output from session one already looks like it came from a project with a standard.
That is the difference between a codebase that stays consistent as it grows and one that accumulates the decisions of every session that came before.
It is not too late if the project already exists
Most projects do not start with rules. That is the reality.
But defining the standard now is still better than never defining it. Every session from this point forward can follow the rules. The inconsistency stops accumulating. The codebase gets more predictable over time even if it takes a while to get there.
The best time to define your React standard was before the first commit. The second best time is now.
The prompt does not matter. The rules do.
GitHub Copilot will set a standard for your React project. That is guaranteed.
The only question is whether you define it first or let the AI invent it session by session.
Define it once. Apply it from the start. And stop inheriting a standard you never chose.
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)
Thinking back to my first projects with Copilot. No rules, no standard, just prompting and hoping. The inconsistency crept in so quietly. By the time I noticed it was everywhere. Anyone else recognize that moment where you look at the codebase and realize it does not feel like one project anymore?