DEV Community: Avery

Launch Day Was Perfect. Day Two Showed What GitHub Copilot Had Been Hiding.

Avery — Mon, 25 May 2026 09:08:46 +0000

Launch day feels like proof.

The app is live. It works. Users are in it. The team is celebrating. Everything you built held up under real conditions and the effort was worth it.

Then the first feature request comes in.

Something small. A new filter on an existing page. A slightly different version of a component that already exists. A change to how state flows through one part of the app.

And suddenly the codebase that felt clean at launch feels like a different project entirely.

What launch day hides

Launch day is the best possible version of your codebase.

Everything is fresh. The decisions are recent. The context is still in everyone's head. The inconsistencies are there but they are invisible because the people who built it know where everything is and why it was done that way.

The first change after launch is when the codebase has to prove itself without that context.

GitHub Copilot generates a new component for the feature request. It looks at the existing codebase for patterns to follow. And it finds three different patterns in three different parts of the app because no standard existed to make them consistent.

So it picks one. Or invents a fourth.

The feature ships. It works. And the codebase has drifted a little further from whatever standard it had at launch.

Why post-launch is when the standard matters most

Before launch you are building. The codebase is growing in one direction and the team has enough context to stay roughly consistent.

After launch you are changing. Features get added. Components get modified. State flows get restructured. And every change is an opportunity for GitHub Copilot to make a decision that either follows the standard or invents something new.

Without rules, every post-launch session is a coin flip. Copilot might follow the existing pattern. It might not. It depends on what is in context and what the prompt asked for.

Over enough post-launch sessions, the codebase that felt clean at launch becomes something nobody fully understands anymore.

The launch is not the test of your React standard. The first six months of changes after launch is the test. And GitHub Copilot takes that test with whatever rules you gave it. Which is often none.

What a standard does for post-launch development

When rules exist before the first post-launch session, Copilot has something to follow regardless of how the prompt is written.

New component for the feature request? Same structure as every other component. New state management for the filter? Same pattern as everywhere else. Modified flow through an existing part of the app? Same conventions, same naming, same layer separation.

The codebase does not drift. It grows. In the same direction. With the same standard it had at launch.

Here is what that looks like in practice:

Post-launch rules that keep the standard:
1. Every new component follows the existing presentational or container pattern. No exceptions.
2. New state always goes into a dedicated hook. Never inline in the component.
3. Before building anything new, check if a similar component or hook already exists.

Three rules. Applied to every session after launch. The codebase that was clean at launch stays clean six months later.

The prompt does not matter. The rules do.

Launch day is a milestone. It is not a guarantee.

The guarantee comes from the rules that tell GitHub Copilot what the standard looks like every time it generates something new. Without them, post-launch development slowly undoes everything launch day proved.

Define the standard before the first change. Apply it to every session after. And let the codebase that launched clean stay clean.

Want to see where your React project is missing the rules that hold up after launch?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that launch day hides and post-launch development reveals.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your React Standards Exist. They Are Just Trapped in Your Head Where GitHub Copilot Cannot Reach Them.

Avery — Fri, 22 May 2026 12:46:49 +0000

Every experienced React developer has a standard.

You know what a good component looks like. You know where state belongs. You know how to name things so they make sense six months later. You know when a file is getting too large and needs to be split.

You have been building this knowledge for years. It lives in every decision you make, every refactor you initiate, every pull request comment you write.

And GitHub Copilot has no idea any of it exists.

The standard that never left your head

Most developers never write their standards down. There is no need to when you are the one applying them. The knowledge is there. The decisions get made. The code stays clean.

Then you start using GitHub Copilot to move faster.

And Copilot generates code that works but misses everything you know. The component is too large. The state is in the wrong place. The naming does not follow the pattern you have used for years. The structure makes sense in isolation but does not fit anything around it.

You correct it. You move on. The next session starts exactly the same way.

The standard is still in your head. Copilot still cannot reach it.

Why unwritten rules do not transfer

When you work alone without AI, unwritten rules work fine. You apply them unconsciously. Every decision reflects them. The codebase stays consistent because you are the only one making decisions.

The moment GitHub Copilot starts making decisions, that changes.

Copilot generates based on what it can see and what constraints exist. It cannot infer your unwritten standard from the codebase because your codebase is a result of your standard, not a definition of it. The difference is subtle but critical.

