DEV Community: Avery

GitHub Copilot Without Rules Does Not Just Produce Bad React Code. It Produces Expensive React Code.

Avery — Wed, 15 Apr 2026 11:47:16 +0000

Bad code is obvious. You see it in the review. You fix it. You move on.

Expensive code is different.

It looks fine. It passes the review. It ships. And then it costs you in ways that are hard to trace back to a single decision, a single prompt, a single session with GitHub Copilot.

This is what happens when your AI has no rules.

The cost is not in the bugs

Most developers think about AI output quality in terms of bugs. Does it work? Does it break anything?

That is the wrong question.

The real cost is in the time spent after the code exists.

The ten minutes in every pull request explaining why this component should have been reusable. The hour spent refactoring a component that Copilot built for exactly one use case. The afternoon untangling logic that should have lived in a hook but ended up inline in the UI. The sprint planning conversation about why the codebase is getting harder to work with.

None of these show up as bugs. All of them cost time. And time, for a developer or a freelancer, is money.

Inconsistency has a compounding cost

One inconsistent component is a minor annoyance.

Ten inconsistent components across a project is a maintenance problem. Every new developer who joins needs extra time to understand which pattern is correct. Every design change needs to happen in multiple places instead of one. Every refactor takes longer because nothing is predictable enough to change in bulk.

The cost of no rules does not stay flat. It grows with the project.

A codebase built with GitHub Copilot and no rules is not a codebase that has a few rough edges. It is a codebase that gets progressively more expensive to work with every week.

The hidden cost for freelancers

For freelancers the cost is even more direct.

Inconsistent output means more correction time. More correction time means less time for billable work. Or it means delivering work that looks less professional than it should and clients notice.

A freelancer who cannot trust their AI output spends part of every session cleaning up instead of building. That is not a productivity gain. That is a productivity tax on every project.

What rules actually save you

When GitHub Copilot has rules, the correction loop shrinks.

The output is consistent from the first prompt. Components are reusable by default. Logic lives where it belongs. TypeScript is correct. Accessibility is handled.

You stop spending time fixing what the AI should have gotten right. You stop writing the same pull request comments. You stop explaining the same patterns to the same AI every session.

The rules do not just improve the code. They change the economics of working with AI.

I have been working this way for several months. The time I used to spend correcting Copilot output is now time I spend building. That is the real return on a rule system.

The prompt does not matter. The rules do.

Every hour you spend correcting GitHub Copilot output is an hour the rules would have saved.

Define the output before the first prompt. Make consistency the default. Make expensive code impossible.

Want to know where your React project is losing time?

I built a free 20 point checklist that helps you find exactly that. The structural gaps that make AI output inconsistent and your codebase expensive to maintain.

👉 Get the React AI Audit Checklist — free

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

👉 Avery Code React AI Engineering System

A New Developer Joined Your Team. GitHub Copilot Has No Idea What Your Standard Is.

Avery — Mon, 13 Apr 2026 15:24:59 +0000

The first week of a new developer on the team is always the same.

They read the docs. They look at existing code. They try to understand how things are done here. What patterns the team uses. What the naming conventions are. How components are structured.

It takes time. But eventually they get it.

GitHub Copilot never gets it.

Every session starts from zero. No memory of the decisions your team made. No knowledge of the patterns you established. No awareness of the standard that took months to build.

The new developer learns your standard over time. The AI never does. Unless you give it rules.

What happens without an AI standard

The new developer opens their first ticket. They start working with Copilot. They prompt naturally, the way they always have.

And Copilot generates code that works. Technically correct. No errors. And completely inconsistent with everything the rest of the team built.

Different naming. Different component structure. Different TypeScript patterns. Not because the new developer did anything wrong. Because Copilot had no standard to follow.

The pull request comes in. The review takes longer than it should. Half the comments are about consistency, not logic. The new developer fixes it. The next PR looks the same.

This is not an onboarding problem. It is a missing AI standard problem.

The standard lives in your head. Not in the AI.

Most teams have a standard. It is just not written down in a way the AI can follow.

It lives in the codebase. In the pull request comments. In the institutional knowledge of developers who have been there for years. New developers absorb it over weeks. Senior developers enforce it in reviews.

But GitHub Copilot does not absorb anything. It does not learn from your codebase over time. It does not read your pull request comments. It generates based on what it sees in the prompt and the immediate context.

If the standard is not explicitly defined as rules, Copilot does not know it exists.

What changes when the AI has a standard to follow

