Cómo evitar que la IA coloque código del servidor en componentes del cliente

Los agentes de IA filtran consultas a la base de datos, variables de entorno secretas y APIs de Node.js en componentes 'use client', exponiendo lógica del servidor al bundle del navegador.

El agente añade una directiva "use client" a un componente que importa Prisma, fs o una variable de entorno secreta, lo que envía ese código al bundle del navegador de cada visitante.

El síntoma

Un componente marcado con "use client" realiza una llamada directa a la base de datos o lee un secreto de process.env.

"use client";
import { db } from "@/lib/db"; // Prisma client — Node.js only
import { useState, useEffect } from "react";

export function UserCard({ id }: { id: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    // db is a Node.js module — this will throw at runtime in the browser
    db.user.findUnique({ where: { id } }).then(setUser);
  }, [id]);

  return <div>{user?.name}</div>;
}

La compilación puede tener éxito (Next.js agrupa la importación) pero la página lanza un error en tiempo de ejecución en el navegador porque @prisma/client requiere APIs de Node.js.

Por qué ocurre

El agente ve que se necesitan datos dentro de un componente que también usa estado o efectos, y recurre a la capa de datos que conoce. No modela el límite servidor/cliente ni sabe que los componentes "use client" no pueden importar módulos exclusivos de Node.js.

Cómo detectarlo

"use client" al inicio de un archivo que también importa desde @/lib/db, prisma, fs, path o crypto.
process.env.DATABASE_URL o cualquier variable _SECRET_ leída dentro de un archivo "use client".
La salida de compilación contiene Critical dependency: the request of a dependency is an expression o una advertencia de bundle de Prisma.
El paquete server-only está ausente del proyecto.

Cómo solucionarlo

Dividir en un componente padre del servidor que obtiene los datos y un componente hijo del cliente que maneja la interactividad.

// app/users/[id]/page.tsx — Server Component (no directive)
import { db } from "@/lib/db";
import { UserCard } from "./UserCard";

export default async function UserPage({ params }: { params: { id: string } }) {
  const user = await db.user.findUniqueOrThrow({ where: { id: params.id } });
  // Serialize — pass plain data, not the Prisma object
  return <UserCard name={user.name} email={user.email} />;
}

// app/users/[id]/UserCard.tsx — Client Component
"use client";
import { useState } from "react";

export function UserCard({ name, email }: { name: string; email: string }) {
  const [expanded, setExpanded] = useState(false);
  return (
    <div>
      <p>{name}</p>
      {expanded && <p>{email}</p>}
      <button onClick={() => setExpanded((v) => !v)}>Toggle</button>
    </div>
  );
}

[ ] Install "server-only" and import it at the top of every server-side lib file
[ ] No db/prisma imports in "use client" files
[ ] No process.env secrets read in "use client" files
[ ] Server Component fetches data; Client Component receives plain props
[ ] Use Server Actions (not useEffect+fetch) when a client interaction needs db access

Prompt de solución

This "use client" component imports server-only modules (Prisma, fs, or secret
env vars). Refactor it: move all data fetching into an async Server Component
parent, pass only serializable props to the client component, and keep "use
client" only on the part that needs browser APIs or React state. Add
"server-only" to any shared lib files that must never reach the browser.

Prueba

# List all "use client" files that also import known server-only packages
grep -rl '"use client"' app/ | xargs grep -l "prisma\|@/lib/db\|\"fs\"\|\"path\"\|\"crypto\"" && echo "FAIL: server code in client component" || echo "OK"