DEV Community: DevUnionX

5 Things AI Can't Do, Even in React Context API

DevUnionX — Fri, 27 Mar 2026 15:21:49 +0000

Artificial intelligence has become very good at producing React code that looks convincing. Give it a prompt, mention Context API, and within seconds it can generate a provider, a custom hook, and a clean enough consumer structure to pass a quick review.

That speed is impressive, but it is also deceptive.

React Context is one of those tools that appears simple until the surrounding reality of a production application begins to matter. The moment you move beyond surface level implementation and start thinking about component boundaries, render cost, state modeling, accessibility, debugging, and migration, the conversation changes. At that point, the issue is no longer whether AI can generate working code. The issue is whether it can make the right architectural decisions.

In practice, that is still where human judgment matters most.

This is not because AI is useless. It is because Context is not just a syntax feature. It is an architectural mechanism. When used well, it reduces friction and clarifies ownership. When used poorly, it spreads cost and confusion across an entire application.

Here are five things AI still struggles to do, even when React Context API is part of the solution.

It cannot decide where Context should begin and where it should stop

One of the most common mistakes in React applications is not a broken Context implementation. It is an unnecessary one.

AI tends to see shared data and immediately treat Context as the answer. A theme value becomes Context. Session data becomes Context. Modal state becomes Context. Notifications become Context. Filters, tabs, loading flags, and form state soon follow. Before long, the application starts to resemble a storage unit where unrelated concerns have been placed side by side simply because they might be needed somewhere else.

That is rarely good design.

The real challenge with Context is not creating it. The real challenge is drawing a boundary around what genuinely deserves to be shared across a subtree and what should remain local, explicit, and easier to reason about through props or composition.

Human developers are still better at noticing when a piece of state only feels global because the component structure is messy. In many cases, the right fix is not Context at all. It is a clearer component boundary, a better parent child relationship, or a simpler data flow.

AI often optimizes for convenience. Humans still have to optimize for clarity.

It cannot truly understand the structural cost of a provider

A provider is never just a wrapper. Its position in the tree affects how state is distributed, how updates propagate, and how difficult the application becomes to reason about over time.

This is where AI often falls short. It can generate a provider and consumer pair without difficulty, but it usually treats them as isolated code fragments. It does not naturally reason about the full topology of the component tree in the way an experienced engineer does.

That difference matters.

A provider placed too high can cause broad and unnecessary subscriptions. A provider placed in the wrong branch can make data ownership unclear. A provider whose value object is recreated on every render can trigger update cascades that seem invisible at first but become expensive later. A provider that mixes unrelated concerns in one value may work perfectly in the beginning and quietly become a maintenance problem six months later.

None of this is obvious from a generated snippet.

The code may compile. The UI may behave correctly. Yet the structure underneath may already be wrong.

That is why Context design remains a human task. It requires thinking in terms of the tree, not just the file.

It cannot model state meaningfully as well as it models syntax

There is a large difference between storing state and understanding state.

Context is very good at making values available lower in the tree. It is not, by itself, a guarantee that the values inside it have been modeled correctly. Once applications become more complex, the hard problem is no longer distribution. It is meaning.

Imagine a session object that contains the current user. From that session, you derive whether the user is authenticated. Then perhaps feature flags influence what the user is allowed to see. Then permissions shape what actions are available in the interface. At that point, the central question is not how to expose the data. It is which value is the source of truth, which values should be derived, and where that derivation should happen.

AI often blurs those layers.

It may store source state and derived state together in the same context value. It may duplicate the same business logic in multiple consumers. It may calculate important meaning in the provider itself, even when that logic should live in a dedicated hook or a more focused abstraction.

That kind of design can survive for a while. The application still runs. The UI still appears correct. But the structure becomes fragile. Sooner or later you get inconsistencies that are difficult to explain, such as a user object being null while an authentication flag still says true, or two screens interpreting the same state differently.

The more important the logic becomes, the more dangerous that drift is.

AI is very good at producing shapes that resemble solutions. Humans are still better at protecting the internal truth of a system.

It cannot instinctively protect you from Context performance traps

Performance problems in React are rarely caused by one dramatic mistake. More often, they come from small design decisions that seemed harmless at the time.

Context is especially vulnerable to this.

A provider value that changes identity too often can trigger broad re renders. A large context that bundles fast changing and rarely changing values together can force unrelated consumers to update. A context that acts as a catch all store can spread render pressure through wide parts of the application even though only one small field has changed.

This is where AI often sounds confident and remains shallow.

Mention a rerender issue and it may quickly recommend memoization. That sounds reasonable, but it often fails to address the real problem. In many Context related cases, the issue is not whether a child is memoized. The issue is that the provider value itself is unstable, or that the shape of the context is too broad, or that the update frequency of the stored values makes the design unsuitable.

In other words, the architecture is wrong before the optimization strategy even begins.

An experienced developer usually responds differently. Instead of asking how to patch the rerender, they ask why this state is in Context at all, how often it changes, how many components subscribe to it, whether state and dispatch should be separated, whether the provider value should be stabilized, or whether another state management approach would fit the problem better.

That diagnostic instinct still belongs mostly to humans.

AI can suggest remedies. It is much less reliable at identifying the true source of the disease.

It cannot own the consequences of debugging, migration, and maintenance

The first version of Context is rarely the hard part. The hard part arrives later, when something subtle breaks and the failure is spread across multiple layers of the application.

A consumer unexpectedly reads a fallback value. A provider override deep in the tree changes behavior only on one screen. A React version upgrade introduces a rendering difference that was never visible before. A bundling issue duplicates modules and causes Context identity to behave strangely even though the code looks correct.

These are not beginner problems. They are engineering problems.

And this is precisely where AI becomes least dependable.

Debugging Context requires more than pattern recognition. It requires tracing provenance. Which provider is supplying this value. Where is it being overridden. Why is this consumer seeing a different result than another one. Is the issue in the component tree, the module graph, the build output, or the migration path.

AI can offer plausible guesses, but it cannot truly hold the lived context of your codebase in the way a human maintainer can. It does not own the repository history. It does not remember why the provider was placed there in the first place. It does not feel the weight of a bad migration choice that will cost your team weeks of cleanup later.

This becomes even more important during framework upgrades. Context heavy areas are often sensitive to subtle behavioral differences. What looked stable under one version may suddenly require retesting, restructuring, or more careful profiling under another. AI can tell you what changed in general terms. It cannot responsibly judge the pressure points of your specific application without human verification.

And that verification is not a formality. It is the work.

Why this matters more than people admit

The discussion around AI in development is often framed the wrong way. People ask whether AI can write React code. That question is already outdated. Of course it can.

The better question is whether AI can make architectural decisions under uncertainty, with incomplete visibility, and with long term consequences in mind.

React Context is a very good test of that question because it sits exactly at the border between code generation and system design.

Do you know these?

DevUnionX — Sat, 21 Mar 2026 01:21:50 +0000

DevUnionX

Mar 21

5 Things AI Can't Do, Even in • Recoil

#recoil #webdev #programming #ai

Comments

12 min read

5 Things AI Can't Do, Even in Recoil

DevUnionX — Sat, 21 Mar 2026 01:20:28 +0000

5 Things AI Still Can't Do Even With Recoil

I wrote this report based on Recoil's (for React) atom to selector based data flow graph approach. The goal was showing concrete limits through Recoil-specific technical nuances rather than staying at slogans like "AI writes code but can't design". Recoil official documentation speaks of a data graph flowing from atoms to selectors and selectors being able to do sync/async transformations. citeturn8view1 The five places where AI struggles in this technical framework all come down to the same root in my view: lack of intent and context.

As of March 20, 2026, there's another critical background affecting the table: Recoil's most current release note is 0.7.7 from March 1, 2023, containing various SSR/Suspense issues and possible "unhandled promise rejection" fix for useRecoilCallback. citeturn10view2 Additionally Recoil GitHub repository was archived (read-only) on January 1, 2025. citeturn10view0 This further weakens the assumption that "AI already knows everything" because AI assistants mostly don't account for current maintenance status and ecosystem risk when generating code.

The report's five main findings can be summarized like this. When component to state composition isn't properly structured, Recoil atom keys, boundaries (RecoilRoot), shared state versus local state distinction quickly gets out of control. citeturn8view1turn10view0 In atom/selector design, especially with atomFamily/selectorFamily normalization, small key or cache choice can return as "slowdown" or "memory leak" in real projects. citeturn7view0turn7view1turn8view2 Async selectors and atom effects, especially async calling of setSelf, can lead to race conditions and difficult bugs like "later value overwrote user change". citeturn4view1turn8view0 On debugging/snapshot/time-travel side, snapshot lifetime management with retain/release and "API under development" warnings are details AI frequently misses causing problems directly in production. citeturn6view1turn6view2turn6view0 In performance and large-scale compatibility, reading large collections through families in loops can lock CPU, plus memory management of some patterns is questionable. AI can produce these as "works" and leave it. citeturn7view0turn7view2turn7view3

For preparing this report, I first examined Recoil's official documentation including Core Concepts, atom/selector APIs, dev tools and snapshot pages, Recoil blog release notes, and issues in Recoil GitHub repository. citeturn8view1turn8view3turn6view2turn10view2turn10view0 To understand Recoil's async selector patterns, I additionally utilized case writings focused on Recoil and community examples. citeturn0search20turn0search18turn0search4 In accessibility section, I didn't treat Recoil as "direct a11y tool". Instead I related how state changes create risk on UI/focus/announcement (live region) side with WCAG and WAI-ARIA guides. citeturn2search3turn3search1turn3search0 Finally to contextualize AI code assistant error modes, I referenced current research on AI agent PR analysis and software supply chain risks like package hallucination and slopsquatting. citeturn11search6turn11search5turn11search0

Connected corporate document source wasn't provided this session, so I proceeded only with publicly available web sources. Therefore I didn't make claims like "says so in internal docs".

Following flow summarizes where I see AI as accelerator versus risk multiplier in Recoil project.

flowchart TD
  A[Product requirement and boundaries: local state or Recoil?] --> B[Draft with AI: atom/selector, atomFamily/selectorFamily suggestions]
  B --> C{Atom/selector key strategy consistent?}
  C -- No --> D[Create key dictionary and naming standard] --> B
  C -- Yes --> E{Should derived state really be selector?}
  E -- No --> F[Separate local state / memo / computation layer] --> B
  E -- Yes --> G{Async flow exists? (Promise selector, atom effects, SSR/Suspense)}
  G -- Yes --> H[Test race/cancel/retain rules, validate SSR target] --> B
  G -- No --> I{Performance and memory review: family+loop, leak risk}
  I -- Problem exists --> J[Change scaling pattern, apply cache policy & splitting] --> B
  I -- Clean --> K{a11y: focus, live region, modal behavior correct?}
  K -- No --> L[WAI-ARIA/WCAG check: focus trap + aria-live + keyboard flow] --> B
  K -- Yes --> M[Code review + test + prod observation]

Technical background: Recoil builds data graph flowing from atoms to selectors. Atoms are subscribable state units and selectors transform this state sync or async. citeturn8view1turn8view0 Official documentation says atoms "can be used instead of React local component state", meaning technically you can atomize everything. citeturn8view1 This point moves design decision from "library" to "architecture". Whether a state will be shared (atom), derived (selector), or component-specific (local state) requires reading product behavior more than generating code.

AI's concrete error modes: AI most frequently shows "let's write atom for everything" reflex in Recoil world. This produces two easy but dangerous results: (1) atom keys become soup, (2) application's "semantic boundaries" disappear (which state is UI state, which is domain state?). Recoil requires atom keys to be globally unique and these keys get used in places like debugging/persistence. Same key in two atoms gets accepted as error. citeturn8view1turn8view3 AI leaning toward Date.now or random IDs saying "let's generate key" undermines key's need to be "stable across executions" especially in persistence/debug scenarios. Recoil documentation emphasizes selector key (and similarly atom key) needs to be unique across entire application and stable for persistence. citeturn8view0turn8view3

Additionally Recoil tries protecting atom/selector values from direct mutation to detect change correctly. If object held in atom or selector gets directly mutated, might not notify subscribers correctly, so freezes value objects in development mode. citeturn8view0turn8view3 AI using doors like dangerouslyAllowMutability as "quick fix" suppresses error short term but produces ugliest failures like "sometimes doesn't render" long term.

Short code examples showing good versus bad. Good example with keys module-level constant and meaningful. Export const cartItemCountAtom equals atom number with key cart/itemCount comment persistent, unique, carries meaning, and default 0. Bad example with different key every run causing debug/persist nightmare. Export const cartItemCountAtom equals atom number with key cart/itemCount plus Date.now comment key not stable, and default 0.