A codebase built by someone who knows the rules looks consistent. But consistency is not the same as documentation. Copilot cannot reverse-engineer your standard from the output it produced. It needs the input.

Your unwritten rules are the most valuable part of your development knowledge. They are also completely invisible to GitHub Copilot until you write them down.

What happens when you finally write them down

Writing down a standard that lives in your head is a strange experience.

It feels obvious. Of course components should have one responsibility. Of course state belongs in hooks. Of course imports should go through the feature index file. You have known this for years.

But obvious to you is invisible to Copilot. The moment you write it down and give it to the AI, the output changes. Not because the rules are new. Because they finally exist somewhere the AI can follow them.

Here is what that looks like in practice:

Rules I had in my head for years:
1. Components are presentational or container. Never both.
2. Custom hooks own all state logic for a feature. No exceptions.
3. File names match the component or hook they export. Always.

Three rules. Years of implicit knowledge. One session to write them down. Every Copilot session after that follows them automatically.

The team version of this problem

For solo developers the unwritten standard creates inconsistency across sessions.

For teams it creates something worse. Every developer has their own unwritten standard. Five developers. Five invisible rule sets. No shared definition of what the codebase should look like.

GitHub Copilot picks up signals from whichever developer is running the session. The output reflects their implicit standard, not the team's. And the codebase accumulates five different invisible standards at once.

Writing the rules down does not just help the AI. It forces the conversation about what the shared standard actually is.

The prompt does not matter. The rules do.

Your React standard is real. It is valuable. It is the result of years of experience.

It is also completely inaccessible to GitHub Copilot until you write it down.

Write it down. Give it to the AI. And stop watching Copilot ignore a standard it never had a chance to follow.

Want to find which of your unwritten rules are missing from your React project?

I built a free 24 point checklist that helps you find exactly that. The gaps between what you know and what your AI has been given to follow.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

GitHub Copilot Respects Your TypeScript Types. It Does Not Respect Your Architecture.

Avery — Wed, 20 May 2026 06:37:00 +0000

TypeScript is one of the best decisions a React team can make.

Explicit types. Compile-time errors. A shared language for what data looks like and how it flows through the application. TypeScript catches mistakes before they ship and makes the codebase easier to understand.

And then GitHub Copilot generates a component that is perfectly typed, compiles without errors, and completely ignores the architecture your team spent months establishing.

TypeScript did its job. The architecture still broke.

What TypeScript actually protects

TypeScript protects data. It defines what a value looks like, what a function accepts, what a component expects as props.

It does not protect structure. It does not define where logic belongs. It does not enforce whether state lives in a hook or inline in the UI. It does not prevent a component from doing five things when it should only do one. It does not stop GitHub Copilot from building a feature in a completely different pattern than everything around it.

TypeScript is a contract about data. Architecture is a contract about structure. They are different contracts. And only one of them is enforced automatically.

Why GitHub Copilot passes TypeScript and fails architecture

Copilot is very good at following TypeScript constraints. Types are explicit. Violations are measurable. The compiler tells you immediately when something is wrong.

Architecture constraints are not explicit unless you write them down. There is no compiler for "this component should be presentational" or "business logic belongs in a hook" or "imports must go through the feature index file."

Without rules that define the architecture explicitly, Copilot makes its own decisions. The types will be correct. The structure will be whatever made sense in that session.

Correct types. Wrong place. Every time.

TypeScript tells GitHub Copilot what the data looks like. Only rules tell it where the data belongs, how it flows, and what the structure must look like. Without rules, the types are right and the architecture is invented.

The false confidence TypeScript creates

TypeScript passing is a signal that feels like safety.

No type errors. No compiler warnings. The IDE is happy. And developers move on assuming the code is correct in all the ways that matter.

But TypeScript passing means the data contracts are correct. It says nothing about whether the component is too large, whether the logic is in the right layer, whether the naming follows the project convention, or whether the pattern matches what the rest of the codebase does.

That false confidence is expensive. The code ships. The architectural debt accumulates. And TypeScript never flags any of it because TypeScript was never responsible for it.

What rules add that TypeScript cannot

TypeScript enforces data contracts. Rules enforce structural contracts.

Together they define what correct code looks like in both dimensions. Without rules, you have one half of the picture.

Rules like these cover what TypeScript cannot:

