Hay una ilustración famosa que compara cómo distintas metodologías abordan la construcción de un producto. Seguramente la viste:
- Waterfall construye un auto pieza por pieza — ruedas, chasis, carrocería — y no tenés nada usable hasta el final.
- Agile arranca con una patineta. Después un monopatín. Después una bici. Después una moto. Cada iteración entrega algo que podés usar.
Las dos se discutieron hasta el cansancio. Pero ahora hay una fila nueva en el gráfico, y nadie está hablando realmente de ella.
IA — o más específicamente, vibe coding — arranca con el auto de Homero Simpson. Sí, ese: el monstruo sobreingeniereado de ese episodio de Los Simpsons donde Homero diseña el auto de sus sueños. Tiene tres bocinas, una cúpula de burbujas, aletas por todos lados, y cuesta tanto que lleva a la quiebra a la empresa de su hermano.
Eso es lo que muchos MVPs construidos con IA parecen hoy.
¿Qué es el vibe coding y por qué se siente tan bien?
Vibe coding es un término que viene circulando en la comunidad dev para describir la experiencia de construir software con asistentes de IA — herramientas como Cursor, Copilot, V0, Bolt o Claude. Describís lo que querés en lenguaje natural, la IA genera el código, y vas iterando por vibra. Se siente como magia. Estás sacando features en minutos que antes te hubieran tomado horas o días.
Y ahí está exactamente el problema.
La velocidad y facilidad del vibe coding genera un subidón emocional. Estás en la zona. Los features van apareciendo en pantalla. Los golpes de dopamina siguen viniendo. Entonces seguís. Un feature más. Una pantalla más. Una integración más. Antes de que te des cuenta, construiste algo que se ve impresionante en un demo pero estructuralmente es un desastre.
Construiste el auto de Homero.
El MVP Homero Simpson: un nuevo anti-patrón
Lo que hace diferente a este anti-patrón del clásico "sobredimensionamos el MVP":
La sobreingeniería tradicional pasa porque los equipos dedican demasiado tiempo a planificar y construir antes de lanzar. Son lentos, metódicos y perfeccionistas. La solución es conocida: reducir scope, lanzar más rápido, aprender de los usuarios.
El MVP Homero Simpson pasa porque los equipos lanzan demasiado rápido. La IA elimina la fricción de implementar, entonces cada idea que se te cruza por la cabeza se construye. No filtrás porque construir es prácticamente gratis. El resultado es un MVP que tiene:
- Features que nadie pidió
- Pantallas que resuelven problemas imaginarios
- UX inconsistente porque cada feature se vibecodeó de forma independiente
- Un codebase que es un patchwork de código generado por IA sin arquitectura coherente
- Bugs escondidos detrás de cada feature, porque nada se testeó como corresponde
La ironía es brutal: usaste IA para moverte más rápido, pero el bloat que generó significa que vas a pasar más tiempo iterando, corrigiendo bugs y sacando features que si hubieras empezado con un producto mínimo y enfocado.
Por qué pasa esto: el high del builder
Cuando estás vibecodeando, experimentás lo que llamo el high del builder. Es parecido a lo que sienten los corredores — un rush de endorfinas por el acto de crear en sí mismo. El problema es que este high te desconecta del pensamiento de producto.
En el desarrollo tradicional, el costo de construir un feature actúa como un filtro natural. Si algo toma dos semanas de implementar, naturalmente te preguntás: "¿Esto es realmente esencial para la v1?" La fricción es un feature — te fuerza a priorizar.
La IA elimina esa fricción. Y sin ella, no hay nada que te obligue a ser disciplinado con el scope. Cada pensamiento de "¿no estaría bueno si...?" se implementa porque solo toma cinco minutos.
Vi este patrón repetidamente en reuniones iniciales con founders que vienen a nosotros después de su primer intento vibecodeado. Tienen muchas pantallas. Muchos features. Y muchos bugs. Lo que no tienen es una respuesta clara a: "¿Cuál es la única cosa que este producto tiene que hacer realmente bien?"
El costo real del MVP Homero Simpson
Seamos específicos sobre lo que sale mal:
1. Más features = más bugs
Cada feature es una superficie de ataque para bugs. Cuando vibecodeás diez features en vez de dos, no tenés 5x más bugs — tenés 10x o 20x más, porque los features interactúan de formas inesperadas. El código generado por IA es particularmente propenso a bugs sutiles de integración porque cada pieza se generó de forma aislada.
2. Más features = iteración más lenta
Tu loop de feedback se destruye. Cuando los usuarios reportan problemas, no podés distinguir si el problema está en la propuesta de valor central o en los features extras que agregaste. Tu ratio señal-ruido se va al piso.
3. Más features = decisiones más difíciles
Cuando llega el momento de cortar scope (y siempre llega), enfrentás la falacia del costo hundido potenciada. "¡Pero la IA construyó esto en diez minutos!" Claro — pero entenderlo, debuguearlo y mantenerlo no es gratis.
4. Más features = usuarios confundidos
Los usuarios que se encuentran con un MVP inflado no piensan "wow, este producto hace un montón". Piensan "no entiendo para qué es esto". Un MVP enfocado comunica su valor al instante. Un MVP Homero Simpson comunica caos.
Cómo evitarlo: disciplina de scope en la era de la IA
La solución no es dejar de usar herramientas de IA. Son genuinamente transformadoras. La solución es recuperar la disciplina de priorización que la fricción solía imponer naturalmente.
Empezá por el problema, no por las herramientas
Antes de abrir Cursor o cualquier herramienta de coding con IA, escribí las respuestas a tres preguntas:
- ¿Qué problema único resuelve este MVP?
- ¿Para quién?
- ¿Cómo voy a saber si está funcionando?
Si no podés responder cada una en una oración, no estás listo para construir. Andá a leer nuestra guía sobre validar antes de construir.
Definí tu lista de "no voy a construir"
Esto es más importante que tu lista de features. Escribí cada feature que podrías construir pero no vas a incluir en la v1. Colgalo donde lo puedas ver. Cuando te agarre el high del vibe coding y pienses "ah, también podría agregar..." — revisá la lista.
Poné un presupuesto de features
Elegí un número. Tres features. Cinco pantallas. Lo que encaje con tu producto. Ese es tu tope duro. Si querés agregar algo nuevo, tenés que sacar algo existente. Esta restricción es el mejor sustituto para la fricción natural que la IA eliminó.
Time-box, no feature-box
Date un deadline — una semana, dos semanas — y lanzá lo que tengas. El approach de la patineta de Agile funciona precisamente porque cada iteración tiene una restricción de tiempo. Aplicá el mismo principio a tus sesiones de vibe coding.
Separá construir de decidir
Vibecodeá todo lo que quieras durante las sesiones de construcción. Generá diez enfoques diferentes. Explorá libremente. Pero después dá un paso atrás, ponete el sombrero de producto, y cortá sin piedad. La exploración creativa y la disciplina editorial tienen que ser fases separadas.
La forma correcta de usar IA para tu MVP
El desarrollo asistido por IA es un superpoder cuando se aplica correctamente. Este es el patrón que vemos que funciona bien:
Validá primero — Usá IA para construir landing pages, prototipos y smoke tests. Validá la demanda antes de comprometerte con un producto real. Escribimos extensamente sobre por qué la validación viene antes de construir.
Definí el scope sin piedad — Usá el framework de MVP para identificar el set mínimo absoluto de features. Escribilo. Comprometete con eso.
Construí la patineta — Usá IA para construir tu set mínimo de features rápido y bien. La ventaja de velocidad del vibe coding es increíble cuando se canaliza en un scope enfocado.
Lanzá y aprendé — Ponelo frente a usuarios. Recolectá feedback. Después decidí qué agregar basándote en datos reales, no en vibras.
Iterá con intención — Cada nuevo feature debería ser una decisión de producto deliberada, no un impulso de "la IA puede hacer esto en cinco minutos así que por qué no".
La conclusión
El approach Waterfall construye el auto secuencialmente — lento pero predecible. Agile construye incrementalmente — cada paso entrega valor real. La IA, sin control, construye el auto de Homero Simpson — impresionante a la vista pero disfuncional.
Los mejores founders en la era de la IA no son los que construyen más. Son los que usan la velocidad de la IA para construir menos, más rápido y mejor. Lanzan la patineta en un día en vez de una semana. No usan ese tiempo ahorrado para agregarle un motor de cohetes y una cúpula de burbujas.
Las herramientas cambiaron. Los principios no. Disciplina de scope, foco en el usuario y aprendizaje iterativo siguen ganando. La IA solo hace más fácil olvidarse de eso — si lo permitís.
