Five things Cursor assumes about your Next.js project (that are probably wrong)

Cursor's training skews toward Next.js projects built before the App Router was the default. If you're on App Router — which you probably are if you started a project in the last year — you'll spend time correcting the same generation mistakes repeatedly until you write rules that override the assumptions.

Here are the five that come up most.

1. It defaults to the Pages Router

Even when you're clearly in an App Router project, Cursor will sometimes suggest creating files under pages/, propose getServerSideProps, or write API routes as pages/api/ handlers. This isn't confusion — it's prior probability. Most of the Next.js code in its training was Pages Router.

The rule that fixes it:

This project uses the Next.js App Router. Never create files under pages/.
Never use getServerSideProps, getStaticProps, or getStaticPaths.
API routes go in app/api/[route]/route.ts using the new route handler format.

2. It makes components client components by default

Cursor adds "use client" more than you want it to. The App Router default is server components, which is better for performance and simpler for data fetching. But Cursor's pattern-matching pulls toward client components because so much React code in its training was client-side.

If you don't specify, you'll end up with "use client" on components that don't need it, which forces their entire subtree to be client-rendered.

Default to server components. Only use "use client" when the component
needs browser APIs, event handlers, or React hooks (useState, useEffect).
Never add "use client" preemptively.

3. It uses fetch in useEffect for data fetching

The old pattern: fetch data in useEffect inside a client component. The App Router pattern: fetch directly in a server component, or use a server action. Cursor defaults to the old pattern when generating data fetching code unless you tell it otherwise.

Fetch data in server components directly — no useEffect, no useState for
server data. For client-triggered mutations, use Server Actions (use server).
Never fetch API routes from client components when a server component would work.

4. It puts types in the wrong place

Cursor will scatter type definitions — sometimes inline, sometimes in a local types.ts, sometimes in a component file. Whatever your project's convention is, Cursor won't know it unless you say so. The inconsistency adds up fast in a large codebase.

Shared types go in lib/types.ts. Component-specific types are defined
inline in the component file. Never create per-feature types files.

(Adjust to match your actual project structure — the point is making the rule explicit.)

5. It suggests next/image without your size constraints

Cursor knows to use next/image for images. It doesn't know your layout's size constraints. So it generates image components without width and height, or with fill when that's not what you want, and you end up editing the generated code every time.

Use next/image for all images. Always specify width and height explicitly —
never use fill unless the parent has explicit dimensions. Alt text is required.

The pattern

Each of these is the same problem: Cursor has a prior from its training and will apply it unless there's a rule that says otherwise. You need rules that are prohibitions, not preferences. "Prefer server components" won't do anything. "Never use "use client" unless the component needs browser APIs" will.

Five rules. They cover 80% of the corrections you'd otherwise make by hand in a Next.js App Router project.

---