Upgrade Next.js 13 to Next.js 16

The agent first measures how far the app is from current. In an app like shadcn-ui/taxonomy, package.json pins next to 13.3.2-canary.13 with React 18.2, next-auth 4.22.1 and @next-auth/prisma-adapter, Prisma 4.13 on MySQL, contentlayer 0.3 with next-contentlayer, Tailwind 3.3, ESLint 8 with eslint-config-next 13.0.0, TypeScript 4.7.4 and @types/react 18.0.15; .nvmrc says Node 16.18, pnpm-lock.yaml says pnpm, and the scripts are dev (concurrently "contentlayer dev" "next dev"), build (contentlayer build && next build), lint (next lint) and a postinstall of prisma generate. next.config.mjs wraps withContentlayer around experimental.appDir: true, experimental.serverComponentsExternalPackages and images.domains. There are no tests and no CI workflow; husky runs pretty-quick on commit.

It reads the code for the patterns the upgrade changes. Route handlers such as app/api/posts/[postId]/route.ts read context.params synchronously through a zod schema, and pages such as app/(marketing)/blog/[...slug]/page.tsx read params.slug directly; from Next.js 15 those are promises, so each is awaited and the codemod next-async-request-api does most of it. middleware.ts uses withAuth from next-auth/middleware. NextAuth is wired twice, in pages/api/auth/[...nextauth].ts and a disabled app/api/auth/[...nextauth]/_route.ts, so the app has both routers; the agent keeps the Pages handler working or enables the App Router handler and deletes the other, and names that choice. app/layout.tsx already uses next/font, and env.mjs validates every secret with @t3-oss/env-nextjs, which means next build needs a .env.local with non-empty placeholders to get past validation.

The upgrade goes one major at a time, with pnpm build and pnpm lint after each. Node first, since Next.js 16 does not run on Node 16: .nvmrc moves to a supported Node 20 release. Then next@14 with experimental.appDir removed, next@15 with React 19, @types/react 19, serverComponentsExternalPackages renamed to serverExternalPackages, images.domains rewritten as remotePatterns and the async request API codemod applied, then next@16, where next lint is gone and the lint script calls ESLint directly with the flat config eslint-config-next now ships, and the middleware.ts convention gives way to proxy.ts. eslint-config-next and @next/codemod run at each matching major (npx @next/codemod@canary upgrade does the version bumps and offers the codemods).

Some steps are decisions, and the agent lists them rather than guessing. contentlayer 0.3 stopped releasing before Next.js 14, so the MDX pipeline either moves to the community fork contentlayer2 with next-contentlayer2 or is left for a person; next-auth 4 on React 19 and the App Router works for this app's email and GitHub providers but Auth.js 5 is the supported line; Prisma 4 to 6 and Tailwind 3 to 4 are independent majors the prompt does not ask for, so they stay. TypeScript 4.7 cannot type-check Next.js 16's types, so it moves to 5 in the same step. Each step is its own commit, the build output after each is in the record, and the description ends with the decisions list.

What comes back is a pull request on a new branch with one commit per step: Node and TypeScript, Next.js 14, Next.js 15 with React 19 and the async request APIs, Next.js 16 with the lint script and the proxy.ts rename. The diff touches package.json, pnpm-lock.yaml, .nvmrc, next.config.mjs, tsconfig.json, the route handlers and pages that read params, and the middleware file. Content under content/ and components under components/ui/ are unchanged unless a type error forced a one-line fix.

The description is a table of steps with the pnpm build and lint result after each, then the decisions: the MDX pipeline (contentlayer fork or replacement), the NextAuth handler location and the Auth.js 5 question, and any dependency it pinned to make the build pass. The trajectory keeps every build log, including the ones that failed before a fix.

Before merging, a reviewer runs the app locally against a database, signs in with the email provider and opens the editor, since no test covers them, checks that generateStaticParams pages still prerender, that the Stripe webhook route still verifies signatures with the awaited headers(), and reads each decision before deciding which follow-up pull requests to open.

Create an automation in the Project with this prompt and a schedule trigger that runs once a month, with the target version read from the prompt or left as latest. Most months the run finds nothing to do and ends without a pull request; when a major lands, the pull request arrives with the steps already separated and the decisions listed.

Give the API key a webhook URL to receive run.completed and post the pull request link to the frontend channel. For a fleet of Next.js apps, start one run per repository; each sandbox installs that app's own lockfile and works through its own list.

Three major versions of Next.js in one sitting means a day of reading upgrade guides, running codemods, and reading build errors about async params and renamed config keys, on a laptop that cannot do anything else while next build runs. On Rush the agent does that in its own sandbox with the project's pnpm and a pinned Node, and every build log is in the record.

The result is a pull request where each step is a commit and each build after it is quoted, so a reviewer can trust the mechanical parts and spend their attention on the decisions the agent listed instead of made. The same request runs on every app that is still on an old major, at the same time.

There are no tests. How do I know the app still works?

Will it upgrade Prisma, Tailwind and ESLint too?

What happens to contentlayer?

Does it need a database to build?

Can it stop at Next.js 15 instead?