When every developer on the team uses the same rule system, the AI stops improvising.

The new developer starts on day one with the same rules as everyone else. Copilot follows the same structure, the same naming, the same separation of concerns. The pull request looks like it came from a developer who has been on the team for months.

Not because the new developer is exceptional. Because the rules are the same for everyone. Including the AI.

Onboarding becomes faster. Reviews become shorter. Consistency is not something you enforce in comments. It is built into every session from the start.

The prompt does not matter. The rules do.

A new developer should not need weeks to figure out what consistent AI output looks like on your team.

Define the standard once. Give it to the AI as rules. Every developer, every session, every prompt produces the same output.

That is what an AI onboarding standard actually looks like.

Want to see what those rules look like?

I packaged my first three React AI rules as a free PDF. The starting point for consistent AI output across your entire team from day one.

👉 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

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

Avery — Fri, 10 Apr 2026 10:36:43 +0000

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

GitHub Copilot Can Produce Accessible React Code. It Just Needs the Right Rules.

Avery — Wed, 08 Apr 2026 08:36:03 +0000

Accessibility is one of those things most React developers agree on in theory.

Semantic HTML. Keyboard navigation. Screen reader support. Proper labels. Everyone knows it matters.

And then they open a pull request and find a clickable div where a button should be. An icon with no label. A form input with no associated label element. A modal that traps focus nowhere.

Not because the developer forgot. Because GitHub Copilot generated it that way and nobody defined what accessible output actually looks like.

The AI does not skip accessibility on purpose

GitHub Copilot is not making a judgment call when it generates a clickable div instead of a button.

It is taking the path of least resistance. A div works. It renders. It does not throw an error. Without a rule that says "interactive elements must always use semantic HTML", Copilot has no reason to reach for a button instead.

The same is true for form labels. For ARIA attributes. For focus management in modals. For keyboard operability.

Copilot will generate accessible code when the rules define that it must. Without those rules, it improvises. And improvised accessibility looks like the pull request nobody wants to review.

Accessibility is not a prompt problem

You cannot fix this by describing accessibility requirements in every prompt.

You will forget sometimes. You will be in a hurry sometimes. The prompt will be vague sometimes. And the moment the description is missing, Copilot falls back to whatever it defaults to.

Accessibility built on prompt discipline is fragile. It works when you remember. It breaks when you do not.

The only way to make accessibility consistent is to move it out of the prompt and into the rules. Rules that define what every piece of generated UI must look like before Copilot writes a single line.

Semantic HTML by default. Labels always present. Interactive elements always keyboard operable. Focus management always handled. Not sometimes. Every time.

What consistent accessible output actually looks like

I have been working with a rule system for GitHub Copilot for several months now.

Accessibility is not something I think about per prompt anymore. It is defined in the system. Every component that comes out follows the same accessible patterns. Semantic HTML. Proper labels. Keyboard support. ARIA only where semantic HTML is not enough.

The output is accessible by default. Not because every prompt asks for it. Because the rules make it impossible for Copilot to generate anything else.

That is what the right rules do. They remove the dependency on memory, discipline, and perfect prompts. The standard is always there. The output always follows it.

The prompt does not matter. The rules do.

Accessible React output is not a question of how well you describe accessibility to your AI.

It is a question of whether your AI has rules that make accessible output the only option.

Give it those rules. Stop reviewing for accessibility issues after the fact. Start defining what accessible means before the first line is generated.

The prompt doesn't matter. The rules do.

Want to see what those rules look like?

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

👉 Get My First 3 React AI Rules — free

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

👉 Avery Code React AI Engineering System

Stop Reviewing GitHub Copilot Output. Here Is How to Define It Instead.

Avery — Mon, 06 Apr 2026 08:46:37 +0000

Most developers have the same routine with GitHub Copilot.

Generate. Review. Correct. Generate again.

It works. Slowly. Expensively. And it never really ends because the next session starts the same way.

There is a different approach. And it changes everything about how AI-assisted development feels.

Reviewing is a symptom of missing rules

When you review Copilot output, you are doing one thing: checking whether the AI guessed your standard correctly.

Sometimes it did. Sometimes it did not. And you correct accordingly.

But the standard was never communicated. Copilot invented it based on your prompt, the visible code, and whatever patterns it has seen before. You are reviewing a guess.

The more you correct, the more follow-up prompts you write, the more time you spend steering — the clearer it becomes that something is missing upstream.

That something is a definition of what the output should look like before Copilot starts generating.

