DEV Community: Avery

Index as Key Is Not a Knowledge Problem. Your AI Already Knows the Rule. It Just Does Not Always Follow It.

Avery — Mon, 10 Aug 2026 15:50:50 +0000

Ask any AI coding assistant directly whether using array index as a React key is a good idea, and it will tell you no. It will explain why. Reordering, insertion, and deletion of list items can cause React to misidentify which DOM node corresponds to which data, leading to state bugs and unnecessary re-renders. This is not obscure knowledge. It is one of the most commonly repeated pieces of React advice that exists, and every model has clearly seen it thousands of times during training.

And yet, if you look through a codebase where the AI generated a meaningful portion of the list rendering, you will very likely find at least one instance of exactly this pattern. A map over an array, using the index as the key prop, sitting quietly in a component that otherwise looks perfectly reasonable.

This is a strange thing to observe once you notice it. The AI is not confused about the rule. Ask it directly and it recites the correct answer immediately and confidently. But somewhere between knowing the rule in the abstract and applying it consistently during generation, something gets lost.

Why knowing a rule and applying it are different things

There is a meaningful difference between an AI model having encountered information during training and that information reliably surfacing during every relevant generation task.

When you ask directly whether index as key is a good idea, you are prompting the model to retrieve and state a fact it has strong, well reinforced associations with. This is a different cognitive task than generating a list rendering component from scratch while simultaneously handling several other decisions about structure, naming, data shape, and styling.

During active generation, the model is not running through a checklist of best practices for every line it writes. It is producing output token by token based on patterns, and in the moment of writing a map function, the path of least resistance is often exactly the pattern that gets flagged as wrong when examined afterward. Using item.id as a key requires the data to reliably have a stable id field, requires the model to correctly identify which field serves that purpose, and requires slightly more consideration than reaching for the index, which is always available and always simple.

The rule is not forgotten. It is simply not the strongest pull during the specific moment of generating this specific line of code, especially when the data shape is ambiguous or when generation is happening quickly across a larger component.

Where this actually shows up

The pattern tends to appear in a few predictable situations rather than randomly across all list rendering.

It shows up most often when the data being mapped does not have an obviously named unique identifier readily visible in the immediate context. A list of strings. A list of objects where the unique field is called something other than the expected id or key. A list assembled from a transformation where the original identifier got dropped somewhere in the pipeline.

It shows up when the component is being generated as part of a larger request, where the list rendering is a small piece of a bigger component and gets less individual attention than it would if it were the sole focus of the prompt.

It shows up in draft or placeholder-feeling code, static lists, dummy data, early stage components where correctness feels less pressing in the moment of generation, even though these components frequently end up shipping unchanged.

None of these situations involve the AI forgetting the rule exists. They involve situations where correctly applying the rule requires slightly more work than the shortcut, and nothing in the generation process forces that extra work to happen.

Why asking for better prompts does not fully solve this

A natural response is to just include the instruction in the prompt. Do not use index as key, use a proper unique identifier. This helps in the specific session where it is included, the same way any explicit instruction helps for that one request.

But this does not solve the underlying pattern for the same reason that most single-session fixes do not solve recurring problems. The instruction has to be remembered and re-included every time list rendering comes up, across every developer using the AI on the project, across every session, indefinitely. Miss it once, in one prompt, in one session, and the shortcut reappears.

This is different from the AI not knowing the rule. It is the rule not being present at the moment it needs to apply, because presence in a specific prompt is not the same as presence as a standing constraint that applies regardless of what that day's prompt happened to include.

What actually closes the gap

The fix is not teaching the AI something it does not know. It already knows. The fix is removing the situation where knowing the rule and applying it under generation pressure can diverge.

This means being specific about what counts as an acceptable key, not just stating the negative rule about what to avoid. A rule that says do not use index as key is less effective than a rule that specifies exactly what to use instead and what to do when the obvious identifier is missing.

Key selection rule for list rendering:
1. Every list item requires a unique, stable identifier that persists across re-renders, insertions, and deletions of other items in the list.
2. If the data object has an id field, or any field that is guaranteed unique and stable, use that field directly as the key.
3. If no such field exists in the data, generate one during data transformation before the list reaches the rendering component, not as an inline fallback during the map call itself.
4. Index as key is acceptable only for lists that are static, never reordered, never filtered, and never have items inserted or removed during the component's lifetime. This is a narrow exception, not a default.
5. When uncertain whether a list qualifies for the exception in rule four, treat it as not qualifying and require a proper identifier.

This rule does something the general knowledge did not. It removes the ambiguity about what to do when the obvious id field is missing, which is exactly the situation where the shortcut tends to appear. Instead of the model having to decide in the moment whether this particular list is an exception, the rule states that uncertainty defaults to requiring a real identifier.

Why the specificity matters more than the reminder

A rule that just says avoid index as keys functions as a reminder of something already known. A rule that specifies exactly what qualifies as acceptable, what does not, and what to do when the data does not have an obvious answer functions as a decision procedure.

The difference matters because the actual failure point was never a lack of awareness. It was the absence of a clear procedure for the ambiguous cases, the ones where the ideal identifier is not immediately obvious and a decision has to be made quickly during generation. General awareness does not resolve ambiguity. A specific procedure does.

This pattern generalizes beyond this one example. Anywhere the AI demonstrably knows a rule when asked directly but inconsistently applies it during generation, the fix is rarely restating the rule more forcefully. It is usually making the rule specific enough that it resolves the exact situations where the shortcut becomes tempting, rather than leaving those situations as judgment calls.

What changed after adding the specific rule

Since adding the more detailed key selection rule rather than just a blanket reminder, index as key stopped appearing in generated list rendering, including in the ambiguous cases that used to produce it most often. Lists without an obvious id field now consistently get a generated identifier during data transformation rather than falling back to the index inline.

The interesting part is that this did not require teaching the AI anything new about why index as key causes problems. That knowledge was never missing. What changed was removing the specific decision point where the shortcut used to win by default.

The prompt does not matter. The rules do.

Your AI is not confused about index as key. It has known the rule since before you started this project and it will tell you so if you ask it directly.

