De demos con IA a productos a gran escala: por qué el 'vibe coding' falla

Si has estado siguiendo mis artículos recientes, sabes que he pasado mucho tiempo construyendo demos con IA. Desde crear chatbots locales con Gemini y Angular hasta experimentar con agentes WebMCP y crear proyectos como mcpclick.app.

Cuando empecé a hacer esto, se sentía como magia.

Describía lo que quería construir y dejaba que agentes como Cursor, gemini-cli o Antigravity generaran y aplicaran el código directamente en mi proyecto. Simplemente funcionaba. No me preocupaba por diagramas de arquitectura ni por escribir documentación detallada. Solo escribía un prompt, confiaba en que el agente lo ejecutaría y avanzaba rápido.

Esto es lo que la gente llama "vibe coding". Simplemente fluyes con la IA y el código se va escribiendo.

Pero cuando intenté ir más allá de las demos rápidas para construir productos más grandes y confiables, me di contra una pared. Muy duro.

Se termina la luna de miel

En esos primeros proyectos, las dos primeras semanas siempre fueron increíbles. Me sentía como un desarrollador 10x. Pero después, algo cambiaba.

Recuerdo haberle pedido a la IA un pequeño cambio en un módulo de enrutamiento. El agente actualizó los archivos y el enrutamiento quedó resuelto. Pero, de repente, mi dashboard se rompió. Le pedí a la IA que arreglara el dashboard y entonces falló un endpoint de la API que no tenía nada que ver. Me sentía como el Coyote persiguiendo al Correcaminos. Cada vez que creía haber atrapado el bug, un nuevo problema me explotaba en la cara.

Para cuando el proyecto creció a cuarenta o cincuenta archivos, la IA empezó a alucinar dependencias que no existían en mi package.json. Proponía soluciones que ignoraban por completo la arquitectura que habíamos "acordado" tres días antes.

Terminé escribiendo prompts gigantescos solo para explicarle el contexto histórico del proyecto al agente. Llegó a un punto en el que realmente me daba miedo pedirle nuevas funcionalidades. Me aterraba romper la aplicación porque ya no tenía una idea clara (ni un changelog) de todo lo que la IA había construido. Después de un fin de semana largo, hasta yo mismo olvidaba cómo estaba estructurado mi propio código.

La IA no es el problema. El problema era mi proceso.

Mi primera reacción fue escribir prompts más largos y complejos. Intenté meter cada archivo dentro de la ventana de contexto. Aun así, la IA se contradecía entre una sesión de chat y otra.

Ahí fue cuando me di cuenta: los modelos de IA son probabilísticos. Nunca serán 100% deterministas. Si dependes de una sesión de chat para mantener el contexto de tu aplicación, estás construyendo tu casa sobre arena. Cada vez que abres un chat nuevo, el agente empieza desde cero.

Antes de la IA, si un nuevo desarrollador se sumaba al equipo y empezaba a cambiar código sin entender la arquitectura, también rompía cosas. ¿Cómo solucionábamos eso? Con especificaciones y documentación.

Con la IA es exactamente el mismo problema, solo que pasa diez veces más rápido. Yo no necesitaba un mejor prompt. Necesitaba un artefacto de referencia.

Poniendo orden en el caos

Comprendí que mi rol tenía que cambiar. Ya no podía ser únicamente la persona que ejecutaba prompts y miraba cómo el agente escribía archivos. Tenía que convertirme en el orquestador.

Esta idea encajó a la perfección con una metodología llamada Spec-Driven Development (SDD). La propuesta es brillante por su simplicidad: antes de que la IA escriba una sola línea de código, creas un documento vivo (una spec) que describe qué se va a construir, por qué y cuáles son los criterios de aceptación.

La IA deja de ser un cofundador tomando decisiones de arquitectura y pasa a ser lo que mejor sabe hacer: un motor de ejecución que sigue un contrato estricto por escrito.

Desde que empecé a adoptar este enfoque (escribir la spec primero, ejecutar con la IA en segundo lugar y revisar como humano en tercer lugar), mis proyectos volvieron a ser predecibles. El caos desapareció.

En resumen

Pasar de solo escribir prompts a tener un proceso real cambió por completo mi forma de trabajar. En los próximos artículos, te voy a ahorrar horas de prueba y error. Te mostraré exactamente cómo escribir specs que la IA realmente entienda y cómo crear un ciclo de trabajo que sirva para cualquier proyecto.

Si estás sintiendo el dolor de ver cómo tus proyectos con IA se rompen, te recomiendo mucho leer Spec-Driven Development de Bezael Pérez.

No gano ninguna comisión por decir esto, pero este es exactamente el libro que me hubiera gustado tener hace 8 meses, cuando empecé a construir productos reales con IA. ¿Lo mejor de todo? No está atado a una herramienta o framework en específico. Te enseña las bases que puedes aplicar en cualquier lugar para recuperar el control de tu código.

Foto de Jessie Maxwell en Unsplash