Good example moving expensive state read to action not render. useRecoilCallback provides reading through snapshot without subscribing during render. citeturn9view2 Import useRecoilCallback from recoil. Function CartDebugButton. Const dumpCart equals useRecoilCallback with snapshot parameter async arrow function. Comment reading on click not render time. Const count equals await snapshot.getPromise cartItemCountAtom. Console.log Cart count. Return button onClick dumpCart showing Log Cart.

Mitigation strategies for developer: I treat Recoil key management like "hidden API", extracting a key dictionary, establishing naming standard like domain/entity/field, first place I look in code review when adding new atom is key. To not mutate atom/selector objects, I make immutable update habit into "rule", instead of turning off freeze warnings in development mode, I fix point where warning appears. citeturn8view3turn8view0 If expensive read needed during render, I prefer useRecoilCallback or on-demand snapshot approach because Recoil explicitly warns tools like useRecoilSnapshot can trigger re-render at every state change. citeturn9view0turn9view2

Technical background: Atoms are "source of truth", selectors are "derived state". Selectors should be thought of as pure/side-effect-free function. citeturn8view1turn8view0 Recoil officially provides pattern with selectorFamily that takes parameter and returns same memoized selector instance for same parameter, very powerful for normalization and "ID-based access". citeturn8view2 Despite this, normalization itself, which atomFamily, which selectorFamily, which key schema, is modeling decision not technical. When done wrong, returns not just "wrong value" but "slowness" and "memory bloat".

AI's concrete error modes: AI has two typical extremes here. (1) making everything atomFamily using like "as if DB", (2) conversely keeping everything in single atom trying to fragment with selectors. When large collections have atomFamily/selectorFamily designed wrong, there are early-period issues saying resources on Recoil side aren't released. For instance one issue reports "resources created with atomFamily/selectorFamily aren't properly freed after unmount". citeturn7view2 Parallel to this, "memory management/garbage collection" topic also discussed in Recoil issues under separate headings. citeturn7view3 AI without knowing this history and discussions can present family plus large list combination as default solution saying "works anyway".

More dangerous: using selector for "lazy init" of atom default. Atom API documentation says default can be selector and if selector default used, atom's default can dynamically update as default selector updates. citeturn8view3 But in real world, there's closed issue saying "memory leak when atom default is selector". This issue claims making atom default lazy with selector "caches all old set values" leading to memory leak. Proposed fix even touches eviction strategy with cachePolicy_UNSTABLE. citeturn7view1 AI cannot be expected to catch such "exists in docs but turned out problematic in practice" distinctions.

Short code examples showing normalization plus error. Good example with ID-based atomFamily plus derived selectorFamily. Import atomFamily and selectorFamily from recoil. Type User with id, name, teamId optional. Export const userByIdAtom equals atomFamily User or null, string with key entities/userById and default null. Export const userNameSelector equals selectorFamily string, string with key derived/userName and get with id parameter showing get function with user equals get userByIdAtom id, return user?.name or (nameless). Comment: Atom source of truth, selector derived state, separation clear. citeturn8view2

Risky pattern making atom default lazy init with selector. Some scenarios reported memory leak. citeturn7view1 Import atom and selector from recoil. Export const transactionsAtom equals atom with key transactions and default selector with key transactions/default and get async arrow returning await retrieveTransactions. Comment showing lazy init intent.

Mitigation strategies for developer: I put two safety belts in atom/selector design. First, I do normalization "little but correct", using families only when really need ID-based sharing. Patterns like "pulling thousands of items with loop in selectorFamily" I put in early performance test because this locking CPU was reported with real issue. citeturn7view0 Second, in controversial patterns like making atom default lazy with selector, I shift to atom effects or more controlled loading strategies. Recoil explains atom effects specifically with "putting policy into atom definition" motivation and allows managing side effects by returning cleanup handler. citeturn4view1

Technical background: Recoil selectors can be sync or work async by returning Promise. Documentation positions selectors as "idempotent/pure function" but also explicitly shows get function can return Promise. citeturn8view0 On atom side, default value can be Promise or async selector, in this case atom becomes "pending" and can trigger Suspense. citeturn8view3turn10view2 This is nice but in practice all questions like "when will fetch trigger", "how will it cache", "what happens in SSR" are design decisions.

AI's concrete error modes: Even in simplest scenario like do I fetch data on render or on button click, there are different patterns in Recoil ecosystem. For instance in Recoil issue about data fetching scenario with web API, two options asked: (a) do fetch on onClick writing result to atom, or (b) onClick changes an atom and selector reloads through dependency? citeturn5view2 This question alone makes it hard for AI to produce "one correct answer" because answer depends on product behavior like prefetch, idempotent, user action, rate-limit. AI mostly chooses pattern (b) because "reactive", but this can lead to selector triggering again and again as atom changes and unintentionally raining API calls.

On atom effects side, Recoil officially supports policies like persistence/sync/history with setSelf and onSet. citeturn4view1 But there's subtle landmine here: async setSelf call, according to docs, can overwrite atom's value if comes after atom set by user. citeturn4view1 In "async init plus user interaction" codes AI produces, you mostly see this race condition. User fills form, then old state from localForage arrives and rewinds form. This isn't Recoil's fault, it's design error.

On snapshot side also async subtle detail: Snapshot documentation says snapshots held during callback duration, retain needed for async usage, also warns "async selectors can be canceled if not actively used, must retain if looking with snapshot". citeturn6view2 AI assistants frequently skip this retain requirement in codes wanting to resolve async selector with snapshot to see resolved value. Result becomes hair-pulling failure like "sometimes comes sometimes doesn't".

Short code examples showing async selector plus atom effect. Async selectorFamily fetching with ID parameter, same parameter gets memoized. citeturn8view2turn8view0 Import selectorFamily from recoil. Export const userQuery equals selectorFamily with key queries/user and get with id string parameter async arrow. Const res equals await fetch /api/users/${id}. If not res.ok throw new Error User couldn't be fetched. Return await res.json.

Warning atom effect with async setSelf showing watch for race condition. According to docs "if atom set, later setSelf can overwrite". citeturn4view1 Import atom from recoil. Export const settingsAtom equals atom with key settings, default object theme light, effects array with setSelf, onSet, trigger parameters. If trigger equals get, comment persisted value coming late can overwrite user change. setTimeout with setSelf object theme dark after 1000ms. onSet with newValue arrow, comment persistent write etc. localStorage.setItem settings with JSON.stringify newValue.

Mitigation strategies for developer: I apply two principles in async state. (1) selectors should be pure, if side effect needed move to atom effects or UI layer event handler, (2) "async init" should always be written with assumption "can overwrite user interaction". I take seriously trigger usage in atom effects documentation, especially limiting expensive init with trigger equals get, and don't neglect cleanup handlers like unsubscribe. citeturn4view1 If fetch needed on user action instead of render, I prefer onClick with useRecoilCallback for snapshot read plus set/refresh pattern because this hook designed with motivation of async reading without render-time subscription. citeturn9view2

Technical background: Recoil officially presents "observe all state changes" and inspect through snapshot approach. Dev tools guide says you can subscribe to state changes with useRecoilSnapshot or useRecoilTransactionObserver_UNSTABLE getting snapshot, also puts warning "API under development, will change". citeturn6view1turn6view2 Snapshot API page also notes this area evolving with _UNSTABLE emphasis. citeturn6view2 For time travel, useGotoRecoilSnapshot recommended. citeturn9view1turn6view1

AI's concrete error modes: Most typical AI error here: copying time-travel example from docs and storing snapshots inside React state. Problem is snapshot lifetime is limited. Time-travel issue on GitHub says keeping snapshot outside callback duration gives warning and "if you'll keep snapshot long, do retain/release" sharing example code. citeturn6view0turn6view2 AI assistant generally doesn't see this warning because example appears to "work", but even issue text mentions will turn into exception later. citeturn6view0

Another error is using useRecoilSnapshot everywhere in application for debug. Recoil documentation explicitly says this hook will re-render component at all Recoil state changes and asks to be careful. citeturn9view0 AI can suggest "put debug observer everywhere", then unnecessary render storm starts in prod. Additionally useGotoRecoilSnapshot page notes transaction example is inefficient because subscribes "all state changes". citeturn9view1turn9view0

Short code examples showing correct time travel. If I'll store snapshot, I comply with retain/release discipline. citeturn6view2turn6view0 Import useEffect and useRef from react, useRecoilSnapshot and useGotoRecoilSnapshot from recoil. Export function UndoRedo. Const snapshot equals useRecoilSnapshot. Const gotoSnapshot equals useGotoRecoilSnapshot. Comment holding retained snapshots here. Const historyRef equals useRef array type. useEffect with const release equals snapshot.retain comment extending snapshot lifetime. historyRef.current.push object snap snapshot and release. Comment example 50 step limit. If historyRef.current.length greater than 50, const first equals historyRef.current.shift, first?.release. Return arrow function comment releasing all when component closes. historyRef.current.forEach h arrow h.release. historyRef.current equals empty array. With snapshot dependency. Return button onClick showing last equals historyRef.current.at(-2) comment previous one, if last gotoSnapshot last.snap showing Undo.

Debug state dump with "on-demand snapshot" approach. Dev tools guide and useRecoilCallback recommend this. citeturn6view1turn9view2 Import useRecoilCallback from recoil. Function DumpStateButton. Const dump equals useRecoilCallback with snapshot parameter async arrow. console.debug Atom/selector dump starting. For const node of snapshot.getNodes_UNSTABLE. Const value equals await snapshot.getPromise node. console.debug node.key value. Return button onClick dump showing State Dump.

Mitigation strategies for developer: I design debugging tools like snapshot observer and time travel for "dev" not "prod", taking seriously "under development" note in docs putting durable abstraction layer (adapter) against version changes. citeturn6view1turn6view2 If I'll store snapshots, I make retain/release discipline into code standard, otherwise "ghost snapshot" and memory pressure can happen over time. citeturn6view2turn6view0 Additionally I use feature flag or env guard to not put hooks subscribing to all state changes (especially useRecoilSnapshot) into prod bundle. citeturn9view0turn9view1

Technical background: Recoil's performance promise relies on "render as needed" idea with atom-based subscription and selector re-evaluations. Core Concepts says when atom updated, components subscribed to that atom re-render. citeturn8view1 Selector documentation also explains selector re-evaluates when dependency changes and additionally warns "if you mutate selector value object, subscriber notification can be bypassed". citeturn8view0 So performance comes when application modeling done right, when done wrong Recoil isn't "magic".

AI's concrete error modes regarding performance and memory: In large collections, getting a bunch of IDs one by one with get in loop with selectorFamily can hit CPU to 100% locking main thread in practice. Developer experiencing this opened issue saying "computation takes very long with big array of ids, CPU 100%" sharing example code. citeturn7view0turn8view2 AI can suggest this pattern as "very clean" but problem explodes when scale grows.

Memory side has similar reality: there's issue claiming atomFamily/selectorFamily resources not freed at unmount and key changes, containing strong suggestion like "should be marked _UNSAFE". citeturn7view2 Memory leak reports exist in pattern making atom default lazy init with selector. Issue explains this leak relates to cache behavior and eviction suggestion made with cachePolicy_UNSTABLE. citeturn7view1turn8view0 These don't mean "Recoil is bad" but mean "wrong pattern, wrong cache policy, wrong scale assumption". AI mostly thinks "copy-paste scales".

Ecosystem compatibility for large scale question: Real risk in big project isn't just performance but maintenance and compatibility. Recoil repo being archived and last release note staying in 2023 affects long-term maintenance plan. citeturn10view0turn10view2 In such situation, AI assistant saying "latest Recoil feature" can suggest actually controversial/_UNSTABLE API causing you to lock into it in prod.

Additionally AI's another scale risk in supply chain: models generating code can suggest hallucinated package names and this creating "package confusion" attack surface was examined in detail in large-scale study. citeturn11search0turn11search4 In Recoil ecosystem also third-party tools exist like recoil-persist and recoilize. AI can suggest non-existent package as if exists. This is why I don't accept "package AI suggested equals automatically correct".

Short code examples showing performance and safety belt. Warning large lists plus selectorFamily loop reported as "CPU 100%" in issues. citeturn7view0 Comment I definitely measure this type pattern with profiler. Const resourcesState equals selectorFamily with key resourcesState and get with ids string array parameter showing get function with ids.map id arrow get resourceState id.

Good example consciously choosing cache policy, passes in issue as leak fix suggestion. citeturn7view1turn8view0 Import selector from recoil. Export const safeSelector equals selector with key transactions/defaultSelector, get retrieveTransactions, cachePolicy_UNSTABLE with eviction most-recent. Comment controlled eviction instead of keep-all.