The gap is not knowledge. It is the absence of a specific procedure for the exact situations where applying that knowledge requires more effort than skipping it. A general reminder does not close that gap. A specific rule about what counts as an acceptable identifier, and what to do when one is not obvious, does.

Look for the other places in your project where the AI would give you the correct answer if asked directly but does not consistently apply it during generation. Those are not knowledge gaps. They are missing decision procedures, and they are usually easier to fix than they first appear.

Want to find where your React project has knowledge gaps versus procedure gaps?

I built a free 24 point checklist that helps you identify exactly that. The structural decisions where a general rule is not enough and a specific procedure is missing.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

I Found Four Different Solutions to the Same Prop Drilling Problem in One Codebase. All Written by AI.

Avery — Wed, 05 Aug 2026 11:44:21 +0000

I was looking for a specific piece of state logic and ended up finding something more interesting instead.

Four components in the same project were passing data down through their children. Same underlying problem in every case. A piece of state needed several levels below where it originated. Classic prop drilling, the kind every React developer has run into at some point.

What caught my attention was that each of the four instances solved it differently. One used React Context. One used a composition pattern, passing components as children instead of passing data as props. One just kept passing the props down through four levels without addressing it at all. One introduced a small state management library that was not used anywhere else in the project.

Four different solutions. Same problem. Same codebase. No consistency between any of them.

None of the four solutions was wrong exactly. Context is a legitimate answer to prop drilling. So is composition. So is a state library in the right circumstances. Even just passing props through multiple levels is defensible when the chain is short. But having all four approaches scattered across one project, with no indication of when each one applies, is not a technical problem. It is a standard problem.

Why this particular pattern reveals so much

Prop drilling is a good lens for understanding how AI makes architectural decisions, because it does not have one correct answer. Unlike something with a clear right and wrong way to do it, prop drilling has several legitimate solutions, and the correct choice depends on context that is specific to your project rather than universal to React.

Context is a good solution when the data is genuinely global to a subtree, changes infrequently, and does not need fine grained update control. Composition is a good solution when the components in between do not actually need the data themselves, they are just structurally in the way. A dedicated state management approach makes sense when the state has complex update logic or needs to be accessed from many unrelated parts of the tree. And sometimes just passing props through two or three levels is genuinely fine and does not need a more sophisticated solution at all.

All four of these are correct in the right circumstances. The AI has been trained on enough React code to know all four patterns exist and roughly when each one tends to get used. What it does not have is a rule specific to your project about which one your project prefers, or under what threshold prop drilling stops being fine and starts needing a different pattern.

Without that rule, every session makes an independent judgment call. And because the judgment call depends on subtle context, session to session variance is almost guaranteed.

What actually happens during four separate sessions

Session one. A component three levels deep needs a piece of user data. The AI, working from whatever context is visible in that session, decides Context makes sense here. It wraps the relevant subtree in a Context Provider and consumes it three levels down.

Session two, weeks later, working on a different feature. A different component four levels deep needs a piece of data. The Context solution from session one is not visible in the current context window, or the AI does not connect this situation to that one. It decides composition is cleaner here, restructures the component tree so the data-needing component receives its content as a child prop instead.

Session three. Another instance of the same underlying problem. This time the component chain is shorter, only two levels, so the AI just passes the prop through directly without introducing any additional pattern. Reasonable, in isolation.

Session four. A more complex case, several pieces of related state needing to reach multiple deeply nested components. The AI reaches for a small state management solution because the complexity seems to warrant it, even though nothing else in the project uses that approach.

Look at each of these individually and every decision is locally reasonable. The AI is not confused or making mistakes. It is applying its general React knowledge to each specific situation as it encounters it, without any awareness of how the previous three situations were handled.

The problem only becomes visible when you look at all four together, which is exactly the kind of visibility that individual sessions never have.

Why more context does not fix this specific problem

This is a case where the context and rules distinction becomes very concrete. Even with full access to the codebase, more context does not solve the prop drilling inconsistency, because the codebase itself already contains four different answers.

If the AI has access to all four existing solutions when it encounters a fifth instance of the pattern, it does not have a clear signal about which one to follow. It has four examples showing four different approaches. Averaging across them or picking whichever one seems most similar to the current situation does not produce consistency. It produces a fifth variation, or at best, a coin flip between the four that already exist.

This is different from a situation where context genuinely helps, like naming conventions where the existing codebase mostly shows one consistent pattern and the AI can reasonably infer and follow it. Prop drilling in this project had no consistent pattern to infer from. The inconsistency itself is what makes context unable to resolve the problem.

Only an explicit rule breaks the tie. Something that says, independent of what the existing code happens to show, this is the threshold and this is the pattern above that threshold.

What an actual rule looks like for this specific problem

The rule does not need to ban three of the four approaches entirely. It needs to define when each one applies, so the decision stops being a fresh judgment call every session.

Here is a rule that resolves the ambiguity for prop drilling specifically:

Prop drilling resolution rule:
1. Props passed through one or two levels are acceptable without any additional pattern. Do not introduce Context or composition for chains this short.
2. Props passed through three or more levels, where the intermediate components do not use the data themselves, get restructured using composition. Pass the deeply nested content as children rather than threading the data as props.
3. Data that is genuinely needed by multiple unrelated components across a subtree, rather than just passed through structurally, uses Context. This applies when three or more sibling branches of the tree need independent access to the same data.
4. Complex state with multiple related pieces, frequent updates, or logic beyond simple value storage uses the project's established state management approach, not an ad hoc alternative introduced for this one case.

Four situations, four clear answers. Not because three of the four legitimate patterns are wrong, but because the rule specifies exactly when each one is the right one for this project. The AI is no longer choosing based on whatever seems locally reasonable. It is checking the rule and applying the answer that has already been decided.

The pattern this reveals beyond prop drilling

Prop drilling happens to be a clean example because it has several genuinely correct answers that depend on context. But the same dynamic applies to any React decision that has more than one legitimate solution.

Conditional rendering has several valid approaches. Ternary expressions, short-circuit evaluation, early returns, separate component variants. All correct in different circumstances. Without a rule specifying when each applies, expect the same session-to-session variance that prop drilling showed.

