Description
An AI agent will hand you Next.js that builds, deploys, and looks right in the browser, and is quietly wrong in ways the App Router makes easy to miss. It slaps `”use client”` on a component that should have stayed on the server, so your data-fetching code and sometimes a secret key ride down to the browser in the JavaScript bundle. It awaits three requests in a row that had no reason to be sequential, and the page takes three times as long as it should. It leaves the default `fetch` cache in place and serves a price that changed an hour ago, or turns caching off everywhere and hammers your database on every request. It reads `process.env.STRIPE_SECRET` in a client component and ships it to everyone who opens DevTools. It writes a Server Action that trusts whatever the form posts, with no validation between the browser and your database. The build passes, Vercel shows a green deploy, the page renders. None of that proves the component ran where it should have, cached what it should have, or refused the input it should have refused. What you lack is the reviewer’s model of how Next.js actually behaves, so you can read a diff of App Router code and know whether it ships or goes back.
This book trains you to be the reviewer of vibe-coded Next.js, not to memorize the framework. It starts from the premise every chapter returns to: the agent writes the routes, the layouts, and the server components, and your edge is understanding what that code really does on the server, in the cache, and in the browser, so you can review it with judgment the build step does not have. You will learn where the server ends and the client begins and why one wrong `”use client”` changes everything below it, what a server component can reach that a client component cannot, how Next decides when a page is built and when it is cached, what `revalidate` and the `fetch` cache options actually control, how a mutation gets from a button to your database through a Server Action and where that path has to be guarded, and why a missing `loading` or `error` boundary turns one slow or failing widget into a blank screen. You will learn it the way a reviewer needs it: by reading the code the agent would generate for one real project and deciding what is good, what is plausible-but-dangerous, and what to send back. There is almost no syntax drill here, and a great deal about how Next.js behaves under real data, real latency, and real users. For engineers who are going to vibe-code in Next.js either way and want to be the one who catches what the model shipped.
Who this was written for
This book is for: engineers who have decided to let an AI agent write their Next.js (vibe-coding) and now own the part the agent cannot, which is judging whether the App Router code it produced is correct, fast, and safe to ship, and who do not want to spend months memorizing routing conventions and rendering docs to earn that judgment.
What you’ll walk away with
- Chapter 1: The day the agent writes all your Next.js
- Chapter 2: Where /jobs/123 actually comes from
- Chapter 3: The component that never reaches the browser
- Chapter 4: The one line that ships your code to the browser
- Chapter 5: Why two awaits made the page twice as slow
- Chapter 6: The page that keeps serving yesterday’s data
- Chapter 7: Built once, or on every request?
- Chapter 8: The button that writes to your database
- Chapter 9: Why the whole screen went blank when one widget failed
- Chapter 10: Why Google sees an empty page
- Chapter 11: The four-megabyte image the agent shipped without blinking
- Chapter 12: The code that runs before the page does
- Chapter 13: Fast pages, slow app: where the time actually goes
- Chapter 14: Shipping Perch, and what production taught me
