DEV Community: Avery

Your AI Knows Everything About React. It Knows Nothing About Your React Project.

Avery — Mon, 06 Jul 2026 15:10:51 +0000

There is a gap that most developers do not think about until it causes a problem.

The AI you use every day has been trained on enormous amounts of React code. It knows the patterns. It knows the hooks. It knows how components should be structured, how TypeScript integrates, how state management libraries work, what the common anti-patterns are and how to avoid them.

It is genuinely knowledgeable about React as a technology. More knowledgeable than most developers who use it.

And it knows absolutely nothing about your React project specifically.

Not how you structure features. Not what naming conventions your team has settled on. Not where state belongs in your architecture. Not what your component boundaries look like. Not what patterns you have deliberately chosen and which ones you have deliberately avoided. Not the decisions that took months of iteration to arrive at and that define how this particular codebase works.

Every session starts with the same AI that knows everything about React and nothing about yours. And then it generates code. And then you wonder why the output does not quite fit.

The difference between knowing React and knowing your project

React knowledge is general. It applies to every React project that has ever existed or will ever exist.

Project knowledge is specific. It only applies to this codebase, this team, this set of decisions, this particular way of solving the problems this product has.

A developer who knows React but not your project can still write good React code. It just will not fit your project without guidance. You would onboard them. You would explain the architecture, the conventions, the decisions that define how things are done here. You would give them the context they need to make their general React knowledge useful in your specific situation.

The AI gets no such onboarding. It shows up with all its general React knowledge and starts generating based on that plus whatever it can infer from the files around the current work. Which is never enough to substitute for actually knowing the project.

The result is React code that is technically correct and contextually wrong. Code that follows best practices for React as a technology while ignoring the specific practices of your particular project.

What the AI is actually doing when it generates

When the AI generates a component for your project it is making decisions.

Where does this state belong? What should this be named? How should this component be structured? What is the right way to handle this type of interaction given the patterns I can see around me?

These are not trivial decisions. They are exactly the kinds of decisions that experienced developers on your team make quickly because they have internalized the project's standards. They know the answer before they have to think about it because the answer has been established over months of building together.

The AI does not have that internalized knowledge. It has general React knowledge and whatever it can read in the immediate context. So it makes the best decision it can with what it has. Which is often a reasonable React decision that is not your project's decision.

Every session. Every component. Every hook. Every time it names something or decides where something belongs or chooses how to structure a piece of logic, it is working from general knowledge in the absence of specific rules.

And the output reflects that. Not because the AI is bad at React. Because nobody told it how your project works.

What your project knowledge actually consists of

Most developers do not think of their project knowledge as something that can be written down and transferred. It feels too embedded, too contextual, too much like intuition built up over time.

But when you look at what actually constitutes project-specific knowledge for an AI, it breaks down into surprisingly concrete things.

Architectural decisions. Where does logic live? What is the layer structure? What goes in a hook versus a service versus a component? These are not vague preferences. They are decisions your team made and has been following. They can be written as rules.

Naming conventions. What are event handlers called? How are hooks named? What is the pattern for boolean props? What domain language does this project use? These are specific and writable.

Component boundaries. When does a component get split? What is the maximum scope of a single component? What makes something presentational versus container? Again, specific and writable.

Import and module structure. How are features organized? What can import from what? Where do shared utilities live? How are public APIs defined for each feature? Completely writable.

Patterns to use and patterns to avoid. What has your team tried and rejected? What approaches work well in this codebase specifically? What does good look like here, beyond what good looks like in React generally? Writable.

None of this is too contextual or too intuitive to write down. It just has never been written in a form the AI can use before a session starts.

The gap between what the AI knows and what it needs

The AI's React knowledge is genuinely comprehensive. It knows what it knows about React deeply and accurately.

The gap is not in its React knowledge. The gap is in everything that is specific to your project that cannot be derived from general React knowledge alone.

Think about the last time you corrected AI output. What was the correction? Was it a React mistake, something that violated React best practices or introduced a technical error? Or was it a project mismatch, something that was technically fine React but not how things are done in your codebase?

For most developers it is almost always the second category. The AI knows React. What it does not know is your project's specific application of React. And that is the gap that rules close.

Here is what closing that gap looks like in practice:

Project-specific rules that the AI cannot derive from React knowledge alone:
1. Features are self-contained modules. Each feature has its own components, hooks, services, and types folder. External access goes through the feature's index file only. No direct cross-feature imports.
2. State scope is determined before writing any code. Local state stays in the component or a dedicated local hook. Shared state only moves to a global store when two independent features genuinely require it. Auth state is local to the auth feature unless another feature explicitly needs it.
3. Component names reflect what they render, not where they are used. UserCard, not ProfileUserCard. ProductList, not ShopPageProductList. The name travels with the component, not with the page.
4. All API responses are transformed in the service layer before they reach a hook or component. UI components receive domain objects, not API shapes. If the API changes, only the service layer changes.
5. Loading, error, and empty states are defined before building the happy path. No component ships without explicit handling for all three. The pattern for each is consistent across the codebase.

These five rules are not derivable from React knowledge. They are specific to how your project has decided to apply React. Written down and given to the AI before a session starts, they close the gap between what the AI knows about React and what it needs to know about your project.

What changes when the gap is closed

The most immediate change is in the corrections.

The category of correction that accounts for most of the time spent steering AI output — the project mismatch corrections — disappears or shrinks dramatically. The AI is no longer making decisions based on general React knowledge in the absence of specific rules. It is making decisions based on your project's specific application of React.

The components look like they belong. The naming matches what is already there. The structure follows the pattern. The state ends up where you would have put it. The imports follow the module rules.

This is not the AI getting better at React. It is the AI finally having the project knowledge it needed to apply its React knowledge correctly.

Beyond the immediate sessions, something more significant changes over time. The codebase starts to accumulate consistent decisions instead of varied ones. New features look like existing features because the same rules that governed the existing ones governed the new ones. The project develops a coherence that is hard to achieve when every session is working from general knowledge alone.

