Lo que los vibe coders hacen mal al desarrollar software (y cómo evitarlo)
El vibe coding - término acuñado por Andrej Karpathy para describir el desarrollo guiado por prompts iterativos donde el programador "se entrega a las vibras" y olvida que el código existe - prometía democratizar la creación de software. Y en cierto modo lo ha hecho: hoy cualquiera puede generar una aplicación funcional en horas. Pero cuando ese enfoque se traslada a producción sin disciplina, los resultados son desastrosos. Esto es lo que los vibe coders hacen mal, respaldado por datos y estudios recientes.
Confundir "funciona" con "está bien hecho"
El error más fundamental: creer que porque los tests pasan, el código es correcto. Un estudio sobre percepciones de calidad en vibe coding encontró que el 68% de los practicantes describió el código generado como "rápido pero defectuoso", aceptando los fallos como un costo inevitable de la velocidad. El informe de Komarovsky lo llama directamente una patología: "el patrón se vuelve patológico cuando los desarrolladores confunden adecuación empírica ('los tests pasan') con corrección, sustituyendo validación superficial por ingeniería con principios"
Ignorar la seguridad por completo
Este es el fallo más peligroso y el mejor documentado. Los benchmarks son demoledores: en tareas del mundo real, aunque el 57% de las soluciones generadas por agentes de IA eran funcionalmente correctas, solo el 11,8% eran seguras. Otro estudio encontró que solo el 55% del código generado por IA era seguro, y ese porcentaje se ha mantenido prácticamente plano aunque los modelos han mejorado en corrección sintáctica.
Las vulnerabilidades recurrentes incluyen:
Inyección de comandos y bypass de autenticación: un programador experimentado que probó vibe coding con Chat GPT encontró contraseñas enviadas en texto plano, falta de controles de entrada y código vulnerable a inyecciones que permitían ejecutar aplicaciones arbitrarias.
Exposición de datos sensibles: claves API en texto plano y credenciales accesibles.
Prompt injection indirecta: terceros pueden incrustar comandos maliciosos en el código que la IA interpreta como instrucciones legítimas. Un caso documentado mostró a un desarrollador frustrado con los vibe coders insertando un prompt de "data-nuking" en código open source.
Investigadores de Georgia Tech identificaron 74 casos confirmados de vulnerabilidades en código generado por vibe coding, de los cuales 14 eran críticos y 25 de alto riesgo.
Acumular deuda técnica a velocidad industrial
El vibe coding prioriza funcionalidad inmediata sobre arquitectura sólida. Esto acelera la deuda técnica y crea cargas de mantenimiento a largo plazo. Un análisis de la ACM lo describe sin rodeos: las plataformas de vibe coding "a menudo producen soluciones sobre-ingenieradas con código redundante y errores sutiles que crean pesadillas de mantenimiento".
El problema se agrava con cada iteración de prompt. Las reescrituras impredecibles del código hacen que la depuración local sea menos efectiva e introducen inestabilidad con efectos secundarios no anticipados. Un paper lo resume así: “El vibe coding es inherentemente frágil. Las ediciones prompt a prompt inevitablemente colisionan con las restricciones de diseño acumuladas, llevando a la decadencia por reconciliación de restricciones, deuda técnica y fallos de seguridad”.
No revisar, no entender, no documentar
La práctica misma del vibe coding —descrita como “entregarse por completo a las vibras, abrazar las exponenciales y olvidar que el código existe”— implica renunciar a la comprensión del sistema que se está construyendo. El código generado conversacionalmente a menudo carece de estructura cohesiva, patrones consistentes y documentación adecuada, lo que complica enormemente el mantenimiento futuro.
Peor aún: muchos vibe coders omiten por completo el control de calidad. Un estudio encontró que el 36% de las sesiones de vibe coding saltaron el QA por completo. Y cuando se hace revisión, a menudo es superficial, porque el desarrollador no tiene el conocimiento profundo para evaluar lo que la IA produjo.
Atrofiar las habilidades de ingeniería
Este es el daño colateral silencioso. La erosión de la experiencia en programación ocurre cuando los desarrolladores actúan más como articuladores de prompts que como implementadores: el pensamiento algorítmico, la depuración y la planificación arquitectónica se atrofian. El informe de Komarovsky describe el patrón del “Hollow Senior”: ingenieros que dominan la orquestación de IA pero pierden competencias fundamentales de depuración.
Desarrolladores entrevistados admiten que el uso intensivo de IA “les está haciendo olvidar habilidades críticas”. La consecuencia a largo plazo es un ecosistema donde nadie puede auditar, mantener o corregir el software que se está produciendo en masa.
Generar arquitecturas incoherentes
Cuando cada funcionalidad se genera mediante prompts independientes, la arquitectura del sistema se convierte en un mosaico de decisiones inconexas. Komarovsky documenta incoherencia arquitectónica y brechas de verificación que resisten la garantía de calidad tradicional. Los problemas específicos incluyen:
Inconsistencia de restricciones: una nueva funcionalidad contradice silenciosamente el comportamiento existente.
Bugs de propagación parcial: un cambio se aplica en un módulo pero no en otros, causando errores o corrupción de datos.
Con el 25% de las startups de Y Combinator en 2025 teniendo bases de código 95% generadas por IA, estos problemas ya no son teóricos: están en producción
La alternativa: disciplina sobre vibra
El problema no es la IA, sino cómo se usa. Los mismos estudios que documentan los desastres también señalan el camino:
Calibrar la supervisión según el contexto. El NCSC británico propone un “espectro del vibe coding” donde el nivel de oversight varía según la criticidad del código. No es lo mismo un prototipo desechable que un sistema de autenticación.
Hacer revisión de código rigurosa. La validación humana no es opcional. El paso crítico es donde la experiencia humana verifica no solo si el código funciona, sino si es mantenible, eficiente y seguro.
Usar prompts orientados a la seguridad. Los prompts que incorporan consideraciones de seguridad reducen tanto la prevalencia como la severidad de las vulnerabilidades, aunque los riesgos residuales persisten.
Preservar el conocimiento. Implementar “Sprints de Arqueología” para ingeniería inversa de sistemas generados por IA no documentados, y mantener prácticas de mentoría y revisión por pares que transmitan conocimiento tácito.
Definir “terminado” con rigor. Los criterios de aceptación deben incluir no solo funcionalidad, sino seguridad, mantenibilidad y rendimiento. Los tests generados por IA requieren revisión humana para evitar que validen comportamiento incorrecto.
Conclusión
El vibe coding no es intrínsecamente malo. Como herramienta de prototipado rápido, es transformador. El problema surge cuando se trata como un sustituto de la ingeniería en lugar de un acelerador de ella. Los datos son claros: la velocidad sin disciplina produce software frágil, inseguro y difícil de mantener. La pregunta no es si la IA puede escribir código —puede—, sino si los humanos que la dirigen están dispuestos a seguir haciendo el trabajo que hace que el software sea digno de confianza: entender, revisar, probar y asumir responsabilidad.
La vibra está bien para empezar. Pero para terminar, hace falta ingeniería.