Architecture rules:
1. UI components render JSX only. No business logic, no data fetching.
2. All state logic lives in dedicated hooks within the feature folder.
3. Domain types are defined in a central types file, never inside UI components.

TypeScript will catch type violations. Rules will catch structural violations. Together they make GitHub Copilot produce code that is correct in every way that matters.

The prompt does not matter. The rules do.

TypeScript is not enough on its own. It was never designed to be.

It handles the data layer. Rules handle the structural layer. Both are necessary. Only one is automatic.

Write the rules. Give them to GitHub Copilot before the session starts. And stop relying on TypeScript to catch problems it was never built to catch.

Want to see where your React project is missing structural rules?

I built a free 24 point checklist that helps you find exactly that. The architectural gaps that TypeScript cannot catch.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Working Code Is Not the Same as Clean Code. GitHub Copilot Does Not Know the Difference.

Avery — Mon, 18 May 2026 08:32:25 +0000

The tests pass. The app runs. The feature ships on time.

And somewhere in the codebase a component is doing four things at once, state is living in the wrong place, and a naming convention that made sense in session one has quietly been replaced by something different in session twelve.

Nothing is broken. Everything is wrong.

What working code hides

Working code is the minimum bar. It means the app does what it is supposed to do. It does not mean the code is maintainable, consistent, or built on a standard that will hold up as the project grows.

GitHub Copilot clears the working code bar every time. That is not the problem.

The problem is that working code and clean code look identical in the short term. Both pass tests. Both ship features. Both make the deadline.

The difference shows up later. In the refactor that takes three times longer than it should. In the new developer who cannot understand the codebase. In the bug that appears in three places because the same logic was written three times.

By the time the difference is visible, the working code has been in production for months.

Why GitHub Copilot cannot tell the difference

Working code has a clear definition. It runs without errors. It produces the expected output. Copilot can optimize for this because it is measurable.

Clean code does not have a clear definition without rules. Single responsibility means different things in different projects. Clear naming depends on domain context. Separation of concerns depends on architecture decisions that were made before the session started.

Without rules that define what clean looks like in this specific project, Copilot defaults to working. Every time. Because working is the only bar it can measure against.

The gap nobody talks about

Most conversations about AI coding tools focus on whether the output works.

Does it compile? Does it pass the tests? Does it do what the prompt asked?

The gap nobody talks about is the space between working and clean. That gap is where technical debt lives. Where inconsistency accumulates. Where the codebase slowly becomes harder to work with despite the fact that everything technically functions.

GitHub Copilot fills that gap with its own decisions when no rules exist to fill it first.

Working code is what GitHub Copilot produces by default. Clean code is what it produces when the rules define what clean means before the session starts.

What defining clean actually looks like

It starts with translating what you know into what the AI can follow.

You know that components should have one responsibility. Write it as a rule:

React output rules:

Every component has exactly one responsibility. If it does more, extract the rest.
No component exceeds 200 to 300 lines. Extract logic into hooks before adding more.
State lives in hooks. UI components receive data through props only.

Now Copilot has a definition of clean that it can apply. Not a vague principle. A specific constraint. The output moves from working to clean because clean is now defined.

The prompt does not matter. The rules do.

Working code will always be GitHub Copilot's default. That is not a criticism. It is how the tool works.

Clean code requires a definition. And the definition has to come from you, in the form of rules, before the first prompt is written.

Stop measuring success by whether the code runs. Start measuring it by whether the code is clean. And give your AI the rules it needs to produce the difference.

Want to find where your React project stopped at working and never reached clean?

I built a free 24 point checklist that helps you find exactly that. The structural gaps between working output and clean output.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your React Code Follows Every Clean Code Rule. Your AI Has Never Heard of Them.

Avery — Fri, 15 May 2026 08:17:34 +0000

Clean Code is not a new idea.

Single responsibility. Clear naming. Small functions. Separation of concerns. Developers have been applying these principles for decades. Books have been written. Careers have been built around them.

And then GitHub Copilot joins the project and generates a 300 line component with UI, fetching, and business logic all in one file.

Not because Clean Code is wrong. Because nobody told the AI it existed.

What Clean Code looks like without AI rules

Most experienced React developers have internalized Clean Code principles. They write small components. They separate concerns. They name things clearly. They refactor before things get messy.

Then they use GitHub Copilot to move faster. And Copilot generates code that works but violates every principle they have spent years applying.