Data fetching patterns have several valid approaches depending on whether the data is needed on initial render, needs caching, needs revalidation, or is fetched in response to user interaction. Without a rule, expect a different pattern chosen based on whatever seems reasonable in each specific session.

Form handling has several valid approaches, from fully controlled components to uncontrolled refs to third party form libraries. Same story.

Any React decision with more than one textbook-correct answer is a decision that will drift unless a rule specifies which answer applies under which conditions in your specific project. This is a broader category than most developers realize when they first start writing rules, because the instinct is to write rules for things that are obviously wrong. The actual highest value rules are often for things that are not wrong, just inconsistent, because those are exactly the decisions where the AI has multiple correct options and no way to know which one you want.

What changed after writing the rule

Going back through sessions after the prop drilling rule was in place, the pattern was noticeably different. New instances of the same underlying problem consistently resolved the same way, based on the threshold defined in the rule rather than whatever seemed reasonable in that specific session.

More importantly, the decision stopped requiring active review. Before the rule existed, every new instance of prop drilling needed a moment of evaluation during code review, checking whether this particular solution made sense or whether it should have been handled differently given what the rest of the codebase does. After the rule existed, the review could simply check compliance with the defined threshold, which is a much faster and more mechanical check than evaluating whether an architectural judgment call was reasonable.

The four existing inconsistent instances did not fix themselves. Rules apply going forward, not retroactively. But no new instances of the inconsistency have appeared since, which is the actual goal. Preventing new instances of the drift matters more than immediately correcting the ones that already accumulated, because the accumulated ones are a known, bounded cost while ongoing drift is unbounded.

The prompt doesn't matter. The rules do.

Prop drilling is not a hard problem. React developers have known how to solve it for years, and the AI knows all the standard solutions as well as any experienced developer would.

The inconsistency does not come from the AI lacking knowledge about how to solve prop drilling. It comes from the AI having multiple correct options and no project-specific rule about which one applies when. That gap exists for prop drilling and it exists for every other React decision that has more than one legitimate answer.

Find the decisions in your project with more than one correct solution. Write down which solution applies under which conditions. And stop letting each session make an independent, locally reasonable choice that turns out to be different from the choice made three sessions ago.

Want to find where your React project has multiple valid patterns doing the same job differently?

I built a free 24 point checklist that helps you identify exactly that. The structural gaps where more than one correct solution exists and no rule specifies which one your project actually uses.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

You Think Senior Developers Prompt Better. They Just Stopped Hoping the AI Would Guess Right.

Avery — Mon, 27 Jul 2026 15:00:45 +0000

There is a common belief about why experienced developers get better results from AI. The belief is that they write better prompts. More precise instructions. Better context. A sharper sense of how to phrase a request so the model understands what is actually needed.

This belief is not entirely wrong, but it misses the actual mechanism behind the difference. Watch a senior developer work with AI over an extended period and the pattern that emerges is not primarily about prompt quality. It is about what happens before the prompt gets written at all.

Junior developers tend to approach each session as a fresh negotiation. Write a prompt, see what comes back, correct what is wrong, ask again if needed. This is a reasonable way to work when you do not yet know what tends to go wrong repeatedly. Every project feels new. Every session is its own isolated interaction.

Senior developers, after enough repetitions of the same corrections, stop treating each session as a fresh negotiation. They notice the same categories of mistake appearing across projects and across time, and instead of continuing to correct them one at a time, they write the correction down once and stop hoping the AI will guess correctly going forward.

The specific moment where the shift happens

This shift does not happen because someone reads an article about AI rules and decides to try it. It happens because a developer accumulates enough frustration with the same correction to finally write it down.

The pattern looks something like this. A developer notices that the AI keeps putting state in the wrong place. They correct it. Next session, same mistake, different component. They correct it again. This repeats for weeks or months, and at some point the developer has corrected this specific mistake so many times that continuing to correct it manually starts to feel absurd.

That moment of absurdity is the actual trigger. Not a decision to become more disciplined about writing rules. A recognition that the correction has become so repetitive that writing it down once is obviously less effort than correcting it forever.

Junior developers have not yet accumulated enough repetitions to reach that moment. Every mistake still feels somewhat novel because they have not been doing this long enough to recognize the pattern. Senior developers have usually made the same category of correction often enough, across enough different codebases, that the pattern becomes impossible to ignore.

This is why the difference looks like experience from the outside. It correlates with experience because experience is what generates the repetition needed to notice the pattern. But the actual mechanism is not years of practice improving prompt-writing skill. It is enough repeated corrections to finally stop correcting manually and write the rule instead.

Why hoping the AI will guess right is the default state

Every developer starts in the same place, whether they realize it or not. The default assumption when working with AI is that better communication will eventually produce better results. If the output is wrong, the natural response is to explain more clearly, add more context, phrase the request differently.

This assumption is not unreasonable on its face. Communication genuinely does affect output quality in the moment. A clearer prompt does produce a more accurate response to that specific request.

What this assumption misses is that clearer communication in the prompt does not persist to the next session. Every session starts from the same baseline regardless of how well the previous session was communicated. The clarity you achieved in one prompt does not carry forward. It has to be recreated every time, in every session, for every developer who works on the project.

Hoping the AI will guess right, even with better prompts, means hoping that this specific session's communication will happen to land on the right decision. Across enough sessions, across enough developers, across enough different types of components and features, some percentage of those hopes will not pan out. And the corrections required to fix the ones that do not pan out accumulate exactly as fast as the sessions themselves.

Senior developers do not have some special ability to communicate more clearly that eliminates this. They have simply stopped relying on communication clarity as the mechanism for consistency, because they have seen it fail to produce consistency often enough.

What replaces the hoping

The alternative to hoping the AI guesses right is removing the guess entirely. This is the actual practice that experienced developers converge on, whether or not they frame it explicitly as writing rules.

It looks like maintaining a running list of the corrections that keep recurring, and periodically converting the most frequent ones into explicit constraints that get provided before any session starts. Not instructions embedded in a single prompt, but standing context that applies to every session regardless of what that session's specific prompt says.

