Trampa del vibe coding:por qué mueren los proyectos de IA

El vibe coding —construir software describiéndole a una IA lo que quieres sin entender la arquitectura de debajo— funciona de maravilla durante unos tres meses. Después, cada nueva función empieza a romper las antiguas y la mayoría de los proyectos muere en la trampa del vibe coding. La trampa no es la IA. Es quién toma las decisiones de arquitectura: nadie.

Veo el mismo ciclo todas las semanas. Semana 1: «¡Construí el MVP de mi SaaS en un fin de semana, la IA es magia!». Semana 4: «Esta semana añadí 10 funciones nuevas». Semana 12: «Todo se rompe. Cada función nueva rompe 3 antiguas. Creo que tengo que reconstruirlo desde cero». Semana 16: «El vibe coding es una mierda. Vuelvo al desarrollo tradicional».

Gente inteligente y capaz. Un impulso increíble. Y luego un muro tan duro que lo abandonan todo. Te cuento por qué, y cómo ser la excepción.

¿Qué es el vibe coding?

El vibe coding es pedirle a una IA que construya funciones sin tomar tú ninguna decisión de arquitectura. «Hazme un panel de usuario». Lo lanzas. «Ahora añade equipos». Lo lanzas. «Añade facturación». Lo lanzas. Cada prompt funciona. Cada función aparece. Nunca decidiste cómo se estructuran los datos, cómo funcionan los permisos ni cómo se conecta nada con nada.

Y la experiencia inicial es embriagadora por motivos reales: código que funciona en minutos en lugar de días, sin curva de aprendizaje, con un progreso tangible que puedes enseñar. La dopamina es real. Las funciones funcionan de verdad.

Hasta que dejan de hacerlo. Porque esta es la verdad incómoda: el vibe coding parece productivo porque confundes actividad con progreso. Lanzar funciones es actividad. Construir una arquitectura que sobreviva al contacto con la función 20 es progreso.

La trampa del vibe coding: el precipicio del mes 3 donde mueren los proyectos de IA

El colapso sigue una secuencia mecánica predecible:

Semanas 1–4: la luna de miel. Construyes funciones aisladas. Cada una funciona por separado, porque todavía nada está conectado. La IA genera un código razonable porque cada prompt es simple y autocontenido.

Semanas 5–8: las grietas. Las funciones nuevas ya interactúan con las antiguas, y la IA no recuerda las decisiones de arquitectura que tomó hace cuatro semanas. Sesiones distintas toman decisiones distintas. A veces enlaza bien los datos con claves foráneas; a veces los duplica. Un día descubres que el nombre del usuario está guardado en cinco tablas diferentes. Lo cambias en un sitio y queda obsoleto en los otros cuatro.

Semanas 9–12: la espiral de la muerte. Cada función nueva hereda las incoherencias, añade sus propias suposiciones y rompe algo que funcionaba. Pides: «Arregla el bug por el que los nombres de usuario no se actualizan en todas partes». La IA responde: «Actualizaré los 6 sitios donde guardamos nombres de usuario». Preguntas por qué hay seis sitios. Se ofrece a consolidarlos, pero eso romperá 15 funciones. Fin de la partida.

El desajuste que engaña a la gente: la IA es realmente excelente generando código correcto para funciones aisladas. No es buena recordando decisiones entre sesiones, detectando conflictos con patrones existentes ni tomando decisiones estratégicas de arquitectura. Y responde con total seguridad en ambos casos: «por simplicidad, recomiendo desnormalizar aquí» suena inteligente, y no puedes distinguir un buen consejo de uno malo si no entiendes la arquitectura.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Tú eres el arquitecto. La IA es el constructor.

Este es el cambio de paradigma que lo cambia todo. No «la IA es mi desarrolladora y yo soy el product manager». No «programamos juntos como socios». Tú diseñas. La IA construye.

Piensa en construir una casa. El arquitecto decide los cimientos, los muros de carga, por dónde van las tuberías: decisiones que no se pueden cambiar una vez empieza la obra. El constructor ejecuta ese plano con verdadera destreza, pero no lo crea. Dile a un constructor «hazme una casa» sin plano y obtendrás algo que se sostiene, hasta que quieras una segunda planta y descubras que los cimientos no la aguantan.

En el software, las decisiones del arquitecto son tuyas: qué entidades existen y cómo se relacionan, si el sistema es multi-tenant, cómo se aplican los permisos, qué se normaliza, qué patrones sigue cada servicio. El trabajo de la IA es la ejecución: los componentes, el código repetitivo, las migraciones que implementan tu esquema exactamente.

