DEV Community: Lavie

React 19 migration traps your AI keeps falling into (and how to fix them with .mdc rules)

Lavie — Wed, 01 Apr 2026 20:17:59 +0000

Every AI coding assistant was trained on React 18 patterns. When you're building with React 19 + Next.js 15, the AI generates code that compiles perfectly but fails at runtime or behaves unexpectedly.

Here are the 4 most common React 19 traps I've documented, with .mdc rules to prevent each one.

1. useFormStatus() returns `{ pending: false }` forever

The trap: The AI places useFormStatus() in the same component that renders the <form>. This will NEVER work — useFormStatus only reads status from a parent <form>.

// ❌ AI generates this — pending is ALWAYS false
'use client'
export function MyForm() {
  const { pending } = useFormStatus()
  return (
    <form action={createItem}>
      <Button disabled={pending}>Submit</Button>
    </form>
  )
}

// ✅ Extract the button to a child component
function SubmitButton() {
  const { pending } = useFormStatus()
  return <Button disabled={pending}>{pending ? 'Saving...' : 'Submit'}</Button>
}

export function MyForm() {
  return (
    <form action={createItem}>
      <SubmitButton />
    </form>
  )
}

2. useFormState is deprecated — AI still imports it

React 19 renamed useFormState to useActionState and moved it from react-dom to react. The AI generates the old import because its training data is 99% React 18.

// ❌ Deprecated — AI generates this
import { useFormState } from 'react-dom'

// ✅ React 19
import { useActionState } from 'react'
const [state, formAction, isPending] = useActionState(serverAction, initialState)

3. forwardRef is no longer needed

In React 19, ref is a regular prop. The AI wraps every component in forwardRef() because that's what it learned from thousands of React 18 examples.

// ❌ Unnecessary boilerplate in React 19
const MyInput = forwardRef<HTMLInputElement, Props>((props, ref) => {
  return <input ref={ref} {...props} />
})

// ✅ React 19 — ref is a regular prop
function MyInput({ ref, ...props }: Props & { ref?: React.Ref<HTMLInputElement> }) {
  return <input ref={ref} {...props} />
}

4. params are Promises in Next.js 15

This is the #1 runtime crash. In Next.js 15, params and searchParams are Promise objects. The AI generates synchronous destructuring because Next.js 14 used synchronous params.

// ❌ Compiles in dev, crashes in production
export default function Page({ params }: { params: { id: string } }) {
  const { id } = params
}