The practical difference is significant. A prompt that says please keep components small is a hope. A rule that says components exceeding two hundred lines must be split before continuing, applied consistently across every session, is a removal of the guess. The AI is not being asked to interpret what small means in this context. It has an explicit threshold and an explicit action.

Here is what this looks like as an actual practice, based on what tends to recur across most React codebases regardless of team or project:

Corrections that become rules once they recur enough:
1. State placement. After correcting this the same way enough times, the rule becomes explicit: any state used by more than one component moves to a dedicated hook, not scattered useState calls, and this applies before any component gets written, not as a fix afterward.
2. Prop drilling versus context. Once a developer has manually flagged this the same way enough times, the threshold gets written down explicitly instead of evaluated fresh every session: props passed through more than two levels get reconsidered for context or composition before continuing.
3. Naming inconsistency. After noticing the same concept named three different ways across a project one too many times, the domain vocabulary gets documented explicitly so the AI is never guessing at which word applies.
4. Error handling gaps. Once a developer has added the same try-catch pattern manually enough times, the requirement becomes explicit: every async operation handles its error state before the component is considered complete.

None of these represent a fundamentally different skill from what junior developers have access to. They represent the accumulated result of noticing the same problem enough times to stop treating it as something to fix individually.

Why this looks like a skill gap but is not one

The reason this gets attributed to seniority is that seniority is genuinely correlated with having encountered these patterns more often. A developer with five years of experience has had more opportunities to notice the same recurring mistake than a developer with six months of experience.

But the actual capability being described is not a skill that takes years to develop. It is a decision to stop correcting the same thing repeatedly and write it down instead. A developer with six months of experience who notices this pattern early and starts writing rules will get the same benefit as a developer with five years who has been correcting manually the entire time without ever converting the corrections into explicit rules.

This matters because it means the gap is closeable much faster than the skill narrative suggests. If the difference were genuinely about prompt-writing ability developed through years of practice, there would be no way to shortcut it. But because the actual difference is about whether recurring corrections get written down as rules, any developer can close the gap by deliberately tracking what they correct and converting the patterns into explicit constraints, without needing years of accumulated repetition first.

What actually changes once the rules exist

The most noticeable change is not in any single session. It is in the aggregate pattern across weeks and months. The same categories of correction stop appearing. Not because the AI got smarter, but because the decisions that used to be guessed at freshly every session are no longer being guessed at.

This frees up attention for the things that genuinely do require judgment in each specific case. The product logic. The edge cases that are actually unique to this feature. The architectural decisions that are genuinely ambiguous rather than recurring patterns that should have been standardized long ago.

Developers who reach this state describe the shift less as their prompts becoming better and more as their sessions becoming less exhausting. The mental overhead of continuously catching the same categories of mistake disappears, and what remains is the part of the work that actually benefits from careful thought.

The prompt does not matter. The rules do.

The difference between developers who spend their sessions correcting the same recurring mistakes and developers who barely touch their AI's output is not a difference in prompting skill that takes years to acquire.

It is whether the recurring corrections got written down once as explicit rules, or whether they continue getting fixed manually every single session, indefinitely, because nobody stopped to notice the pattern and remove the guessing.

Track what you correct. Look for the patterns. Write the rules down. And stop hoping that this session's prompt will happen to land on the right decision when you could simply remove the decision from being a guess in the first place.

Want to find which recurring corrections in your React project should already be rules?

I built a free 24 point checklist that helps you identify exactly that. The categories of correction that keep appearing because the decision behind them was never made explicit.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your Code Review Happens After Generation. Your Standard Needs to Happen Before It.

Avery — Fri, 24 Jul 2026 13:49:24 +0000

There is an assumption buried in how most teams think about AI generated code. The assumption is that the review process will catch what needs catching. The AI generates, a human reviews, problems get flagged, corrections happen. The system works the way code review has always worked, just with an AI in the author role instead of a person.

This assumption misses something fundamental about how the AI actually operates. It does not review its own output. It does not second guess its architectural decisions. It does not pause halfway through generating a component and ask whether this is the right approach for this specific project. It generates, based on whatever it can infer from context and whatever instructions it received, and then it stops.

There is no internal reviewer inside the generation process. The only reviewer is the human who looks at the output afterward. And by the time that review happens, every decision has already been made.

What generation actually looks like from the inside

When the AI generates a component, it makes a sequence of decisions very quickly. Where should this state live. What should this be called. How should this be structured. What pattern applies here. Each decision happens based on the immediate context and whatever general knowledge the model has, and then the next decision happens on top of it.

There is no step in this process where the AI stops and evaluates whether the decision it just made matches your project's standard. It does not have access to your standard unless you gave it explicit rules to follow. It has its training, the immediate context, and the prompt. That is what informs every decision it makes during generation.

This is different from how a human developer works, even one who is moving quickly. A human developer carries an internalized standard that operates continuously during the work. They do not consciously think about it most of the time, but it is there, shaping decisions as they are made. A senior developer writing a component is applying years of accumulated judgment about what this specific codebase should look like, even without articulating any of it.

The AI has no equivalent internal process. It has no accumulated judgment about your specific project. It has patterns from its training and whatever is visible in the current context. Without explicit rules, every decision during generation is made in the absence of the standard that a human would have been applying automatically.

Why review after generation is the wrong place to catch this

Code review exists to catch what generation itself does not catch. This has always been true, going back before AI was part of the workflow. A human developer writes code, another human reviews it, and the review catches logic errors, missed edge cases, security issues, things the original developer did not think of or got wrong.

This works because human authorship already has a standard embedded in the generation process. The review is catching mistakes on top of a foundation that mostly reflects the project's conventions. The reviewer is looking for what went wrong, not establishing what the baseline should have been.

With AI generated code the review is doing something different, whether anyone intends it to or not. Because there is no standard embedded in the generation process unless rules were provided beforehand, the review becomes the place where the standard gets established after the fact. The reviewer is not just catching mistakes. They are retroactively defining what should have happened, one comment at a time, on code that has already been written based on the AI's best guess without that definition.