The session is not the problem. The missing project context is.

Most attempts to improve AI output focus on the prompt. Better descriptions. More detailed instructions. More context included in each request.

These help at the margins. A better prompt produces better output for that specific request. But it does not solve the underlying problem, which is that the AI does not know your project and has to guess at every session-specific decision it makes.

Rules solve the underlying problem. They give the AI the project knowledge it cannot derive from its React training. They close the gap between knowing React and knowing your React project.

Write them before the session. Not in the prompt. In a system that applies them to every session, every developer, every request. And stop spending session after session teaching the AI things it should have known before it started.

The prompt does not matter. The rules do.

Your AI knows React. That knowledge is real and valuable and it makes your sessions faster than building without AI would be.

What your AI does not know is your project. And without rules that transfer that project knowledge, every session is working from general knowledge in a specific context. The output reflects that. Every time.

Write the rules. Give the AI the project knowledge it needs. And close the gap between knowing React and knowing your React project.

Want to find where your React project knowledge is missing from your AI setup?

I built a free 24 point checklist that helps you find exactly that. The specific project decisions that your AI is currently guessing at because nobody wrote them down as rules.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

The prompt doesn't matter. The rules do.

© Avery Labs — Avery Code

Every New Developer Gets an Onboarding Process. The AI They Use Every Day Never Does.

Avery — Mon, 29 Jun 2026 14:17:25 +0000

Onboarding a new developer is a process most teams take seriously.

There are docs. There is a walkthrough of the codebase. Someone explains the architecture, the conventions, the patterns the team has settled on over time. There are code reviews in the first weeks that are more educational than critical. There is an intentional effort to transfer the knowledge that exists in the team's heads into the new developer's understanding.

It takes time. It takes attention. But teams invest in it because they know that a developer who understands the standard produces better work faster than one who has to figure it out alone.

And then that developer opens their AI tool and starts a session. And the AI generates code with no knowledge of any of it.

No architecture walkthrough. No explanation of conventions. No code reviews that transfer the standard. The AI that is about to generate large portions of the new developer's output has received none of the onboarding the developer just went through. It starts from zero. Every session.

What the first week actually looks like without AI onboarding

A new developer joins a React team that has been building for eighteen months.

They spend the first week getting oriented. They read the docs. They look through the codebase. They start to understand how the team structures features, where state belongs, how components are named, what the import conventions are. They ask questions. They get answers. By the end of the week they have a rough mental model of how this team codes.

On day three they use the AI to build something small. The AI generates a component. It is structured differently from everything around it. The naming does not follow the pattern the new developer just spent three days learning. The state management approach is different from what they were told to use.

They are not sure whether to follow the AI's output or the team's standard. The AI generated something. It looks reasonable. But it does not look like the codebase they just spent a week studying.

So they ask a senior developer. The senior developer looks at it and says "yeah, just fix it to match our pattern." The new developer fixes it. The next session starts exactly the same way.

This happens every day for weeks. The new developer is learning the standard. The AI is not. And the new developer is spending a significant portion of their time reconciling the AI's output with the standard they are trying to learn.

Why this is an invisible cost most teams never measure

Teams measure onboarding success by how quickly a new developer becomes productive.

They do not measure how much of that developer's time in the first months is spent correcting AI output that does not match the standard. They do not measure how many pull request comments in the first weeks are about AI-generated inconsistencies rather than logic errors. They do not measure how much cognitive overhead the new developer carries from having to simultaneously learn the standard and correct the AI that does not know it.

Those costs are real. They are just distributed across enough small moments that they never aggregate into something visible.

A new developer who spends twenty minutes a day reconciling AI output with team standards spends over eighty hours in their first year doing something that rules would have eliminated. That is two full weeks of productive time. Gone.

And that is just one developer. Every new developer who joins faces the same invisible tax because the AI was never onboarded.

What the AI actually needs to know

The onboarding that matters for the AI is not the same as the onboarding that matters for the developer.

A developer needs context, history, relationships, judgment. They need to understand why certain decisions were made. They need to know who to ask when something is unclear. They need to develop an intuition for how this particular team thinks.

The AI needs rules. Specific, explicit constraints that define what the output must look like. Not history. Not context. Not judgment. Rules.

The good news is that the rules the AI needs are almost entirely derivable from the things teams explain during developer onboarding. The architecture walkthrough is a set of rules. The explanation of naming conventions is a set of rules. The code review comments that say "we do it this way here" are rules. They just exist in conversations and documents and people's heads instead of in a form the AI can follow.

Translating them takes less time than the onboarding itself. Here is what that looks like for a typical React team:

AI onboarding rules derived from developer onboarding:
1. Feature structure is self-contained. Components, hooks, services, and types live inside the feature folder. Nothing imports directly across feature boundaries.
2. State that belongs to a feature lives in a dedicated hook inside that feature. No state logic in UI components. No shared state unless it is used by at least two independent features.
3. Components are named after what they render, not the page they live on. UserCard, not ProfilePageCard. ProductList, not ShopPageList.
4. Event handlers use the handle prefix. handleSubmit, handleChange, handleClick. Not on, not process, not manage.
5. API contracts live in the service layer. UI components receive already-transformed data. They have no knowledge of API structure.

Five rules. Derived from the same knowledge that gets transferred during developer onboarding. Written down once. Given to the AI before every session. The new developer stops spending their first months reconciling AI output with team standards. The AI follows the standard from session one.

What changes when the AI is onboarded

The new developer's experience changes immediately.

The AI generates components that look like the codebase they are learning. The naming matches what they are being told to use. The structure follows the pattern they are reading in the existing code. Instead of constantly reconciling two different versions of the standard, they see one consistent version in both the existing codebase and the AI's output.

The learning accelerates. Not because the AI is teaching them. Because the AI is reinforcing what the team is already teaching them. Every session produces output that looks like the standard, which means every session is another data point for the new developer about what the standard looks like in practice.