A component that does too much. A function that knows too many things. State in the wrong place. Logic where it does not belong.

The developer reviews it, fixes the obvious problems, and moves on. But the next session starts the same way. And the one after that.

Clean Code exists in the developer's head. It does not exist in the AI's output until someone puts it there.

Why Clean Code principles do not transfer automatically

Clean Code is a set of principles, not a set of rules.

Principles require judgment. Rules require compliance. GitHub Copilot can comply with rules. It cannot exercise judgment.

When a developer applies Clean Code, they make dozens of small decisions in every session. Is this component doing too much? Should this logic live here or somewhere else? Is this name clear enough?

Copilot does not make those decisions. It generates based on what is in context and what constraints exist. Without explicit rules defining what Clean Code looks like in this specific project, Copilot defaults to whatever produces working output fastest.

Working output and clean output are not the same thing.

Clean Code principles live in your head. GitHub Copilot cannot read your head. It can only follow rules you write down and give it before the session starts.

What happens when you translate principles into rules

Clean Code principles become powerful for AI when you translate them into explicit constraints.

Not "write clean components" — that is a principle. But this:

React component rules:
1. Every component has exactly one responsibility. If it does more, split it.
2. No component exceeds 200-300 lines. Extract logic into hooks before adding more.
3. No fetching inside UI components. Data access belongs in services or hooks only.

Now Copilot has something to comply with. Not a vague principle but a specific constraint. The output changes immediately because the rules exist before the first line is generated.

The gap between knowing and defining

Most developers who care about Clean Code know what it looks like. They can recognize when it is violated. They can refactor toward it.

What most developers have not done is write it down as rules their AI can follow.

That gap is where the inconsistency lives. The developer knows the standard. The AI does not. Every session without rules is a session where Copilot fills that gap with its own decisions.

And Copilot's decisions are not Clean Code. They are whatever works.

The prompt does not matter. The rules do.

Clean Code does not live in the prompt. It lives in the rules you define before the prompt is written.

Write the principles down. Turn them into constraints. Give them to GitHub Copilot before the session starts. And stop watching the AI undo in one session what took you years to learn.

Want to see where your React project is missing those rules?

I built a free 24 point checklist that helps you find exactly that. The structural gaps where Clean Code principles are known but not enforced.

Get the React AI Clean Code Checklist — Free

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

Avery Code React AI Engineering System

You Work Alone. But Your React Codebase Looks Like Five Developers Built It.

Avery — Wed, 13 May 2026 07:00:00 +0000

Solo development is supposed to be simple.

One developer. One vision. One way of doing things. No coordination overhead. No conflicting opinions about folder structure or naming conventions. Just you and the codebase.

Then you open a file you wrote three weeks ago and it looks like someone else wrote it.

The component structure is different from the one you built last week. The naming follows a pattern you do not recognize as yours. The state management approach is subtly different from everything around it.

You did not change. Your standards did not change. But GitHub Copilot had a different session that day and made different decisions.

The invisible team problem

When multiple developers work on a project without a shared standard, the codebase accumulates their individual styles. Every developer leaves traces of how they think, how they name things, how they structure code.

Solo developers with AI have the same problem. Except the other developers are sessions.

Every Copilot session is slightly different. Different context. Different decisions. Different output. Over weeks and months those sessions accumulate the way team members accumulate. The codebase starts reflecting not one developer but every version of every session that contributed to it.

You are working alone. But the codebase has five authors. All of them are you. All of them are slightly different.

The consistency problem is not a team problem. It is a standard problem. And solo developers with AI have it just as much as teams do. They just do not expect it.

Why solo developers do not see it coming

Teams expect consistency problems. They set up style guides, code review processes, naming conventions. They know that multiple people working on the same codebase without a shared standard creates chaos.

Solo developers do not expect it because they are only one person. The assumption is that one developer naturally produces consistent output.

But with AI generating large portions of the code, you are not really one developer anymore. You are one developer plus an AI that makes different decisions every session. And different decisions across enough sessions look exactly like a team without a standard.

What a solo standard actually looks like

It does not have to be complex. It just has to exist before the session starts.

Something as focused as this changes what every session produces:

React project rules:
1. Components use functional declarations. No arrow function components.
2. Every custom hook lives in a dedicated hooks folder within its feature.
3. No inline Tailwind chains longer than four classes. Extract into a component.