This is expensive in a way that traditional code review is not. The code already exists. The developer already spent time on it. Correcting it after the fact costs more than it would have cost to define the standard before generation began. And because the standard was never written down, the same retroactive correction happens again in the next pull request, and the one after that.

The reviewer that does not exist

If you think about what would actually solve this problem, the answer is obvious once you say it out loud. You need something reviewing the decisions as they get made, before the output reaches a human reviewer. You need a standard that operates during generation, the way a senior developer's internalized judgment operates during their own writing process.

The AI cannot provide this on its own. It does not have accumulated judgment about your project. It has no internal reviewer checking its work against your conventions because it has no access to your conventions unless you give them to it explicitly.

This is what rules actually do. They are not documentation for humans to reference later. They are the internal reviewer the AI does not otherwise have. When a rule says state belongs in a dedicated hook, that rule is operating during generation, before the component exists, shaping the decision the same way a human developer's internalized standard would shape their own writing.

The difference between a rule and a code review comment is the difference between prevention and correction. A code review comment happens after the mistake is already in the codebase, in a pull request, taking up review time. A rule happens before the mistake has a chance to exist. The generation itself follows the standard because the standard was present during generation, not absent from it and discovered afterward.

What it looks like when the standard operates during generation

Consider a specific decision that happens constantly during React development. Should this piece of logic live in the component or in a hook.

Without a rule, the AI decides this based on whatever it infers from context. Sometimes it puts logic in the component because that is simpler for the specific case. Sometimes it extracts a hook because the context suggests that pattern. The decision is made fresh every time, based on immediate signals rather than a consistent standard.

With a rule specifying exactly when logic must be extracted into a hook, the decision is no longer being made fresh. It is being checked against a standard that exists before the component is written. The AI does not have to infer what your project prefers because your project's preference has been stated explicitly and it is present during the generation process itself.

Here is what a set of rules that operate during generation actually looks like, as opposed to comments that would otherwise appear during review:

Rules that replace after-the-fact review comments:
1. Any state that affects more than one render decision moves into a dedicated hook, not inline useState calls scattered through the component. This is checked during generation, not flagged during review.
2. Components receiving more than four props get evaluated for whether they are doing too much before the component is written, not after a reviewer counts the props and asks why.
3. Any function passed as a prop follows the handleX naming convention consistently, checked as the function is named, not corrected in a review comment asking for a rename.
4. Data fetching never happens directly inside a component body. This is enforced as the component is structured, not caught when a reviewer notices a useEffect doing something it should not be doing.

Each of these represents a decision point during generation where a rule can operate instead of a human catching the absence of that rule after the fact. The review still happens. It just has less retroactive standard-setting to do because the standard was already present when the code was written.

What changes for the humans doing review

This does not eliminate code review. It changes what code review is for.

When rules operate during generation, the review process gets to focus on what it was originally designed for. Logic correctness. Edge cases. Whether the feature actually does what the product requires. The kinds of judgment calls that genuinely benefit from a second set of eyes, as opposed to structural and conventional decisions that should have been consistent from the start.

Reviewers stop writing the same comments about component structure and state placement and naming conventions, not because they got more lenient, but because those categories of feedback are no longer necessary. The AI was not left to guess at those decisions during generation. The rules already determined them.

The time this saves compounds. Every pull request that does not need retroactive standard correction is a pull request where the reviewer's attention goes to something that actually requires their judgment. Over enough pull requests this is a substantial shift in how review time gets spent.

The prompt does not matter. The rules do.

Your AI does not review its own output. It generates and stops. There is no internal process checking whether the decisions it just made match your project's standard, unless that standard was given to it explicitly before generation started.

Your human reviewers are catching this after the fact, one comment at a time, on code that has already been written without the standard that should have shaped it. This is not a failure of your review process. It is a mismatch between where the standard needs to operate and where it is currently being applied.

Write the rules. Give them to the AI before generation happens. And let your review process finally focus on what it was built for instead of retroactively establishing a standard that should have been there from the start.

Want to find where your React project needs rules operating during generation instead of corrections during review?

I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your standard is currently being discovered after the fact instead of applied before generation.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Your AI Has More Context Than Ever. It Still Does Not Know Your Standard. Context and Rules Are Not the Same Thing.

Avery — Mon, 20 Jul 2026 08:33:45 +0000

The promise of more context is compelling.

If the AI can see more of your codebase before it generates, it should produce output that fits better. It should pick up on the patterns. It should infer the conventions. It should understand from what already exists how new things should be built.

This is the argument behind tools that give the AI access to your entire project. More files. More history. More awareness of what surrounds the code it is about to write. The assumption is that more context produces more consistent output.

The assumption is partially right and fundamentally incomplete.

More context does help the AI make better local decisions. It can see that you use TypeScript strictly. It can see that you have hooks in a certain folder structure. It can pick up on some of the surface-level patterns and extend them.

What it cannot do is infer your standard from your codebase. Because your codebase is the result of your standard, not a definition of it. And there is a critical difference between a result and a definition that determines whether more context actually solves the problem.

What context actually gives the AI

Context gives the AI examples.

It can see what components look like in your project. It can see where hooks tend to live. It can observe naming patterns in the files it has access to. It can make educated guesses about conventions based on what it reads.

This is genuinely useful. A model with access to your entire project will make better guesses than one with access to only the current file. The local consistency improves. The obvious mismatches become less common.

But guessing from examples is not the same as following rules. And the difference between the two becomes visible exactly in the situations where consistency matters most.

When the AI is guessing from examples it can only infer what the examples show consistently. If your codebase has any variation — any place where two different approaches exist, any historical inconsistency, any feature where something was done differently — the AI has to choose between them. And it will choose based on which pattern is more common in its context window, or which one appears most recently, or which one the current prompt seems to suggest.

That choice is a guess. A more informed guess than without context. But a guess.

Rules are not guesses. A rule says this is always done this way. Not this is usually done this way based on what I can see. Always. The AI does not have to infer anything. The decision has already been made and communicated explicitly.

The cases where context fails and rules succeed

The difference between context and rules becomes most visible in specific situations that every project eventually faces.

Legacy inconsistency. Every codebase older than a few months has places where things were done differently before the current standard was established. Those inconsistencies exist in the context the AI reads. When the AI infers patterns from context, it averages across all of them, including the old ones you no longer want. Rules specify the current standard, not the historical average.