The pull request reviews change too. Instead of comments about AI-generated inconsistencies, the feedback is about logic, product decisions, edge cases. The things that actually require the senior developer's attention and the new developer's growth.

The invisible tax disappears. Not because onboarding got better. Because the AI was finally included in it.

The onboarding that scales

Developer onboarding does not scale easily. Each new developer needs dedicated time, attention, and patience from senior team members. The knowledge transfer is personal and takes weeks.

AI onboarding scales perfectly. Write the rules once. Every new developer who joins uses the same rules. Every session from day one follows the same standard. The knowledge that took weeks to transfer to the developer takes minutes to give to the AI.

Teams that do this find that new developers become productive faster. Not because the onboarding documentation improved. Because the AI that generates large portions of their output is finally working from the same playbook as everyone else on the team.

The prompt does not matter. The rules do.

Your team spends real time and energy onboarding new developers. That investment is worthwhile.

The AI those developers use every day has never been onboarded. It starts each session without any of the knowledge your team just transferred. And it generates code that undermines the standard your new developers are trying to learn.

Write the rules. Give them to the AI before the first session. And stop expecting new developers to bridge the gap between what you taught them and what the AI generates.

The AI can follow the standard. It just needs to be told what it is.

Want to find where your React team is missing the rules that new developers need from day one?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that make every onboarding harder than it needs to be and every AI session a source of inconsistency instead of consistency.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

The Most Expensive AI Standard Problem Is the One You Cannot See Yet.

Avery — Fri, 26 Jun 2026 09:32:27 +0000

The projects that cause the most damage are rarely the ones that look broken.

Broken projects are obvious. The bugs are visible. The team knows something is wrong. The conversation about fixing it has already started.

The expensive projects are the ones that feel fine. The features ship. The reviews pass. The team is productive. Nobody is worried because there is nothing visible to worry about.

Underneath that calm surface the AI has been making decisions without rules for months. And every decision without a rule is a small divergence that compounds quietly until it is not small anymore.

Why the invisible problem is the most expensive one

Visible problems get solved.

A bug gets fixed. A performance issue gets addressed. An architectural problem that is causing pain gets refactored. The pain creates urgency and the urgency creates action.

Invisible problems accumulate.

When the AI is making decisions without rules and the output still works, there is no signal that anything needs attention. The inconsistency grows. The technical debt builds. The codebase slowly becomes harder to work with. But because nothing is broken, nothing triggers a response.

By the time the problem becomes visible it is no longer small. It is distributed across the entire codebase. It is embedded in every feature the AI built without constraints. And fixing it is no longer a one-session refactor. It is a project.

What the calm before looks like

It looks like a productive team.

Features getting shipped. Pull requests getting approved. Velocity feeling good. Nobody is complaining about the codebase because the codebase is working.

What nobody is noticing is that each feature the AI built made slightly different decisions about structure. Each session invented a slightly different approach to state. Each developer who used the AI got slightly different output because the rules that would have made the output consistent were never written.

The divergence is real. It is happening. It is just not visible yet because the codebase has not grown large enough or old enough for the inconsistency to become painful.

That moment is coming. The question is whether the rules exist before it arrives or after.

The best time to define your AI standard is when everything feels fine. Not because something is wrong. Because nothing is wrong yet and the cost of defining it now is a fraction of the cost of fixing what it prevents later.

The compounding problem nobody measures

Technical debt from missing AI standards does not grow linearly. It compounds.

Each session without rules adds inconsistency. Each inconsistency becomes a reference point for the next session. The AI sees what exists and extends it. So the inconsistency that started in one feature slowly influences the features built around it.

A codebase that felt fine at thirty components starts feeling like a problem at a hundred. Not because something changed. Because the accumulated decisions of thirty components without rules are now the foundation that the next seventy are built on.

By a hundred components the refactor is significant. By two hundred it is a project nobody wants to take on.

The teams that define their AI standard when the project is small and healthy are the ones that never have this conversation. Not because they got lucky. Because they solved the problem before it became one.

What defining the standard looks like when nothing is wrong

When nothing is broken, defining the standard feels optional.

There is no pain driving it. No urgent problem to solve. No visible reason to stop and write rules when the features are shipping and the team is productive.

That is exactly why most teams never do it. The window where it is easiest and cheapest to define the standard is the window where it feels least necessary.

Here is what it takes to do it anyway:

Rules worth defining before the problem appears:
1. Where does state live? Define it before the AI decides for you across a hundred components.
2. What is the component boundary rule? Define it before three different answers accumulate across the codebase.
3. What does the naming convention look like? Define it before six variations of the same pattern become the norm.

Three questions. Answered once. Applied to every session from that point forward. The calm that exists now stays calm because the rules prevent the divergence that would have ended it.

The prompt does not matter. The rules do.

The most expensive AI standard problem is not the one you are dealing with today.

It is the one building quietly underneath a codebase that feels fine. The one that will surface in six months or a year as a refactor nobody planned for and a codebase nobody fully understands anymore.

Define the standard now. While the project is healthy. While the cost is low. While the rules can prevent the problem instead of repair it.

Want to find where your React project is accumulating invisible AI standard problems?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that are building quietly underneath a codebase that currently feels fine.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your Code Review Is Working Perfectly. It Just Cannot Catch What Was Never Defined.

Avery — Mon, 22 Jun 2026 10:35:39 +0000

The review process did everything right.

Someone opened the pull request. Someone else read through it carefully. The logic was sound. The tests passed. The naming was reasonable. Nothing obviously wrong. Approved.

Three months later that feature is the one nobody wants to touch. The patterns it introduced do not match anything around it. The state management approach it used became a local convention that contradicts the one two features over. The component boundaries made sense in isolation and make no sense in context.

The review did not fail. It caught what it was designed to catch. The problem is that what it was designed to catch does not include missing AI standards.

What code review is actually for

Code review is a human process designed to catch human mistakes.

Logic errors. Security vulnerabilities. Missing edge cases. Unclear naming that a second pair of eyes catches. Architecture decisions that need discussion. These are the things code review is built to find.