The difference between reviewing and defining

Reviewing happens after the output exists. You read it, judge it, fix it.

Defining happens before the output exists. You tell the AI what structure, naming, separation, and conventions every piece of code must follow — regardless of what you ask for.

When you define upfront, Copilot stops guessing. It follows. And the output looks the same whether the prompt was precise or vague, whether it was Monday morning or Friday afternoon.

You stop correcting the same things over and over. You stop writing follow-up prompts that start with "actually" or "wait, no." You stop spending the first ten minutes of every session re-establishing context.

The review becomes a formality instead of a necessity.

What defining actually looks like

It is not about writing longer prompts. Longer prompts still disappear at the end of the session.

It is about giving your AI a system it follows every time. Rules that define architecture. Rules that define naming. Rules that define where logic lives, what TypeScript discipline looks like, how components are structured.

I have been working this way for three months with GitHub Copilot. The output is consistent. The reviews are fast. The corrections are rare.

Not because Copilot got smarter. Because I stopped asking it to guess and started telling it what to follow.

The prompt does not matter. The rules do.

This is the shift.

Stop optimizing your prompts. Start defining your output.

Your AI does not need better questions. It needs a system that tells it what every answer must look like.

Want to see what that system looks like?

I packaged my first three React AI rules as a free PDF. The exact rules I use before every Copilot session so the output is defined before the first line is generated.

👉 Get My First 3 React AI Rules — free

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

👉 Avery Code React AI Engineering System

Why GitHub Copilot Produces Inconsistent React Code. Even in the Same Project.

Avery — Fri, 03 Apr 2026 08:40:34 +0000

Open any React project where GitHub Copilot was involved for more than a few weeks.

Scroll through the components. Look at the naming. Check how state is handled. See where the logic lives.

Chances are it does not look like one codebase. It looks like three.

Not because the team was bad. Not because the AI failed. Because nobody defined what consistent output should look like before the first prompt was written.

Every session starts from zero

GitHub Copilot has no memory of your previous sessions.

It does not remember that two weeks ago you decided components should always be presentational. It does not know about the naming convention you established last sprint. It does not care about the folder structure you refactored toward on Tuesday.

The moment you open a new chat, everything resets. No memory of your last session. No knowledge of the decisions you made yesterday.

If you do not bring the rules, Copilot invents them. And invented rules look different every single time.

One session produces clean TypeScript with proper separation. The next one puts everything inline. One component follows the domain naming. The next one uses whatever made sense in the moment.

Same project. Same AI. Completely different results.

The prompt is not the problem

Most developers try to fix this with better prompts.

They get more specific. They add more context. They write longer instructions at the start of each session.

And the output improves — sometimes. On good days with focused prompts. But it still drifts. Still varies. Still looks different depending on who wrote the prompt and when.

Because the problem was never the prompt.

The problem is that there is nothing telling Copilot what the standard looks like before it starts generating. No rules about structure. No rules about naming. No rules about where logic belongs.

A better prompt is still just a prompt. It disappears the moment the session ends.

What actually creates consistency

I have been using a rule system with GitHub Copilot for eight months now.

Not better prompts. Rules that define what every output must look like regardless of how I ask.

The prompt stops mattering as much. It does not matter if the prompt is vague or precise. The rules define the output before Copilot even starts generating.

Same structure. Same naming. Same separation of concerns. Every session. Whether it is a focused Monday morning or a tired Friday afternoon.

That is what consistency actually requires. Not better prompts. A system that runs underneath every prompt.

The prompt does not matter. The rules do.

This is the shift that changes everything.

Stop trying to control Copilot through the prompt. Start defining what every output must look like regardless of how you ask.

Your codebase should look like it came from one senior engineer. Not from every version of you on every kind of day.

Want to see what those rules look like?

I packaged my first three React AI rules as a free PDF. The exact rules I use before every Copilot session to keep output consistent regardless of how I prompt.

👉 Get My First 3 React AI Rules — free

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

👉 Avery Code React AI Engineering System

Why GitHub Copilot Produces Different Code for Every Developer on Your Team

Avery — Wed, 01 Apr 2026 08:09:00 +0000

Six months ago your team started using GitHub Copilot.

Everyone was excited. Faster code. Less boilerplate. More time for actual problems.

Then you opened a pull request last week and spent ten minutes trying to figure out who wrote what.

Not because the code was bad. Because nothing looked the same anymore.