New patterns. When your team decides to adopt a new approach — a new way of structuring features, a new state management pattern, a new import convention — the context initially shows the old pattern more than the new one. The AI will continue generating the old pattern because it is what the examples show. A rule immediately applies the new standard regardless of what the historical examples look like.

Ambiguous situations. Many architectural decisions are genuinely ambiguous from context alone. Should this state be local or global? Should this logic be in a hook or a service? Should this component be split now or later? The context shows examples of both approaches in different situations. The AI has to guess which applies here. Rules eliminate the guessing by making the decision explicit.

Cross-session consistency. Context changes every session based on which files are open, which parts of the codebase are visible, what the prompt focuses on. The AI's inferences change with the context. Rules are constant. They apply regardless of which files happen to be in context this session.

These are not edge cases. They are the situations that produce the inconsistency that more context was supposed to fix. And more context does not fix them because the problem is not the quantity of examples. It is the absence of explicit decisions.

Why developers believe context is the answer

The context argument is intuitive because it mirrors how human developers learn.

A new developer joins a project and gets better by seeing more of the codebase. The more code they read, the better they understand the patterns. The more context they have, the more consistently they code.

So it feels natural to apply the same logic to AI. Give it more context and it will code more consistently, just like a developer who has seen more of the project.

But there is a crucial difference. A human developer does not just see examples. They have conversations. They ask questions. They get explanations. They receive explicit feedback in code reviews. They absorb not just what the codebase looks like but why it looks that way and what it should look like when they add to it.

The AI only gets the examples. It does not get the conversations. It does not get the explanations. It does not get the code reviews that say "we stopped doing it that way six months ago, here is the current approach." It infers from what it can see, which is never the complete picture.

Rules give the AI what conversations give a human developer. Not more examples. Explicit decisions. This is the standard. This is always the answer. This is what you do here.

What rules give the AI that context cannot

Rules are decisions made once and communicated explicitly.

They do not require inference. They do not depend on the consistency of the existing codebase. They do not change based on which files happen to be in the context window. They apply every session regardless of what examples are visible.

This is what makes them different from context in a way that matters practically.

Consider the state placement decision. A project with more context might show the AI that state sometimes lives in components and sometimes in hooks. The AI infers that both are acceptable and makes a session-by-session judgment about which applies. Inconsistency.

A rule says state belongs in a dedicated hook within the feature. Always. The AI does not have to infer anything. The decision has been made. Every session produces the same answer regardless of what the context shows.

Here is what that looks like across a set of decisions that context cannot reliably determine:

Rules that context cannot replace:
1. State scope is decided before any code is written. Local state stays local. Shared state moves to a dedicated hook. Global state only when two independent features require it. Context shows examples of all three. The rule specifies which applies when.
2. The domain language is defined explicitly. Customer means this. User means that. Order means this. Cart means that. Never these alternatives. Context shows whatever words have been used. The rule defines which words should be used.
3. The current architectural pattern applies to new code even when the existing codebase shows the old pattern. Context averages across history. The rule specifies the present standard.
4. Import paths go through feature index files. Always. Not sometimes, not when it seems appropriate. Context shows some direct imports from the pre-refactor period. The rule says those are not the standard.

These rules cannot be inferred from context with the reliability that makes them useful. They have to be stated explicitly. Context is useful for many things. Replacing explicit decisions is not one of them.

The right relationship between context and rules

Context and rules are not competing approaches. They work together and each does something the other cannot.

Context helps the AI understand what already exists. It helps with local consistency. It helps the AI extend existing patterns when those patterns are clear and consistent. It is genuinely valuable and more context is generally better than less.

Rules tell the AI what should exist. They define the standard that new code must meet regardless of what the existing code shows. They are the explicit decisions that remove ambiguity from the situations where context produces inconsistent guesses.

A project with good context and good rules gets both benefits. The AI understands the existing codebase and follows a defined standard when adding to it. The output is consistent not because the AI made good guesses but because the decisions were made before the AI started guessing.

A project with good context but no rules gets the benefit of better local guesses. The output is more consistent than without context. But it is still inconsistent in the ways that matter because the AI is still guessing at the decisions that rules would have made explicit.

More context is not the answer to inconsistent AI output. It is a partial improvement on top of a missing foundation. The foundation is rules. And no amount of context replaces the need to define what the standard actually is.

The prompt does not matter. The rules do.

Your AI has more context than ever. It can see your folder structure, your existing components, your patterns and naming and architectural decisions.

And it still does not know your standard. Because your standard is not in the examples. It is in the decisions behind the examples. And decisions have to be stated explicitly to be followed consistently.

Give your AI the context it needs to understand what exists. Give it the rules it needs to know what should exist. And stop expecting more examples to do the work that only explicit decisions can do.

Want to find where your React project is relying on context where it needs rules?

I built a free 24 point checklist that helps you find exactly that. The structural gaps where your AI is inferring instead of following and the inconsistency that results.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

Every React Project Develops a Domain Language Over Time. The AI Invents Its Own Every Session.

Avery — Fri, 17 Jul 2026 13:57:17 +0000

Every product has a language.

Not a programming language. A domain language. The specific words that mean specific things in the context of this particular product, this particular business, this particular problem space.

In an e-commerce platform a Customer is not the same as a User. An Order is not the same as a Cart. A Listing is not the same as a Product. These distinctions matter. They reflect real differences in the business domain. The right word in the right place makes code readable. The wrong word, or five different words for the same concept, makes code that requires translation every time someone reads it.

Your team knows this language. You have been building it for months or years. It lives in conversations, in pull request comments, in the names your product managers use when they describe features. It is the shared vocabulary that makes your team efficient.

Your AI does not know any of it. And every session it invents its own.

What domain language drift actually looks like

It starts subtly and accumulates over time.

In the first few months the AI generates components and hooks that use reasonable naming. Nothing obviously wrong. The words it chooses are generic React vocabulary and they work well enough for what they describe.

