Nothing. You're not missing anything. Redux at that scale is cargo culting, teams add it because the last project had it. For user data and a loading flag, useState or Zustand with one slice is the honest answer. Redux earns its keep at 15+ slices with complex cross-slice dependencies. Below that it's overhead.

The paper vs production gap on RSC is exactly this. Server handles data fetching beautifully until you need optimistic updates, local UI state, or anything that responds to user interaction mid-session. RSC and client state aren't competing, they're layers. The mistake is treating them as a choice.

The versioning problem is real. Cursor generates components that work in isolation but have no concept of the token system beneath them. You end up with one-off hardcoded values that look right until the next design system update breaks everything silently.

Route groups share a layout, not a state boundary - that's the trap. The cleanest fix in production: lift state to a root layout provider scoped above the route group, or use Zustand with a slice tied to that layout segment. Context inside the group causes remounts on navigation.

The PR bottleneck is real, but hiring before you tighten scope is the wrong order. AI-generated PRs tend to be large because the agent has no reason to keep them small. That's a prompting problem, not a people problem. Enforce atomic PRs at the agent level first. On tooling: automated checks (lint, tests, type safety) should catch the mechanical stuff so human review stays focused on architecture and intent. That's the only version of this that scales. A dedicated reviewer gets buried fast if every PR is 400 lines of generated code with no boundaries.

The frontend angle doesn't get enough attention here. Most agent breakage I've seen isn't the model, its an undefined response contract. Agent returns something unexpected, component doesn't know what to render, silent failure two screens later. Teams are building agent UI like a form submission flow. Predict the response, render it. But agent outputs are probabilistic. Your component boundaries matter more than which model you picked.

The confidence problem runs deeper than it looks. AI is optimised for plausibility, not correctness. The code looks structured, compiles fine, variable names make sense. You're reading in review mode, not debugging mode. "Treat it like a junior dev" is right, but juniors at least understand the system. AI doesn't know your auth context, your state decisions, or the two hacks from six months ago everything quietly depends on. That context gap is where the real risk lives.

API docs get attention. The frontend/API contract usually doesn't. TypeScript helps, but types lie without runtime validation. The API returns an unexpected null, a renamed field, an edge case you never tested and your types had no idea. Zod fixes this. Parse at the boundary. If the API changes shape, you catch it at the schema. Not in a Sentry alert a week later. We do this with Next.js Server Actions too. The server/client boundary is the natural place to validate. Keep the schema next to the call. Documentation problem and type-safety problem are usually the same problem.

The frontend side of this doesn't get enough attention. Building UI for AI-native products is a different problem than CRUD. You're dealing with response times you can't predict, outputs that arrive mid-stream, and failures that don't look the same twice. A loading spinner and a try/catch don't cut it. Most teams are still reaching for the same patterns they'd use for a form submission. It works until users start feeling the difference and they do feel it. React Suspense + streaming in the Next.js App Router is the first thing I've reached for that actually matches how AI responses behave. You stop thinking about how long to wait and start describing what to show while waiting. The stream decides when things appear. Small shift in how you write the component, noticeable shift in how it feels to use. The teams getting this right aren't the ones with the nicest chat UI. They're the ones who questioned where their component boundaries sit before they wrote a single line.

Full stack, not even close. At least if Staff IC is the target. Mobile isn't a wrong move, but it splits your focus at exactly the point where you need to go deeper. Staff roles reward people who can own a problem from end to end, not people who can work across platforms. What's actually mattered most in my career isn't the stack, it's understanding what happens between a user clicking something and a database changing. Where data lives, how it gets there, what goes wrong when it drifts. That thinking transfers to every codebase I've touched. The React Server Components + Next.js App Router story has made this concrete in 2026. You can own a full feature slice without leaving the JS ecosystem. That's a much easier sell in a Staff IC conversation than "I do a bit of both."