One component uses a custom hook. The next one puts everything inline. One file has strict TypeScript. The next one is full of any. One developer names things after the domain. Another names things after whatever made sense at 2pm on a Thursday.

Same project. Same AI tool. Completely different results.

This is not a skill problem

Nobody on your team is doing it wrong.

Everyone is just prompting differently. And GitHub Copilot does exactly what it is told — nothing more, nothing less.

The problem is that Copilot has no idea what your project standard is. It does not know how your team names things. It does not know which patterns you agreed on. It does not know what the last five developers already built.

Every prompt starts from zero. Every developer brings their own habits. And the codebase slowly becomes a collection of five different coding styles held together by a shared package.json.

The problem compounds over time

In the beginning it feels fine. Everyone is shipping fast. Reviews are quick.

Then the project grows.

A new developer joins and spends three days trying to understand which pattern is the actual standard. A bug appears in a component that looks slightly different from all the others — because it was generated with a different prompt six weeks ago. A refactor takes twice as long because nothing is consistent enough to change in bulk.

The AI did not slow you down. The missing standard did.

What changes when the AI has rules

When every developer on your team uses the same system, Copilot stops improvising.

It does not matter who writes the prompt. It does not matter how they phrase it. It does not matter if it is Monday morning or Friday afternoon.

The output follows the same structure. The same naming. The same separation of concerns. The same TypeScript discipline.

Not because the AI got smarter. Because the rules are the same for everyone.

That is what consistency actually means in AI-assisted development. Not hoping everyone prompts the same way. Defining what the output must look like — regardless of the input.

The prompt does not matter. The rules do.

This is the shift most teams have not made yet.

They invest in prompt engineering. They write guides on how to ask Copilot the right questions. They review AI output and give feedback in comments.

And the codebase still looks different every week.

Because the problem was never the prompt. The problem is that there are no rules defining what the output should look like.

Give your AI a system. Every developer on your team uses the same rules. Every output looks like it came from the same senior engineer.

Want the rules that make this work?

I packaged my first three React AI rules as a free PDF — the exact starting point for consistent AI output across any project.

👉 Get My First 3 React AI Rules — free

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

👉 Avery Code React AI Engineering System

The prompt doesn't matter. The rules do.

Why GitHub Copilot Defaults to 'any' in React TypeScript Projects

Avery — Mon, 30 Mar 2026 09:10:29 +0000

There is a pattern that shows up constantly in React TypeScript projects where GitHub Copilot was involved.

It looks like this:

const [data, setData] = useState<any>(null)

const handleResponse = (response: any) => {
  setData(response.data)
}

TypeScript is installed. The project is set up correctly. And Copilot still reaches for any — every single time.

Why this happens

Copilot is not trying to write bad TypeScript. It is taking the path of least resistance.

any works. It compiles. It does not throw errors. And without explicit constraints telling Copilot what the actual types are, it defaults to the safest assumption it can make — which is no assumption at all.

The result is TypeScript that looks correct but provides zero protection. You have all the overhead of a typed language with none of the benefits.

What any actually costs you

TypeScript exists to catch errors before they reach production. The moment you use any, that protection disappears for that value — and everything that touches it.

A component that receives any as a prop passes any down the tree. A function that returns any spreads uncertainty through the entire codebase. One any becomes ten. Ten becomes a codebase where TypeScript is installed but not actually working.

And the worst part is that it fails silently. No warnings. No errors. Just runtime surprises that TypeScript was supposed to prevent.

What changes when you give Copilot explicit types

When you define your domain types clearly and tell Copilot to use them, the output changes completely.

Instead of any, Copilot reaches for the types you have already defined. Props are typed correctly. API responses are mapped to real interfaces. State has a shape.

The key is that Copilot needs the context. It cannot invent your domain types. You have to give them.

The deeper problem

TypeScript any is just one symptom of a bigger issue.

GitHub Copilot generates code based on what it can see. If your types are vague, your constraints are missing, or your project structure gives it nothing to work with — it improvises.

And improvised TypeScript in a React project is TypeScript in name only.

Want to find where your React project is missing structure?

I built a free 20 point checklist that helps you identify exactly this. Structural and typing weaknesses that make AI output unpredictable and your codebase fragile.

No guessing. No endless follow up prompts. Just a clear picture of what to fix before you prompt again.

👉 Get the React AI Audit Checklist free

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

👉 Avery Code React AI Engineering System

GitHub Copilot Stores Derived State in useEffect. This Is Why That Breaks Your App.