Three rules. One developer. Every session follows the same standard. The codebase starts looking like it came from one person with one consistent approach.

Because it does.

The solo advantage

Teams have to coordinate standards across multiple people. That is hard.

Solo developers only have to define the standard once and give it to the AI. That is easy.

The consistency problem that takes teams weeks to align on takes a solo developer an hour to solve. Define the rules. Apply them before every session. Done.

That is the solo developer advantage that most solo developers are not using.

The prompt does not matter. The rules do.

Working alone does not protect you from consistency problems. GitHub Copilot creates the invisible team whether you want one or not.

The only way to stay the sole author of your codebase is to define what your standard looks like and give it to the AI before it starts making decisions for you.

Want to see where your React project has invisible inconsistency?

I built a free 24 point checklist that helps you find exactly that. The gaps where your AI sessions have been producing different output every time.

Get the React AI Clean Code Checklist — Free

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

Avery Code React AI Engineering System

You Switched From GitHub Copilot to Cursor. The Inconsistency Followed You.

Avery — Mon, 11 May 2026 08:50:38 +0000

At some point most developers make the switch.

GitHub Copilot feels limiting. Cursor looks more powerful. Better context awareness. Better chat integration. Better everything.

So you switch. You spend a weekend setting it up. You start a new session and the output feels different. Sharper. More aware of the codebase.

Two weeks later the inconsistency is back.

Different component structures. Naming that drifts between sessions. State that ends up in the wrong place. The same problems you had with GitHub Copilot, now in a different tool.

The tool was never the problem

Cursor is a better tool than GitHub Copilot in many ways. More context. Better conversation. Stronger codebase awareness.

But better context awareness does not create a standard. It means Cursor can see more of your codebase before it generates. And if your codebase has no consistent standard, Cursor sees more inconsistency and generates based on that.

A more powerful tool without rules does not produce more consistent output. It produces more confident inconsistency.

What actually transfers when you switch tools

When you move from GitHub Copilot to Cursor, your prompts transfer. Your habits transfer. Your way of working with AI transfers.

What does not transfer is a standard — because no standard existed to transfer.

The inconsistency you experienced with GitHub Copilot was not a Copilot problem. It was a missing rules problem. And missing rules follow you to every tool you use.

The debate between Cursor and GitHub Copilot is real. But it is the wrong debate. The question is not which tool you use. The question is whether the tool has rules to follow.

What changes when the rules exist

I have used both tools for React development. The output quality difference between them is real but smaller than most developers think.

The bigger difference is between working with rules and working without them. With rules in place both tools produce consistent, structured output. Without rules both tools drift.

Here is a rule that changes what either tool produces:

Before generating any React code:
1. Check what components already exist before building new ones.
2. Follow the existing naming convention in the project.
3. Place business logic in hooks, never in UI components.

Paste that into Cursor. Paste it into GitHub Copilot. The output from both tools becomes more consistent immediately. Not because the tool changed. Because the constraint existed.

The tool debate is a distraction

Every few months there is a new tool that promises better AI coding. Better context. Better suggestions. Better integration.

And developers switch. And the inconsistency follows them. Because the inconsistency was never in the tool.

The developers who produce consistent React output regardless of which tool they use are not better at picking tools. They are better at defining rules that work across any tool they choose.

The prompt does not matter. The rules do.

Cursor or GitHub Copilot. The choice matters less than you think.

What matters is whether the tool you use has rules that define what consistent output looks like. Without rules both tools drift. With rules both tools follow.

Stop switching tools. Start defining rules.

Want to find where your React project is missing those rules?

I built a free 24 point checklist that helps you identify exactly that. The structural gaps that cause inconsistency regardless of which AI tool you use.

Get the React AI Clean Code Checklist — Free

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

Avery Code React AI Engineering System v

GitHub Copilot Does Not Scale With Your React Project. Your Rules Do.

Avery — Fri, 08 May 2026 12:00:36 +0000

Small projects forgive a lot.

When the codebase has ten components and two developers, inconsistency is manageable. You know where everything is. You remember the decisions you made. The AI output varies a little but nothing breaks badly enough to slow you down.

Then the project grows.

More features. More developers. More sessions with GitHub Copilot. And the inconsistency that was manageable at ten components becomes a real problem at a hundred.

What scaling without rules actually looks like

It does not happen dramatically.

