El fin del vibe coding: cómo montar un proceso de desarrollo con LLM que no hunda el proyecto

Según distintas encuestas, más del 70% de los desarrolladores ya utiliza herramientas de AI de forma habitual para escribir código, pero las metodologías para trabajar con ellas siguen surgiendo de manera improvisada. Un desarrollador que lleva más de un año usando LLM en su trabajo diario ha relatado el doloroso camino que recorrió desde un «vibe coding» ingenuo hasta un sistema de ingeniería basado en tres principios. Ese sistema le permite usar asistentes de AI sin degradar la calidad del código base.

Qué es el vibe coding y por qué falla

El término «vibe coding» se popularizó entre los desarrolladores como una forma irónica de describir un proceso en el que el programador se limita a pasarle tareas a un modelo de lenguaje y acepta casi sin revisión todo lo que genera. Al principio todo parece estupendo: el modelo genera funciones rápidamente, escribe tests y propone soluciones de arquitectura; el código es visualmente limpio, las variables tienen nombres cuidados y los comentarios están en su sitio. 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, desconoce el patrón de gestión de errores adoptado en el proyecto e inserta stubs donde hace falta lógica real. Además, lo hace con tanta seguridad que es fácil confundir esos stubs con código funcional. Como resultado, la depuración se encarece, la refactorización se vuelve más dolorosa y la confianza en el código generado cae.

Hoy la mayoría de los enfoques para trabajar con LLM se reducen a dos extremos: o confianza total en el modelo, o renuncia total a él tras el primer bug 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, el autor dedica sesiones independientes a tareas concretas: decisiones de arquitectura, escritura de la lógica de negocio, testing y 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, las suposiciones asumidas y una indicación explícita de los puntos donde se han usado stubs o simplificaciones. Así, el trabajo con LLM deja de ser una caja negra y se convierte en un proceso transparente, en el que cada decisión queda documentada y puede cuestionarse durante la code review.

El tercer elemento son las checklists de verificación. Tras cada generación, el autor revisa el resultado: si hay duplicidades con el código existente, si el estilo cumple las convenciones adoptadas, si todos los stubs están marcados como TODO y si los casos límite se gestionan correctamente. Parte de estas comprobaciones está automatizada con linters y análisis estático, y otra parte requiere revisión manual. En cualquier caso, la verificación no es opcional: es una parte obligatoria del pipeline, y sin ella el código no llega a la rama principal.

El precio de la disciplina y el papel del desarrollador

El enfoque descrito aumenta la carga de trabajo adicional: separar el contexto, redactar prompts y verificar resultados exige un tiempo que podría dedicarse a escribir código directamente. El autor sostiene que esta inversión se amortiza con creces a largo plazo: un proyecto que no acumula deuda técnica oculta acaba avanzando más rápido que otro en el que cada sprint empieza limpiando las consecuencias de una generación sin criterio.

Para la industria, lo interesante del enfoque es que formaliza el papel del desarrollador cuando trabaja con asistentes de AI. El programador deja de ser un operador que pulsa un botón y acepta el resultado, y pasa a ser el arquitecto del proceso: quien fija el marco, controla la calidad y toma las decisiones finales. Esto coincide con una postura que cada vez se oye más en las grandes empresas: la AI no sustituye al ingeniero, sino que lo potencia, pero solo si hay disciplina.

Todo indica que la era del vibe coding ingenuo toca a su fin. Los desarrolladores están pasando a construir procesos maduros en torno a 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: velocidad sin pérdida de calidad, y no simplemente velocidad.

¿Qué es el vibe coding?

El vibe coding es un término irónico para la práctica en la que el programador se limita a pasarle tareas a un modelo de lenguaje y acepta casi todo lo que genera sin una revisión seria. Al principio el código parece limpio y cuidado, pero a medida que el proyecto crece se acumula una deuda técnica oculta: lógica duplicada, contexto que el modelo olvida y stubs fáciles de confundir con código funcional.

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

La metodología se basa en tres principios. El primero es separar el contexto en chats independientes para tareas concretas (arquitectura, lógica de negocio, testing, refactorización), cada uno con su propio prompt de sistema. El segundo son los artefactos estructurados obligatorios en cada paso: descripción de las decisiones, dependencias, suposiciones y stubs explícitos. El tercero son las checklists de verificación tras cada generación, que comprueban duplicidades, estilo, marcas TODO y casos límite; parte de ellas está automatizada con linters.

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

Según distintas encuestas, más del 70% de los desarrolladores utiliza de forma habitual herramientas de AI para escribir código. Aun así, como señala el autor, un enfoque de ingeniería intermedio entre la confianza total en el modelo y la renuncia total a él tras el primer bug grave sigue siendo poco común.