El fin del vibe coding: cómo estructurar un proceso de desarrollo asistido por LLM sin matar el proyecto

Más del 70% de los desarrolladores, según diversas encuestas, ya utilizan regularmente herramientas de IA para escribir código, pero las metodologías para trabajar con ellas todavía se están formando de manera espontánea. Un desarrollador que lleva más de un año usando LLM en su trabajo diario describió el doloroso camino desde el ingenuo "vibe coding" hasta un sistema de ingeniería basado en tres principios que permite usar asistentes de IA sin perder la calidad de la base de código.

Qué es el vibe coding y por qué falla

El término "vibe coding" surgió entre los desarrolladores como una descripción irónica de un proceso en el que el programador simplemente le da tareas al modelo de lenguaje y acepta casi todo lo que este genera, casi sin revisión. Al principio todo parece magnífico: el modelo genera funciones rápidamente, escribe pruebas, propone decisiones arquitectónicas, el código se ve visualmente limpio, las variables tienen nombres cuidados y los comentarios están en su lugar. Pero a medida que el proyecto crece, se acumula una deuda técnica invisible.

El modelo no recuerda que ya escribió una utilidad similar tres chats atrás, no conoce el patrón de manejo de errores adoptado en el proyecto e inserta stubs donde se necesita lógica real, y lo hace con tanta seguridad que esos stubs se confunden fácilmente con código funcional. Como resultado, la depuración se vuelve más costosa, la refactorización más dolorosa y la confianza en el código generado disminuye. La mayoría de los enfoques actuales para trabajar con LLM se reducen a dos extremos: la confianza total en el modelo o el rechazo total tras el primer error grave.

Los tres principios de la metodología

El primer principio es separar el contexto por chats. En lugar de un único diálogo interminable en el que el modelo va perdiendo el hilo poco a poco, el autor crea sesiones separadas para tareas concretas: decisiones arquitectónicas, redacción de la lógica de negocio, pruebas, refactorización. Cada chat recibe su propio prompt de sistema con la descripción del stack, las convenciones clave y el estado actual del módulo; esto no elimina por completo el problema de la ventana de contexto limitada, pero reduce el riesgo de que el modelo "olvide" detalles críticos.

El segundo principio son los artefactos obligatorios en cada paso: no solo código, sino una salida estructurada que describa las decisiones tomadas, la lista de dependencias, la lista de supuestos y una indicación explícita de los lugares donde se usaron stubs o simplificaciones. Esto convierte el trabajo con el LLM de una caja negra en un proceso transparente, donde cada decisión queda documentada y puede cuestionarse durante la revisión de código.

El tercer elemento son las listas de verificación. Después de cada generación, el autor revisa el resultado: si hay duplicación con código existente, si el estilo respeta las convenciones adoptadas, si todos los stubs están marcados como TODO, si los casos límite se manejan correctamente. Parte de estas comprobaciones está automatizada con linters y análisis estático, y otra parte requiere revisión manual, pero la verificación no es opcional: es una parte obligatoria del pipeline sin la cual el código no llega a la rama principal.

El precio de la disciplina y el papel del desarrollador

El enfoque descrito aumenta los costos generales: separar el contexto, redactar los prompts y verificar requieren tiempo que podría dedicarse directamente a escribir código. El autor argumenta que estas inversiones se recuperan muchas veces con el tiempo: un proyecto que no acumula deuda técnica oculta acaba avanzando más rápido que uno en el que cada sprint empieza limpiando las consecuencias de una generación irreflexiva.

Para la industria, el enfoque es notable porque formaliza el papel del desarrollador al trabajar con asistentes de IA: el programador deja de ser un operador que pulsa un botón y acepta el resultado, y se convierte en el arquitecto del proceso, quien define los límites, controla la calidad y toma las decisiones finales. Esto coincide con una postura cada vez más repetida en las grandes empresas: la IA no sustituye al ingeniero, lo potencia, pero solo si existe disciplina. La era del vibe coding ingenuo, al parecer, está llegando a su fin: los desarrolladores están pasando a construir procesos maduros alrededor de los modelos de lenguaje, y quienes conviertan la generación caótica en una cadena de ingeniería controlada obtendrán una ventaja competitiva real: no solo velocidad, sino velocidad sin pérdida de calidad.

¿Qué es el vibe coding?

El vibe coding es un término irónico para la práctica en la que el programador simplemente le da tareas al modelo de lenguaje y acepta casi todo lo que este genera, sin una revisión seria. Al principio el código parece limpio y ordenado, pero a medida que el proyecto crece se acumula deuda técnica oculta: lógica duplicada, contexto que el modelo ha olvidado y stubs que se confunden fácilmente con código funcional.

¿Qué tres principios propone el autor de la metodología?

La metodología se basa en tres principios: separar el contexto en chats independientes para tareas concretas (arquitectura, lógica de negocio, pruebas, refactorización), cada uno con su propio prompt de sistema; artefactos estructurados obligatorios en cada paso, con la descripción de decisiones, dependencias, supuestos y stubs explícitos; y listas de verificación después de cada generación que comprueban duplicación, estilo, marcas TODO y casos límite, parte de las cuales están automatizadas con linters.

¿Cuántos desarrolladores ya usan herramientas de IA en su trabajo?

Según diversas encuestas, más del 70% de los desarrolladores usa regularmente herramientas de IA para escribir código. Al mismo tiempo, como señala el autor, un enfoque de ingeniería intermedio entre la confianza total en el modelo y el rechazo total tras el primer error grave sigue siendo poco frecuente.