Next.js 16.2 includes several improvements designed for AI-assisted development. These changes make it easier for agents to understand your project, debug issues from the terminal, and inspect running apps — all without requiring a browser.
create-next-app: Scaffold AI-ready projects out of the boxcreate-next-appcreate-next-app now includes an AGENTS.md file by default, giving AI coding agents access to version-matched Next.js documentation from the start of your project.
This builds on our research into AGENTS.md, which found that giving agents access to bundled documentation achieved a 100% pass rate on Next.js evals — outperforming skill-based approaches that maxed out at 79%. The key insight: always-available context works better than on-demand retrieval, because agents often fail to recognize when they should search for documentation.
The AGENTS.md file is a short directive that tells agents to read the docs bundled at node_modules/next/dist/docs/ before writing any code. The Next.js npm package now includes the full documentation as plain Markdown files, giving agents accurate version-matched references locally without fetching external data.
For existing projects, the setup depends on your Next.js version.
On 16.2 or later, the docs are already bundled in the next package. Add these two files to the root of your project:
The comment markers delimit the Next.js-managed section. You can add your own project-specific instructions outside them — future updates will only replace content between the markers.
CLAUDE.md is the instruction file for Claude Code. The @ directive tells it to include AGENTS.md as additional context:
On earlier versions, use the codemod to generate these files automatically:
For more details, see the AI agents setup guide.
Next.js now forwards browser errors to the terminal by default during development, so you can see client-side errors without switching to the browser console. This is especially helpful for AI agents that operate primarily through the terminal and can't access a browser console.
By default, only errors are forwarded to the terminal. You can control the level of forwarding with logging.browserToTerminal in your next.config.ts:
Next.js now writes the running dev server's PID, port, and URL into the .next/dev/lock file. When a second next dev process starts in the same project directory, Next.js reads the lock file and prints an actionable error:
This is especially useful for AI coding agents, which frequently attempt to start next dev without knowing a server is already running. The structured error gives the agent the PID to kill the existing process or the URL to connect to it — no manual intervention required.
The lock file also prevents two next build processes from running simultaneously, which could otherwise corrupt build artifacts.
The features above help agents understand your project and debug issues. @vercel/next-browser extends this by letting agents inspect a running Next.js application.
next-browser is an experimental CLI that exposes browser-level data — screenshots, network requests, console logs — along with framework-specific insights from React DevTools and the Next.js dev overlay, like component trees, props, hooks, Partial Prerendering (PPR) shells, and errors. All returned as structured text via shell commands.
An LLM can't read a DevTools panel, but it can run next-browser tree, parse the output, and decide what to inspect next. Each command is a one-shot request against a persistent browser session, so agents can query the app repeatedly without managing browser state. This turns the browser into something an agent can reason about, instead of a UI it can't access.
The feature set is evolving quickly. As of this release, next-browser supports:
Install it as a skill (a reusable capability for AI agents):
Then type /next-browser in Claude Code, Cursor, or any AI agent that supports skills. The CLI manages a Chromium instance with React DevTools pre-loaded — no browser configuration required.
With Partial Prerendering (PPR), Next.js can serve a static shell instantly from the edge — the parts of your page that don't depend on per-request data — then stream in the rest. The more content that fits in the static shell, the faster users see a meaningful page.
In practice, a single per-request fetch can accidentally make an entire page dynamic. Consider a blog post with a visitor counter:
Every slug is enumerated in generateStaticParams, so the post content could be prerendered at build time. But getVisitorCount runs on every request — and because it sits at the top level of the component, it makes the entire page dynamic. As a result, the entire page waits behind a loading skeleton instead of streaming in progressively.
An agent can use next-browser to diagnose this. Locking PPR mode shows only the static shell — in this case, the app/blog/[slug]/loading.tsx skeleton, because nothing in the page made it into the shell:
The agent then runs ppr unlock to find out what went wrong:
The report tells the agent exactly what to do: getVisitorCount is the blocker, it lives in BlogPost, and the fix is to push it into its own Suspense boundary. The agent wraps just the counter:
Running ppr lock again confirms the shell grew — the post content now prerenders instantly. Only the visitor count shows a fallback:
next-browser is still evolving, but it points toward a future where agents can debug and optimize apps with the same visibility as a developer.
Share your feedback and help shape the future of Next.js:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。