Avery — Fri, 27 Mar 2026 13:03:15 +0000

There is a pattern that shows up in almost every React project where AI was involved.

It looks harmless. It works on first glance. And it silently creates bugs that are annoying to track down.

It looks like this:

const [total, setTotal] = useState(0)

useEffect(() => {
  setTotal(items.reduce((sum, i) => sum + i.price, 0))
}, [items])

GitHub Copilot writes this confidently. No warnings. No errors. Just broken logic waiting to happen.

What is actually wrong here

Total is not state. Total is a calculation.

It depends entirely on items. Every time items changes, total gets recalculated anyway. Storing it in useState and syncing it with useEffect adds a second source of truth that never needed to exist.

The result is a component that renders twice when it should render once. State that is always one step behind. And a useEffect that exists for no reason other than that the AI had no rule against it.

Why GitHub Copilot does this

Copilot is not broken. It is pattern matching.

It has seen thousands of examples where useState and useEffect are used together. So it reaches for that pattern by default even when the situation does not call for it.

It has no concept of derived state. It does not ask whether something should be stored or computed. It just generates what looks plausible.

And plausible is not the same as correct.

The fix is one line

const total = items.reduce((sum, i) => sum + i.price, 0)

No useState. No useEffect. Just a variable that is computed directly from items on every render.

One render instead of two. One source of truth instead of two. Zero unnecessary state.

The deeper problem

useEffect misuse is one of the most common AI coding mistakes in React projects.

Not because the pattern is rare. Because Copilot reaches for it constantly for derived state, for synchronous logic, for things that should never be effects in the first place.

Every area where your AI has no explicit constraints is an area where it improvises. And improvised useEffect logic compounds fast in a real React codebase.

Want to find where your React project has these problems?

I built a free 20 point checklist that helps you identify exactly this. Structural weaknesses that make AI output unpredictable and your app fragile.

No guessing. No endless follow up prompts. Just a clear picture of what to fix before you prompt again.

👉 Get the React AI Audit Checklist free

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

👉 Avery Code React AI Engineering System

Same AI. Different rules.

© Avery Labs — Avery Code

I Spent an Hour Fixing Tailwind Classes GitHub Copilot Created in 10 Seconds

Avery — Wed, 25 Mar 2026 09:43:54 +0000

I still remember the moment clearly.

I asked GitHub Copilot to build a simple React component. Ten seconds later it was done. Clean, functional, no errors.

Then I looked at the Tailwind classes.

The same combination of fifteen utilities scattered across four different places in my React project. Inline on every element. No abstraction. No pattern. Just raw utility chains copied pasted into existence.

It looked fine. Until I had to change the design.

Then I spent an hour hunting through files, fixing the same styling in place after place after place.

Ten seconds to create. One hour to fix.

The problem is not Tailwind

The problem is not Tailwind. It is that Copilot has no styling rules.

Tailwind is fast by design. You write utility classes inline and move on.

That works when you are the only one writing the code. When you remember what you wrote. When the project is small enough to hold in your head.

GitHub Copilot does not remember anything.

Every prompt is a fresh start. No memory of what you wrote last session. No awareness of the patterns you have established. No idea that you already used those fifteen classes somewhere else.

So it inlines everything. Every time. Confidently.

And your React project slowly turns into a styling mess that nobody including you can maintain.

What changed when I gave Copilot one rule

I added one constraint to my Copilot sessions.

Never repeat the same Tailwind utility combination. If a pattern appears more than once, extract it.

That is it.

The inline chaos stopped. Repeated patterns got extracted automatically. When the design changed I changed it in one place.

One rule. One constraint. Completely different output.

The deeper problem

Tailwind chaos is just one symptom.

Your AI coding tool has no styling rules, no architecture rules, no component rules unless you give them explicitly.

Every area without constraints is an area where GitHub Copilot improvises. And improvised Tailwind in a React project compounds fast.

That is what makes AI coding in React predictable. Not a better prompt, but explicit rules your AI has to follow.

Want the exact rules I use?

I packaged my first three React AI rules as a free PDF including the exact prompt blocks ready to paste into GitHub Copilot or Cursor before your next session.

👉 Get My First 3 React AI Rules — free

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

👉 Avery Code — React AI Engineering System

Why GitHub Copilot Ignores Your React Project Structure

Avery — Mon, 23 Mar 2026 13:14:01 +0000

I have been a freelance frontend developer for a while now.

