En julio de 2025, Jason Lemkin, fundador de SaaStr, una de las comunidades B2B SaaS más conocidas del sector, dejó que el agente de vibe coding de Replit construyera una aplicación de producción. Durante un code freeze explícito, el agente ignoró la instrucción, generó datos ficticios para disimular errores, afirmó que unos tests pasaban cuando no era cierto y acabó borrando la base de datos de producción completa. Meses de registros ejecutivos, desaparecidos de la noche a la mañana.

Esto es lo que pasa cuando el vibe coding sale de donde nació (un fin de semana, un prototipo, aprender rápido…) y entra en producción sin que nadie active el filtro profesional. 

Y no es un caso aislado, es un patrón que se repite con la suficiente frecuencia como para tener nombre propio en varios informes de seguridad de este año.

¿Qué es el vibe coding y en qué se diferencia de programar con IA?

Vibe coding es el término que acuñó Andrej Karpathy en febrero de 2025 para describir un estilo de programar dejándose llevar por lo que sugiere la IA, sin revisar ni entender del todo el código que genera. No es lo mismo que programar con IA de forma profesional: la diferencia no está en la herramienta que usas, está en si alguien audita lo que sale antes de que llegue a un usuario final.

Eso no convierte al vibe coding en un error. Es un modo de trabajo con un objetivo distinto: prototipar rápido, aprender cómo se conecta una API por primera vez, validar una idea antes de invertir en ella. Revisar cada línea ahí sería perder el sentido del ejercicio. El problema empieza cuando ese mismo modo de trabajo se usa para construir algo que sí va a tener usuarios.

El término pasó de no existir a generar decenas de miles de búsquedas mensuales en español en menos de un año, lo cual tiene sentido, porque describe algo que mucha gente ya estaba haciendo antes de tener nombre para ello. Sin embargo, se ha popularizado más rápido de lo que ha madurado la conversación sobre sus límites.

Cuando el vibe coding llega a producción. El caso Replit-SaaStr

Lemkin se lo contó después a ZDNet con una frase que resume el problema mejor que cualquier informe de seguridad: «No puedes sobrescribir una base de datos de producción. Nunca, jamás, ni una vez».

El fallo de fondo no era solo el borrado en sí. Replit, en aquel momento, no separaba el entorno de pruebas del de producción, así que cualquier decisión que tomara el agente por su cuenta afectaba directamente a los datos, sin ninguna capa intermedia que lo frenara.

Lo llamativo del caso no es que un agente cometiera un error, lo cual puede pasar con cualquier sistema, sino que ignoró una instrucción explícita (el code freeze) y que lo hizo mintiendo activamente sobre el estado del trabajo. 

Y esto es la ausencia total de un mecanismo que verificara lo que decía frente a lo que realmente hacía.

No es un caso aislado de errores de vibe coding

Una vulnerabilidad de autorización (BOLA) dejó expuestas las bases de datos de más de 170 aplicaciones construidas con Lovable durante 48 días, catalogada oficialmente como CVE-2025-48757. Un escaneo de Escape.tech sobre 5.600 aplicaciones vibe-coded públicas encontró más de 2.000 vulnerabilidades de alto impacto y más de 400 secretos expuestos en sistemas ya en producción.

Y esto no está mejorando al ritmo que cabría esperar. 

Según el GenAI Code Security Report 2026 de Veracode, que lleva dos años midiendo esto en más de 100 modelos, el 44% de las tareas de generación de código todavía introduce una vulnerabilidad de seguridad conocida. La tasa de aprobación en seguridad apenas se ha movido del 55% al 56% en un año, mientras la cantidad de código generado por IA que llega a producción se ha disparado.

Ningún modelo nuevo ha resuelto esto todavía y probablemente ninguno lo haga solo con mejor entrenamiento. Un modelo más capaz genera código con menos errores de sintaxis, no código que decida por sí solo qué merece revisión humana y qué no. Esa decisión sigue siendo un problema de proceso, no de modelo.

Dónde sí funciona el vibe coding

Nada de esto significa que el vibe coding sea inútil ni que haya que evitarlo siempre. Para un prototipo de fin de semana, una prueba de concepto que nadie más va a usar, un script interno de un solo uso o para aprender jugando con una API nueva, dejarte llevar por lo que sugiere la IA es exactamente lo que toca hacer. 

Pero es importante saber en qué momento hay que dejar atrás la parte técnica y muchos equipos no se dan cuenta de que ya cruzaron esa línea hasta que algo se rompe en producción.

Recomendación: si el código que generas va a tocar datos de un usuario, dinero o una decisión que no se puede deshacer con un clic, ya no es vibe coding, es desarrollo de producción, tenga la IA el papel que tenga en escribirlo.

La línea que separa un prototipo de un sistema en producción

Esa línea tiene nombre y ya la describimos con detalle en nuestro artículo sobre Spec-Driven Development. La diferencia entre vibe coding y desarrollo profesional con IA no es cuánto código escribe la IA, puesto que en ambos casos puede ser casi todo… sino si existe una especificación que defina qué tiene que cumplir ese código antes de generarlo y alguien revisando después si la cumple.

El mismo patrón se repite en cómo se construye el sistema alrededor del agente: Context Engineering para que sepa cómo está montada tu arquitectura en vez de improvisar y Harness Engineering para que las acciones destructivas, como borrar una base de datos, tengan que pasar por un sandbox antes de llegar a producción. El agente de Replit no tenía nada de esto, por eso pudo hacer lo que hizo.

Ninguna de las dos disciplinas exige renunciar a la velocidad que hace atractivo al vibe coding en primer lugar. Un agente con una spec clara, contexto real del proyecto y un sandbox de por medio sigue siendo rápido, la diferencia es que lo que produce se puede confiar antes de que llegue a un usuario, no después de que algo se rompa.

Cuando un equipo entero adopta esta disciplina, deja de depender de que cada developer se acuerde de revisar por su cuenta, es la misma transición de la que hablamos en nuestro artículo sobre el AI Champion. Y el problema de fondo, si te fijas, no es tan distinto del que ya vimos con las herramientas de IA que no te hacen productivo: no falla la tecnología. Falla la ausencia de método.

En el Máster AI4Devs no enseñamos a hacer vibe coding más rápido. Enseñamos a construir el sistema que hace que ese mismo código llegue a producción sin sorpresas.

Agenda tu entrevista de admisión al Máster AI4Devs →