What it is not built to find is the absence of a standard that should have existed before the AI generated anything. A reviewer can see that a component is structured a certain way. They cannot see that the AI made that structural decision because no rule existed to make it differently.

The missing standard is invisible in the code. It only becomes visible over time, when enough sessions have made enough slightly different decisions that the inconsistency becomes impossible to ignore.

By then the review that approved all of it is long forgotten.

The confidence that code review creates

This is the part that makes missing AI standards expensive in a specific way.

When a pull request gets approved, it signals that the code meets the standard. The team has looked at it. The team is satisfied. Everyone moves on with confidence that what was built is correct.

That confidence is not wrong about what was reviewed. It is wrong about what was not reviewed. The review confirmed the logic. It did not confirm that the AI had rules to follow. It did not confirm that the structural decisions the AI made match the ones three features over. It could not confirm those things because they were never defined.

The approval creates confidence in code that has a silent gap underneath it. And silent gaps do not stay silent forever.

A code review tells you the code is correct. It cannot tell you that the standard behind the code exists. Those are two different questions and only one of them gets asked in most review processes.

What happens when the gap surfaces

It usually surfaces during a refactor or a handover.

Someone opens the codebase to extend a feature and realizes the pattern used in that approved pull request from three months ago does not match anything else. They have to decide whether to follow the local pattern or the global one. Either way something is now inconsistent.

Or a new developer joins and tries to understand the codebase by reading through it. They find three different ways of doing the same thing and no indication of which one is correct. All three were approved. None of them was wrong. None of them was the result of a defined standard.

The review worked. The standard was missing before the review ever happened.

Where the gap actually gets closed

Not in the review. Before the session.

The review cannot close a gap that existed before the AI generated anything. It can only catch the symptoms of that gap, and only if the reviewer knows to look for them, which they usually do not because the symptoms look like reasonable code.

The gap closes when the AI has rules that define what the output must look like before any generation happens. When those rules exist the review confirms something different. Not just that the code is correct but that the code follows a standard that was defined before the first line was written.

Here is what that looks like in practice:

Rules that exist before the review:

Component structure follows the presentational or container pattern. Reviewers can verify this against a defined standard.
State placement follows a defined rule. The review confirms compliance, not just correctness.
Naming follows documented conventions. The review catches deviations from something explicit.

The review becomes a compliance check against a known standard instead of a judgment call about whether something reasonable was done.

The prompt does not matter. The rules do.

Your code review process is not the problem. It is doing exactly what it was designed to do.

The problem is that what it was designed to do does not include catching the absence of AI standards. That is not the review's job. That is the rules' job.

Define the standard before the AI generates anything. Let the review confirm what was already defined. And stop expecting the review to catch something that was never defined to begin with.

Want to find where your React project is missing the standards your reviews cannot catch?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that pass every review because they were never defined in the first place.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

My Own Codebase Stopped Feeling Like Mine. Here Is What I Found When I Looked Closer.

Avery — Fri, 19 Jun 2026 07:58:51 +0000

I opened a component I had built with AI a few months earlier.

The logic was right. The feature still worked. But something about it felt unfamiliar. The naming was not how I would have named it. The structure was not how I would have structured it. It worked, and it was technically mine, but it did not feel like something I had built.

I checked the git history just to be sure. I had written it. The AI had generated most of it, and I had reviewed and accepted it at the time. But looking at it now, it read like someone else's code wearing my project's file extension.

What was actually happening

I had been assuming that working with the AI consistently over time would naturally produce something that reflected how I work.

It does not work that way. Each session is its own decision-making process. The AI does not carry forward a sense of "how this developer codes." It carries forward whatever is visible in the current context and generates based on that, plus its own defaults when the context runs out.

So the component I built three months ago reflected whatever made sense to the AI in that specific session, with whatever I had described at the time. The component I built last week reflected a different session, a different prompt, a different set of assumptions about what good output looks like.

Neither was wrong. They were just not the same. And across enough sessions, "not the same" stops feeling like minor variation and starts feeling like the codebase does not have an author anymore.

Why this is different from inconsistency between developers

When a team has inconsistency, you can usually trace it. This part was Sarah's. This part was Alex's. The styles differ because the people differ.

When it is just you and the AI, there is no second person to blame the inconsistency on. It is still your project, still your name on every commit, but the actual decisions about structure and naming and pattern were made by something that has no concept of you specifically.

That is a strange thing to sit with. The codebase is yours in every way that matters legally and professionally. But large parts of how it actually reads were never decided by you. They were decided session by session by a tool that does not retain a sense of your preferences unless you give it one.

Your codebase does not stop feeling like yours because you forgot how you code. It stops feeling like yours because nobody ever told the AI how you code in a way that persisted past a single session.

What it actually took to fix

I did not rewrite the codebase. That was not the point, and it would have taken too long to be worth it.

What I did was sit down and write out the patterns I actually wanted to see. Not abstract principles, but specific decisions:

Components are named after what they render, not after the page they live on.
State that only affects rendering stays local. Anything shared moves to a dedicated hook.
Every exported function has an explicit return type, even when inference would work.

Three rules, in this case, though the list grew over time. Each one was something I already believed about how my code should look. I had just never written it down anywhere the AI could see it before generating something new.

The next few components I built were noticeably closer to what I would have written by hand. Not because the AI got smarter. Because for the first time it had something concrete to follow instead of guessing at what I might want.

The part that surprised me

I expected the rules to make the output more consistent. They did.

What I did not expect was how much it changed the experience of opening old files. Once the rules were in place, new components started to actually look like they belonged next to the ones I wrote without much AI involvement. The project started to read as one thing again, instead of a series of disconnected decisions stitched together by working code.

That is the part that mattered more than I initially gave it credit for. Consistency is not just about avoiding bugs or making code reviews faster. It is about being able to open your own project and recognize it.

If you have noticed your own codebase drifting away from how you actually think, the first place to look is not the code. It is whether you have ever written down, in a form the AI can actually use, what "how you code" means in the first place.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

