El vibe coding rompió su promesa

Pasa una hora en cualquier foro de constructores y encontrarás la misma confesión escrita de cien maneras distintas. Alguien construyó su aplicación en un fin de semana con una herramienta de IA. Funcionaba. La lanzó. Ahora es lunes, la autenticación está rota, la base de datos pierde filas en silencio y el error que nadie puede reproducir es el que le está costando clientes.

El sueño que nos vendimos unos a otros hace seis meses se está presentando en la puerta a pedir su dinero de vuelta.

Quiero ser cuidadoso con cómo digo esto, porque no creo que quienes construyeron o usaron estas herramientas se equivocaran al entusiasmarse. El salto fue real. Ver materializarse una interfaz funcional a partir de un párrafo en lenguaje llano es una de las experiencias genuinamente mágicas de la última década del software. Yo también lo sentí. Todos lo sentimos.

Pero en algún punto entre la demo y el despliegue ocurrió una sustitución silenciosa. Empezamos a llamar productos a los prototipos. Empezamos a llamar software a las demos. Y la factura de esa confusión está venciendo ahora.

El diagnóstico equivocado

La explicación más común que veo sobre por qué está pasando esto culpa al modelo. La IA todavía no es lo bastante lista. Alucina. Elige las librerías equivocadas. Escribe código que alguien sénior detectaría y reescribiría.

Esa explicación es reconfortante porque sugiere un arreglo que ya está en camino. Espera seis meses. El siguiente modelo será mejor. Al final la brecha se cierra y todo funciona.

No me lo creo. Y no me lo creo porque el modo de fallo que veo una y otra vez no tiene nada que ver con lo bueno que sea el código.

Microsoft informó en su llamada de resultados de 2025 que alrededor del 46% de todo el código que envían los usuarios activos de GitHub Copilot es ahora generado por IA. Por las mismas fechas, la firma de seguridad de aplicaciones Veracode publicó una investigación que encontró que el código generado por IA introducía vulnerabilidades de seguridad en cerca del 45% de las muestras que probó. Esos números empeorarán antes de mejorar, y un modelo más listo no los va a arreglar.

El modelo no es el problema. El proceso lo es.

Qué falta realmente

Repasa conmigo cómo se construye una aplicación hecha con vibe coding y dime dónde ocurre la decisión arquitectónica.

Describes lo que quieres. La IA genera una interfaz y algo de código detrás. Miras la interfaz, haces clic por ahí, hace aproximadamente lo que pediste, y lo das por terminado. En ningún momento de ese ciclo nadie, ni humano ni máquina, se detuvo a definir qué se estaba construyendo.

No hay esquema. No hay modelo de datos. No hay una lista de estados en los que el sistema puede estar ni una definición de qué cuenta como válido. No hay contrato entre el frontend y lo que sea que esté haciendo de backend. No hay ninguna decisión sobre qué pasa cuando el usuario hace algo que el generador no anticipó, porque nadie lo anticipó.

Lo que se construyó es una cosa que parece la cosa que pediste, en el camino concreto que recorriste durante la demo. Sal de ese camino y toda la estructura se revela como andamio. Nunca hubo un edificio debajo.

Esto no es un fallo de inteligencia. Es un fallo de definición. Y ninguna cantidad de inteligencia adicional aplicada a un problema sin definir producirá un resultado definido. Solo producirá una versión más convincente del mismo andamio.

Las tres decisiones que nunca se tomaron

Voy a ser concreto, porque las abstracciones son la razón por la que esta conversación sigue dando vueltas.

La autenticación no es una función que añadas más tarde. Es una decisión sobre quiénes son tus usuarios, qué pueden ver y sobre qué frontera de confianza se asienta tu aplicación. Atornillarla a una aplicación hecha con vibe coding dos semanas después del lanzamiento es el equivalente en software a instalar una puerta principal en una casa construida sin paredes.

El esquema de una base de datos no es algo que una IA deba estar adivinando mientras genera el formulario que escribe en él. El esquema es la columna vertebral de la aplicación. Cada decisión posterior (qué puedes consultar, qué puedes indexar, qué puedes cambiar después sin romper todo) está limitada por elecciones que se tomaron, o no se tomaron, al principio. Cuando el esquema se improvisa, cada cambio futuro es una reforma.

Un contrato de API no es opcional, y en una economía donde los agentes de IA consumen software directamente, está más cerca de ser el producto que la interfaz. En el momento en que tu aplicación habla con cualquier otra cosa (un procesador de pagos, un servicio de correo, otro software, un agente de IA) tiene que haber una superficie definida. Sin una, las integraciones se convierten en una serie de apaños puntuales que nadie puede mantener y nadie quiere heredar.

Estos no son temas avanzados. Son lo mínimo para construir software que vive más allá de su primer fin de semana. Y son exactamente las cosas que se saltan cuando todo el proceso de construcción es descríbelo, velo, lánzalo.

El problema del 70% ya tiene nombre

No creo que nadie se propusiera construir una industria que lanza software frágil. Creo que las herramientas que surgieron en esta categoría optimizaron para el momento que vende la herramienta: el momento de magia, cuando una idea se convierte en una pantalla funcional en menos de un minuto.