But beneath the surface the domain language is fragmenting. The concept your team calls a Customer appears as User in some components, Client in others, Buyer in the ones the AI generated when it was looking at a different part of the codebase. The concept your team calls an Order appears as Purchase in one hook, Transaction in another, Checkout in a third.

None of these are wrong in isolation. User is a reasonable word. So is Client. So is Buyer. But they are not the same word and in your domain they do not mean the same thing. The AI does not know the difference because nobody told it.

Over six months of sessions, the codebase stops speaking one language. It speaks five. The AI's language for this week's feature, the AI's language from three months ago, what the senior developer wrote before the AI was in the workflow, what the new developer added last sprint, and the actual domain language that exists in business conversations but has never been written down in a form the AI could follow.

A new developer joins and tries to understand the codebase by reading it. They find Customer in some places and User in others and cannot tell if they are the same thing or different things. They have to ask. The answer is that they are the same thing. The AI just did not know.

Why domain language matters more than naming conventions

Naming conventions are about form. PascalCase for components. camelCase for functions. handleX for event handlers. These are rules about how words are written.

Domain language is about meaning. Customer versus User. Order versus Purchase. Listing versus Product. These are decisions about which words carry which concepts.

Both matter. But they solve different problems. Naming conventions solve consistency of form. Domain language solves consistency of meaning. And consistency of meaning is what makes a codebase readable to someone who understands the business.

A codebase with perfect naming conventions but fragmented domain language is technically consistent but semantically confusing. You know how the words are capitalized. You do not know which word to use when you are describing a person who has completed a purchase.

Domain language fragmentation is harder to notice than naming convention violations because it does not trigger any automated checks. No linter catches the fact that Customer and User are being used interchangeably. No TypeScript error appears when a component receives a User object and calls it a Customer internally. The code compiles. The tests pass. The language is fragmented and nobody knows.

Where the AI's invented language comes from

The AI is not making random choices when it names domain concepts.

It is making locally reasonable choices based on whatever context is visible in the current session. If the file it is working in uses User, it uses User. If the adjacent hook uses Customer, it might switch. If the prompt mentions a buyer, it might use Buyer. If it cannot infer anything from context, it falls back to the most generic available term.

Each individual choice is defensible. The aggregate is chaos.

This is the core of the problem. The AI is not bad at naming. It is excellent at locally consistent naming within a session. The problem is that locally consistent naming across different sessions, with different context, making different locally reasonable choices, produces a codebase that is globally inconsistent in meaning.

Domain language is by definition not something the AI can derive from context alone. Context tells it what React patterns are visible nearby. It does not tell it that in this product, in this business domain, Customer means someone who has completed at least one purchase while User means anyone with an account. That distinction exists in the business. It has never been written down in a form the AI can use before it generates something.

Building the domain language document

The fix is not complicated. It is just work that almost no team does because it does not feel like a development task.

A domain language document is a list of the concepts in your product and the specific words your codebase uses to represent them. Not a business glossary. Not user-facing terminology. The specific technical terms that should appear in component names, hook names, type definitions, and variable names throughout the codebase.

Here is what a domain language document looks like for a simplified e-commerce context:

Domain language rules for this project:

Person concepts:
- User: anyone with an account, authenticated or not
- Customer: a User who has completed at least one purchase
- Guest: an unauthenticated visitor
- Never use: Client, Buyer, Shopper, Member

Transaction concepts:
- Cart: items selected but not yet purchased
- Order: a completed purchase transaction
- LineItem: a single product within a Cart or Order
- Never use: Basket, Purchase, Transaction, Item (alone)

Product concepts:
- Product: the base catalog entry
- Listing: a Product with pricing and availability for a specific context
- Variant: a specific configuration of a Product
- Never use: Item, Good, Merchandise, SKU (in component names)

This document does not take long to create for a project that has been running for any meaningful time. The domain language already exists. It lives in conversations and pull request comments and the names product managers use. Writing it down is mostly a matter of making explicit what is already implicit.

Once it exists it becomes part of the rules the AI receives before every session. The AI stops inventing its own vocabulary because the vocabulary has been defined. Customer appears where Customer should appear. User appears where User should appear. The distinction is maintained because the rule exists.

What changes in the codebase over time

Domain language consistency compounds in the same way that domain language fragmentation does. But in the right direction.

When the AI uses the correct domain terms consistently, new components look like existing components not just structurally but semantically. A developer reading a new feature written last week can immediately understand what it is talking about because the words are the same words used everywhere else.

The cognitive overhead of reading the codebase drops. Not because the code became simpler. Because the language became consistent. A developer does not have to translate between User and Customer and Client when reading different parts of the system. They encounter one word for each concept and they know immediately what it means.

Onboarding accelerates. A new developer learns the domain language once from the documentation and then sees it applied consistently everywhere in the codebase, including in every component and hook the AI generates from that point forward.

Search becomes reliable. A developer looking for everything related to Orders can search for Order and find it. They do not have to also search for Purchase and Transaction and Checkout and Fulfillment and hope they have covered all the variations.

The codebase starts reading like it was written by a team that shared a language. Because the rules ensure that it was. Even when the AI was involved in building large portions of it.

The language your product already has

Your product already has a domain language. Your team already knows it.

The gap is not that the language does not exist. The gap is that it has never been written down in a form the AI can follow before it generates something.

Every time the AI uses the wrong word for a concept in your domain, it is not making a mistake. It is filling a gap you left open. The word you wanted was not in the rules. So it used the word that seemed most reasonable given the context it had.

Write the domain language down. Give it to the AI before every session. And stop finding five words for the same concept in a codebase that should only ever have one.

The prompt does not matter. The rules do.

Your React project has a language. It developed over time through the work your team did and the conversations you had about what things should be called.

Your AI speaks a different language every session. Not because it cannot speak yours. Because you never told it what yours was.

Write it down. Apply it consistently. And let the codebase finally speak one language instead of five.

Want to find where your React project's domain language has fragmented?

I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your AI has been inventing vocabulary instead of following the language your product already has.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

I Started Tracking How Much Time I Spent Correcting AI Output. The Number Changed Everything.

Avery — Mon, 13 Jul 2026 12:00:24 +0000

It started as a small experiment.