AI versus Human: Recoil output comparison table intentionally simplified. I prepared following table to quickly answer question "can I take Recoil code written with AI to prod same day". Recoil-specific risks like key stability, snapshot retain discipline, family scale, _UNSTABLE APIs affect most criteria. citeturn8view1turn6view2turn7view0turn10view0

Criterion	AI Generated Recoil Code	Human Generated Recoil Code
Correctness	Mostly "works" but fragile in edge cases like retain, race, cache	Validated with behavior-focused tests, modeling according to intent
Debuggability	Snapshot/time-travel errors and "subscribe to all state" traps frequent	Keeps debug tools in dev, snapshot lifetime and cost managed
Maintainability	Key standards, normalization, file organization tend weak	Standards, key dictionary, reusable selector/atom patterns
Package size	Mostly similar but AI can suggest "hallucinated package" (supply chain risk)	Package choice conscious, dependency policy and security scanning exist
Runtime safety	Race condition, memory leak patterns, _UNSTABLE API lock risk	Scale and maintenance plan considered, "archived repo" reality accounted for

5 Things AI Can't Do, Even in Zustand

DevUnionX — Wed, 18 Mar 2026 00:37:39 +0000

This report analyzes in depth technical and conceptual limitations AI assistants can encounter when using Zustand. We addressed the topic under five main headings: store architecture and normalization, complex async flows and side effects, middleware and listener ordering nuances, performance with subscriptions and memoization traps, and migration/update and ecosystem compatibility. Each section includes technical explanations, real error modes where AI gets stuck, GitHub case studies, and code examples.

For instance under Store Architecture heading, how Zustand's persist middleware works and functions added to state cannot be automatically saved were emphasized. AI generally includes a function like login in persist without considering this serialization limitation, and application cannot find this function when reloaded getting error. In Middleware section, noted that order of middlewares like persist, querystring, and immer affects behavior. AI assistants mix up middleware order leading to data merging or priority problems. In comparative table, Zustand code generated by AI and code written by human hand get evaluated in terms of correctness, accessibility, maintainability, package size, and runtime safety. Flow diagram models developer and AI collaboration, showing decision points to check at each stage. From outputs, clearly understood that human supervision is critical in situations AI can easily skip.

For this study, first Zustand's official documentation and README were examined. Then GitHub issues and discussion topics about middleware order, persist problems, subscriptions and related blog posts were evaluated. For instance dev.to article about state persist addressed persistent store's rehydration problems. Literature and case studies examining AI code assistant errors like LinearB research were also utilized. In light of obtained data, five topics were determined and technical details specific to each, code examples, real case study examples, and solution recommendations were developed. Throughout report relevant information was supported with sources.

In Zustand, store structure is flexible but correct modeling of state is important. Though no official normalization tool like in RTK, certain parts of state can be saved to localStorage with persist middleware. For example import create from zustand and persist from zustand/middleware. Const useStore equals create with persist and set function containing user object with name and email, token null, login async function with user and token parameters setting user and token, with name auth-store.

In this code, persist middleware's purpose is making specified slice persistent. But AI assistants can manage side effects in this structure incorrectly. For instance while primitive types like user and token serialize well, login function cannot be stored in JSON. Developer had observed login function disappearing from state when page refreshed. This is expected situation because JSON.stringify only supports primitive types. AI code generally cannot notice this serialization limit, adds login function inside persist expecting it works, but in real life function doesn't get preserved.

AI failure modes: AI thinks store content as simple data trying to serialize complex objects or functions. In this case code AI created saves items that cannot be converted to JSON and cannot access later. For instance a date like new Date or class instance doesn't give value you expect after persist. Additionally using non-normalized large array or object structures also causes repetitive updates. AI generally keeps state organization flat and doesn't separate data dependencies like related objects.

Developer strategies: keep store design simple and use values serializable to JSON. Avoid storing functions and class instances inside state. When using persist, use only pure data like primitive types and pure objects. Manually review store structure AI created. If carries function or complex object, extract these outside state. Manage events inside action instead of functions like login. Manually fix normalization AI skipped, divide state into parts when needed or use separate slices. For instance keeping user information in separate slice and persisting it prevents confusion of functions. Ultimately state model should be planned, AI outputs should be subjected to manual normalization when needed.

Zustand supports async/await directly, doesn't need middleware like redux-thunk. For instance fetchTodos function can be defined directly inside store. However in complex side effect scenarios, AI assistant limitations emerge. Especially in situations requiring multiple async steps or error management, AI can lean toward simple solutions. For instance in scenario refreshing user's token, AI focuses on just adding async to login function and returning expected value. In real life if refresh fails, need to catch error. AI code generally doesn't put try/catch structure correctly. When error happens, application crashes due to uncaught promise. Additionally AI generally does step-by-step async tasks with .then/.catch chain instead of await and forgets returning error. This produces code not suitable for async thunk based state management.

Real example showing user authentication process. AI can produce code like this. Const useAuthStore equals create with set function containing loading false, error null, authenticate async function with credentials parameter. Set loading true. Try with const response equals await api.login credentials, set loading false and user response.user. Catch err with set loading false and error err.message. If AI forgot a problem like set loading false and error err.message, loading can stay true forever or error contains wrong value. In real QA scenario, AI output generally doesn't contain such finally blocks.

Developer strategies: catch errors correctly in every async function. Using try/catch/finally blocks, close loading state in every situation. In mandatory cases additionally trigger with useEffect or onMount. Manually add try/catch or set calls missing in async function from AI. For complex scenarios like unusual side effects and rollbacks, consider using additional helpers from zustand/middleware like subscribe-with-selector. Additionally combination with solutions like React-Query instead of global API calls reduces AI's error-making area.

Zustand combines middleware chain with compose method. For example const useSearchStore equals create with persist wrapping querystring wrapping immer with set function, query params config, and name search. In above code, persist, querystring, immer get applied in order. When order changes, behavior also changes. Developer had observed querystring arrow persist arrow immer order gives different results compared to persist arrow querystring arrow immer order. But AI assistant generally neglects putting middlewares in correct order or does reverse. This leads to errors in state merging and priority ordering. For instance if persist comes first, localStorage gets used first, whereas if querystring comes first, URL parameters gain priority. Wrong ordering can cause unexpected default behaviors.

For listeners also ordering is important. If a subscribe or addListener function will be called from inside middleware or React hook, structure needs preserving. Otherwise can have repetitive calls or memory leaks. For instance if you create subscriber outside store and don't clean, new listener gets added at every page redirect and memory increases.

Developer strategies: check order of all middlewares used. Adjust recommended combination like persist querystring immer by looking at examples in documentation. In store definitions from AI, pay attention to middleware callback function. If static array written, fix it. In subscriptions, use subscribe inside useEffect and do unsubscribe on component unmount. When you see missing unsubscribe in AI codes, definitely add it. Additionally when working with external triggers like URL parameters or storage, check usage examples in each middleware's docs. Briefly side-effect ordering should be manually validated.

Zustand gives useStore hook for selectors where you take desired state slice and subscribe component. However AI assistants generally overlook memoization side. For instance const count equals useStore with state arrow state.counter.value, when used like this, component re-renders only when counter.value changes. But AI sometimes can write like this. Const state equals useStore with state arrow state, or const count equals useStore with state arrow state.counter. This usage causes component to render even when another field in state changes. Thus application slows down unnecessarily. For performance, zustand/shallow or customized equality functions can be used.

When using subscriptions or store.subscribe, also should be careful. For instance a listener triggers at every state update. Especially in large and frequently changing states, callback running at every change slows application. Code written by AI generally contains anonymous functions listening to every change. AI assistant might not specify selected state pieces. For performance, using subscribe with selector and callback is recommended. Also in useEffect plus subscribe usage inside React components, if unsubscribe not called, memory problems happen.

Developer strategies: when using useStore, always select only state fields you need. If possible apply shallow or custom equality function. Review subscriber codes from AI. If anonymous function listening to all state exists, customize this. For example subscribe correctly with const unsub equals useStore.subscribe with state arrow state.token and token arrow console.log Token changed token. Cleanup with unsub. This will trigger only when token changes. Additionally for large state, consider making immutable updates with libraries like immer. But sometimes in AI code, wrong set usage catches eye like set nested with spread. When nesting deepens, prefer using produce with immer. Thus you use clean approach instead of complex update codes AI created.

The following table presents general comparison in Zustand context between AI generation and human generation. Correctness medium containing function serialization, subscriber cleanup, and middleware order errors versus High with persist/rehydration and subscriptions managed correctly and tests done. Accessibility weak with code comments and structure explanations generally missing and state changes can be overlooked versus Good using explanatory slice and selector names and clear error handling.

Maintainability low with short auto-generated codes mostly undocumented in inline usages versus High with comprehensive documentation and examples and well-designed hooks. Package Size low because Zustand is small library so no noticeable difference, Zustand around 1.8KB versus Low again lightweight but extra middlewares can be manually added. Runtime Safety medium with runtime problems like subscription mismanagement and function persistence errors possible versus High with antipatterns tested and warnings tracked in React build process.

The mermaid flowchart shows workflow between developer and AI. In first step, checked whether functions exist in store content. If functions exist, moved to external sources needing serialization. Then middleware ordering and async functions inspected. Finally appropriateness of subscriptions and performance strategies evaluated. After each check when found incomplete, necessary corrections made. This process aims to detect and address error-prone points in Zustand code AI created.

Flowchart shows: Requirements including store model, middleware/listing, async needs. Get Zustand code from AI. Decision whether functions in state. If yes extract these functions outside serialization and return. If no decision whether middleware order correct. If incomplete return. If complete decision whether async operations checked. If incomplete return. If complete decision whether subscribe and performance adjusted. If incomplete return. If complete code review and test approval.

5 Things AI Can't Do, Even in Redux Toolkit

DevUnionX — Sun, 15 Mar 2026 00:16:17 +0000

This report examines important technical and conceptual challenges AI-assisted tools can encounter when using Redux Toolkit or RTK. Beyond conveniences Redux Toolkit offers, situations were addressed where AI assistants can fail in five critical topics: store architecture and normalization, complex async flows and side effects, middleware ordering and composition, performance and memoization traps, and update/upgrade and ecosystem compatibility. Each section provided technical details, concrete scenarios where AI can make errors, and real-world examples.

For instance in Store Architecture, importance of data normalization using createEntityAdapter in RTK was explained. AI generally leads to chaos by putting related data in wrong model. In Async Flows section, example given how not handling errors correctly with createAsyncThunk causes problems. In Middleware section, emphasized that middleware arrangement inside configureStore must be given as callback. If AI gives array directly and doesn't add default middleware, important functions stay missing. Additionally in table we compared AI outputs to human outputs in criteria like correctness, debugging, maintainability, package size, and runtime safety. Because AI code can skip patterns RTK recommends, emphasizes necessity of human supervision and code review. In conclusion, importance of human intervention clearly emerged in Redux Toolkit projects as well.

For this study, first Redux Toolkit's official documents and release notes were scanned. Attention paid to topics like store configuration, asyncThunk usage, middleware configuration, and code migrations. GitHub issues about memory leak and migration and StackOverflow questions were examined. Developer discussions about RTK memory management like immer-sourced leaks were evaluated. Research about AI code assistant limitations like LinearB code analysis was also reviewed. Obtained findings were explained with examples in five topics. Each section contains technical explanations, faulty AI scenarios, code snippets, and development strategies. Citations to sources are directly linked with relevant topics.

Redux Toolkit facilitates structuring store with entity-based normalization. In RTK, normalizing data with createEntityAdapter is common approach. For instance for blog application, posts and comments states can be kept like this. Import createSlice and createEntityAdapter from redux toolkit. Post entity adapter with const postsAdapter equals createEntityAdapter and commentsAdapter equals createEntityAdapter. Example normalized initial state with posts as postsAdapter.getInitialState, comments as commentsAdapter.getInitialState, and users as empty array. Slice using state update with const postsSlice equals createSlice with name posts, initialState posts, and reducers containing postAdded as postsAdapter.addOne and postsUpdated as postsAdapter.upsertMany.

createEntityAdapter facilitates performing update in single center by storing each item in only one place. AI tools generally skip this normalization. For instance can keep related post and user objects in different places both in posts and users slice, making update synchronization difficult. AI writing plain state.posts equals array with spread without knowing RTK standards like entityState breaks normalization. As result reducers become complicated, to update a record requires operating on many slices.

