Guide development and debugging in Next.js 16 and later using Turbopack, a tool that bundles application code. Review slow startup, live updates, caching, webpack alternatives, bundle analysis, and version-specific proxy file naming.
Next.js 16+ and Turbopack guidance — incremental Rust bundling, file-system caching, faster dev startup and HMR, Turbopack vs webpack tradeoffs, and the middleware.ts to proxy.ts filename change. Use when developing or debugging Next.js 16+ apps, diagnosing slow dev startup or hot reload, choosing between bundlers, or reviewing middleware/proxy file naming.
Review the instructions the agent will receive before you install.
Next.js 16+ uses Turbopack by default for local development: an incremental bundler written in Rust that significantly speeds up dev startup and hot updates.
--webpack (or --no-turbopack depending on your Next.js version; check the docs for your release).next build) may use Turbopack or webpack depending on Next.js version; check the official Next.js docs for your version.Use when: developing or debugging Next.js 16+ apps, diagnosing slow dev startup or HMR, or optimizing production bundles.
next dev runs with Turbopack unless disabled..next; no extra config needed for basic use.next dev
next build
next start
Run next dev for local development with Turbopack. Use the Bundle Analyzer (see Next.js docs) to optimize code-splitting and trim large dependencies. Prefer App Router and server components where possible.
Next.js 16 introduced proxy.ts as the middleware filename, replacing the older middleware.ts convention:
proxy.ts at the project rootmiddleware.ts at the project rootThe filename change is tied to the Next.js version, not to which bundler (Turbopack or webpack) is in use. Always check the official docs for the version you are reviewing.
Do not flag proxy.ts as a misnamed or missing middleware file in Next.js 16 projects. The file is correct and intentional. Suggesting a rename to middleware.ts will break middleware execution.
Reference: Next.js proxy docs
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.
Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.
Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.
Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.
Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.
Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.