I use GitHub Copilot and Cursor every day. AI coding tools that are supposed to make me faster.

And one thing kept happening that drove me completely crazy.

Everything worked. And everything was wrong.

I would ask Copilot to build something.

It would build it.

Clean. Working. No errors.

And completely disconnected from everything else in my project.

Wrong folder
Wrong naming convention
New utility function even though one already existed
New component even though one was three files away

Every single time.

I kept thinking:

Does this thing even see my project? Or is it just generating into a void?

After a lot of frustration, I realized the answer is both.

Your AI does not read your project. It reads your prompt.

This sounds obvious when you say it out loud.

But it took me an embarrassingly long time to actually understand it.

When you open a new Copilot session and write a prompt, it does not automatically scan your entire codebase.

It works with what is in context.

What you give it.

What it can see.

If you do not explicitly point it to your React project structure, it improvises.

And improvised structure looks clean on the surface.

But underneath, it creates a parallel system next to yours.

Two naming conventions
Two utility patterns
Two ways of organizing the same thing

Not because Copilot is broken.

Because it had no map.

What I started doing differently

I stopped assuming Copilot knew where it was.

Before every session, I now tell it explicitly:

What the React project structure looks like
Where components live
What naming conventions we use
What already exists before it builds anything new

It sounds like extra work.

It takes about thirty seconds per session.

The drift stopped almost immediately.

No more parallel systems.

No more rebuilding what already existed.

No more wrong folders.

The deeper problem

React project structure is just one thing your AI does not know unless you tell it.

There is also:

Typing
State management
Accessibility
Component boundaries
useEffect patterns

Every area where you have not given your AI explicit constraints, it improvises.

And improvised code looks fine until it does not.

What actually makes AI coding predictable

It is not a better prompt.

It is a better structure.

The question is not whether your AI is good enough.

The question is whether you have given it enough structure to work with.

Want to find the gaps in your project?

If your AI output feels inconsistent, the problem is usually not the tool.

It is the structure underneath.

I built a free 20 point checklist that helps you identify exactly that.

The structural gaps that make AI output unpredictable.

No guessing.

No endless follow up prompts.

Just a clear picture of what to fix before you prompt again.

👉 Get the React AI Audit Checklist — free

And if you want the full system

Rules across:

Architecture
Typing
State
Accessibility
And more

👉 Avery Code React AI Coding System

I Work as a Freelancer. My AI Coding Tool Was Making Me Look Bad.

Avery — Sat, 21 Mar 2026 15:18:40 +0000

I still work as a freelancer.

Deadlines. Clients. Code reviews. The whole thing.

I use GitHub Copilot every day. Not because it is perfect, but because it is fast. And as a freelancer, fast matters.

But somewhere along the way, fast stopped feeling fast.

I wasn’t building anymore. I was babysitting.

Every session turned into a back and forth.

I would ask Copilot for something.

It would go in a direction I did not want.

I would correct it.

It would drift again.

I would correct it again.

I was not building anymore.

I was babysitting.

And the worst part? Things slipped through.

Not obvious bugs.

Subtle things.

A component that already existed got rebuilt slightly differently
Styling did not match the rest of the project
Structure worked in isolation but broke patterns elsewhere

I only noticed when someone else did.

Code review. Client feedback.

That moment where you think:

I would never have written it this way myself.

That was the moment it stopped being a productivity tool

and started feeling like a liability.

The real problem

The problem was not Copilot.

It was me.

I gave it nothing to work with.

No rules.

No constraints.

No structure it had to follow.

So it improvised.

Every single time.

That is the thing about AI coding tools

If you do not give them rules

they will make them up.

And they do it fast.

Confidently.

And wrong.

So I wrote rules

Not a full system.

Just the things that kept going wrong.

The first three were simple:

Do not build new React components when one already exists
Do not scatter Tailwind classes. Extract what repeats
Check the project before you generate anything

Three rules.

That was it.

What changed

The back and forth got shorter.

The drift stopped.

Things stopped slipping through during code review.

I was not babysitting anymore.

I was building again.

That became Avery Code

I kept going.

More rules.

More structure.

More control.

What started as three rules turned into a full system.

Want the exact prompt blocks?

The three rules above are the concept.

If you want the exact text ready to paste into GitHub Copilot or Cursor before your next React session, I packaged them as a free PDF.

👉👉 Avery Code My first 3 React AI Rules

And if you want the full system

Rules across:

Architecture
Typing
State
Accessibility
And more

👉 Avery Code React AI Coding System