Developer strategies: normalize state using createEntityAdapter. Check AI output ensuring each data type gets stored using singular IDs. If needed examine RTK's example projects. Restructure AI's plain array or nested object suggestions with adapter. Do immutable updates with adapter's methods like addOne and setAll. Normalization especially in related data reduces bug possibility. If AI violates normalization rules, reorganize files ensuring compliance.

Redux Toolkit manages async actions with tools like createAsyncThunk. However AI helpers can use this structure incorrectly. For instance error handling topic is critical. If you don't catch error inside createAsyncThunk, promise automatically gets rejected triggering rejected action. But AI generally returns all errors with return and marks as fulfilled. In such situation application goes to success state instead of error. In StackOverflow question, developer using try/catch inside createAsyncThunk observed returning fulfilled when network cut. As solution in response, emphasized correct to directly await Axios call leaving without catching error. Another method is using rejectWithValue.

Export const fetchData equals createAsyncThunk with data/fetch and async function with id and rejectWithValue parameters. Try with const response equals await api.get id, return response.data. Catch err with return rejectWithValue err.message as part AI skips. AI code mostly doesn't think to use rejectWithValue and writes return err after try/catch, detecting error as fulfilled. Thus UI can turn to wrong data instead of error.

Regarding conditional operations and listener, tools like createListenerMiddleware or RTK Query recommended for more complex flows. AI most times tries solving problem with manual setTimeout or Promise chain. For instance in application needing renewal when user's token expires, listening to userLogin event inside createListenerMiddleware and renewing token is more robust instead of manual dispatch logout. AI might not think best in such effect-heavy scenarios.

Developer strategies: use RTK's tools correctly for async operations. Review async thunk codes from AI, errors should be handled with rejectWithValue instead of directly returning. Also apply advanced methods like createListenerMiddleware or onQueryStarted with RTK Query. Provide control with methods RTK offers instead of manual promise. Briefly if you see missing error catching or wrong async configurations in AI codes, make correction with examples in RTK documentation.
In Redux Toolkit, middleware chain given with configureStore determines arrangement. As of RTK 2.0, middleware must be defined in callback function. If you give direct array, default middlewares like thunk and serial check don't get added. For instance middleware array with myMiddleware definition doesn't add default thunk leading to unexpected deficiencies. According to RTK upgrade guide, middleware should only be callback, otherwise thunk and debug middlewares don't activate.

AI assistants miss this detail. AI code typically writes like this. Const store equals configureStore with reducer rootReducer and middleware array with loggerMiddleware showing wrong here because default middlewares not added. In this example, if AI gave middleware directly as array, means no thunk RTK recommended. Correct usage should be like this. Const store equals configureStore with reducer rootReducer and middleware as function getDefaultMiddleware arrow getDefaultMiddleware().concat loggerMiddleware showing checkmark default middleware also added.

Additionally RTK's control middlewares like serializableCheck or immutableCheck get provided automatically. These staying deactivated in AI code leads to runtime errors. Developer strategies: ensure configureStore.middleware usage done correctly by AI. If AI suggests array, convert it to callback format combining with getDefaultMiddleware. Check middleware count AI added, unnecessary plugins affect application performance. createListenerMiddleware or RTK Query providers generally should be taken to bottom of list. Since default middleware usage already emphasized in RTK documentation, always validate thunk is added.
RTK provides selector and memoization tools but AI generally skips these. When using useSelector, if complex calculations exist, memoization should be applied with createSelector. For instance when filtering product list, simple selector can be written like this. Export const selectAvailableProducts equals state arrow state.products.filter with p arrow p.available. This code applies filter at every state change. Whereas can be memoized using Reselect like this.

Import createSelector from redux toolkit. Export const selectProducts equals state arrow state.products. Export const selectAvailableProducts equals createSelector with selectProducts and products arrow products.filter with p arrow p.available. Code written with AI assistance mostly doesn't contain this optimization. Calculating at every render in large lists leads to performance problem. RTK's tools like createEntityAdapter provide fast CRUD on similar data. AI sometimes manages data with raw array operations doing unnecessary copying. Other problem in AI code is adding unnecessary code to build, pulling entire package from libraries like lodash increases bundle size similar to code binding.

Developer strategies: using memoization in every createSelector or slice should be mandatory. Wrap operations like filter or map in AI code with useMemo if need to calculate once and store. RTK using immer in immutable updates optimizes change by default, therefore pay attention to deep copies. If possible paginate taking large states in components. Against extra dependencies AI suggested, import only really needed lodash methods like import get from lodash/get format. Measure performance with tools like Redux DevTools Profiler discovering bottlenecks.

The following table presents general comparison in RTK context between AI generation and human generation. Correctness low with wrong normalization, faulty async thunk management, missing default middleware usage versus High with configuration compliant with RTK recommendations, necessary middleware and error handling exist. Debugging Ease medium with actions and state structure mixed, RTK DevTools provides most info but errors stay hidden versus High with naming of createSlice and thunks, debug tools like RTK Query used.
Maintainability low with AI outputs generally containing repetitive hard-to-understand codes versus High with little code using createSlice and createAsyncThunk, clear structure, explicit comments. Package Size medium with possibility of unnecessary library loading, code block conflict if thunk missing versus Low with tree shaking effective, minimal dependencies with RTK recommendations. Runtime Safety medium with wrong data type management like serialize errors, memory leak risk with immer versus High with immutable updates, serializable state guarantee, strict TS type usage.

The mermaid flowchart shows developer first reviews Redux Toolkit code obtained from AI for normalization, async thunk usage, and middleware. If deficiency exists, corrects and repeats process. Thus AI output passes through human control. For instance in RTK upgrades, need to convert object form to builder form for extraReducers. Every step AI skipped should be manually completed by developer.
Flowchart shows: Requirements including RTK installation, slice structure, async requirements. Get Redux Toolkit code from AI. Decision whether state normalization done. If no normalize with createEntityAdapter and return. If yes decision whether async thunks and error handling appropriate. If incomplete return. If complete decision whether middleware configuration correct. If incomplete return. If complete decision whether memoization and performance optimization done. If incomplete return. If complete code review and live test approval

5 Things AI Can't Do, Even in Redux

DevUnionX — Fri, 13 Mar 2026 21:51:34 +0000

This report examines technical and conceptual limitations AI-assisted tools can encounter when using Redux. Deep analysis will be presented under five topics in context of Redux's unique architecture and ecosystem: store architecture and normalization, complex async flows and side effects, middleware ordering and composition, performance and memoization traps, and update/migration and ecosystem compatibility. Each section includes technical details, concrete error modes explaining why AI fails, real-world examples from GitHub issues and case studies, and code snippets.

For instance in Normalization section, data normalization format Redux recommends is explained and keeping each data type as separate table gets emphasized. AI assistants can make errors in normalizing complex related data deeply in one go, locking update operations. In Middleware section, emphasized that ordering written inside applyMiddleware directly determines operation. According to StackOverflow answer, defined middleware gets processed in order, changing ordering later isn't possible. AI code sometimes depends on flow inside function instead of middleware order, creating unexpected behaviors. Table compares AI and human outputs with criteria like correctness, debugging, maintainability, package size, and runtime safety. Finally mermaid diagram summarizing developer and AI collaboration shows which decisions to make at each stage. Study results clearly reveal human supervision still needed in Redux projects due to AI limitations.

For this report, first official Redux documents and Redux Toolkit documentation with release notes were compiled. Then StackOverflow questions, GitHub issues, and blog posts were scanned, for example normalization, middleware flows, and performance issues. Migration stories about async flows and side effect management like thunk versus saga were examined. Memory leak and performance-focused case studies like weakMapMemoize problems in a Redux Toolkit version were addressed. Literature about AI code assistant limitations like LinearB code quality research was also reviewed. Obtained findings were explained with technical clarifications, code examples, and solution recommendations under five topics. Each section cited relevant sources and AI error modes were supported with real examples.

Redux store generally gets structured with data normalization method. In official Redux guide, normalized structure is recommended for complex related data. That is, separate table gets created for each data type and items get stored with their IDs. For instance blog posts and comments get kept in separate objects, relationships established only through IDs. Example showing normalized Redux store structure. Const initialState with posts object containing byId with post1 containing id, title, commentIds array, and allIds array, comments object with byId containing c1 with id and text, and allIds array, users object similar.

Thanks to normalization, each item gets defined in only one place, thus update operations get done in single center. AI tools can skip this concept, might try storing complex nested data structure inside single-piece state. For instance if an AI tries keeping both posts and comments list inside state.posts, data updates get processed in two different places increasing error risk. Additionally in non-normalized structure, deep data updates require writing code nested and increase error-making possibility.

AI failure modes: AI-assisted code can embed related data in same object and skip normalization. In this case update logic inside reducer gets complicated. For instance to update author name in blog post, both author object inside post and author object in users list should be updated. AI generally tries handling this with single-line code getting wrong result. Additionally might prefer making customized normalization without using Redux Toolkit tools like createEntityAdapter. Ultimately can lead to inconsistencies in state structure and unexpected re-renders.

Developer strategies: use really normalized state structure. Adopt byId/allIds model shown in Redux documents. Definitely review state structure AI suggested. If nested repeating data exists, apply normalization. Benefit from examples coming with RTK's createEntityAdapter or createSlice. Update reducers become simpler in normalized structure. If AI neglected bringing normalization, manually fix store. Ultimately consistent and normalized state arrangement especially in complex data relationships reduces error possibility.

Redux basically doesn't manage asynchronous workloads, for this work middleware or additional tools like thunk, saga, observable are needed. AI assistants might not combine these structures correctly. For instance when using Thunk, might mistakenly return async function itself instead of dispatch or can write wrong try/catch. Additionally for multiple async steps might completely skip solutions like saga or RTK Query trying to produce manual solution. Real-world example: developer had created pattern like dispatch asyncThunk then when using asyncThunk. AI lost control after dispatch by not managing this promise chain properly. Such errors led to not catching errors or unexpected state updates. On other hand in project using Saga, AI-sourced code used take instead of takeEvery, causing only first action to work and listening to stop afterward.

AI failure modes: AI leans toward simple solutions in async workflows. For instance tries writing all business logic inside single Thunk for complex REST call, whereas generally dividing to side effects layer like saga or RTK Query is more correct. AI additionally can skip error catching by using .then instead of await in promise-based calls like axios. AI code falls short in reflecting errors occurring during side effects to Redux state, for instance can forget using rejectWithValue.

Developer strategies: use tested methods for async flows. Proceed with createAsyncThunk, createListenerMiddleware, or saga templates in React-Redux application when possible. Definitely look at try/catch blocks in code from AI. When triggering an action, ensure you handle and dispatch both success and failure states. For advanced scenarios examine redux-saga or redux-observable approaches. Since AI won't do automatic configuration, manually integrate according to documentation examples. Carefully review Thunk or saga codes AI generated, validate async steps are complete.

Redux middlewares are functions intercepting when actions get dispatched. Order is very clear. Middleware array defined as applyMiddleware m1, m2, m3 processes in exactly that order. That is if you wrote m1, m2, m3, m1 first then m2, when m3 comes real reducer runs. StackOverflow answer clearly expressed this: middleware pipeline exactly matches order you wrote to applyMiddleware and you cannot change after creating it. AI assistant generally misunderstands middleware flow. For instance wrong AI output puts protective middleware at end of list thus running after all actions processed, whereas this middleware should be placed at start to break actions like blocking unauthenticated ones. AI additionally can confuse relationships with compose or combineReducers. Common error is forgetting next call in async middleware. In this case no reducer runs and action stays halfway.

Example showing filtering actions in middleware. Const logger equals store arrow next arrow action with console.log dispatching action, return next action with warning that without next action ends here. Above if next action not added, action chain stops here. This omission can be easily made when written by AI. Developer strategies: carefully plan middleware ordering. Review applyMiddleware order AI suggested, pay attention whether critical middlewares like auth check or error reporting are in right place. Ensure next action not missing in function definitions. If using multiple middlewares, design so they don't interact with each other. For instance ensure thunk or saga middlewares are definitely in bottom order so other middlewares can see async actions. Verbal test: check by asking Does action continue flowing without this middleware.

Performance and re-render behavior of Redux applications relate largely to memoization and selective updates. AI assistants generally produce unnecessary recalculations. For instance if complex calculations exist inside useSelector and this selector not memoized, recalculation happens at every state change. AI sometimes forgets using createSelector. Whereas memoized selectors don't do calculation when called again with same inputs. Real example: when developer wrote selector to filter from products list, AI code did like this. Export const selectFilteredProducts equals state arrow return state.products.filter with p arrow p.visible and p.stock greater than 0. This code does filtering after every dispatch. Instead should have used memoized selector with reselect.