You Already Know What Your First AI Rule Should Be. You Just Have Not Written It Down Yet.

Avery — Wed, 17 Jun 2026 07:33:00 +0000

Every developer who works with AI regularly has a list of corrections they make.

Not a written list. A mental one. The things they fix after every session. The patterns the AI gets wrong consistently. The naming that never quite matches. The component that always ends up doing too much. The state that keeps ending up in the wrong place.

Those corrections are not random. They are consistent. And consistent corrections are rules that have not been written down yet.

You already know what your first rule should be. You have been communicating it to the AI through corrections for months. You just have not written it down where the AI can follow it before it makes the mistake.

Why the first rule is the hardest

Starting a rule system feels like a big decision.

Where do the rules live? How many do you need? What format should they be in? Do you need a whole system before you start? Do you need to cover every case before the rules are useful?

The answer to all of those questions is the same. You do not need to answer them before you write the first rule.

The first rule does not need to be part of a system. It does not need a format. It does not need to be comprehensive. It just needs to exist somewhere the AI can see it before the session starts.

One rule. The thing you correct most often. Written down. Given to the AI before the next session.

That is the entire starting point.

What the first rule usually is

The first rule is almost always the same category of thing across different developers.

It is the correction that happens in nearly every session. The one that takes two minutes to fix but has been taking two minutes every session for six months. The one that feels too obvious to write down because surely the AI should just know.

It does not just know. It cannot. It has no memory of the last correction. It has no definition of what the standard is. It generates based on what it receives and then you correct what it got wrong.

For most React developers the first rule falls into one of three categories. Component boundaries. State placement. Naming conventions. Not because those are the most important rules. Because those are the decisions the AI gets wrong most consistently when no constraints exist.

Here is what writing that first rule actually looks like:

The first rule for most React developers:
Every component has exactly one responsibility.
If it renders UI and manages state and handles data fetching,
it is three components pretending to be one.
Split before continuing.

One rule. Specific enough to follow. The AI stops making that particular decision on its own.

What happens after the first rule

The first rule does two things.

It reduces the correction it covers. That session, the component is already the right size, or the state is already in the right place, or the naming already follows the convention. The specific correction the rule addressed does not appear.

And it shows you that the system works. That writing a rule down and giving it to the AI actually changes the output. That the problem was never the AI. It was the missing constraint.

That realization is what leads to the second rule. And the third. Not because you planned a system. Because you experienced the result of one rule and wanted more of it.

The system grows from evidence, not from planning.

The rule you keep not writing

Most developers who work with AI regularly have a correction they make so often it has become automatic.

They do it without thinking. They barely notice anymore. It is just part of the workflow.

That correction is a rule. A rule the AI has never been given. A rule that has been communicated through corrections hundreds of times and has never transferred because corrections do not transfer between sessions.

Writing it down takes less time than making the correction one more time.

The prompt does not matter. The rules do.

You do not need a complete system to start. You do not need a format. You do not need to know where this is going.

You need one rule. The one you already know. The one you have been communicating through corrections for months.

Write it down. Give it to the AI before the next session. See what happens.

Everything after that is just doing it again.

Want help identifying what your first rule should be?

I built a free 24 point checklist that helps you find exactly that. The corrections you keep making that are waiting to become rules.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your AI Does Not Have a Naming Convention. It Has a New One Every Time You Start a Session.

Avery — Mon, 15 Jun 2026 08:00:21 +0000

Open any React project where the AI has been generating code for a few months.

Search for how buttons are named. How handlers are named. How hooks are named. How the same concept appears across different features.

Chances are you will find three or four variations of the same thing. Not because different developers made different choices. Because the AI made a different choice every session and nobody defined what the convention was supposed to be.

Naming looks consistent until you look closely. Then it looks like a project with no memory.

Why AI naming drifts

Naming is one of the most context-dependent decisions in code.

What something is called depends on the domain, the existing conventions, the patterns already established in the project, and a shared understanding of what words mean in this specific codebase.

The AI has access to some of that context in each session. It can see the files around the current work. It can infer patterns from what it reads. But it cannot see the entire codebase at once. It cannot remember what it called something three sessions ago. And it has no definition of what the naming convention actually is unless someone wrote it down.

So it invents. Each session produces names that make sense in isolation. Button handler today. Handle button click tomorrow. On button press the session after that.

All reasonable. All different. All adding to a codebase where the same concept has accumulated three names and nobody remembers which one was intentional.

What inconsistent naming actually costs

Naming inconsistency is not a cosmetic problem.

When the same concept has different names in different parts of the codebase, developers spend time figuring out whether they are the same thing or different things. New developers spend longer onboarding because the vocabulary is not consistent. Search becomes unreliable because you have to know which variation to look for.

More subtly, inconsistent naming signals that no standard exists. And a codebase that signals no standard invites more inconsistency. The next developer sees the variation and adds a fourth version because there was no single correct answer to follow.

The AI did not create this problem maliciously. It created it because naming decisions were never defined as rules.

Inconsistent naming is not a sign that the AI is bad at naming. It is a sign that the naming convention was never written down where the AI could find it. The AI names things perfectly consistently within a session. The problem is that sessions do not share memory.

What a naming rule actually looks like

A naming rule does not have to cover every possible case. It has to cover the decisions that keep coming out differently.

The most common variations are usually handlers, hooks, and component props. Those are worth defining explicitly:

Naming rules that eliminate drift:
1. Event handlers are always named handle followed by the action. handleSubmit, handleClick, handleChange. Never on, never process, never manage.
2. Custom hooks are always named use followed by the feature they serve. useUserProfile, useCartItems. Never get, never fetch, never load.
3. Boolean props are always named with is or has as a prefix. isLoading, hasError, isVisible. Never loading, never error, never visible alone.

Three rules. Written once. The AI stops inventing variations because the convention exists before the session starts.

The naming that becomes the codebase vocabulary

When naming rules exist, something interesting happens over time.