// ✅ Next.js 15 — params are async
export default async function Page({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
}

The .mdc solution

Each of these traps has a corresponding .mdc rule file that activates based on file globs. When the AI opens a .tsx file, the rules inject the correct patterns into the context window, overriding the stale training data.

I've documented 29 of these patterns (React 19, Next.js 15, Supabase SSR, Stripe) as open source .mdc rule files:

GitHub: github.com/vibestackdev/vibe-stack

Quick install (5 free rules):

npx vibe-stack-rules init

What React 19 traps have you hit with AI code generation? I'd love to add them to the rule set.

Why your Cursor rules are being silently ignored (and how to fix it)

Lavie — Wed, 01 Apr 2026 17:56:56 +0000

The most frustrating thing about Cursor rules

You write a rule. You are confident it is correct. You open a chat. The AI ignores it completely and generates the exact pattern you told it not to.

No error. No warning. Just silence.

This happens to almost every developer who adopts .mdc rules, and it almost always comes down to four root causes.

Cause 1: Malformed YAML frontmatter (the silent killer)

This is the number 1 reason rules are ignored. If your frontmatter has any syntax error, Cursor silently skips the file. No warning, no log, nothing.

Wrong patterns that silently fail:

---
description: My rule
alwaysApply: true

Missing the closing ---. Rule is never loaded.

---
description: My rule
globs: src/**/*.ts
---

Glob must be an array. Rule is never loaded.

---
description: My rule
alwaysApply: True
---

YAML is case-sensitive. True is not true. Rule is never loaded.

Correct format:

---
description: What this rule prevents
globs: ["src/**/*.ts", "src/**/*.tsx"]
alwaysApply: false
---

Debug step: Open Cursor Settings and navigate to Rules. You should see your rule listed there. If it is missing, your frontmatter is broken.

Cause 2: You are using the old single-file format

The .cursorrules single file at the project root still works, but it conflicts unpredictably with the newer .cursor/rules/ directory format. If you have both, behavior is undefined.

Migrate fully to .cursor/rules/:

.cursor/
  rules/
    supabase-auth.mdc
    nextjs15-params.mdc
    project-context.mdc

Delete your old .cursorrules file entirely.

Cause 3: Too many rules with alwaysApply: true

Rules with alwaysApply: true load into every session and consume context window tokens whether the task needs them or not.

If you have 10+ rules all set to alwaysApply: true, you are burning a large portion of the context window before the conversation even starts. The model satisfies all of them simultaneously and produces average output that partially violates most of them.

The fix: only 1-2 rules should have alwaysApply: true. Everything else should be glob-targeted.

A well-structured system:

project-context.mdc      alwaysApply: true  (project identity only -- keep it tiny)
supabase-auth.mdc        globs: ["**/lib/supabase/**"]
nextjs15-params.mdc      globs: ["**/app/**/*.tsx"]
stripe-payments.mdc      globs: ["**/api/webhooks/**"]

Now only the relevant rules load for each file. Context is clean. Compliance improves.

Cause 4: Negative instructions vs. positive instructions

LLMs are trained to predict the next token. Negative instructions require the model to first imagine the bad pattern and then suppress it. This is harder than positive instructions.

Weak: "Never use getSession() on the server"

Strong: "Always use supabase.auth.getUser() for server-side auth. getUser() is the only method that verifies the JWT with the auth server."

For security-critical rules, use both: tell the model what to do AND explicitly ban the alternative.

Cause 5: The session is too long

LLMs lose track of early context in long chat sessions. A rule loaded at the start may be effectively forgotten after 10-15 turns.

Two fixes:

Start fresh sessions for new tasks. Do not continue a 20-turn session for a new feature.
Add rules as explicit references in your prompt: "Implement this following the auth patterns in supabase-auth-security.mdc."

The debugging checklist

When a rule is being ignored, run through this in order:

Is the file in .cursor/rules/ (not .cursorrules)?
Does the frontmatter have both opening and closing ---?
Are glob patterns wrapped in an array ["..."]?
Is alwaysApply lowercase true or false?
Does the rule appear in Cursor Settings > Rules?
Is the rule file under 150 lines?
Is the rule phrased positively?
Is this a fresh session?

What the Claude Code leak teaches us

The leaked Claude Code source code (March 31) revealed something relevant: even Anthropic's own production agent treats constraints as hints, not truth by default. It actively re-reads source files before acting because it knows its own memory is unreliable.

The lesson: rule enforcement is not a passive property of having a rule file. It requires the rule to be correctly formatted, the task to be scoped small enough that the rule stays in context, and explicit invocation for critical operations.

That is the same principle behind structuring rules as small, focused, glob-targeted files instead of one giant instruction document.

Next in this series: how to structure more than 20 rules without causing constraint drift.

The Claude Code leak proves what I've been building for months - AI architecture rules are not optional

Lavie — Wed, 01 Apr 2026 14:13:33 +0000

Anthropic just accidentally published the best argument for .mdc rules

On March 31, Anthropic shipped a source map file in their Claude Code npm package. Inside: 512,000 lines of unminified TypeScript showing exactly how a production-grade AI coding agent works internally.

The developer community has been picking through it for 24 hours. I have been reading every analysis I can find, and one thing jumped out immediately:

Claude Code's own architecture validates the exact approach I have been building for the past two months.

The pattern Anthropic uses internally

Claude Code is not a thin wrapper around an API. It is a full agent harness with five key architectural patterns:

1. Persistent rule files (CLAUDE.md)

Claude Code loads a CLAUDE.md file at session start -- a markdown document containing project constraints, architectural rules, and "things to never do." Sound familiar?

This is the same concept as .mdc rules in Cursor, .github/copilot-instructions.md in GitHub Copilot, and .windsurf/rules/ in Windsurf. Every major AI coding tool has converged on the same idea: persistent, file-based architectural constraints that survive between sessions.

2. A "fail-closed" permission pipeline

Every action in Claude Code passes through a permission system that classifies operations as LOW, MEDIUM, or HIGH risk. The evaluation order is strict: Deny > Ask > Allow.

When a permission is denied, the denial gets fed back to the model as an error, so it learns to adjust its plan. Constraints must be enforced at generation time, not audited after the fact.

3. Skeptical retrieval -- never trust your own memory

The leaked code shows that Claude Code treats its own stored knowledge as "hints, not truth." Before acting on something it "remembers," it re-reads the actual source file to verify.

4. Strict Write Discipline

Claude Code only updates its memory after verified success. If a file write fails or a test breaks, nothing gets stored. This prevents the agent from "learning" incorrect patterns from its own failures.

5. KAIROS and autoDream -- where this is headed

The leaked source references an unreleased autonomous daemon called KAIROS (mentioned 150+ times). It runs background sessions and monitors GitHub webhooks even when the developer is idle. Its companion, autoDream, consolidates memory during idle time -- removing contradictions and converting observations into facts.

The rules you write today become seeds of your project's permanent architectural memory.

Why this matters for your Next.js project

The leak reveals the architecture, but not domain-specific rules. Here are three hallucination patterns I have been cataloguing:

The getSession() hallucination

// INSECURE -- reads JWT without verification
const { data: { session } } = await supabase.auth.getSession()

// SECURE -- verifies with auth server  
const { data: { user } } = await supabase.auth.getUser()

The Next.js 15 async params crash

// Compiles fine. Crashes at runtime in Next.js 15.
export default function Page({ params }: { params: { id: string } }) {
  return <div>{params.id}</div>
}

// Correct -- params is a Promise in Next.js 15
export default async function Page({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params
  return <div>{id}</div>
}

Middleware auth enforcement (false security)

Middleware runs on Edge Runtime and cannot verify Supabase JWTs. Auth enforcement must happen in layouts/pages via getUser(), not middleware.

The takeaway

The Claude Code leak is a roadmap. Anthropic built a constraint-first architecture because that is the only way to make AI coding reliable at scale.

I maintain 25 free .mdc architecture rules for Next.js 15 + Supabase + Stripe: github.com/vibestackdev/vibe-stack

Follow me for the full series on preventing AI hallucinations in modern web development.

The Claude Code leak proves what I've been claudecode, cursor, nextjs, aibuilding for months

Lavie — Wed, 01 Apr 2026 14:12:43 +0000

I catalogued every AI hallucination in Next.js 15 — then I built a system to prevent them permanently

Lavie — Mon, 30 Mar 2026 16:51:27 +0000

TL;DR: AI coding assistants have 5 recurring hallucination patterns that ship critical bugs to production. I documented 47 of them, then wrote 22 .mdc rule files that physically prevent Cursor from generating insecure auth, deprecated imports, and broken Next.js 15 patterns. The entire system is free and open source.

I stopped writing code three months ago.

Not because I was burned out or because I found a "no-code" tool. I stopped because I realized I was playing the wrong game.

I was using Cursor's Agent mode to build a Next.js SaaS app. The code looked clean. The types were correct. Everything compiled. And then I deployed to production and discovered that every single auth check in my application was insecure.

The AI had used getSession() everywhere -- a function that reads a JWT from cookies without verifying it. Any user could craft a fake token and my app would treat them as authenticated.

That bug cost me 6 hours to fix. And it taught me something important.

The Uncomfortable Truth About AI Coding

AI models are crowd-pleasers. They'll generate whatever you ask for, with perfect TypeScript syntax and zero compiler errors. But they have systematic blind spots -- patterns baked into their training data that are now deprecated, insecure, or broken.

I started keeping a spreadsheet. Every time Cursor generated a pattern that I had to manually fix, I logged it. After three months, I had documented 47 recurring hallucination patterns across Next.js 15, Supabase, and Stripe.

Here are the five most dangerous:

1. The getSession() Security Flaw

What the AI generates:

// Looks correct. Compiles fine. Catastrophically insecure.
const { data: { session } } = await supabase.auth.getSession()
if (!session) redirect('/login')

Why it's dangerous: getSession() reads the JWT from cookies but does NOT verify it with Supabase's auth server. An attacker can craft a fake JWT and your server will accept it.

The secure pattern:

// This sends a request to Supabase to cryptographically verify the token
const { data: { user } } = await supabase.auth.getUser()
if (!user) redirect('/login')

The training data is dominated by pre-2024 tutorials when getSession() was the recommended approach. Supabase changed their guidance -- but the models haven't caught up.

2. The Next.js 15 Params Time Bomb

What the AI generates:

export default function Page({ params }: { params: { slug: string } }) {
  return <h1>{params.slug}</h1>  // CRASHES: params is a Promise in Next.js 15
}

The correct pattern:

export default async function Page({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  return <h1>{slug}</h1>
}

This breaks silently in development (Next.js does some auto-handling) but explodes in production builds. I've seen 4 different open-source repos with this exact bug.

3. The Deprecated Package Import

What the AI generates:

import { createClientComponentClient } from '@supabase/auth-helpers-nextjs'

The correct import:

import { createBrowserClient } from '@supabase/ssr'

auth-helpers-nextjs was deprecated in favor of @supabase/ssr. The old package doesn't handle cookie-based sessions correctly with the App Router. But the AI has seen 10x more examples of the old package.

4. The Client Component Disease

The AI loves 'use client'. Ask it for a product page, and it'll slap 'use client' at the top and use useState + useEffect to fetch data from an API route.

This is the React equivalent of driving a Ferrari in first gear. Server Components fetch data on the server with zero client-side JavaScript. They're faster, more secure, and simpler. But the AI defaults to 2022 patterns because that's what it was trained on.

5. The Missing RLS Time Bomb

When the AI creates a Supabase table, it almost never enables Row Level Security. This means your database is wide open -- any authenticated user can read any other user's data using the anon key.

My Solution: Architecture Rules That Physically Constrain the AI

After documenting all 47 patterns, I realized that "being careful" wasn't enough. I needed guardrails that work automatically.

Cursor supports .mdc rule files -- markdown files with YAML frontmatter that the AI reads based on which files you're editing. They act like a senior code reviewer that's always watching.

Here's how they work:

---
description: Supabase auth security -- enforces getUser() over getSession()
globs: ["**/app/**", "**/actions/**", "**/api/**"]
---

# Supabase Auth Security

SECURITY CRITICAL: NEVER use getSession() in server-side code.
ALWAYS use getUser() -- it verifies the JWT against the auth server.

SECURE: const { data: { user } } = await supabase.auth.getUser()
INSECURE: const { data: { session } } = await supabase.auth.getSession()

When this rule is active, every file matching **/app/** automatically receives this constraint. The AI cannot generate getSession() calls because the rule explicitly overrides its training data.

I wrote 22 of these rules. Not 22 random guidelines -- 22 precisely scoped constraints targeting the most dangerous hallucination patterns across:

Authentication security (getUser vs getSession, deprecated packages)
Next.js 15 breaking changes (async params, generateMetadata)
Component architecture (Server vs Client, minimal 'use client')
Database security (RLS enforcement, service_role restrictions)
Input validation (Zod at every boundary)
Performance (parallel fetching, N+1 prevention, dynamic imports)
Payments (server-only Stripe, webhook signature verification)
OWASP Top 10 (injection, XSS, rate limiting)

The 3-Stage Agentic Loop

The rules prevent bad output. But to get great output, you need a prompting framework. Here's mine:

Stage 1: Plan (Act as the Architect)

"I need to build a magic-link auth flow. Before writing any code, create an Architectural Plan: which files, which are Server vs Client Components, what RLS policies. Wait for my approval."

Forcing the AI to plan before coding catches bad architectural decisions before they become bad code.

Stage 2: Implement (Constrained Batches)

"Execute Phase 1 only -- database schemas and RLS policies. Stop when Phase 1 is done."

AI output quality degrades with length. Small batches keep it sharp.

Stage 3: Verify (Self-Audit)

"Review the server action you wrote. Did you use getUser()? Did you validate input with Zod? Check against our project rules."

Self-reflection catches 80% of hallucinations before you hit save.

Try It -- It's Free and Open Source

I packaged the entire system as Vibe Stack -- a Next.js 15 + Supabase boilerplate with all 22 rules pre-configured.

What you get:

Next.js 15 App Router + React 19 + TypeScript (strict mode)
22 battle-tested .mdc architecture rules
Supabase SSR auth (the secure way)
4 pre-configured MCP servers (GitHub, Filesystem, Supabase, Browser)
Working auth flow (login, signup, email confirm, protected dashboard)
Error boundaries, loading states, custom 404
Complete Architecture Decision Records explaining every "why"

git clone https://github.com/vibestackdev/vibe-stack.git
cd vibe-stack && npm install
cp .env.example .env.local
npm run dev

Open it in Cursor. Start building. Watch the AI write architecture instead of spaghetti.

try the Premium Stack

If you want the extended version with Stripe subscription management, Resend email templates, n8n automation workflows, and the complete "Vibe Coding Masterclass" -- it's linked in the repo's README.

What hallucination patterns have you been fighting? I'm building new rules every week -- drop your worst AI-generated bugs in the comments and I'll turn them into constraints.

Follow me for more posts on AI-assisted architecture. Next up: "How I use MCP servers to give Cursor superpowers."

DEV Community: Lavie

React 19 migration traps your AI keeps falling into (and how to fix them with .mdc rules)

1. useFormStatus() returns { pending: false } forever

2. useFormState is deprecated — AI still imports it

3. forwardRef is no longer needed

4. params are Promises in Next.js 15

The .mdc solution

Why your Cursor rules are being silently ignored (and how to fix it)

The most frustrating thing about Cursor rules

Cause 1: Malformed YAML frontmatter (the silent killer)

Cause 2: You are using the old single-file format

Cause 3: Too many rules with alwaysApply: true

Cause 4: Negative instructions vs. positive instructions

Cause 5: The session is too long

The debugging checklist

What the Claude Code leak teaches us

The Claude Code leak proves what I've been building for months - AI architecture rules are not optional

Anthropic just accidentally published the best argument for .mdc rules

The pattern Anthropic uses internally

1. Persistent rule files (CLAUDE.md)

2. A "fail-closed" permission pipeline

3. Skeptical retrieval -- never trust your own memory

4. Strict Write Discipline

5. KAIROS and autoDream -- where this is headed

Why this matters for your Next.js project

The getSession() hallucination

The Next.js 15 async params crash

Middleware auth enforcement (false security)

The takeaway

The Claude Code leak proves what I've been claudecode, cursor, nextjs, aibuilding for months

I catalogued every AI hallucination in Next.js 15 — then I built a system to prevent them permanently

The Uncomfortable Truth About AI Coding

1. The getSession() Security Flaw

2. The Next.js 15 Params Time Bomb

3. The Deprecated Package Import

4. The Client Component Disease

5. The Missing RLS Time Bomb

My Solution: Architecture Rules That Physically Constrain the AI

The 3-Stage Agentic Loop

Try It -- It's Free and Open Source

try the Premium Stack

1. useFormStatus() returns `{ pending: false }` forever