He vuelto a estar casi dos meses sin escribir en el blog, otra vez me superó la agenda. Ahora que anda algo más despejada y el calor invita a quedarse bajo el aire acondicionado, toca volver a las teclas y como no se habla de otra cosa que de inteligencia artificial, hoy quiero poner el foco en algo muy concreto: cómo el vibe coding ha cambiado la configuración de una startup y por qué el MOAT (la barrera que protege a una empresa de que la copien) nunca estuvo en el producto que construías, sino en lo caro que era construirlo.
Cuando co-dirigía el programa de aceleración de El Cubo en Andalucía Open Future, teníamos un requisito de entrada: los equipos debían tener al menos dos personas, idealmente tres. Buscábamos una distribución balanceada: alguien con visión de negocio y comercial, alguien capaz de construir el producto tecnológico.
Esa regla, que fijamos en 2014, tenía sentido en su momento. Al programa de aceleración llegaban propuestas interesantes que difícilmente iban a traccionar en los ocho meses que duraba el programa, porque ningún socio fundador sabía desarrollar lo que planteaban.
De hecho, en 2020 escribí sobre esto reafirmando la tesis. Veía equipos intentando tapar ese agujero contratando a una agencia para construir el MVP, y eso les comía el runway en meses, o peor, los empujaba a levantar una ronda solo para pagar la subcontrata.
Sin embargo, esta tesis de 2020 se ha venido abajo por completo y toca replantear muchas cosas…
¿Por qué el vibe coding ha cambiado el «equipo mínimo viable» de una startup, y qué te sigue protegiendo de la competencia? Vamos a verlo en detalle.
Lo que cambió: la IA generativa
Llegaron Lovable, Cursor, Claude Code… y con ellos el vibe coding, término que acuñó Andrej Karpathy en febrero de 2025 para describir programar dejándose llevar por la IA en vez de escribir código línea a línea.
Y todo cambió…
Desarrollar producto ya no es un cuello de botella exclusivo de quien sabe programar. Con una suscripción y unos créditos, cualquiera puede levantar un MVP para poner delante de clientes potenciales, recoger feedback y empezar a validar hipótesis.
El bloqueo de «no tengo quien me lo construya» ya no es excusa.
Y el salto no es solo de accesibilidad, es de alcance. Cadabra Studio documentó cómo un equipo de tres personas levantó un MVP funcional completo (onboarding, analítica, soporte multiplataforma) en ocho semanas, un 60% más rápido que con un proceso tradicional.
El MVP ya no tiene por qué ser cutre: puede cubrir mucho más scope que el clásico Pareto del 20% del esfuerzo para el 80% de las necesidades del cliente, y seguir siendo rápido y barato de construir.
La paradoja de la velocidad
Aquí es donde está la parte incómoda; si construir software es accesible y barato para todo el mundo, la ventaja competitiva deja de estar en la complejidad del producto y pasa a estar en la velocidad: quien itera más rápido aprende más rápido y se adelanta a su categoría.
El problema es que esa ventaja también se evapora rápido. Si tú puedes vibe-codear un MVP completo en un fin de semana, tu competencia también. Ricardo Bedin lo plantea sin rodeos: cuando todo el mundo puede construir igual de rápido, la velocidad deja de ser la ventaja, y lo que queda es la ejecución, el criterio sobre qué construir y la distribución.
Benedict Evans lo plantea todavía más afilado en «AI eats the world» del pasado mes de mayo: «was the cost of that task your MOAT?» (¿el coste de esa tarea era tu MOAT?).
Evans separa la tarea (escribir el código, montar la pantalla, redactar la hoja de cálculo) del trabajo real: el conocimiento implícito, el criterio, el gusto.
El vibe coding automatiza la tarea. El trabajo sigue sin sustituto y la cosa no se queda en tu código: el propio Evans documenta cómo los modelos de IA que usas para programar se están volviendo una commodity entre sí, sin efectos de red que protejan a ninguno.
Si ni el modelo que usas es defendible, menos lo va a ser el MVP que construyes con él.
Dicho de otra forma: la tecnología, las features únicas o tener «algo que los demás no tienen» dejan de funcionar como el MOAT de una startup.
Si lo construyes tú en una semana, alguien con la misma idea y un prompt parecido lo construye en la siguiente. El diferencial ya no vive en el código, vive en cómo lo ejecutas, en el criterio para decidir qué merece la pena construir, y en llegar al cliente antes y mejor que el resto.
Dos límites que el vibe coding no ha movido
Pero el vibe coding no es la varita mágica que algunos venden:
- La IA no adivina qué quieres construir, ni vigila lo que no le has pedido que vigile. Si no tienes claro el problema, la solución, los casos de uso y para quién es, la IA no te lo va a resolver. Y tampoco sustituye el criterio: Cadabra Studio cuenta cómo, construyendo con GPT-5 y Claude, el modelo llegó a montar dos sistemas de caché distintos para la misma función sin darse cuenta de que duplicaba datos. Nadie lo pilló en las pruebas; habría explotado en producción. El barco sigue necesitando un capitán, o como lo llaman ellos, alguien que haga de «guardián de la arquitectura».
-
MVP no es sinónimo de producto escalable. Que construyas algo funcional con vibe coding no significa que tenga la arquitectura para pasar de 5 a 5 millones de usuarios. Matas Rimkus lo resume en cuatro palabras: «vibe first, engineer second«. Primero validas rápido, luego reconstruyes con criterio de ingeniería de verdad. Y si llegas a tener ese problema de escalar, enhorabuena: significa que validaste el problema, la solución y el segmento, y que estás empezando a tocar product-market fit.
Mauricio Perera lo convierte en una regla interesante: cuanta más solidez necesita el producto y más alto es el riesgo, menos tolerancia hay para el código «por vibes»; cuanta más incertidumbre y menos riesgo, más sentido tiene soltar las riendas. No es una frontera fija entre prototipo y producto. Es un gradiente que sube de exigencia a medida que crece el impacto.
El Equipo Mínimo Viable (EMV), reescrito
La IA generativa ha reescrito lo que hace falta para arrancar. Ya no necesitas 2-3 socios fundadores ni presupuesto para subcontratar desarrollo en el caso que no haya nadie que pueda desarrollar producto en el seno del equipo.
El Equipo Mínimo Viable, el que pedíamos en El Cubo allá por 2014, puede ser hoy una sola persona.
Un solopreneur o monofounder puede dar sus primeros pasos sepa o no programar. Eso no quita ni una coma a lo que sigue siendo imprescindible:
- Conocimiento del sector. La IA acelera el estudio de mercado y el mapeo de competencia, pero no lo sustituye.
- Contacto real con el cliente. Entender por qué las soluciones actuales no convencen, y qué haría que alguien cambiase a la tuya, se averigua hablando con gente, no preguntándoselo a un modelo.
Lo que sí cambia radicalmente es la velocidad de respuesta: el feedback de tus primeros clientes puede llegar al producto en horas, no en sprints.
Y si el MOAT ya no está en la tecnología, un fundador en solitario no compite por tener más código que el resto. Compite por entender mejor a su cliente y moverse más rápido que él.
La pregunta que importa
Si no tienes MVP en plena era de la IA, hazte esta pregunta: ¿tengo claro qué problema quiero resolver, para quién, y con qué enfoque?
Si la respuesta es sí, no te queda excusa técnica ni económica para no construirlo y ponerlo delante de clientes reales.
Si la respuesta es no, el problema nunca fue de producto ni de falta de desarrolladores: es de hipótesis sin aterrizar y de conocimiento de sector. Y eso, ni el vibe coding más fino te lo resuelve.
Nos seguimos leyendo. Hasta la próxima.
Imágenes: Magnific, Giphy, adaptación con Gemini de una imagen de KwFoundation y Nano Banana Pro.