The codebase develops a vocabulary. The same words appear in the same patterns across every feature. A new developer joins and learns the vocabulary once. From that point they can navigate any part of the project because the language is consistent.

That vocabulary is not created by the AI. It is created by the rules that define what the AI names things. The AI then applies those rules consistently across every session, every feature, every developer who uses it.

The codebase starts to feel like it has a voice. Like it was written by someone with a clear point of view about what things should be called.

It was. You just had to write that point of view down as rules.

The prompt does not matter. The rules do.

Your AI will name things every session. That is unavoidable.

What is avoidable is letting it invent a new convention every time. Write the naming rules once. Give them to the AI before every session. And stop spending time renaming things that should have been named right the first time.

Want to find where your React project has accumulated naming inconsistency?

I built a free 24 point checklist that helps you find exactly that. The structural gaps where your AI has been inventing conventions instead of following one.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

A Code Review Catches Mistakes. An AI Audit Catches the Missing Rules That Caused Them.

Avery — Fri, 12 Jun 2026 08:23:32 +0000

Code review is good practice.

You look at what was built. You check the logic. You catch the obvious problems. You leave comments about the things that should have been done differently.

And next week the same categories of problems appear in the next pull request.

Not because the developer did not read the comments. Because the AI that generated the code never saw them. And the missing rules that caused the problems in the first place are still missing.

A code review fixes the output. An AI audit fixes the system that produced it.

What a code review cannot do

A code review operates on what already exists.

By the time the review happens the AI has already made its decisions. The component is already too large or the right size. The state is already in the right place or the wrong one. The naming already follows the convention or it does not.

The reviewer can catch these things. They can leave comments. The developer can fix them. But none of that changes what the AI will generate in the next session. Because the review happens after the output. The rules need to happen before it.

A code review is the most expensive place to catch an AI standard problem. The code is already written. The developer already spent time on it. Now both the developer and the reviewer spend more time on something that rules would have prevented.

What an AI audit actually is

An AI audit is not a review of the code. It is a review of the system that generates the code.

It asks different questions. Not "is this component correct?" but "does the AI have a rule that prevents incorrect components?" Not "is this state in the right place?" but "does the AI have a rule that defines where state belongs?"

The audit looks at the gaps. The areas where the AI is making decisions without constraints. The places where every session produces something slightly different because no rule defines what consistent looks like.

Those gaps are the source of the problems that keep appearing in code reviews. Fix the gap and the problem stops appearing. Leave the gap and the code review keeps catching the same thing week after week.

A code review is a symptom report. An AI audit is a root cause analysis. One tells you what went wrong. The other tells you why it keeps going wrong and what to change so it stops.

What an AI audit looks like in practice

It starts with the repeated code review comments.

If you look at the last ten pull requests and certain categories of feedback keep appearing, those categories are your audit starting point. Each repeated comment is a missing rule waiting to be written.

"This component is doing too much" — missing rule about component responsibility.
"State should be in a hook" — missing rule about state placement.
"This naming does not match the convention" — missing rule about naming standards.

The audit turns those comments into rules. Not documentation. Not style guide entries. Rules that exist before the session starts and define what the output must look like.

Here is what that process looks like:

AI audit findings turned into rules:
1. Components have one responsibility. If the review keeps catching this, the rule was missing.
2. State lives in dedicated hooks. If the review keeps moving state, the rule was missing.
3. Names follow domain language. If the review keeps renaming things, the rule was missing.

The audit finds the gaps. The rules close them. The code review stops catching the same things.

The audit that pays for itself immediately

Most developers spend more time in code review than they realize enforcing standards the AI never had.

An AI audit takes a fraction of that time. You look at what keeps going wrong. You write the rules that prevent it. You give them to the AI before the next session.

The payoff is immediate. The next pull request does not have the comments the audit addressed. The review gets shorter. The developer spends less time on corrections. The reviewer spends less time on the same feedback.

One audit. Compounding returns across every session that follows.

The prompt does not matter. The rules do.

Code review will always exist. It is the right place to catch logic errors, discuss product decisions, and share knowledge.

It is the wrong place to enforce AI standards. That is what the audit is for.

Audit the system. Find the missing rules. Write them down. And let the code review be about the work that actually requires human judgment.

Want to run an AI audit on your React project right now?

I built a free 24 point checklist that covers exactly that. The structural gaps where your AI has been making decisions without rules and your code reviews have been paying the price.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

The Day I Stopped Thinking About My AI Was the Day the System Finally Worked.

Avery — Wed, 10 Jun 2026 07:00:00 +0000

There was a period where working with AI felt like a second job.

Every session required active management. What context does it need? What patterns should I describe? What will it get wrong this time? How do I phrase this so it does not drift?

The thinking was constant. Not about the feature I was building. About the AI building it. About how to get the output close enough to acceptable that the corrections would not take too long.

Then one day I opened a session, wrote a short prompt, and the output was exactly what it should have been.

I did not think about it. I just moved on.

That was the day I realized the system was finally working.

What it means to stop thinking about your AI

Stopping thinking about your AI does not mean ignoring it.

It means the standard is so consistently applied that you no longer have to hold it in your head during every session. The rules handle it. The output reflects them. Your attention is free for the actual problem.

Before that point every session cost cognitive overhead. Is this component structured right? Is the state in the right place? Does this naming follow the convention? Those are not hard questions. But they are questions that take attention. And attention spent on standards is attention not spent on building.

When the rules exist and the AI follows them, those questions stop being your job. They become the system's job. And you get your attention back.

Why this matters more than better output

Most conversations about AI rules focus on output quality. Cleaner code. More consistent structure. Fewer corrections.

Those things are real and they matter. But the deeper gain is cognitive.

A developer who does not have to think about whether the AI will follow the standard has more mental space for everything else. For the architecture decision that actually requires judgment. For the edge case that needs careful thinking. For the product question that no rule can answer.

The rules do not just improve the code. They change where your attention goes. And attention is the most limited resource in any development workflow.