Y parte del trabajo es llevarle la contraria. Cuando la IA dice «por simplicidad, guardemos también el nombre del usuario en la tabla de pedidos», no: normalízalo. Cuando dice «por rendimiento, desnormalicemos», enséñame antes el problema de rendimiento. Cuando sugiere un arreglo rápido, nada de apaños: busca la causa raíz. La IA optimiza para código que funciona rápido. Tú necesitas código de producción que no haya que reconstruir nunca.

La alternativa de la arquitectura primero (con pruebas)

No desarrollé este enfoque porque sea listo. Lo desarrollé porque no tuve elección. Tras perderlo todo en una aventura empresarial fallida, estaba reconstruyéndome desde casa de mis padres: mis padres, de 83 años, me pagaban la suscripción a Claude porque yo no podía permitírmela. Tenía meses de margen, no años. Si hacía vibe coding y chocaba con el muro en el mes 3, no habría un segundo intento.

Así que, antes de escribir una sola línea de interfaz, pasé 2 semanas diseñando el esquema completo de la base de datos de FIKR Space: cada relación mapeada, multi-tenancy en todas las tablas desde el día 1, seguridad a nivel de fila aplicada en la propia base de datos, más del 90 % de los datos normalizados en una única fuente de verdad. Luego le di ese plano a la IA y le hice construir, peleándome con ella a diario cuando sugería atajos.

El resultado tras 11 meses: 11 productos integrados, listos para producción, cero reescrituras. Con los cimientos sólidos, las funciones volaron: un sistema de OKR completo en 3 días, la gestión de la tabla de capitalización en 4. Cuando la gente lo probaba, la pregunta era siempre la misma: «¿Cómo pudiste construir esto tú solo?». El presupuesto tradicional para esa plataforma es de 10–15 desarrolladores durante 2 años: de 1,6 a 2,4 millones de euros solo en sueldos de desarrollo, fácilmente más de 2 millones con todos los costes. A mí me costó menos de 3.250 € el primer año. (El desglose completo del coste del stack de herramientas tiene su propio artículo.)

La elección que tienes delante es sencilla de enunciar: rápido ahora y lento después, o lento ahora y rápido para siempre. El vibe coding lanza 20 funciones en el mes 1 y luego pasa el mes 3 arreglando lo que construyó el mes 1. La arquitectura primero dedica 2 semanas al plano y luego lanza funciones que siguen funcionando.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Preguntas frecuentes

¿Cómo sé si estoy haciendo vibe coding?

Las señales de alerta: le has pedido a la IA que arregle el mismo bug más de 3 veces, no sabes explicarle tu esquema de base de datos a otra persona, los mismos datos parecen guardarse de forma distinta en distintas funciones, evitas añadir funciones porque no sabes qué romperán, o piensas en silencio en «empezar de cero con una pizarra limpia». Tres o más de esas señales significan que te diriges al precipicio.

¿Está bien alguna vez el vibe coding?

Sí, para prototipos y apps sencillas que estás dispuesto a tirar. Las herramientas pensadas para el puro prompting son geniales para MVP rápidos. La trampa se cierra cuando un prototipo desechable se convierte en silencio en el producto y las decisiones de arquitectura del mes 3 las tomó nadie.

¿Puedo rescatar un proyecto hecho con vibe coding o tengo que reconstruirlo?

Normalmente se puede rescatar. Pausa el desarrollo de funciones unos días, mapea cada tabla y cómo se conectan, identifica dónde se duplican los datos, diseña el esquema que esas entidades deberían haber tenido y después migra: consolida los duplicados, añade las claves foráneas que faltan, añade el aislamiento por tenant, activa la seguridad a nivel de fila. Se siente lento. Es cuestión de meses más rápido que la reescritura hacia la que te diriges si no lo haces.

¿Necesito aprender a programar para ser el arquitecto?

No, pero sí tienes que aprender los fundamentos de cómo encajan los sistemas: entidades, relaciones, fuente única de verdad, permisos. Tú tomas esas decisiones; la IA escribe la implementación. Esa habilidad se aprende en semanas, y es la diferencia entre un proyecto que muere en el mes 3 y uno que se acumula. Si estás construyendo tu salida de la empresa sobre esto, empieza midiendo cuánto la necesitas y luego constrúyela sobre unos cimientos de verdad.