ChatGPT, GitHub Copilot, Cursor y sus primos ahora pueden generar un componente de React antes de que termines de escribir el prompt. ¿Conectar una ruta de Next.js a Supabase? Hecho en segundos. ¿Refactorizar esa utilidad de TypeScript enredada? Aquí tienes tres opciones, completas con sus type guards. Para cualquiera que trabaje con stacks web modernos, la experiencia puede sentirse casi mágica.
Uso estas herramientas a diario. Mi stack es Next.js, TypeScript y Supabase, y la IA está ahí mismo en mi editor, lista para crear la estructura de hooks personalizados, generar consultas a la base de datos o limpiar lógica condicional desordenada. En tareas pequeñas, se comporta como un desarrollador junior muy rápido. Conoce la sintaxis de memoria. Recuerda superficies de API que yo tengo que buscar en Google. No se cansa de escribir boilerplate.
Pero el software sigue rompiéndose. Las aplicaciones se sienten más lentas. Los paneles de control de los clientes tienen lag. Los casos de borde rompen los formularios. Si la IA ha hecho que programar sea mucho más fácil, ¿por qué usar software se siente peor que hace unos años?
La respuesta es que generar sintaxis y construir software no son el mismo trabajo.
La sintaxis no es arquitectura
La IA maneja los tokens de forma notable. Pídele que escriba un hook useEffect que escuche un canal en tiempo real de Supabase y obtendrás algo que compila. Puede convertir un archivo JavaScript sin tipar en TypeScript estricto, o montar un componente de formulario con validación de Zod antes de que te hayas tomado tu café.
Lo que no puede hacer es entender los contornos de tu aplicación específica. El buen software requiere una gestión de estado deliberada, un manejo cuidadoso de las condiciones de carrera y un mapa claro de dónde residen los datos frente a dónde simplemente se muestran. La IA ve el archivo inmediato, no el sistema. Trata tu base de código como un pasillo de texto plano en lugar de una estructura viva con muros de carga.
Piénsalo como un arquitecto que nunca ha vivido en una casa. Puede dibujar planos hermosos. Sabe cuántas ventanas debería tener un dormitorio. Pero no sabe dónde suelen tener fugas las tuberías en febrero, o qué pasillo se vuelve inutilizable con el calor del verano. Ese conocimiento vivencial es lo que mantiene en pie un edificio. El código funciona de la misma manera.
Los dos puntos de fricción
Cuando dejo que la IA escriba bloques de código más grandes sin protecciones estrictas, noto que los mismos dos problemas aparecen una y otra vez.
Primero, ignora los patrones de diseño que ya has establecido. Quizás tu equipo extrae toda la obtención de datos a una capa dedicada de hooks personalizados. Quizás tienes una convención estricta sobre cómo las políticas RLS de Supabase se mapean con los helpers del frontend. A la IA no le importa. Insertará un supabase.from().select() puro directamente en el onClick de un botón si eso resuelve el prompt inmediato. El código funciona. Incluso parece limpio. Pero es un elemento discordante en tu base de código, y cada elemento discordante es un impuesto de refactorización futuro. Seis meses después, alguien tendrá que encontrar esa aguja, entender por qué existe y volver a alinearla suavemente.
Segundo, recurre a la complejidad cuando la simplicidad bastaría. La herramienta ha sido entrenada con repositorios lo suficientemente grandes como para necesitar fábricas abstractas, patrones de reducer intrincados y componentes de orden superior multicapa. Cuando le pides que construya un simple formulario de contacto, bien podría entregarte una máquina de estados, un context provider y una abstracción de hook personalizado que se extiende a través de tres archivos. La solución no es técnicamente incorrecta. Simplemente es pesada. Cada capa innecesaria añade deuda cognitiva. No te saltaste el trabajo; lo pospusiste, con intereses.
La trampa de la velocidad
Aquí hay un bucle de retroalimentación peligroso. La IA te permite construir funcionalidades el doble de rápido, pero la atención humana no escala de la misma manera. Si estás lanzando productos en la mitad de tiempo, ¿estás pasando el doble de tiempo en la revisión de código? ¿Estás escribiendo más pruebas, o menos?
En la práctica, es increíblemente fácil confiar en el código generado porque parece convincente. Utiliza sintaxis moderna. Los comentarios están esparcidos exactamente en los lugares correctos. Los nombres de las variables suenan profesionales. Los errores sutiles se esconden tras ese pulido. Un array de dependencias en un hook que omite un setter. Un tipo de TypeScript que es técnicamente correcto pero permite un estado nulo que olvidaste manejar. Una consulta de Supabase que olvida tener en cuenta las filas con borrado lógico en tu esquema específico. Lees por encima en lugar de leer cada línea, porque el ritmo de entrega lo exige. La velocidad se siente genial el lunes. La sesión de depuración del viernes dura hasta la medianoche.
El costo real
Las personas que pagan por esto no son los desarrolladores. Son los usuarios finales.
El software se siente más tosco porque la complejidad crece más rápido de lo que los equipos pueden gestionarla. Estamos construyendo aplicaciones más grandes con equipos más reducidos, armados con herramientas que nos hacen sentir invencibles. Cuando un desarrollador puede estructurar todo un panel de control en una tarde, la organización espera tres paneles para el miércoles. Escalar sin cuidado produce sistemas frágiles. El estado se infla. El tamaño de los bundles aumenta progresivamente. Las condiciones de carrera se multiplican. La interfaz puede parecer moderna, pero se reinicia cuando un usuario pulsa el botón de retroceso, o tarda cuatro segundos en hidratarse porque nadie tuvo tiempo de analizar la cascada de peticiones de datos generadas por IA.
Trabaja con la máquina, no para ella
Nada de esto significa que debas echar la IA de tu editor. Significa que necesitas límites.
Úsala para lo que es buena. Deja que escriba las cosas aburridas: interfaces de TypeScript repetitivas, consultas boilerplate de Supabase, la configuración de Jest.