Additionally instead of storing large lists in Redux state should be solved with other methods like pagination or off-memory DB. AI most times when updating large arrays kept in state keeps old objects even due to immer and memory usage increases. For instance when updating list of 100,000 items, approach like setState with spread causes both high package size and heap growth. If using RTK, consider doing normalization and memoized operations with createEntityAdapter.

Developer strategies: make using reselect or RTK createSelector mandatory in selectors. In complex state changes use immutable methods like RTK's current function instead of shallow copy. When you see large constant lists in AI code, question whether these really need to be kept in state. Optimize React components with useMemo or useCallback. After each render look at console which components re-rendered. Detect bottlenecks using performance tools AI might have forgotten like Redux DevTools Performance tracing. Ultimately you can speed up application by manually removing performance traps that can emerge in AI code.

The following table presents general comparison in Redux context between AI generation and human generation. Correctness low with wrong normalization, missing side-effect management, wrong middleware order versus High with state normalization, async flows, middleware order validated. Debugging Ease weak with action history DevTools meaningless and error origin point unclear versus Good with regular action type and state structure, understandable tracking with DevTools.

Maintainability medium with much code repetition and lack of comment seen in AI code versus High using RTK and slice structure, clean code, good documentation. Package Size medium with unnecessary dependencies like all lodash packages possibly added versus Low with only needed libraries, tree shaking and bundle analyses done. Runtime Safety medium with API errors and memory leaks like circular references visible versus Good using immutable updates, appropriate memory management and error handling.

The mermaid flowchart summarizes AI collaboration in Redux development process. First store architecture and normalization checked, if needed state gets organized. Then correctness of async tasks and middleware flow evaluated. Performance optimizations like memoized selectors addressed. After passing all stages, code tested and approved. If error found, returns to process. At each step if deficiency exists, intervention should be made to AI code.

5 Things AI Can't Do, Even in Babel

DevUnionX — Thu, 12 Mar 2026 20:50:13 +0000

This report addresses limitations emerging when using Babel with AI-assisted tools. Five main topics examine Babel's plugin and transform pipeline, AST-level transformations and semantic intent, source maps and debugging, performance and caching determinism, and compatibility with polyfill and runtime semantics. Each section provides technical explanations, frequent error modes AI falls into, and real-world examples. For instance in Transform Pipeline section, how critical plugin application order is gets emphasized. According to Babel documentation, plugins get applied in order they're written in configuration file, while presets work in reverse order. In a GitHub error, when import placement done incorrectly in automatic JSX transform with importPosition after, error occurred in Jest tests. Such surprises are details AI assistant cannot notice.

In AST Transformations section, Babel's operation steps on AST and its limitations are explained. Babel parses a file, processes AST, then converts back to source code. During this process, for example Recast library's original attribute can be lost and differences appear in format information. Adding strict mode between codes is typical example of this. In Source Maps and Debugging section, explained that even AST traversal without transformation can break source map. AI assistants generally skip source maps, leaving errors pointing to transformed code instead of original file in browser console. Ultimately, code generation without detailed review and testing with Babel leads to incorrect or hard-to-debug results.

Table compares Babel configurations generated by AI with configurations written by human hand in terms of correctness, debugging ease, maintainability, deterministic build, and runtime compatibility. This analysis bringing curious points to forefront shows human supervision is essential in Babel projects as well. For this study, primarily official Babel documents and changelogs were examined. Notes about plugin API and compilation process from StackOverflow and GitHub issues were collected. For real-world problems, relevant GitHub issues and community blogs were scanned, for example React JSX plugin error and Recast integration. For source maps and error management, MDN and Babel guides were reviewed. AI code assistant analyses were also included. Obtained data was processed with examples in five distinct topics with Babel's own terminology. In each section technical explanations, concrete error modes, code examples, and remediation strategies were given. Report flow was arranged to facilitate developer reading.

Babel performs code transformations with plugins and presets. Important subtle point is application order. Plugins run in order written in configuration, while presets get applied in reverse order. For example in .babelrc, with plugins array containing transform-decorators-legacy and transform-class-properties, and presets array with babel/preset-env and babel/preset-react, in this configuration first transform-decorators-legacy then transform-class-properties plugins get applied. For presets, React preset then Env preset activates, preset order gets reversed. Wrong ordering can cause code to be transformed unexpectedly.

For example in error reported on GitHub, babel/preset-react automatic JSX transform with runtime automatic was placing import lines in wrong position. In this case jsx-runtime imports were added to end of other code and jsxRuntime stayed undefined in Jest tests. Simply if not set as importPosition before, AI code output can lead to timing error. AI failure modes: AI assistants generally skip or misunderstand plugin order. Doesn't think about a plugin's interaction with previous transformation. For instance if order of usages like class properties and decorators is wrong, solution path breaks. Nuances like using preset mixture instead of plugin can be overlooked in AI code. Additionally compile-time options like only/ignore filters and env.targets can be skipped. According to official Babel configuration examples, plugin orders and presets compatibility should be manually validated.

Developer strategies: pay special attention to ordering. When reviewing .babelrc or babel.config.js outputs from AI, ensure plugin array is in correct order. If custom plugins used like parserOpts.plugins, these should be configured in right place. If you see a transformation giving error, test by swapping plugins. Like in above JSX example, temporary solution was found by changing importPosition setting. Ultimately manual check is mandatory that plugins are running in ordering that will produce effect you want.

Babel first makes source code into AST or Abstract Syntax Tree, then manipulates this AST and converts back to code. AST-level transformations frequently require expertise. For instance a syntax plugin only prepares parser for new syntax, while transform plugin converts AST nodes to target language. This three-stage process looks like this: parsing source code to AST, modification/transformation on AST, and printing AST back to source code. AI failure modes: AI code generators can misinterpret AST clarifications. For instance to transform a class property, generally both syntax and transform plugins are needed. Inspired by above example, if only transform plugin added and syntax plugin forgotten, Babel cannot parse unconventional syntax.

According to SO answer, if code contains new syntax like at.foo semicolon, for parser to understand this, syntax plugin must be used first, otherwise error gets received in AST creation. AI tools sometimes miss this difference and focus only on transformation part. Another example is difficulty of transforming without breaking code's meaning. In error report on GitHub, original information Recast library added to AST nodes got lost during Babel transformation. As result, as seen in images, code's format changed with use strict added and line endings shifted. This is side effect difficult for AI to notice. Transformer code actually works correctly but format in original source gets lost.

Another error mode is transformers overlapping or creating opposite effect. For instance while transform-classes plugin changes constructor function, if another plugin makes different change to same node, order matters. In AI-assisted code, situations where two plugins conflict with each other can be overlooked. Developer strategies: ensure plugins are used appropriately for their purpose. Syntax plugin automatically added by AI should be checked. If code still cannot be parsed, syntax plugin or preset might be missing. In plugins changing AST, sometimes directives like path.skip or path.remove being in wrong place inside visitor can break transformation. When working with tools like Recast, when functions like babel.transformFromAst are used, pay attention that original information doesn't get thrown away. If difference occurs in format after code transformed like added use strict or line shifts, consider checking these transformation settings or generatorOpts parameters. Ultimately AI codes definitely require logical review at AST level.

When using Babel, source maps and error tracking are very critical. When Babel transforms code, generally adds or removes new lines, causing error when looking at original file. In real example, even though no change made on AST, transformFromAst function broke source map because processed spaces differently. For instance formatting differences in return writing gets marked by compiler skipping point. As mentioned in StackOverflow answer, AST transformations break source map, therefore producing new maps becomes mandatory. In AI-assisted code, source map generally gets overlooked. Developer might notice code appearing error-free explicitly references different lines in dev tool. Error messages come according to code Babel generated, not original code. For instance if Unexpected token error given, in transformation created with AI templates might have no relation to actual line.

Regarding debugging and stack trace, Babel's error reports are sometimes misleading. For instance in errors like TypeError undefined during a test, AI code generally shows transformed names. Tools like babel-code-frame might be needed to reach code's actual source. Additionally during babel/plugin-transform-runtime or babel/polyfill usage, global variable conflicts can emerge. AI can easily neglect these. Developer strategies: create new source map after every Babel transformation. As mentioned in above SO response, update maps using transformFromAstSync with ast, code, and options including sourceMaps true and inputSourceMap oldMap. By developer's hand, should be validated that lines error messages show match original source lines. When working with Babel CLI or Webpack plugins, devtool source-map settings should be configured correctly. When you get error under code, check AST output examining spans and location information. Additionally if you see Babel helper function names in error stack traces, babel-code-frame or Chrome devtools Decompiler features should be used. Ultimately Babel configuration from AI should definitely be gone over to allow tracing and mapping error source after every transformation.

Babel affects compilation times and package sizes especially in large projects. Babel configurations generated by AI generally contain unnecessary plugins or complex plugin chains. For instance should be tested whether plugin doing every transformation gets applied. Using many small plugins might not provide significant advantage. Performance-wise, build caching like babel/plugin-transform-runtime and babelHelpers should be configured correctly. Additionally Babel might not behave deterministically even when input source doesn't change. Some plugins can assign random IDs. Regarding caching, when using Webpack/Babel loader, options like cacheDirectory being open seriously shortens compilation time. AI code can generally forget this step. Real case: in large monorepo during Babel 8 update, all packages' compilation took seconds when cache was open versus reaching minutes when closed.

Regarding determinism, some plugins can give different results at different compilation times. For instance generating unique helper function names at each run with babel/plugin-transform-runtime. AI assistant cannot see reason for this. For build to stay deterministic, Babel's modes like assumeMutableTemplateObject or loose might need to be fixed. In current Babel options there's no parameter like deterministicUUIDs, therefore additional checks should be put in AI-generated configuration to get same result.

Developer strategies: reduce plugin count for Babel performance, do only necessary transformations. In Webpack enable loader cache with cacheDirectory true and cacheCompression false. In plugins AI recommended like transform-runtime, test options like helpers true or regenerator false. Repeat builds several times comparing results. If difference exists, review configuration. Before taking ready solutions AI advised to production, do performance tests in your own application.

Babel is used to convert language's new features to old environments. But AI assistants can fall short on this topic. For instance during babel/preset-env usage, if target browser list or targets not determined correctly, some polyfills don't get added or get added unnecessarily. In real migration story, when a team mistakenly used entry mode instead of useBuiltIns usage with preset-env, bundle size grew astronomically, AI recommendations couldn't see this. Regarding polyfill mismatches, core-js and regenerator-runtime configuration generally gets skipped in AI tools. In a bug report, AI code transformed code supporting async/await and didn't add needed runtime, giving error in browser.

Regarding runtime differences, some semantic changes happened between Babel 7 and 8. For instance in topics like new pipeline operator or private fields, runtime behaviors changed. AI's automatic update can ignore these differences. Additionally in special modes like JSX Runtime, runtime like React jsx-dev-runtime should be manually configured. Regarding security and compatibility, when using babel/plugin-transform-runtime, selecting correct corejs version is important to prevent global pollution. AI doesn't test wrong corejs version compatibility.

Developer strategies: customize babel/preset-env configuration appropriately for your project. Give targets list explicitly and validate which polyfills get added, see browserslist structures. Manually check options like regenerator true/false and corejs AI added in code. In migration projects, create small test files to validate runtime semantics like private class field and optional chaining. In Babel version upgrades, examine changelog. If AI code doesn't notice feature requiring polyfill, manual addition should be made. Ultimately configure Babel not just automatically but manually according to your needs.

The following table presents general comparison in Babel context between AI generation and human generation. Correctness low with wrong plugin ordering and missing parser plugin causing incorrect transformations versus High with AST changes and semantic transformations checked. Debugging Ease weak with broken source maps and unclear stack trace, errors not matching original code versus High with code and original source matching and clear error messages received.

Maintainability medium with complex configurations and lack of comments, AI code generally doesn't contain lines/comments versus High with clear configuration and comments, well documented. Build Deterministic low with different results in concurrent builds, some plugins are non-deterministic versus High with caching active and consistent output provided with same config. Runtime Compatibility medium with missing polyfills and wrong runtime settings like jsx-runtime common versus High with polyfill and runtime requirements like core-js and runtime properly set.

The mermaid flowchart models a developer-AI collaboration. At start, .babelrc or babel.config.js configuration obtained from AI gets checked for ordering and plugin/preset usability. If needed ordering gets adjusted. Next step validates transformations to be done on AST like React JSX and ESNext syntax. Then source maps and debug methods examined, map creation process AI skipped gets added. Performance settings and caching mechanisms like Babel cache and transform-runtime settings get tested. At each step if problem exists correction made, at very end process completed with manual test and code review. Through this loop, Babel code AI generated gets cleaned from errors.

5 Things AI Can't Do, Even in Svelte.Js

