Construir una web compleja con IA en 2026 funciona — si tenés un workflow definido. La diferencia entre un proyecto que avanza y uno que se enreda en bugs no está en el modelo elegido (Claude, GPT, Gemini), sino en cómo dividís el trabajo entre lo que delegás a la IA y lo que mantenés en control humano. En este artículo contamos cómo construimos esta web —Next.js 15 + Supabase + admin panel completo + flujos de mail automático— usando un asistente de IA como par de programación, los patrones que terminaron funcionando, los que descartamos por costo de mantenimiento, y los seis errores recurrentes con los que tropezamos durante el camino.
El contexto: qué construimos
La web que estás leyendo tiene varias capas que rara vez aparecen juntas en un proyecto chico:
- Landing institucional con secciones para varios servicios distintos.
- Sistema de blog con artículos como componentes React (no MDX runtime).
- Admin panel con varios módulos CRUD, lista de usuarios, exportaciones y reportes.
- Auth con segundo factor + middleware server-side para proteger las páginas del panel.
- Sistema de inscripciones a cursos gratuitos con email automático de bienvenida.
- Suscripción al blog con double opt-in y broadcast de nuevos artículos.
- Schemas JSON-LD para SEO/GEO, sitemap dinámico, robots.txt con allowlist de AI bots.
Es mucho superficie para un equipo chico. Sin asistencia IA habríamos tardado tres veces más — o habríamos cortado scope. Con IA mal usada, habríamos terminado con un código difícil de mantener y bugs ocultos. La forma en que dividimos el trabajo es la diferencia.
Qué delegamos a la IA (y qué no)
Después de varios meses iterando, la división estable que nos quedó es esta. No es la única posible — pero es la que probamos en producción y nos resultó.
Lo que delegamos casi por completo
Componentes de UI aislados. "Necesito una tabla con paginación, búsqueda y bulk actions" → la IA arma el componente en una pasada, lo revisamos visualmente, ajustamos detalles de spacing y listo. El riesgo es bajo porque el componente vive en un archivo, no toca lógica de negocio, y cualquier bug es visible al instante.
Endpoints REST simples con un solo handler. "POST que recibe email, valida, manda mail con Resend" → la IA escribe el handler completo incluyendo validación de input y manejo de errores. Acá hay que revisar más cuidadosamente (los detalles importan), pero el patrón es repetible y la IA lo hace bien si le pasás ejemplos de otros endpoints del proyecto como referencia.
Migraciones SQL. "Tabla de suscriptores con email único, token de confirmación, timestamps y RLS para que el admin pueda listar" → la IA escribe la migración. Revisamos especialmente las RLS (las RLS mal escritas son una clase de bug que solo aparece en producción).
Templates HTML para email. Históricamente lo más tedioso del desarrollo web. La IA arma tablas con inline styles email-safe, escapa los datos del usuario, soporta dark mode parcial. Lo único que hacemos a mano es validar en Gmail/Outlook/Apple Mail con un test real.
Lo que mantenemos en control humano
Arquitectura general. La decisión de "blog con JSX articles" vs "blog con MDX runtime" la tomamos nosotros. La IA puede argumentar pros y contras si le preguntás, pero quien decide cómo se va a estructurar el proyecto por los próximos años somos nosotros. Si dejás esa decisión en manos de la IA, terminás con un Frankenstein de patrones distintos según el día.
Sistema de autenticación. Cualquier código que toque login, sesiones, tokens, contraseñas, lo escribimos o revisamos línea por línea. Los modelos pueden tener patrones inseguros aprendidos de codebases viejos — pasar secretos por query param, mensajes de error que filtran info, validaciones que se saltean cuando el token "no parece" un JWT. Son patrones que se ven naturales pero abren puertas.
Integraciones críticas. Resend, Stripe (cuando lo agreguemos), webhooks. Acá un bug significa correos no enviados, pagos no procesados, o eventos perdidos. La IA puede escribir el código base pero cada caso edge se revisa a conciencia.
Código que toca dinero o datos sensibles. Cálculos de precios, descuentos, cupones, montos finales. Si hay un bug en la matemática, perdemos plata o le cobramos mal a un cliente. Esa lógica la escribimos nosotros y le pedimos a la IA que escriba tests.
| Característica | ~60% del códigoDelegado a IA | ~40% del códigoControl humano |
|---|---|---|
Componentes UI aislados | Sí | No |
Endpoints REST simples | Sí | No |
Migraciones SQL básicas | Sí | No |
Templates HTML email | Sí | No |
Copys de UI | Sí | No |
Arquitectura general | No | Sí |
Autenticación + autorización | No | Sí |
Integraciones de pago / mail | No | Sí |
Cálculos de precios y descuentos | No | Sí |
RLS de la base (revisar siempre) | No | Sí |
Decisiones de stack y dependencias | No | Sí |
El workflow concreto
Más allá de qué se delega y qué no, lo que más impacta en la calidad final es cómo se interactúa con la IA. Estos son los cuatro patrones que terminamos usando.
1. Contexto antes que prompt
El error más común al usar IA para programar es pedir cosas sin contexto. "Hacé un componente de tabla" produce algo genérico que probablemente no encaja con el resto del proyecto. La forma de obtener buenos resultados es darle al asistente acceso al codebase para que vea cómo están hechas otras tablas, qué design tokens usamos, qué utilidades hay disponibles.
En la práctica esto significa usar asistentes que pueden leer archivos del repo (Claude Code, Cursor en modo agent, Aider, etc.) en vez de chats donde tenés que pegar manualmente. La diferencia en calidad es enorme — un componente "tipo nuestro" en vez de un componente "tipo de la documentación".
2. Verificar antes de aceptar
La IA puede afirmar con seguridad cosas que son falsas. Un caso típico: te dice "agregué la columna X en la tabla Y" pero en realidad la agregó en la tabla Z. O "el endpoint devuelve 401 si no hay sesión" pero olvidó el check. La regla práctica es:
- Compilá / lintá / corré tests después de cada cambio significativo.
- Hacé un git diff y leelo de verdad. No "lo hojeo" — lo leo línea por línea si toca seguridad o lógica de negocio.
- Probá manualmente el feature en local. Los tests automáticos no atrapan todo.
3. Iteraciones chicas vs prompts gigantes
Es tentador pedir "armame todo el sistema de subscripción al blog con form, endpoints, templates, admin y notify". A veces sale. Más veces sale algo razonable pero con detalles raros: una columna SQL que no encaja, un endpoint con tipo de error distinto al resto del proyecto, un componente que rompe la convención de styling.
Encontramos que iterar en chunks de 30-90 minutos de trabajo (un endpoint, un componente, una migración) y revisar cada uno antes del siguiente da resultados mejores. La IA es rápida, así que no perdemos velocidad — ganamos calidad.
4. Conversaciones largas pierden calidad
Si una sesión de trabajo con el asistente lleva 3+ horas, los modelos empiezan a perder contexto: olvidan decisiones tomadas al inicio, repiten errores ya corregidos, mezclan archivos. La heurística que nos quedó es: cuando notamos que el modelo "se confunde", abrimos una sesión nueva con un brief corto del estado actual. Cuesta dos minutos y restaura la lucidez.
"La pregunta correcta no es "¿puede la IA escribir este código?" sino "¿puedo yo revisar el código que la IA escribió a la velocidad que la IA lo escribe?" Si la respuesta es no, tenés que bajar el ritmo de delegación, no el del asistente."
Errores recurrentes con los que tropezamos
Más útil que los aciertos son los tropezones — son los que se repiten en cada proyecto que usa IA. Estos son seis que aparecieron en esta web:
Error 1 · "El SDK no tiró excepción, así que funcionó"
Algunos SDKs modernos devuelven { data, error } en vez de tirar excepción cuando algo falla. Nuestro código asumió excepción y marcó como "email enviado" mails que en realidad nunca salieron. La IA generó el patrón inicial y nosotros lo aprobamos porque "se ve normal". Es un patrón normal en otros SDKs — no en este. Aprendimos a leer la doc de cada SDK que toca producción aunque la IA "ya lo sepa".
Error 2 · Doble LayoutShell en el blog
El root layout de Next.js envolvía la app en un <LayoutShell> (navbar + footer). Cuando creamos las páginas del blog, la IA agregó otro <LayoutShell> dentro de cada página. Resultado: dos footers stackeados. El bug solo era visible en producción porque en dev mode con HMR el segundo footer aparecía intermitente.
Error 3 · CSP roto en producción, no en dev
Activamos Content-Security-Policy con un set de directivas "razonables". En dev funcionaba porque las URLs eran localhost. En producción rompió las imágenes de logo y team (que vivían en otro dominio CDN). Lección: probar CSP en dev con las URLs reales de producción, no con localhost.
Error 4 · useSearchParams sin Suspense
Next.js 15 requiere que cualquier componente que use useSearchParams() esté wrappeado en <Suspense> para que el build SSG funcione. Si no, el build se completa en dev pero falla en producción con un error críptico. Lo descubrimos cuando el deploy a producción no buildeaba.
Error 5 · Migraciones de SDK con varios call sites
Cuando un SDK que usás en muchos archivos te obliga a cambiar la forma en que se instancia (deprecación de un paquete, cambio de patrón cliente/servidor, etc.), la migración consiste en tocar TODOS los call sites. La IA suele tocar la mayoría pero "olvida" alguno escondido en una utility menos visitada. Y ese call site queda usando el patrón viejo — silencioso, hasta que en runtime alguien pasa por ese código y se rompe algo. Lección: después de una migración global, revisar manualmente con grep que no quedó ni un solo uso del patrón anterior.
Error 6 · Confirmación de comandos destructivos
En el admin panel, los bulk actions (eliminar 50 inscripciones de una vez) no tenían modal de confirmación al inicio. Es el clásico bug "la IA hace lo que le pediste, no lo que necesitabas". Lo agregamos después de un click accidental (sin pérdida de datos porque era ambiente de testing). Si fuera producción real, habríamos perdido data.
El stack final
Para referencia, este es el stack con el que llegamos a una versión estable de la web. No es prescriptivo — cada proyecto puede elegir distinto — pero sí refleja qué combinó bien con un workflow asistido por IA.
- Framework: Next.js 15 App Router. Estable y muy bien documentado, lo que ayuda a la IA a generar código que sigue convenciones reales.
- Base de datos + auth: Postgres con un proveedor que incluye RLS y auth completo. Documentación accesible para los modelos.
- Styling: Tailwind CSS v4 con design tokens en variables CSS. Tailwind tiene el mejor "lenguaje compartido" entre humanos y IA — los class names son los mismos en todos los ejemplos.
- UI: componentes propios + librería de iconos + librería de animations.
- Emails: proveedor de email transaccional con templates HTML hand-rolled. La opacidad de un template servido como string nos da más control sobre rendering en clients viejos.
- Hosting: hosting tradicional Node.js. Cumple para esta escala; si más adelante necesitamos edge o queues, evaluaremos opciones tipo Vercel/Railway/Fly.io.
- Asistente: Claude Code para el grueso del coding agent-style.
Cómo arrancar si querés probar este workflow
Si nunca usaste IA para programar más allá de copiar snippets de un chat, el salto al modo "agent" puede sentirse desorientador. Estos son los primeros pasos que recomendamos para un equipo chico:
- Elegí un proyecto pequeño pero no trivial. Una landing con form de contacto, o un mini-CRUD. Algo que tenga al menos un endpoint, una base de datos, y un flujo end-to-end.
- Setupeá el entorno bien antes. Stack elegido, repo iniciado, deploy de prueba funcionando, env vars documentadas. La IA acelera el desarrollo, no el setup inicial.
- Empezá con un asistente file-aware. Claude Code, Cursor en modo agent, Aider. Las herramientas que pueden leer/escribir archivos del repo dan resultados mucho mejores que chats sueltos.
- Hacé revisión de código a tu propio código. Aunque seas el único humano, revisá cada cambio significativo como si lo hubiera escrito un junior. Es exactamente eso.
- Trackeá los errores recurrentes. Llevá una nota con los bugs que la IA introdujo y las correcciones. En 2-3 semanas vas a tener tu propio "manual de defensa" personalizado.