It happens one session at a time. A new feature gets built slightly differently from the last one. A new developer joins and their Copilot sessions produce output that works but does not match the existing patterns. The components folder grows but the structure inside it becomes harder to navigate.

Nobody made a bad decision. Nobody cut a corner. GitHub Copilot just kept inventing a slightly different standard every session because no rule told it to do otherwise.

At small scale that is invisible. At large scale it is a maintenance problem that touches every part of the project.

Why GitHub Copilot does not scale on its own

GitHub Copilot generates based on what it can see in context. In a small project, the context is manageable. Copilot can infer patterns from the files around it and produce something reasonably consistent.

In a large project, the context becomes noisy. There are more files, more patterns, more decisions from more sessions. Copilot cannot infer a consistent standard from a codebase that does not have one. So it keeps inventing.

The more the project grows without rules, the more Copilot has to guess. And the more it guesses, the more the output diverges.

GitHub Copilot does not get better as your project grows. Without rules it gets less consistent. Because the codebase it is drawing from has more variation, not less.

What scales instead of Copilot

Rules scale.

A rule defined once applies to every session, every developer, every feature, regardless of how large the project gets. The codebase grows but the standard stays the same.

Rules like these do not become harder to enforce as the project grows. They become more valuable:

Architecture rules:
1. UI components render JSX only. No fetching, no business logic.
2. State logic lives in hooks. One hook per feature area.
3. External imports go through feature index files only.

In a small project these rules produce clean output. In a large project they are the difference between a codebase that stays navigable and one that requires a full refactor every six months.

The scaling problem most teams solve too late

Most teams notice the scaling problem when it is already expensive to fix.

The codebase has grown. The inconsistency is everywhere. A refactor is on the roadmap but keeps getting pushed because there is always something more urgent.

The rules that would have prevented this take an hour to define. The refactor they would have prevented takes weeks.

Defining a standard before the project scales is not a luxury. It is the cheapest investment you can make in a growing React project.

The prompt does not matter. The rules do.

GitHub Copilot will not automatically produce more consistent output as your project grows. It will produce less consistent output because the codebase it draws from has more variation.

The only thing that scales with your project is the rules you define before it grows.

Define them early. Apply them everywhere. And let the project scale without the debt that comes from having no standard.

Want to see where your React project is missing rules that scale?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that become more expensive as the project grows.

Get the React AI Clean Code Checklist — Free

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

Avery Code React AI Engineering System

Technical Debt Does Not Come From Moving Fast. It Comes From Having No AI Standard.

Avery — Wed, 06 May 2026 07:00:00 +0000

There is a story most developers tell themselves about technical debt.

You moved too fast. You cut corners. You shipped features under pressure and told yourself you would clean it up later. Later never came.

That story made sense before AI coding tools existed. It makes less sense now.

Today a lot of technical debt does not come from moving fast. It comes from moving fast with an AI that has no standard to follow.

What AI technical debt actually looks like

It does not look like obvious shortcuts.

It looks like a codebase where every feature was built correctly in isolation but nothing fits together. Components that handle state differently depending on which session built them. Naming that is consistent within a file but inconsistent across the project. TypeScript that is strict in some places and full of any in others.

Nobody cut corners. Nobody made bad decisions. GitHub Copilot made a lot of small decisions across a lot of sessions and none of them were wrong on their own. They just were not the same.

That is AI technical debt. Not the result of moving fast. The result of having no standard that every session had to follow.

Why this kind of debt is harder to fix

Traditional technical debt has a clear source. A specific decision. A specific shortcut. You can find it, understand it, and fix it.

AI technical debt is distributed. It lives in the accumulated decisions of every session that came before. It is in the folder structure, the naming patterns, the way state is handled, the way components are composed. It is everywhere and nowhere at the same time.

You cannot fix it with one refactor. You can only stop it from growing by defining the standard now and applying it going forward.

The debt is not from moving fast. It is from letting GitHub Copilot make a different decision every session because no rule told it to make the same one.

The connection between missing rules and accumulating debt

Every area of your React project without a rule is an area where GitHub Copilot improvises.

Improvised architecture. Improvised naming. Improvised TypeScript patterns. Each improvisation is slightly different from the last. And slightly different at scale is what a codebase full of technical debt looks like.

The rule does not have to be complex. Something as simple as this changes what every session produces:

All React components must:
1. Keep UI and data fetching strictly separated.
2. Use named exports only. No default exports.
3. Keep components under 200 lines. Extract logic into hooks.

Three rules. Applied consistently. And the debt stops accumulating because the decisions stop varying.

Moving fast is not the problem

Speed is not the enemy of a clean codebase. An undefined standard is.

You can move fast and produce consistent output if the rules are in place before the session starts. The speed stays. The debt does not accumulate. Because the AI is not improvising. It is following.

The teams and developers who accumulate the least AI technical debt are not the ones who move slowly. They are the ones who defined what consistent output looks like before they started moving at all.

The prompt does not matter. The rules do.

Technical debt from AI is not inevitable. It is the predictable result of working without a standard.

Define the standard. Apply it everywhere. And let GitHub Copilot move fast inside boundaries that keep the codebase clean.

Want to see where your React project is accumulating AI technical debt?

I built a free 24 point checklist that helps you find exactly that. The structural gaps where GitHub Copilot has been making different decisions every session.

Get the React AI Clean Code Checklist — Free

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

Avery Code React AI Engineering System

GitHub Copilot Sets a React Standard in Your First Session. The Question Is Whether It Matches Yours.

Avery — Mon, 04 May 2026 12:30:39 +0000

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.

The standard does not start when the project grows. It starts when the first prompt is written. And if you did not define it, Copilot already did.

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:

Avery Code React AI Engineering System

I Stopped Letting GitHub Copilot Invent My React Standard. Here Is What I Did Instead.

Avery — Fri, 01 May 2026 07:56:08 +0000

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.

The problem was not the code. The problem was that I had never told Copilot what my standard was. So it invented one. Twice. And they were not the same.

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:

Avery Code React AI Engineering System

What Senior React Developers Do Differently With GitHub Copilot. It Is Not the Prompt.

Avery — Wed, 29 Apr 2026 07:06:00 +0000

Watch a junior developer work with GitHub Copilot and watch a senior developer work with GitHub Copilot.

The prompts are not that different. Both describe what they want. Both iterate when the output is not right. Both spend time reviewing and correcting.

But the output is different. Not because one is smarter. Not because one writes better prompts. Because one of them has defined what the output must look like before the session begins.

What experience actually teaches you about AI

Junior developers trust the output.

They prompt, review quickly, and move on. The code works. That feels like enough. The inconsistencies are not obvious yet. The technical debt is not visible yet. The cost of no standard has not shown up yet.

Senior developers have seen the cost.

They have inherited codebases where every developer used AI differently. They have done the refactors. They have written the pull request comments about consistency for the hundredth time. They have watched a project that started clean slowly become unreadable because nobody defined what the output standard was.

That experience changes how they approach AI. Not the prompts. The constraints.

The difference is not skill. It is a system.

A senior developer working with GitHub Copilot does not write better prompts.

They define the rules upfront. Architecture rules. Naming rules. TypeScript rules. Component structure rules. Accessibility standards. Before the first prompt is written, the output space is already constrained.

The prompt then operates inside that constraint. Vague or precise, tired or focused, the output follows the same standard because the rules are always there.

A junior developer working without those rules gets whatever GitHub Copilot decides. Sometimes clean. Sometimes not. Always different.

The gap between them is not experience. It is the presence or absence of a system.

Why this matters for teams

Most teams assume that senior developers produce better AI output because they are better at prompting or better at reviewing.

That assumption leads to the wrong solution. More prompt training. Stricter reviews. Longer onboarding.

None of that closes the gap. Because the gap is not about skill. It is about whether a standard exists that every developer, at every level, follows when they work with AI.

When the standard exists, a junior developer on day one produces the same consistent output as a senior developer who has been on the project for a year. Not because they are equally experienced. Because the rules are the same for both.

That is what a rule system actually does for a team.

The prompt does not matter. The rules do.

The most experienced React developers are not better at working with GitHub Copilot because they have learned to prompt more precisely.

They are better because they stopped relying on the prompt to carry the standard. They defined the standard once. They apply it everywhere. And the output is consistent regardless of who is writing the prompt.

That is not a senior developer skill. That is a system anyone can use.

Want to see where your React project is missing that standard?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that make AI output inconsistent regardless of experience level.

👉 Get the React AI Clean Code Checklist — free

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

👉 Avery Code React AI Engineering System