DevUnionX — Thu, 12 Mar 2026 01:08:56 +0000

This report examines in depth the limitations in Svelte.js development process with AI-assisted tools. Considering Svelte's compiler-based architecture, technical and conceptual challenges were analyzed in five topics: component semantics and composition, reactivity model and complex state flows, compile-time versus runtime behavior and edge cases, accessibility and ARIA integration, and performance with build toolchain and scale compatibility. In each topic Svelte-specific rules were explained and supported with concrete error examples AI makes and case studies.

For instance in Reactivity Model topic, Svelte's reactivity based on variable assignments gets emphasized. When you update values inside object or array, for compiler to detect this you need to make assignment to variable itself. If this gets neglected in AI-assisted code, updates don't reflect to DOM. Additionally limitations arising from Svelte's compile-first design were examined. For instance html tag might not do correct hydration after SSR, or reactive classes like MediaQuery don't give correct result during SSR because no browser measurement exists. In each section, code examples and failure modes were addressed and solution paths discussed. For example to prevent async errors, using onMount and tick, cleanup with effect in code snippets shown.

Table at end of writing compares Svelte code generated by AI with code written by human in criteria like correctness, accessibility, maintainability, package size, and corporate compliance. Finally a mermaid diagram showing developer plus AI workflow summarizes process steps. Findings clearly reveal that human supervision and experience remain indispensable in Svelte projects. For this study, primarily official Svelte documents and release notes were examined. Reactivity, compile-time features, and performance recommendations were scanned in detail in Svelte documentation. Then feedback from Svelte developer community including GitHub issues, blog posts, StackOverflow questions was evaluated. For accessibility standards, MDN and W3C/WCAG sources were reviewed. Literature and case studies analyzing errors in code AI code assistants wrote were also compiled.

Obtained data was processed in depth in five main topics specific to Svelte. Under each topic, technical explanations, concrete error scenarios, example codes, and solution strategies were presented. Each section of report was supported with results using relevant and priority sources. Svelte components require tight integration with HTML. Interaction between components is provided with props and createEventDispatcher. Semantically, developer should always prefer valid HTML tags and avoid unnecessary wrapping. For instance when creating list item with li tag, this must definitely be inside ul or ol. Though not an error from Svelte itself, AI sometimes can make similar semantic incompatibilities.

Another situation is bind:this usage. Svelte offers bind:this directive to get reference to DOM nodes. In following example, an input element gets bound to nameEl variable getting reference and after form submission gets pulled back to focus with focus. Script. Let name equals empty string. Let nameEl for DOM element reference. Function addTodo. Add new task operation. Name equals empty string. nameEl.focus for giving focus back to input. Script. Input bind:value equals name bind:this equals nameEl id equals todo-input. Button on:click equals addTodo disabled equals not name showing Add.

Code generated by AI might skip this kind of bind:this usage leading to focus management problems. Also correct positioning of component contents with Svelte's slot mechanism is important. For instance modal component content should be placed with slot. AI sometimes might suggest transition with methods like direct innerHTML, which can be problematic in terms of accessibility and maintainability.

Developer strategies: semantic HTML usage in AI code should always be reviewed. For instance instead of adding role equals button to elements that aren't button, use real button when possible. Props and event dispatch structures should be defined correctly. Missing createEventDispatcher usage in AI code should be carefully checked. If submission preventDefault or custom directive usage needed, should be manually added. When operations toward focus requiring bind:this usage are seen in code, should be manually added if AI skipped. Ultimately component composition should pass through human supervision.

Svelte offers compiler-based reactivity system. State changes typically get tracked with assignment equals or dollar colon reactive declarations. Important rule: for Svelte to understand a variable updated, variable name needs to be on left side of assignment. For instance in reference types like arrays and objects when element update done, Svelte might not detect this. In following MDN example, completed field of items inside todos array gets updated but Svelte doesn't notice. Const checkAllTodos equals with completed parameter. Todos.forEach with t arrow t.completed equals completed. Todos equals todos notifying Svelte of change.

In this code, though each item of array updated, Svelte doesn't observe this update because array itself didn't change. As solution, reassignment done like todos equals todos, this way compiler understands variable got modified. Alternatively updating each item from array's index or assigning completely new array also works, for example todos equals todos.map with t arrow spread t with completed. AI assistants generally might not remember this reactive assignment rule. For instance might do t.completed equals directly inside todos.forEach and finish code, in this case UI doesn't update. Similarly in complex state management, usage of derived stores can be neglected. As example:

Import writable derived from svelte/store. Export const cartItems equals writable empty array. Export const cartTotal equals derived cartItems with dollar items arrow items.reduce with sum item arrow sum plus item.price times item.qty starting at 0. This way when items in cart change, total automatically updates. AI might miss that it should use derived instead of just simple forEach loop.

Failure modes: frequent error related to reactive updates is DOM not renewing due to forgetting variable assignment. Outside above todos example, in situations like obj.property plus equals 1, Svelte thinks obj as a whole didn't change. Additionally when using a store, mixing dollar store versus get store or using structures compiler cannot track gives wrong result. As real case, developers sometimes experience memory leak with store subscriptions not cleaned, for example not canceling subscription in onDestroy. Such cleanups can be overlooked in code written by AI.

Developer strategies: check reactive dollar colon declarations and direct variable assignments. If object or array modification exists in AI code, ensure relevant variable gets reassigned. If this isn't possible, create new data structures with methods like map or slice doing same operation. Apply derived or subscription subscribe usage correctly in stores. Do manual supervision in complex state flows. For instance test dollar colon blocks, validate cyclic assignments get cleaned. Ultimately you should adapt code to Svelte's reactivity rules in way compiler will understand.

One of Svelte's most important features is generating code optimized at compile time. This design doesn't require framework with no virtual DOM and lightens runtime. However this approach brings some edge cases. For instance in Svelte 5 version there's bug report about html tag usage, this marker isn't validated after SSR leading to unexpected behavior. AI-assisted code cannot see such version-specific errors so can fall into same trap. Svelte also enables Server-Side Rendering SSR. But some APIs don't work in SSR. For instance Svelte's MediaQuery class cannot give correct value server side because no browser measurement, leading to content change during hydration.

If this gets overlooked in AI code, production and browser output can be incompatible. Lifecycle hooks also matter. Code inside onMount runs only on client. AI sometimes can put operations requiring DOM access like document or window access in places that shouldn't run in SSR. This creates both error and SEO problem. Example showing only dispensable data requests should be made in load function below. If AI fetches large amount of data inside load, render time gets longer.

Script context equals module. Export async function load with fetch parameter. Const res equals await fetch /api/posts. Return posts equals await res.json. Script. SvelteKit documentation emphasizes data not needed shouldn't be pulled to client side immediately. This might not be considered in AI code.

Developer strategies: review Svelte code AI generated considering compile time. Ensure codes requiring SSR are separated with conditions like onMount or dollar client. Check whether custom directives AI uses like use:action and bind are in right place. Track version-specific errors from Svelte announcement pages, for example html problem. For performance, apply code splitting lazy-load where SvelteKit supports dynamic import. In above load example, extra data can be precompiled with prerender or pending properties can be used. Briefly pay attention to runtime and compile-time distinctions avoiding breaking assumptions Svelte is optimized for.

In applications developed with Svelte, accessibility is provided with semantic HTML and correct ARIA usage. Official documents emphasize all elements requiring user interaction should be accessible and usable with keyboard. For instance in a form when input field created dynamically using bind:this equals inputEl, focus should be set correctly with inputEl.focus function. AI assistants might skip focus management and event properties like Enter and Escape key. In MDN Svelte example, user experience improved by calling cancel function when Escape key pressed with on:keydown. Such keyboard shortcuts generally don't get added to AI outputs.

Another point is usage of ARIA attributes and semantic tags. When selecting tag names in Svelte components, screen reader compatibility should be considered. For instance real button should be used instead of div role equals button. Example situation: in modal or popup component, aria-modal equals true and role equals dialog should be added and focus trap precautions taken. This is generally missing in AI code. Additionally attributes like aria-label and aria-labelledby in HTML tags must definitely be added if buttons or links aren't clear. In MDN advanced Svelte guide, focus order arranged so focus loss doesn't happen with tab key. AI outputs might not pay attention to focus shifts.

Developer strategies: adhere strictly to semantic HTML usage and ARIA guides. Every tag like button, input, form in AI code's needed accessibility attribute like aria attributes and label-id association should be checked. For focus management and keyboard access, handlers like tabindex and on:keydown should be added. Consciously use focus-visible in places where focus emphasis gets lost with CSS. After getting reference to DOM nodes with bind:this in Svelte, focus giving strategy should be considered in component lifecycle like onMount. Don't forget to manually provide these details AI might bypass.

In Svelte applications package size and build optimization carry great importance. Svelte's compiler structure provides tree-shaking built-in, but external dependencies should still be checked in bundler configuration. For instance AI code frequently generates by importing entire large libraries like import underscore from lodash, whereas with proper structuring only needed functions should be included like import uniq from lodash-es. In SvelteKit documents, noted that code with static import will load with page. If lazy load forgotten in AI outputs, initial load grows unnecessarily. In developer blog above, dynamic loading of components like modals or admin panels with import inside onMount was recommended. AI-assisted structures not doing this worsen performance.

Another matter mentioned in SvelteKit performance notes is version updates. Svelte 5 is faster and smaller than Svelte 4, Svelte 4 also faster and smaller than 3 is recommended. This is an optimization missed when AI assistants recommend old version codes or don't track updates. Additionally AI generally skips package analysis. As developer should examine bundle size with tools like rollup-plugin-visualizer and vite-bundle-visualizer, replace large dependencies.

Example showing modal loading with dynamic code splitting. Script. Import onMount from svelte. Let ModalComponent. onMount async arrow function. Const module equals await import ./Modal.svelte. ModalComponent equals module.default with Modal component now loaded. Script. If ModalComponent. svelte:component this equals ModalComponent. If. With this method, code segmentation done instead of always import Modal from ./Modal.svelte in code from AI.

Developer strategies: manually check package imports in AI code, prefer including only needed functions. Make dynamic import usage mandatory in compiler and bundler settings. For instance in SvelteKit load functions, pull only critical data instead of loading everything and create static page with prerender equals true. For interactive elements like image lazy load and UI components, use built-in loading equals lazy attributes. Finally during production pre-build process like npm run build, check build minify true settings. These optimizations AI will overlook should be applied manually.

The following table presents general comparison in Svelte context between AI generation and human generation. Correctness low prone to reactivity and lifecycle errors, can make SSR cliche errors like html versus High with compiler warnings considered and edge cases tested. Accessibility medium with focus order and ARIA attribute generally forgotten versus Good with semantic element and keyboard navigation properly set.

Maintainability low with repetitions and lack of explanation in auto-generated code pieces versus High with code component-based organized and enriched with comment lines. Package Size large high due to unnecessary dependencies and static imports versus Low minimal with only needed modules and dynamic imports. Brand Fidelity weak with CSS and theme compatibility, style guide inconsistency visible versus High with configuration compliant with corporate style rules provided.

The mermaid flowchart shows developer checking Svelte code from AI primarily for component structure and props/emits. Then reactive rules like variable assignments get inspected. SSR and CSR distinction like onMount and dollar browser usage gets reviewed. Next step includes accessibility with keyboard navigation and ARIA and performance optimizations including bundle size and lazy-loading. At each step when deficiency detected, correction made, at end of process code approved. Details AI skipped get completed with manual review.

[Boost]

DevUnionX — Tue, 10 Mar 2026 21:22:38 +0000

VueJs future new language of the Web ecosystem?

DevUnionX ・ Mar 10

#vue #javascript #webdev #programming

VueJs future new language of the Web ecosystem?

DevUnionX — Tue, 10 Mar 2026 21:17:29 +0000

5 Things AI Can't Do, Even in Vue.js

DevUnionX ・ Mar 10

#vue #javascript #webdev #programming

5 Things AI Can't Do, Even in Vue.js

DevUnionX — Tue, 10 Mar 2026 21:16:43 +0000

This report addresses limitations AI-assisted tools encounter in Vue.js development process. Analysis of five fundamental limitations is presented in context of Vue.js's unique architecture: component composition and semantics, reactivity system and complex state flows, async behavior and lifecycle edge cases, accessibility and ARIA integration, and performance with build and toolchain compatibility. Each topic includes technical detail explanations, AI error modes, real-world examples, and code snippets.