El tiempo hasta la magia se convirtió en lo medible. El tiempo hasta producción era problema de alguien más.

Esa es una optimización razonable para una demo. Es una optimización terrible para una categoría de software que ahora es responsable de entregar aplicaciones reales a usuarios reales con dinero real en juego. Deja a toda una generación de constructores encallada en el 90%, con una cosa que funciona en su pantalla y se desmorona en todas las demás.

Los constructores de la comunidad de Lovable le pusieron nombre: el problema del 70%. Llegas a algo que se siente casi terminado, y entonces el progreso se detiene. Cada arreglo rompe otra cosa. El trabajo restante no es trabajo que puedas resolver con prompts, porque lo que te bloquea no es código que falta. Es una decisión que falta, tomada en silencio, varios cientos de generaciones atrás.

El secreto sucio de esta categoría es que la parte fácil era el primer 90%. El 9% siguiente (hacer que funcione de verdad para más de un usuario, en más de un dispositivo, bajo condiciones que no anticipaste) es más difícil que el primer 90% junto. Y el último 1%, la parte que distingue una aplicación que funciona de una frágil, es la parte que exige haber sabido qué estabas construyendo antes de empezar.

La regla que la IA no cambió

Aquí está lo que nadie quiere oír, porque suena como un paso atrás en un momento que se supone que es todo movimiento hacia adelante.

El mejor software siempre ha empezado con una definición. Arquitectura antes que código. Un modelo claro del problema antes de que se escriba una línea. Esto era cierto cuando equipos de cincuenta personas construían sistemas a mano, y es cierto ahora que una persona y un modelo pueden construir el mismo sistema en un fin de semana.

La IA no cambió esa regla. La IA la hizo más importante, no menos.

Cuando el coste de producir código se acerca a cero, el coste de producir el código equivocado también se acerca a cero. Lo que significa que lo único que sigue teniendo coste es averiguar cuál habría sido el código correcto. Ese trabajo (el trabajo de definición, el trabajo de arquitectura, la parte en la que decides qué estás construyendo realmente antes de empezar a construirlo) es la única parte que no se ha convertido en materia prima.

Y es también la parte que la generación actual de herramientas se saltó.

Hacia dónde va esto de verdad

No creo que la respuesta sea ir más despacio. No creo que la respuesta sea volver a escribir todo a mano. El salto fue real, y el salto se queda.

La respuesta es incorporar el paso de definición al ciclo, la práctica que la industria llama ahora desarrollo guiado por especificación. No como una puerta manual que te frena, sino como el cimiento real sobre el que se asienta el resto del trabajo. Quienes están averiguando cómo hacerlo trabajan en algo más silencioso que lo que has estado viendo. Están a punto de hacer que la versión ruidosa de esta categoría parezca lo que siempre fue. He escrito por separado sobre cómo es realmente esa siguiente generación.

Una pantalla que funciona nunca fue lo mismo que un sistema que funciona. Todos estamos a punto de recordar por qué.

Lecturas relacionadas

Lo que lo reemplazó: el desarrollo guiado por especificación. Cómo se comparan las herramientas ahora: los mejores constructores de aplicaciones con IA en 2026.

Preguntas frecuentes

¿Qué significa “vibe coding”? El vibe coding es escribir software describiendo lo que quieres en lenguaje llano y aceptando lo que la IA genera, sin especificar la arquitectura, el modelo de datos ni los contratos que van debajo. Andrej Karpathy acuñó el término a principios de 2025. Describe un flujo de trabajo, no una categoría de herramienta: puedes hacer vibe coding en casi cualquier constructor con IA.

¿Por qué se rompen en producción las aplicaciones hechas con vibe coding? Porque el fallo es estructural, no un problema de calidad del código. El ciclo de generación nunca produce un esquema, ni un conjunto definido de estados válidos, ni un contrato entre frontend y backend. La aplicación funciona en el camino sobre el que se hizo la demo y se desmorona fuera de él. Un modelo más listo aplicado a un problema sin definir sigue produciendo un resultado sin definir.

¿Qué es el problema del 70%? Es el patrón en el que una aplicación construida con IA llega a estar completa en un 70% aproximadamente y entonces deja de avanzar: cada arreglo rompe otra cosa y ninguna cantidad de prompts adicionales cierra la brecha. Lo que bloquea suele ser una decisión arquitectónica que se tomó de forma implícita, cientos de generaciones antes, y que ya no se puede cambiar sin una reescritura.

¿El código generado por IA es menos seguro? La evidencia actual dice que necesita revisión. La investigación de Veracode encontró que el código generado por IA introducía vulnerabilidades de seguridad en cerca del 45% de las muestras probadas, en un momento en el que Microsoft informaba de que alrededor del 46% del código enviado por usuarios activos de GitHub Copilot era generado por IA. El volumen crece más rápido que la verificación.

¿Esto significa que no deberían usarse los constructores de aplicaciones con IA? No. Para prototipos, demos y herramientas internas son genuinamente excelentes y la velocidad es real. El argumento aquí es más estrecho: una pantalla que funciona no es un sistema que funciona, y las herramientas que se saltan la fase de definición no pueden producir lo segundo por bueno que se ponga el modelo.