The goal of an AI rule system is not just consistent output. It is consistent output that requires no active management. When you reach that point the AI stops being something you work with and starts being something that works for you.

What the transition actually felt like

It did not happen all at once.

The first rules reduced the most common corrections. The second set of rules reduced the next most common ones. Each rule added was one less thing to think about during a session.

At some point there was a threshold. The rules covered enough of the standard that the remaining decisions were genuinely interesting ones. The kind that required judgment, not just convention enforcement.

That is when the sessions changed. Not faster exactly. But lighter. The mental load of each session dropped because the AI was handling the standard and I was handling everything else.

Here is what that looked like in terms of rules:

Rules that gave me my attention back:
1. Structure is always feature-based. I stopped thinking about where things go.
2. State always lives in hooks. I stopped thinking about whether it was in the right place.
3. Naming always follows domain language. I stopped thinking about whether names were clear enough.

Three rules. Three categories of thinking I no longer do during sessions. The attention they freed went to better places.

The system working for you instead of with you

There is a difference between working with an AI and having an AI that works for you.

Working with an AI means active management. Constant steering. Corrections after every generation. The AI as a capable but undirected tool that needs guidance every session.

Having an AI that works for you means the direction is already defined. The rules exist. The standard is applied automatically. You show up, describe the problem, and the output fits the project.

That transition does not happen by accident. It happens when the rules are comprehensive enough that the AI stops needing to guess.

The prompt does not matter. The rules do.

The cognitive overhead of working with AI without rules is real and it compounds.

Every session you spend thinking about whether the AI will follow the standard is a session where the standard was not given to the AI before it started.

Write the rules. Build the system. And get to the point where the AI handles the standard so completely that you stop having to think about it.

That is when the work gets interesting again.

Want to find which standards you are still thinking about that should already be rules?

I built a free 24 point checklist that helps you find exactly that. The areas where your attention is still doing work that rules could handle automatically.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your AI Produces Its Worst React Code Exactly When You Need Its Best.

Avery — Mon, 08 Jun 2026 11:50:24 +0000

Deadline pressure changes how you work with AI.

The prompts get shorter. The reviews get faster. The corrections get skipped. There is no time to steer the AI toward the standard. There is barely time to check if the output works.

And the AI, sensing none of this pressure, generates exactly what it always generates without rules. Which on a normal day is inconsistent. Under deadline pressure, with shorter prompts and less context, is worse.

The code ships. The deadline is met. And somewhere in the codebase there is now a feature that looks nothing like everything around it.

Why deadline pressure makes AI output worse

On a normal day you give the AI context. You describe the existing patterns. You correct when it drifts. You spend the time it takes to get output that fits the project.

Under pressure none of that happens.

The prompt is three words instead of three paragraphs. The context is minimal. The review is a quick scan for obvious errors. The corrections that would have brought the output in line with the standard get skipped because there is no time.

The AI has no way of knowing the difference. It generates based on what it receives. Less context, shorter prompt, no corrections means more improvisation. And improvisation under pressure produces the AI's best guess at what working code looks like, not what your project's standard looks like.

The deadline does not change what the AI does. It changes what you give it to work with. And what you give it under pressure is almost always less than what you give it on a normal day.

The pattern most developers recognize but never solve

Deadline code looks different. Every developer who has shipped under pressure knows this.

It is not that the code is wrong. It is that it feels rushed. The naming is less careful. The structure is less deliberate. The patterns are less consistent with everything around them.

With AI in the workflow that feeling is amplified. Because the AI's output reflects the quality of the input it received. And the input it received under pressure was minimal.

The result is features that work but stand out. Code that passes review because everyone is moving fast but that the next developer to touch it will immediately recognize as deadline code.

Deadline pressure does not reveal a weakness in your AI. It reveals the absence of rules. Rules do not care about deadlines. They apply the same standard to a three word prompt as they do to a three paragraph one.

What rules do under pressure

When rules exist before the session starts, the length of the prompt stops mattering as much.

A three word prompt under deadline pressure produces the same structured output as a three paragraph prompt on a normal day. Not because the AI understood more. Because the rules defined what the output must look like regardless of how much context the prompt provided.

The component still has one responsibility. The state still lives in a hook. The naming still follows the convention. Not because you had time to enforce it. Because the rules enforce it automatically.

Here is what that looks like in practice:

Rules that hold up under deadline pressure:
1. Every component has one responsibility regardless of how the prompt is phrased.
2. State logic goes into a hook before any UI is written. No exceptions under time pressure.
3. Names follow the existing convention. No placeholder names that will need renaming later.

Three rules. They do not know it is a deadline. They apply the same standard they always do.

The code that survives the deadline

Deadline code without rules becomes the feature nobody wants to touch later.

Deadline code with rules becomes just another feature. One that happens to have been built under pressure but does not look like it. One that the next developer can extend without having to first understand what shortcuts were taken.

That is what rules give you under pressure. Not better AI output in the sense of more creative or more sophisticated. Just consistent AI output. The same standard. Every session. Including the ones where everything is on fire.

The prompt does not matter. The rules do.

Pressure will come. Deadlines will compress your workflow. The time you have to work with your AI will shrink.

The rules do not compress with it.

Write them before the pressure arrives. Apply them before every session. And stop shipping deadline code that looks different from everything else because the AI had less to work with when it mattered most.

Want to find where your React project is most vulnerable when deadline pressure hits?

I built a free 24 point checklist that helps you find exactly that. The structural gaps that become expensive exactly when you have the least time to deal with them.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your React App Has an Architecture. Nobody on Your Team Chose It. The AI Did.

Avery — Fri, 05 Jun 2026 07:59:40 +0000

At some point in every React project someone asks: why is it structured this way?

And nobody has a good answer.

Not because the decision was wrong. But because there was no decision. The structure grew. One session at a time. Each AI generation adding something that made sense in that moment but was never part of a deliberate architectural choice.

The architecture exists. It just was not designed.

How an undesigned architecture gets built

It starts with the first session.