For instance in component composition section, danger of using arrow functions in Vue components methods block is shown. Such nuances can be overlooked in AI codes, ultimately functionality breaks because this doesn't bind. In reactivity system, deep changes inside a component get automatically caught by Vue's proxy-based system. Despite this, AI assistant might skip binding reactive property using toRef for example, making state untrackable. In accessibility, Vue community emphasizes semantic HTML and recommends avoiding unnecessary ARIA roles. AI sometimes can use inappropriate combinations like div role equals button.

Table shows differences between AI and human codes in criteria like correctness, accessibility, maintainability, package size, and brand fidelity. Mermaid flow diagram created in process summarizes step by step how code from AI gets reviewed and submitted for developer approval. In conclusion, need for human supervision continues in critical concepts in Vue.js projects as well. For this study, primarily Vue.js official documents especially component fundamentals and reactivity guides and latest release notes were scanned. Then problems Vue developers encountered including GitHub issues, StackOverflow questions, and blog posts were examined. Accessibility standards with WCAG and ARIA and MDN guides were reviewed. Existing research about AI code assistant limitations like LinearB error statistics was also analyzed.

Information obtained was addressed in depth at five focus topics in context of Vue.js special details and supported with actual code examples. In each section specific error modes AI can encounter and developer strategies against them were emphasized. Vue components are designed to work nested, parent-child relationship provided with props, event emission with emits, and slot mechanisms. Semantically, developers should establish clean HTML structure, avoid unnecessary div usage. For instance wrapping a list wrongly like this breaks semantics.

Wrong with li used directly inside div. Template. Div. Li Item 1. Li Item 2. Div. Template. Correct usage is li inside ul. Semantic HTML usage and avoiding unnecessary ARIA roles is also recommended in Vue documentation. Additionally using arrow function in methods block in Vue components leads to context loss. For example: export default with methods object containing increment as arrow function. Wrong arrow function this doesn't point. This.count plus plus. In above, this reference doesn't bind correctly due to arrow function. This error is frequently made by AI. Required arrangement should be like this.

Export default. Data returning count 0. Methods object with increment function. This.count plus plus where this binds correctly here. Another point is using inter-component communication correctly. In Vue, from parent to child props, from child to parent message sent via dollar emit or defineEmits. AI sometimes misinterprets this structure, for example instead of trying to pull data from child component, might skip structures like provide/inject. Semantically too, Vue recommends using HTML5 elements directly. Don't add extra role to elements like header, nav, main because Vue documents find this unnecessary as W3C recommendation.

Developer strategies: when reviewing component codes from AI, semantic HTML rules should be checked. Component names and props should be selected clearly, value transfer with v-bind done correctly. If arrow function exists in methods in AI code should be corrected. If slot used for content transitions, placement should be correct. In parent-child communication emits and props should be set correctly. AI errors can be solved using dollar emit or defineEmits.

Vue.js reactivity system is Proxy-based and automatically catches deep changes. Changes you make in data defined with ref or reactive cause Vue component to re-render. But in some cases AI assistants can break reactivity. For instance if they directly change a reactive object's key and keep old reference, Vue might not notice. Following StackOverflow example shows this situation. Wrong with store.state.cart directly copied, reactivity cut. Import store from at store. Const cart equals store.state.cart. Cart here keeps old reference, updates not detected.

To solve this problem toRef should be used. Correct with reactive property obtained with toRef. Import toRef from vue. Const cart equals toRef store.state with cart. Now cart.value updates get tracked. In this example, if AI doesn't use toRef and does plain const cart equals store.state.cart, cart change doesn't get observed by Vue and reactivity breaks. Vue doesn't reflect state changes to DOM immediately, defers updates to next tick. Accordingly nextTick should be used. For example:

Methods object with async addItem function. This.items.push newItem. Await this.dollar nextTick. Now DOM updated, rows rendered. AI generally ignores this deferral necessity. Failure modes: AI code generators can make these errors in reactive data flow: using normal variable without using ref or reactive or wrong import, taking partial copy from reactive object like toRef example above, not seeing depth differences. Additionally when nextTick not added, problems can be experienced with DOM update timing. Real-life case is trying to access DOM elements immediately after adding to a list in a component. In this situation element hasn't been created yet because nextTick not used.

Example showing reactive state with Vue Composition API. Script setup. Import ref from vue. Const count equals ref 0. Function increment. Count.value plus plus. Script. Template. Button at click equals increment showing Increase count. Template. This code shows correct reactive usage. In AI-assisted output, wrongly writing let count equals 0 instead of ref destroys reactivity and button doesn't update number each time clicked.

Developer strategies: review reactive state definitions. Usage of ref and reactive should be applied as needed. Test by replacing normal variables in AI output with reactivity. In nested objects when change made, Vue catches but references should be extracted with functions like toRef and toRefs. nextTick should not be forgotten. Additionally to preserve performance, places where shallowReactive or markRaw needed in large data structures should be checked.

Vue.js components work according to specific lifecycle stages: beforeCreate, created, beforeMount, mounted and so on. When writing async code, this order needs watching. For instance DOM manipulation should be done inside mounted, in created stage DOM hasn't been created yet. AI sometimes makes error by trying to access DOM reference inside setup or created. In Vue data updates get processed in batches. Multiple ref.value changes happen within same tick and DOM renews in next update cycle. Therefore nextTick needed to access DOM immediately after change. AI code might not add await nextTick. For example:

Methods object with setColor function. This.color equals blue. Console.log this.dollar refs.box.style.backgroundColor. Wrong error with DOM not updated yet, shows old background. Above, because AI code didn't use nextTick, console.log can give wrong result. Async data fetching also requires attention. In Vue 3 Composition API using async await inside setup function is supported but needs managing. Especially in SSR, onServerPrefetch or in frameworks like Nuxt, asyncData usage should not be forgotten. AI generally doesn't know framework-specific options about data fetching.

Failure modes: AI assistants generally overlook timing problems. For instance might wrongly guess lifecycle and try connecting to DOM inside created instead of mounted. Watcher usage is also tricky. If async work done inside a watcher and cleanup not added, memory leak happens. In real life, developer break example: AI code setting up setInterval inside mounted without cleanup continues running even after component closes.

Developer strategies: do lifecycle validation in async operations. Review AI code and add cleanup with onMounted, onUnmounted, or watchEffect usage if needed. In server-side flows, onServerPrefetch or appropriate functions should be used. In UI updates wait for DOM to be ready with await nextTick. If subscriptions or event listeners set up in AI code, pay attention to cleanup inside beforeUnmount or onUnmounted.

In Vue projects accessibility is provided with semantic HTML and ARIA. Official Vue documentation also behaves according to W3C recommendations: use header, nav and so on, avoid extra role assignment. For instance creating navigation bar inside semantic nav is more correct than adding role equals navigation. AI codes generally don't pay attention to semantics, can make unnecessary wrapping with div and span. In Vue accessibility practices, attributes like aria-label and aria-labelledby should be emphasized. For instance if button contains only an icon, aria-label must definitely be added. AI-assisted tools can skip these gaps, creating ambiguity for screen readers. Similarly relationship of label and v-bind:id should be established solidly instead of for in Vue.

Failure modes: AI generally skips ARIA attributes or forgets role assignment when using tabindex. For instance in a modal window, title not being associated with aria-labelledby or aria-describedby is seen. On GitHub, required aria attributes deficiency was reported in a version of Vue Multiselect component. Similarly in Vue codes AI generates, aria-asterisk deficiencies can exist. On other hand, in projects created with Vue CLI or Vite, accessibility checks like eslint-plugin-vuejs-accessibility do automatic scanning. Running AI code through these checks is beneficial.

Developer strategies: adhere strictly to semantic and ARIA guides. In Vue files these should be checked: alt to img tags, label to form elements and appropriate for/id relationships should be added. Role should be given directly to custom components in AI codes if needed, for instance for elements that aren't button. Aria errors should be scanned with automatic accessibility tools like axe-core and Lighthouse. Specific to Vue, ensure optimization directives like v-once or v-memo are compatible with ARIA. If needed place additional descriptions with sr-only class. Ultimately Vue templates AI wrote should also be made ARIA compliant with human supervision.

In Vue applications bundle optimization and build configuration are important for performance. Vue official sources note APIs not needed can be removed with tree shaking. For instance if Transition component not used, gets automatically removed from package thanks to modern build tools. AI-assisted codes generally don't pay attention to packaging optimizations, for instance can import entire lodash library bloating bundle. Recommended practice is using only needed methods like import map from lodash/map.

Code splitting or lazy loading is another critical area. Separating your routes with defineAsyncComponent or dynamic import with Vue Router lightens initial load. AI generally writes code with static import and doesn't do code splitting. For instance including a large component without dynamic import causes page to load unnecessarily heavy at start. Official Vue guide draws attention to importance of this. Wrong with no dynamic import, all code loads. Import HeavyComponent from ./HeavyComponent.vue. Correct with component lazy loading. Const HeavyComponent equals defineAsyncComponent with arrow import ./HeavyComponent.vue.

Package size also grows with adding unnecessary dependencies. In Vue performance guide, importance of choosing ES module tree-shakable package is emphasized. Typical errors in AI-assisted codes: committing dist folder as source, loading in node_modules to browser, incompatible Vite/Webpack configuration. Developer strategies: review Vue CLI or Vite configurations. During build, tree-shaking and code-splitting settings should be enabled. Clean unnecessary package imports if exist in AI outputs. Check which modules are heavy using bundle analysis tools. For cached data, keep-alive or v-memo directives evaluated. Long-lived reactives that could cause memory leak in browser like watch without unsubscribing should be carefully handled. Compatibility of AI code with project rules should be validated with tests like Jest plus Vue Test Utils and profile tools.

The following table presents general comparison in Vue.js context between AI generation and human generation. Correctness low with reactivity and lifecycle errors, forgetting ref/toRef versus High compliant with Vue concepts with reactivity control done. Accessibility medium can neglect ARIA/semantics like unnecessary role versus Good with header, nav correct, alt and label complete. Maintainability low with complex structures, repeated code, missing comments especially setup API versus High using modular, readable Composition/Options API.

Package Size large with unnecessary dependencies, missing tree-shaking like all of lodash versus Small with tree-shaking and code splitting active and minimal dependencies. Brand Fidelity weak with UI/theme guide incompatible style and component usage possible versus High loyal to corporate style, using SCSS and theme systems correctly. The mermaid flowchart summarizes Vue.js development process. Developer checks component structure, props/emits usage, and slots of code from AI. Then reviews reactivity rules like ref, reactive, toRef. Compliance with async and lifecycle stages like nextTick and mounted gets checked. Finally accessibility and performance steps including tree-shaking and lazy load get evaluated.

At each stage if deficiency exists, returns and correction made. When all conditions satisfied, code approved and tested. Flowchart shows: Requirements including UI semantics, reactivity, lifecycle, performance. Get Vue code from AI. Decision whether component props/emits correct. If no make props/emits correction and return. If yes decision whether reactivity correct. If incomplete return. If complete decision whether async/lifecycle problem exists. If yes return. If no accessibility check. If incomplete return. If complete package optimization. If incomplete return. If complete code review and test approval.ms.

5 Things AI Can't Do, Even in Next.js

DevUnionX — Sun, 08 Mar 2026 18:12:21 +0000

This report examines limitations AI-assisted tools encounter in Next.js development process. Five main topics address technical nuances specific to Next.js infrastructure: component and page semantics including differences between SSR, SSG, and ISR, data fetching and caching covering getServerSideProps, getStaticProps, App Router fetch, and cache headers, routing and dynamic routes with i18n and Middleware edge cases, performance and build toolchain addressing image optimization, ISR, server components, and packaging, and finally security and deployment examining Edge versus Server environments, secret keys, and header management.

Each section provides technical detail, concrete error scenarios AI encounters explained through real-world examples from GitHub issues and blog posts. For instance in data fetching, getStaticProps usage is emphasized because this function runs only on server and doesn't get included in client bundle, meaning secret keys or private request information don't leak from here. But AI assistants sometimes cannot see this distinction and might transfer problematic data to client side. In performance section, Next.js Image component becomes important. AI frequently makes simple operations with standard img tag, whereas Next.js Image serves visuals in WebP or AVIF format appropriate to screen size.

Table noting differences between AI-generated and human-written code regarding correctness, accessibility, maintainability, package size, and deployment security shows AI-sourced code generally contains more errors. Ultimately, human supervision remains indispensable in Next.js-specific advanced topics. For this study, primarily Next.js official documents and latest release notes were reviewed. Then Next.js community resources including GitHub Issues and StackOverflow, developer blogs, and case studies were examined, particularly ISR errors and i18n topics. Accessibility guides with WCAG and security standards were compared against Next.js examples. Research revealing AI code assistant limitations was also reviewed. All this data was gathered under five distinct topics enriched with technical explanations, code examples, error scenarios, and solution recommendations.

