Vibe coding: la promesa, el colapso y la lectura correcta
Qué ha fallado, qué está cambiando y por qué importa aunque no quieras construir software
Antes de empezar
Este artículo no va de aprender vibe coding ni de hacer apps. Te puede interesar si usas la IA para tomar decisiones, crear productos o escalar servicios.
Desde la experiencia de trabajar con sistemas de IA y de construir, en Amplify, un SaaS como Ipolaris, aquí analizamos:
por qué muchas promesas recientes colapsaron al tocar la realidad
qué ha cambiado de verdad con los modelos nuevos (y qué no)
cómo reconocer productos que solo funcionan como arbitraje temporal
y qué implica todo esto incluso si no quieres construir software
Está escrito para ganar criterio, no entusiasmo.
Detrás del hype del vibe coding
La IA es un poco como esos trenes de mercancías que pasan por la estación a toda velocidad, sin detenerse. Se espera que te subas a ellos. Pero a veces no puedes. Y a veces, dejarlo pasar resulta ser una buena decisión.
El vibe coding fue uno de esos trenes.
Hace tres meses parecía la panacea. Yo mismo me lo creí. La idea era seductora: cualquiera podía crear software simplemente hablando con una IA. Sin saber programar. Sin escribir código. Sin entender sistemas. Solo describiendo lo que quería construir.
Luego vino la realidad.
Bugs infinitos
Productos que nunca se terminaban
Apps poco funcionales
Calidad insuficiente para vender
Imposibilidad de escalar sin tocar código de verdad
El suflé se desinfló.
La promesa era demasiado grande para personas como tú y como yo: emprendedores, freelancers, perfiles no técnicos. La gente lo fue asumiendo, con esa mezcla de decepción y alivio que aparece cuando te das cuenta de que no has llegado tarde a nada importante. Los programadores, por su parte, respiraron aliviados.
Eso no significa que el vibe coding fuera una tontería. El principio sigue siendo válido. Con agentes cada vez más sofisticados, desarrollar software se está volviendo un acto conversacional. El hype murió, pero la idea no.
Y por eso volvemos a oír hablar de ello ahora.
Concretamente, a raíz del lanzamiento de Opus 4.5, el nuevo modelo de Claude, del que algunos dicen que por fin hace el vibe coding verdaderamente viable.
Este artículo nace de ahí. No para reavivar el hype, sino para hacer algo mucho más útil: pararnos un momento, mirar atrás y entender en qué punto estamos realmente. Qué falló, qué ha cambiado y, sobre todo, qué implica esto para quienes usamos la IA para crear negocios, no para programar por placer.
Lo digo desde ya: no voy a vender una nueva revolución. Lo que sí quiero darte es una lectura más limpia. Una que no se venga abajo en cuanto la realidad haga lo que suele hacer: ponerse pesada.
Un momento de recapitulación
Para situarnos rápido: el vibe coding es programar describiendo comportamientos.
Antes, programar significaba escribir código, dominar sintaxis y entender sistemas complejos. Ahora, describes con palabras lo que quieres que haga una aplicación y la IA se encarga de escribir o modificar el código necesario.
El código sigue ahí. No desaparece. La diferencia es que ya no necesitas tocarlo directamente.
Ese desplazamiento fue lo que encendió la imaginación de muchos. Y lo que, durante un tiempo, hizo pensar que el software se había democratizado de verdad.
No fue así. Al menos, no todavía.
Y esto es importante decirlo bien, porque aquí se suele caer en una falsa dicotomía: o “es humo” o “lo cambia todo”. La vida real rara vez funciona así. Lo más frecuente es que algo sea prometedor y frustrante a la vez. Que sea real, pero inmaduro. Que funcione, pero no cuando tú quieres.
El vibe coding, por ahora, vive en ese territorio.
Qué prometía realmente el vibe coding (y por qué era razonable creérselo)
Cuando alguien te enseña un vídeo de veinte segundos donde una persona escribe “hazme una app para organizar mis comidas y que me haga la lista de compra” y la app aparece, tu cerebro hace lo que hace siempre: proyecta.
No proyecta “una demo”. Proyecta “un mundo”. Un mundo donde puedes prototipar productos sin fricción. Donde puedes probar diez ideas en una tarde. Donde puedes iterar con una rapidez absurda. Donde el software deja de ser una barrera y se convierte en un material blando, moldeable.
Esa proyección era razonable, porque se apoyaba en algo real: los modelos ya saben escribir código. Y además lo escriben con una naturalidad que, si no has programado nunca, te parece casi una forma de magia.
El salto conceptual del vibe coding era:
Si el modelo escribe código, ¿por qué necesito yo aprenderlo? ¿Por qué no puedo tratar al software como trato a un diseñador o a un copywriter? Le explico lo que quiero, él lo hace, yo reviso, iteramos.
La promesa, en resumen, era esta: convertir el desarrollo en conversación.
Y no era una locura. Era una extrapolación optimista. El problema fue confundir dos cosas muy distintas: que el modelo sea capaz de producir código, y que sea capaz de producir software fiable.
Qué ocurrió en la práctica
La experiencia real de mucha gente no técnica que probó vibe coding (yo incluido) fue parecida. Empiezas eufórico. En una hora tienes algo que “parece” una app. En dos horas, algo que “casi” funciona. Y a partir de ahí el proyecto entra en una zona rara, como de barro.
Pides un cambio, y se rompe otra cosa.
Arreglas eso, y el arreglo introduce un bug nuevo.
Le dices “no cambies esto”, y lo cambia igualmente.
Le pides que “mantenga el estilo”, y te cambia medio proyecto.
Empiezas a tener miedo de tocar nada, porque cada intervención abre una nueva caja de sorpresas.
Esto no es una crítica moral a la IA. Pero es un patrón: el modelo no ejecuta un plan como lo ejecutaría un ingeniero. Genera texto que parece ingeniería. A veces coincide con la realidad. A veces no.
Y aquí aparece un matiz que me parece central, porque explica la resaca del hype.
La conversación puede ser fluida y aun así el sistema puede ser frágil. Es decir: puede “sonar” competente mientras te está construyendo algo que, bajo estrés, se deshace.
Esto es muy humano, por cierto. Todos hemos trabajado con gente que habla bien y entrega mal. La diferencia es que, con la IA, la elocuencia es constante. Y eso te engaña.
El vibe coding, por ahora, es una fábrica de esa ilusión: una interfaz amable sobre un proceso todavía inestable.
Por qué vuelve a hablarse de vibe coding ahora
Hace un par de semanas asistí a un workshop de programación con Claude organizado por un equipo estadounidense que ha lanzado varios productos de software con IA. El foco del workshop era compartir sus últimos experimentos con Opus 4.5.
El CEO fue tajante: esto sí es un cambio de paradigma.
Según él, Opus 4.5 permite crear aplicaciones completas y funcionales únicamente a base de prompts. Contó que había desarrollado una app entre reuniones y que la prueba de su viabilidad era simple: estaba publicada en la App Store.
Tres meses atrás, una app creada así habría fracasado casi seguro. Demasiados errores. Demasiadas correcciones. Demasiada fricción.
Con Opus 4.5, decía, no tuvo que entrar en diálogos infinitos ni corregir bugs uno a uno. Planificó bien, lanzó prompts claros y la aplicación funcionó. Para añadir funcionalidades, no tocó “features”: editó prompts.
Ahí está el atractivo. Y también la trampa.
El atractivo es evidente: menos barro. Menos tiempo perdido en microcorrecciones. Más continuidad. La trampa es que una demo personal —aunque esté en la App Store— no es una garantía. No de robustez, no de seguridad, no de mantenibilidad, no de soporte.
Lo que sí es —y esto me parece lo importante— es una señal de que el fenómeno se está moviendo. De que hay avances reales en estabilidad. Y de que tiene sentido volver a mirar el tema, pero con menos romanticismo.
El error de fondo: pensar el software con mentalidad SaaS
Aquí es donde conviene ampliar el foco.
Durante la última década, casi todo el software se construyó bajo el mismo marco mental: el del SaaS clásico. Productos cerrados, funcionalidades definidas, roadmaps claros, ciclos de desarrollo largos y equipos humanos manteniendo el sistema.
Muchas startups de IA han intentado hacer exactamente eso, pero “añadiendo modelos”.
El problema es que los modelos generalistas mejoran demasiado rápido.
En el mundo de la IA hay una idea famosa, la bitter lesson, formulada por Richard Sutton:
Cuando compiten sistemas especializados diseñados con inteligencia humana contra sistemas más simples que escalan con más datos y más computación, ganan siempre los segundos. A la larga, la escala se come la artesanía.
No hace falta estar de acuerdo con la versión más agresiva de esa idea para ver lo que está pasando. Herramientas que parecían diferenciarse por flujos de trabajo o prompts ingeniosos acaban siendo absorbidas por los propios modelos base. Lo que antes era un producto, pasa a ser un “feature” dentro del modelo generalista.
En otras palabras: si tu producto es “un poco mejor que el modelo”, estás en terreno peligroso.
Y si eres emprendedor, no técnico, esto importa por una razón muy simple: te protege de invertir tiempo y dinero en modas frágiles. Te recuerda que no todo lo que funciona hoy va a existir mañana, y que hay un tipo de “innovación” que en realidad es arbitraje temporal.
(Un ejemplo muy sencillo de a qué me refiero con arbitraje temporal: si tu producto es “una IA que redacta mejor X”, y el modelo base (ChatGPT; Claude, Gemini) en 6–12 meses redacta X igual de bien (y encima integrado en herramientas que ya usa todo el mundo), tu negocio no era una empresa duradera: era una oportunidad de tiempo.)
Hasta aquí, el hype.
Si has llegado hasta aquí, ya sabes qué falló. Lo importante ahora es entender qué sí tiene recorrido.
En la siguiente parte del ensayo entramos en la lectura estratégica: datos, experiencia real construyendo Ipolaris y criterios prácticos para distinguir sistemas duraderos de demos bien presentadas.
Acceso para suscriptores premium.