1. The caching model flipped—read the manual once

With Cache Components enabled via cacheComponents in config, caching becomes opt-in via "use cache" on pages, components, and functions. Dynamic work runs at request time by default—closer to how teams reason about full-stack apps than “everything static unless you poke holes.”

Partial Pre-Rendering (PPR) ties into this story: static shells with dynamic islands. The old experimental experimental.ppr configuration is removed in favor of the Cache Components setup—budget time in migration guides, not just a version bump.

Also note improved cache APIs such as updateTag() and refined revalidateTag() for invalidation discipline. If your production app relied on implicit behavior, you owe it a staging rehearsal with realistic auth and cookies.

2. proxy.ts is your new network seam

middleware.ts is succeeded for the common case by proxy.ts, exporting a proxy function on the Node.js runtime—clearer naming, one predictable place for redirects, rewrites, and auth gates. middleware.ts remains for Edge-specific needs but is deprecated and slated for removal.

For production, audit every edge assumption: geolocation, JWT parsing, and third-party SDKs that only ever saw Edge may need retesting under Node.

3. Turbopack by default: CI and local parity

Turbopack is the default bundler, with large wins in dev Fast Refresh and build times. That matters for teams where “works on my machine” was webpack-shaped. Still validate production builds, Docker images, and platform adapters—especially if you had custom Webpack plugins. The Build Adapters API (alpha) exists for deeper customization; treat alpha APIs as gated experiments, not load-bearing pillars on day one.

4. React Compiler stable—less manual memo noise

Built-in React Compiler support is stable in this generation of the stack, targeting automatic memoization instead of blanket useMemo sprawl. Pair that with React 19.2 features (View Transitions, new hooks) only when product design actually uses them—shipping for the badge helps nobody.

5. Breaking changes are the real ticket cost

The official upgrade guide calls out items like async request APIs (params and searchParams patterns), next/image default changes, and other framework tightening. Run npx @next/codemod@canary upgrade latest in a branch, then fix what the codemod cannot touch—usually business logic at the edges.

6. Devtools MCP: great for some teams, optional for many

Next.js DevTools MCP feeds agents structured context (routing, caching, logs, stacks). Valuable if your workflow is already MCP-heavy; irrelevant if you lack agent governance. Do not block a release on it.

What I ignore until it hurts

  • Every experimental flag in the changelog—enable when a feature maps to a product requirement.
  • Micro-benchmarks that do not reflect your data-fetch or bundle shape.
  • Rewriting working islands to Cache Components before measuring TTFB and invalidation bugs.

Production checklist

  1. Upgrade path run with codemod + manual fixes from the version 16 guide.
  2. Caching: explicit "use cache" + correct tag invalidation.
  3. proxy.ts migration reviewed for runtime and auth.
  4. CI build matches Vercel/Docker with Turbopack defaults.
  5. Smoke tests on critical flows with production-like data and cookies.

Next.js 16 is a strong release—but production success still comes from boring verification: boundaries, cache semantics, and an upgrade path your on-call rotation can explain.