Next.js serves pages through various pre-rendering methods. SSR or Server-Side Rendering runs on each request. SSG or Static Site Generation creates page at build time. ISR or Incremental Static Regeneration caches static page and renews at specific intervals. Conscious decision should be made about which method to use. For pages requiring user-specific data or authorization, SSR with getServerSideProps should be preferred. Sensitive information should never be added to React components through getStaticProps because this function runs only on server and sends its output to client side. AI assistants sometimes skip this distinction.

For example assume someone uses API key in getStaticProps. Lock warning, secret key should not leak to client. Export async function getStaticProps. Const apiKey equals process.env.SECRET_API_KEY. Const res equals await fetch showing API example URL with key parameter. Const data equals await res.json. Return props with data. In above code SECRET_API_KEY doesn't go to browser because used inside getStaticProps, only processes server side. But AI sometimes might not comply with this rule and cause security vulnerability by adding API key directly to client component.

AI assistants generally miss optimal choice between SSR and SSG. For instance can lower performance by using unnecessary SSR when static cache is possible, or conversely can use static methods to fetch dynamic data. Another error is making wrong ISR settings or not using at all. According to Next.js documents, if a route contains revalidate 0 or no-store in any fetch call, route gets rendered dynamically. If such details are overlooked in AI assistant code, ISR's purpose can break. Wrong example with if revalidate not used, data updates on every request and cache becomes ineffective. Export async function getStaticProps with const res equals await fetch API posts URL with next revalidate false. Const posts equals await res.json. Return props with posts.

In above code revalidate false is specified but static file still gets created in background. Correct usage is making intervals with revalidate number form. AI generally skips these nuances and considers page either static or completely dynamic. Example showing scenario wanting to update page on every request with SSR. SSR example with getServerSideProps runs on every request. Export async function getServerSideProps with context parameter. Const res equals await fetch API data URL with lang equals context.locale. Const data equals await res.json. Return props with data. Export default function Page with data parameter. Return div with data.content. getServerSideProps runs server side and can get request-specific values like locale information.

In this example, getServerSideProps usage suits situations requiring request-time information like locale or authorization. If AI assistant misinterprets this concept, might try getting dynamic data with getStaticProps and encounter wrong results. Developer strategies: correct pre-rendering strategy should be selected according to page's data requirement. Check in code from AI that getStaticProps, getServerSideProps, or getStaticPaths are used correctly. Sensitive data should never be transferred to client. If using ISR, ensure revalidate times are appropriate. If page will be statically created, pages versus app folder configurations should be reviewed. Data fetching logic at Page versus Component level should be clarified according to application needs, example codes AI suggested should be supervised according to these rules.

Next.js provides both Pages Router with getStaticProps, getServerSideProps, getStaticPaths and App Router with fetch inside server components for data fetching. Each method's caching behavior differs. Data fetched with getStaticProps gets cached at build time or in ISR mode, getServerSideProps renews data on every request. AI assistants sometimes select wrong function, for instance can lower performance by fetching simple content with SSR. Additionally Next.js fetch API extended features like next revalidate 60 get mostly bypassed.

For example data fetching in page using App Router. In app/users/page.tsx export default async function UsersPage. Const res equals await fetch API users URL with next revalidate 60 for caching data with revalidate setting. Const users equals await res.json. Return ul with users.map showing li key equals u.id with u.name. AI mostly skips this next revalidate 60 setting. In above code we enabled data renewal every 60 seconds by adding next revalidate 60. If AI assistant doesn't add this setting, page either renews on every request as default or can serve stale data without ever renewing.

As specified in Next.js documents, if revalidate 0 or no-store is used in a fetch request, route becomes dynamic. On other hand when giving caching strategy, Next.js built-in cache should be preferred instead of libraries like React Query. AI generally avoids using fetch inside getServerSideProps and setting cache headers. Failure modes: AI-assisted codes can overlook difference between getStaticProps and getServerSideProps. For instance trying to use data like context.params inside getStaticProps gives error. Not setting correct Cache-Control headers for caching or not using Next.js revalidate features is frequently seen. Example of making wrong cache settings follows.

Export async function getStaticProps. Const res equals await fetch API posts URL with wrong can be skipped by AI, next revalidate 0 causes page to be recreated on every request. Const posts equals await res.json. Return props with posts. In above wrong usage, revalidate 0 means data renews on every request without caching. Whereas generally few seconds of cache would be sufficient. Additionally AI mostly doesn't benefit from context information belonging to getStaticProps like query or headers, leading to error in situations requiring conversion to SSR. For instance when user wants to read browser language from Accept-Language header and change content, getStaticProps not being able to do this becomes a problem.

Example showing cached page using ISR. Export async function getStaticProps. Const res equals await fetch API products URL with next revalidate 300 for recaching every 5 minutes. Const products equals await res.json. Return props with products. Export default function ProductsPage with products parameter. Return div with products.map showing p key equals p.id with p.name. getStaticProps runs on server, cache set with next.revalidate. If AI code skipped revalidate value, page stays static and might not stay current. Similarly if correct cache options aren't put in fetch queries, Next.js built-in client or server cache might not activate.

Developer strategies: optimize code following Next.js caching guide, for example using next revalidate in fetch. Data renewal settings AI skipped should be manually added. For cache control, Cache-Control headers in HTTP responses should be validated with Vercel or browser tools. To test ISR and SSG structures, cache behavior should be observed in production-like scenario by running next build and next start. Additionally avoid sending unnecessary data to client. For instance if data fetched with getServerSideProps goes to client in props, pay attention to sensitive fields. AI code must definitely go through manual review and test processes.

Next.js has powerful routing system supporting file-based routes or Route Segments, dynamic segments like bracket id.js and bracket dot dot dot catchAll, subdirectories, and internationalization i18n. Next.js additionally uses middleware for preprocessing incoming requests and dynamizing routes. AI can make errors especially in i18n and getStaticPaths combinations. For instance for multilingual blog page, every language variant needs to be returned inside getStaticPaths. According to Next.js guide, each localization combination should be specified separately.

In pages/blog/bracket slug.js export const getStaticPaths equals with locales parameter. Return paths array containing params slug merhaba with locale tr, params slug hello with locale en-US, and fallback true. Above specified separate slug path for each language. AI generally skips this step and specifies only paths belonging to default language, resulting in 404 error in other languages. When getStaticPaths is used, if a route outside what you specified is requested, behavior depends on fallback option. AI tools sometimes skip difference between fallback true versus false or blocking, leading to unexpected user experiences.

In a GitHub discussion, how to manage fallback mode between i18n and dynamic routes was explained. For instance during language switches, in a request outside getStaticPaths scope, page is expected to load with fallback true, but if this gets forgotten in AI code, empty page or error can occur. Next.js can redirect routes or add headers using middleware. AI code can struggle understanding middleware logic. For instance instead of defining middleware for a path requiring authentication, might put redirect code in page component. Additionally AI generally doesn't consider Edge and Server environment difference. For instance if using Vercel Edge Functions, special methods are needed instead of process.env.

Developer strategies: in i18n and dynamic routes, directives in Next.js documentation should be followed. Ensure in code from AI that locales and locale settings are complete. Pay attention that paths getStaticPaths returns are complete for every variant. If middleware usage needed, example configurations like JWT validation should be checked. Review next.config.js settings like route groups and routing with redirects and rewrites in code AI added. Test that page handles appropriately with notFound or redirect in error situations like wrong parameter.

Next.js offers performance-focused optimizations: Image component, automatic code splitting, ISR, server components in app folder, and advanced configuration with next.config.js. AI generally skips some of these features. For instance using classic img instead of Image usage makes page load heavier. According to Next.js documentation, Image tag serves visuals in appropriate size WebP or AVIF according to device size. Import Image from next/image. Export default function Avatar. Return Image source /avatar.png width 200 height 200 alt Avatar Image with priority. Image component uses automatically optimized images.

In AI-assisted code, generally with img given fixed size, page shift and unnecessary package load emerge. Additionally in large projects creating many pages, AI can create confusion in ISR, dynamic render, and static export decisions. For instance as error might skip flags like export const dynamic equals force-static or export const dynamicParams equals false. With Next.js 13 plus server components RSC were introduced. AI codes mostly cannot see use client rule to push components to client side. This causes unnecessary JavaScript to be loaded to client. If use client deficiency in code snippet is overlooked, RSC benefit gets wasted.

In enterprise projects package size directly affects performance. AI outputs generally come with broad imports and repeated code. For instance importing entire third-party library and including even unused functions is typical error. According to StackOverflow source, to reduce this situation, code splitting and partial import are needed. AI code generally doesn't consider these recommendations. For instance imports entire lodash library. Wrong example with imported all of lodash. Import underscore from lodash. Const arr equals underscore.map array with lambda. Good example importing only needed function. Import map from lodash/map. Const arr equals map array with lambda.

AI code generally bloats package size, negatively affecting load times and user experience. Developer strategies: apply official recommendations for performance. Check in AI code for Image usage and use client settings for components requiring dynamism. Review code splitting strategies with dynamic import and React.lazy and compression steps. Review experimental settings and optimization options in Next.js configuration. With bundle analysis tools check whether AI outputs carry unnecessary dependencies. If needed, manually add performance improvements to part AI wrote.

The following table presents general comparison in Next.js context between AI generation and human generation. Correctness low with wrong redirects, stale data, and missing revalidation errors versus High with SSR and SSG decisions and fetch settings proper. Accessibility medium, generally mixes page semantics with head meta forgotten versus Good with tags like lang and hreflang complete. Maintainability low with automatic code repetition and incomprehensible data flow versus High with modular structure and comment lines added.

Package Size high with unnecessary imports and packages like entire lodash included versus Low with only needed modules and code splitting used. Deployment Security low with environment variables used in wrong place and security update not done versus High with secret values kept on server and updates tracked. The mermaid flowchart summarizes Next.js development process. At start required data fetching method and page type determined. Code from AI gets checked with correct SSR, SSG, ISR options and i18n settings. If needed additions made to AI code like locale parameter and revalidate times. Next step reviews Image usage, code splitting, and other performance optimizations.

Security steps checked including environment variable usage and security patches. At very end code approved with package analysis and tests. When deficiency detected, process returns to start with manual correction done. Flowchart shows: Requirements including page data, routing, performance. Get Next.js code from AI. Decision whether page concept and data method determined. If no add appropriate fetch and SSR/SSG settings to AI code and return. If yes decision whether dynamic route and i18n needs exist. If yes do i18n and getStaticPaths/locale check and return. If no decision whether image optimization done. If incomplete return. If complete decision security whether secret data in correct place. If incomplete return. If complete bundle and performance analysis. Code review and final approval with tests.

In Next.js applications, security starts especially with well-drawn server to client boundary. Secret keys that should be kept server side should never go to client. Environment variables without NEXT_PUBLIC prefix are visible only on server. AI assistants often miss this rule. For instance might place secret API key inside server component. Update management and CVE announcement tracking is needed. For instance a critical security vulnerability in React Server Components protocol CVE-2025-66478 affected Next.js 15 to 16 versions with remote code execution risk. Only upgrading Next.js solves this problem. Closing such risk with AI code suggestions isn't possible.

Vercel Edge and Server environments bring different requirements. For instance in Edge Functions, fetch usage, Node APIs, or long-running operations are limited. AI might suggest configurations like process.env not used in Edge environment giving error. Middleware and header management are also critical. In Next.js 13 security headers or custom headers are added inside next.config.js. AI generally doesn't create these configuration files.

Example showing secure redirect middleware. In middleware.js import NextResponse from next/server. Export function middleware with request parameter. Const token equals request.cookies.get auth_token. If no token redirect to login with NextResponse.redirect new URL /login and request.url. Return NextResponse.next. Use this middleware on all pages requiring authentication. AI assistant might not recognize standard libraries like Auth.js and can make wrong redirect or open redirect error. Environment variable management is also one of topics where AI causes problems. Next.js documentation notes variables without NEXT_PUBLIC will be stored on server.

AI code might mistakenly try using all variables in frontend. Additionally separating important operations from client using server components might be needed. Before deployment, attention should be paid to security scans in CI/CD pipelines like npm audit, all versions should be updated with latest security patch. Developer strategies: apply Next.js security guides. In server components use only server environment variables like process.env.SECRET, don't pass encrypted key or secret information to client. Carefully examine middleware or redirect codes AI added. Take precautions against open redirects and CSRF and XSS attacks. When managing environment variables in Vercel Panel or .env file, ensure NEXT_PUBLIC prefix rules are followed. Finally choose structure appropriate to environment Edge versus Server and validate deployment security with manual tests before deployment.