Next.js 16.3 Agent DevTools: Let Claude Verify Its Code

Your coding agent has never actually looked at the page it just "fixed"

If you drive Next.js work through Claude Code, Cursor, or Codex, you already know the failure mode. The agent reads the error, edits a file, sees the dev overlay go green, and declares victory. Then you reload the route yourself and the hero section is blank, or a Suspense fallback is stuck spinning, or a client component re-renders on every keystroke. The build was happy. The page was not.

Next.js 16.3 (preview dropped June 26) goes after exactly this gap. The next-dev-loop Skill plus agent-browser 0.27 give the agent a real browser and, for the first time, React DevTools introspection — it can list the component tree, inspect a fiber, and profile re-renders while it iterates. This is the difference between an agent that guesses your fix worked and one that reloads the route and checks. Here's how to wire it up, a real before/after on a Cache Components error, and the gotcha that will bite you if you trust the green overlay.

The setup is two commands

The Skill needs agent-browser 0.27+, which is where the React commands live. Install both:

npm install -g agent-browser@^0.27
npx skills add vercel/next.js --skill next-dev-loop

Then you tell the agent, once, to actually use it:

After every edit, verify the page still works at runtime using the next-dev-loop skill.

That one line is the whole behavioral change. The Skill wires the agent into two views of your app: /_next/mcp, the framework's picture of routes, server logs, and compilation issues; and agent-browser, the browser's picture of the DOM, console, network, and — new in 0.27 — the React tree. The agent edits, recompiles through the dev server's MCP endpoints, reloads a real browser, and reads what rendered. No next build in a loop just to check that things compile.

Before: the agent fixes the error message, not the bug

Say you've turned Cache Components on and hit the most common error in the whole feature. A product page does an uncached fetch at the top level:

// app/products/[slug]/page.tsx
export default async function ProductPage(
  props: PageProps<"/products/[slug]">,
) {
  const { slug } = await props.params;
  const featured = await fetch(`/api/products/${slug}`);
  const product = await featured.json();

  return (
    <div className="space-y-4">
      <ProductHeader product={product} />
      <ProductReviews slug={slug} />
    </div>
  );
}

Next.js raises a blocking-prerender-dynamic error: an await outside a <Suspense> boundary stops the route from prerendering, so the navigation can't be instant. The overlay offers three labeled fixes — Stream, Cache, or Block — each a real product decision with trade-offs.

A pre-16.3 agent, or a 16.3 agent you never told to verify, does the obvious thing: it wraps the entire return in a Suspense boundary to make the error disappear.

return (
  <Suspense fallback={null}>
    {/* everything, including the await, hoisted below */}
  </Suspense>
);

The overlay clears. The agent reports success. And the route now ships an empty static shell — the boundary is so high, with fallback={null}, that nothing paints until the whole page streams in. You've traded a build error for a worse user experience, and the agent has no idea because it never looked.

After: the agent reads the docs, applies the pattern, then looks

With next-dev-loop installed and the "verify at runtime" instruction in play, the loop changes shape. The Copy-as-prompt button on the Instant Insight already hands the agent a checklist: identify the failing code, read the per-rule docs page, apply the canonical pattern, then verify what actually renders. That last step is the one that used to be impossible.

The agent pulls the boundary down to the actual dynamic read and gives it a real fallback:

export default async function ProductPage(
  props: PageProps<"/products/[slug]">,
) {
  const { slug } = await props.params;

  return (
    <div className="space-y-4">
      <Suspense fallback={<ProductHeaderSkeleton />}>
        <ProductHeader slug={slug} />
      </Suspense>
      <ProductReviews slug={slug} />
    </div>
  );
}

async function ProductHeader({ slug }: { slug: string }) {
  const res = await fetch(`/api/products/${slug}`);
  const product = await res.json();
  return <h1 className="text-2xl font-semibold">{product.name}</h1>;
}

Now the static shell — the layout, the skeleton, everything around the fetch — prerenders and paints immediately, and only the header streams in. But the agent doesn't take that on faith. It drives the browser:

agent-browser open http://localhost:3000/products/widget-9000
agent-browser react tree
agent-browser react suspense --only-dynamic --json

The react suspense command is the tell. It reports which boundaries are holding dynamic content. If the agent sees the whole page sitting behind one boundary, it knows the shell is empty and pulls the boundary lower. If it sees the header boundary resolving to a real <h1> while the shell painted first, the fix is genuinely done. This is verification the build step literally cannot give you — a green compile says the code is valid, not that the page is fast.

React introspection is the part that earns its keep

DOM and console access have been in agent browsers for a while. The 0.27 React commands are what make this useful for the bugs that don't throw. You launch with the flag, then you have four commands worth knowing:

agent-browser open http://localhost:3000/dashboard --enable react-devtools

agent-browser react tree                 # list the component tree
agent-browser react inspect <fiberId>     # props/state/hooks for one component
agent-browser react renders start
# ...interact with the page...
agent-browser react renders stop          # what re-rendered and why

The react renders profiler is the one I'd reach for most. Ask an agent to "make the filter feel snappier" and without profiling it'll guess — throw useMemo at something, or wrap a callback and call it done. With renders start/stop around a real interaction, it can see that typing in the search box re-renders the entire results table because the parent holds the query state, and fix the actual cause instead of sprinkling memoization. That's the kind of diagnosis that used to require a human with the DevTools panel open.

The gotcha: a green overlay is not a rendered page

Here's the thing that only bites you once you've shipped it. The dev overlay clearing tells you the build is happy. It says nothing about what paints. The empty-shell trap above is the canonical example, and it's sneaky because the visible UI can look identical — the fix often just changes what's in the static shell versus what streams. Load it on a fast local connection and you'd never notice. Load it on a throttled mobile connection, which is where instant navigation actually matters, and the whole page is blank for a beat.

So don't let an agent close out a Cache Components change on "the error went away." The verification instruction has to be explicit, and for shared code it has to be broader than one route. A Suspense boundary added to a layout fixes the route you're on and can quietly break a sibling that depended on the old shell shape. When the fix touches a layout, a wrapper, or a sidebar, the agent needs a before/after capture across the affected routes, not just the one in front of it. next-dev-loop gives it the tools; you still have to tell it the scope.

Where I'd stop short

Two honest limitations. First, this loop has a cost. Launching a browser, reloading, and profiling re-renders on every edit is overkill for a copy tweak or a Tailwind class change. I scope the "verify at runtime" instruction to the work that warrants it — Cache Components adoption, Suspense boundaries, anything touching what renders — rather than bolting it onto every trivial edit and paying the latency tax. The Skill is a scalpel, not a default.

Second, there's the AGENTS.md-versus-Skills question the community has been chewing on. 16.3 leans hard into AGENTS.md as passive context — always in the window, no decision required — and there's an arXiv result making the rounds that pegs the speedup around 29% with lower token use. Skills are the opposite: the agent has to actively decide to invoke them. That's a real trade-off. Passive context is reliable but always costs tokens; a Skill is cheap until it's needed but only fires if the agent recognizes the moment. My read after using both: put your durable, always-true project rules in AGENTS.md (the version-mismatch warning Next.js now injects is a perfect example — it stops the agent writing App Router code from two years of stale training data), and reserve Skills for the multi-step workflows docs can't drive end to end. next-dev-loop is the right shape for a Skill precisely because "edit, compile, reload, inspect, iterate" is a procedure, not a fact.

The bigger shift

Strip away the specifics and this is Next.js conceding that agents write a growing share of the code and designing the framework's feedback surfaces for them. Errors now ship with labeled fixes and paste-ready prompts. Docs are readable as plain Markdown at any URL with .md appended, version-matched through bundled docs so the agent reads 16.3 conventions instead of guessing from training data. The MCP server dropped its knowledge base and added get_compilation_issues and compile_route so an agent can check a single route without a full build.

The through-line: close the loop. An agent that can edit but can't observe is a junior dev who never runs the app. Give it a browser and a React tree and it stops guessing. That's worth the two-command setup — just don't mistake the green overlay for a page that actually renders.