The AI generates a component. It puts it somewhere. It creates a file structure that made sense for that specific request. Nobody stops to ask whether this is where things should live long term. The feature works. The session ends.

The next session builds on top of it. Not because the structure was right. Because it was there. The AI sees what exists and extends it. A new feature gets a folder. A new hook gets placed next to the last one. A new service gets added wherever there was space.

Over enough sessions the codebase has a structure. A folder hierarchy. A pattern for where things live. An implicit architecture that every new session reinforces because it already exists.

Nobody designed it. The AI assembled it from the accumulated decisions of every session that came before.

Why this matters more than most developers realize

An undesigned architecture is not necessarily broken. It might even work well for a while.

The problem is that it was optimized for nothing. Not for scalability. Not for team navigation. Not for the domain it represents. It was optimized for whatever was easiest to generate in each individual session.

That means every decision the architecture reflects was the AI's path of least resistance, not your team's deliberate choice. And path of least resistance architectures do not age well.

New developers struggle to navigate them because there is no logic to learn, only history to trace. Features become harder to add because the structure was never designed to accommodate growth. Refactors become expensive because the architecture is everywhere and nowhere at the same time.

An architecture the AI invented is not wrong because it is bad. It is wrong because it was never yours. And a codebase that nobody deliberately designed is a codebase that nobody fully understands.

What a deliberate architecture looks like

A deliberate architecture starts with rules that define where things live before the AI generates anything.

Not a full architectural document. Not weeks of planning. Just enough rules to answer the questions the AI will otherwise answer on its own.

Where do components live? How are features organized? What is the boundary between UI and business logic? How do different parts of the app communicate?

Rules like these turn architectural decisions into constraints the AI follows:

Architecture rules that replace AI decisions:
1. Features are self-contained folders with components, hooks, services, and types inside.
2. Shared code lives in a dedicated shared folder. Nothing cross-imports between features directly.
3. UI components never know about API structure. Data transformation happens in services.

Three rules. Applied before the first session. The AI stops inventing the architecture and starts building inside one you chose.

Taking back the architecture

Most projects reach a point where the undesigned architecture becomes a problem. The refactor is considered. The conversation about structure finally happens.

That conversation is valuable. But it is expensive when it happens after the architecture already exists everywhere.

The same conversation before the first session takes twenty minutes and costs nothing. The AI follows the outcome of that conversation in every session after it.

That is the difference between an architecture you chose and an architecture the AI assembled without anyone asking it to.

The prompt does not matter. The rules do.

Your React project has an architecture whether you designed it or not.

The question is whether it reflects deliberate decisions about how your application should be structured or accumulated AI decisions about what was easiest to generate.

Design it first. Write it as rules. Give it to the AI before it builds anything. And stop inheriting an architecture nobody chose.

Want to find where your React architecture was invented by the AI instead of designed by you?

I built a free 24 point checklist that helps you find exactly that. The structural gaps where the AI has been making architectural decisions on your behalf.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

The Refactor Took Three Days. The AI Undid It in One Session.

Avery — Wed, 03 Jun 2026 08:28:40 +0000

You know the feeling.

Three days of careful work. Moving logic to the right place. Splitting components that had grown too large. Establishing naming that actually made sense. Cleaning up the state management that had accumulated across too many sessions.

The codebase finally looked the way it should have looked from the start.

Then a new feature request came in. You opened a session. The AI generated the first component.

And it looked exactly like the codebase before the refactor.

Why refactoring without rules does not hold

A refactor changes what exists. It does not change how new things get built.

When you refactor a React project you are correcting the accumulated decisions of every session that came before. You are imposing a standard on a codebase that never had one.

But the AI that builds the next feature does not know about the refactor. It does not know that you spent three days establishing a pattern. It does not know that components should now be split differently, that state should now live somewhere specific, that imports should now follow a particular convention.

It generates based on what it can see and what constraints exist. If the constraints are the same as before the refactor, the output will be the same as before the refactor.

The refactor cleaned the past. The rules were never written down to protect the future.

The cycle most developers do not realize they are in

Refactor. Build with AI. Watch the standard erode. Refactor again.

It feels like progress because each refactor genuinely improves things. But the improvement does not compound. It resets. Because the underlying cause — the AI making its own decisions without rules — never changed.

The three days you spent refactoring were not wasted. But they were not invested either. They were spent. And the next session spent them again on the other side.

A refactor without rules is a correction that expires. The AI will rebuild what you cleaned up the moment it generates something new without constraints to follow.

What makes a refactor permanent

The refactor becomes permanent when the standard it establishes gets written down as rules the AI follows going forward.

Not documentation. Not comments in the code. Rules that exist before the session starts and define what every new piece of output must look like.

When you finish a refactor, the question is not just "does the codebase look better?" It is "have I given the AI the rules it needs to not undo this?"

Here is what that looks like in practice:

Rules written after the last refactor:
1. Components above 200 lines get split before the session continues. No exceptions.
2. Every new feature gets a dedicated hook before the UI component is built.
3. Imports always go through the feature index file. No direct cross-feature imports.

These were the patterns the refactor established. Writing them down took twenty minutes. They have held up across every session since.

The refactor you will not have to do again

Most developers refactor reactively. The codebase drifts, the pain becomes too great, the refactor happens.

With rules in place the drift stops. Not because the AI became better at guessing. Because the AI stopped guessing and started following.

The next feature looks like the refactored codebase because the rules define that it must. Not approximately. Exactly.

That is the refactor you do not have to do again. Not because the codebase never changes. Because the standard that the refactor established now travels with every session that comes after it.

The prompt does not matter. The rules do.

Three days of refactoring deserve more than one session to undo them.

Write the standard down. Give it to the AI before the next session starts. And stop refactoring the same codebase over and over because the rules that would protect it were never written down.

Want to find which parts of your React project are one AI session away from needing another refactor?

I built a free 24 point checklist that helps you find exactly that. The structural gaps the AI will fill with its own decisions the moment you give it something new to build.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System