I had been working with AI for about eight months at that point. The sessions felt productive. Features were getting built faster than before. The general sense was that the AI was saving time and the workflow was better than without it.

But I had a nagging feeling that some of that time was going somewhere it should not. The corrections at the end of each session. The adjustments before a pull request. The small fixes that felt automatic, barely worth noticing individually.

So I started writing them down. Not obsessively. Just a rough log at the end of each session. What I corrected, approximately how long it took.

Two weeks later I looked at the numbers. The correction time was not small. It was not the minor overhead I had assumed. It was a significant portion of every session. And when I projected it across a month, across a year, it was a number that made me stop and think seriously about what I was actually doing.

What the log actually showed

The corrections fell into categories almost immediately.

Some were logic errors. Places where the AI had misunderstood the requirement or made a technical mistake. These were real AI failures in the traditional sense. They were also relatively rare and varied enough that they did not suggest a systemic pattern.

The majority were something else entirely. They were project mismatches. The component structured in a way that worked but did not match the project's pattern. The state placed somewhere reasonable but not where this project puts state. The naming that made sense in isolation but did not follow the convention. The import that went directly to a file instead of through the feature's public API.

None of these were React mistakes. They were project-specific decisions the AI made without guidance because no rules existed to make them differently.

And they were not random. They were the same categories of correction every session. Different files. Different features. Same corrections. Because the missing rules were always the same missing rules and the AI was always filling those gaps with its own decisions.

The actual numbers

Over two weeks I logged corrections across roughly thirty sessions.

Logic errors and genuine AI mistakes: approximately eight percent of total correction time. Varied, unpredictable, the kind of thing you review carefully regardless.

Project mismatch corrections, the category that rules would have prevented: approximately seventy-eight percent of total correction time. Consistent, predictable, the same categories appearing session after session.

The remaining fourteen percent was genuinely ambiguous, things that could go either way and where I made a judgment call.

So roughly four out of every five minutes I spent correcting AI output were minutes spent on something that a rule could have prevented. Not edge cases. Not genuinely uncertain situations. Predictable, repeatable corrections that I had been making session after session for eight months without ever thinking to write them down.

When I calculated the projection, the number was significant. Hours per month spent on corrections that should not have needed to happen. Over a year it was the equivalent of weeks of productive development time spent on something entirely preventable.

Why nobody measures this

Correction time is invisible in the way that matters most. It does not show up on a sprint board. It does not appear in a time tracking system. It does not surface in velocity metrics or planning conversations.

It disappears into the texture of individual sessions. A few minutes here. A few minutes there. Each individual correction is too small to flag, too routine to mention, too automatic to register as a cost.

The result is that teams and individual developers consistently underestimate the real cost of working with AI without rules. The productivity gain from generating code faster is real and visible. The productivity loss from correcting the output of that generation is real and invisible.

The net benefit of AI in a workflow without rules is significantly smaller than it appears. Because the correction time is never subtracted from the time saved.

For freelancers the equation is even more direct. Correction time is not billable. Every minute spent fixing a project mismatch the AI introduced is a minute that contributed nothing to deliverable output. Multiply that across a year and it is a meaningful reduction in effective hourly rate that never shows up anywhere.

What happened after I started writing rules

I did not set out to run a controlled experiment. But the log continued after I started adding rules and the comparison was informative.

The logic error category stayed roughly the same. Genuine AI mistakes do not respond to project rules because they are not caused by missing project knowledge.

The project mismatch category collapsed. Not eliminated entirely, there were still occasional corrections as I discovered gaps in the rules and filled them. But the consistent, predictable corrections that had made up the majority of my correction time largely stopped appearing.

The total correction time per session dropped by more than half within the first month. By the second month it had dropped further as the rule set became more comprehensive.

The productivity gain that the AI was supposed to provide finally materialized in full. Not because the AI got better. Because the time that had been going into corrections started going into building instead.

Here is what the rules that made the biggest difference looked like:

Rules that eliminated the highest-volume corrections:
1. Component structure follows the presentational or container pattern without exception. No component mixes both. This single rule eliminated the most common structural correction I was making.
2. State belongs in a dedicated hook within the feature. Not in the component. Not in a shared store unless genuinely needed across independent features. This eliminated the second most common correction.
3. Imports go through feature index files. No direct imports across feature boundaries. This eliminated a category of correction I had been making so automatically I had stopped noticing it.
4. Names use the project's established patterns. handleX for event handlers. useX for hooks. isX and hasX for booleans. No variations. This eliminated the naming corrections that had been appearing in almost every session.

Four rules. The corrections they covered represented the vast majority of the time I had been spending on project mismatch fixes. Writing them down took less time than a single session's worth of corrections.

The measurement that changes the conversation

Most conversations about AI productivity focus on the time saved by generating code faster.

That number is real. AI does generate code faster than writing by hand. For many tasks the speedup is significant.

But the conversation rarely includes the time spent correcting the output of that generation. And without that number, the true productivity impact of working with AI without rules is invisible.

When you measure both, the picture changes. The time saved by faster generation minus the time spent on avoidable corrections gives you the real productivity gain. For most developers working without rules, that real number is substantially smaller than the apparent number.

For developers working with rules, the correction time that was offsetting the generation speed largely disappears. The real productivity gain approaches the apparent one.

That is not a marginal improvement. It is often the difference between AI that genuinely transforms a workflow and AI that feels like it should be transforming the workflow but somehow never quite delivers on the promise.

The prompt does not matter. The rules do.

The AI is generating code faster than you could write it by hand. That part is working.

What is not working is the time going into correcting what it generates. That time is not random or unavoidable. It is concentrated in predictable, repeatable categories that rules eliminate.

Track the corrections for two weeks. Write down what you fix and roughly how long it takes. Look at the categories. Write rules for the ones that keep appearing.

The number that changes everything is waiting for you in that log.

Want to find which corrections you keep making that should already be rules?

I built a free 24 point checklist that helps you identify exactly that. The structural gaps where your AI is making decisions without constraints and your correction time is paying the price.

→ Get the React AI Clean Code Checklist — free

→ Avery Code React AI Engineering System

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.

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