Has hecho el MVP con Claude Code. Producción es la parte que la demo se saltó

Esta semana nos escribió un fundador con una frase que espero leer muchas más veces: «Estamos desarrollando un MVP para nuestra startup, lo hemos hecho con Claude Code y creemos que no va a ser posible usarlo en producción.» El MVP funciona. Los usuarios lo recorren. Los inversores lo han visto. Y quien lo ha construido ya sabe que no va a aguantar.

Hace bien en dudar, y creo que se equivoca en el motivo. Lo digo desde el asiento que revisa estas bases de código: en Conectia usamos Claude Code, Cursor y agentes de revisión dentro de nuestro propio arnés de ingeniería, y hemos entregado productos regulados de identidad y pagos con agentes en el circuito. Este no es un artículo contra construir con IA. Es un artículo sobre lo que la demo deja fuera.

El código casi nunca es el problema. Lo que falta es el sistema que lo rodea. Un MVP hecho a golpe de prompt es una casa que ya tiene paredes y tejado, y ni instalación eléctrica, ni fontanería, ni licencia. Nadie montó nada de eso porque nadie lo pidió, y el agente que levantó las paredes hace exactamente lo que se le pide.

El «vibe coding» ha producido los prototipos más rápidos de la historia, y los más finos

Andrej Karpathy le puso nombre a la práctica en febrero de 2025: describe, acepta, ejecuta, pega el error de vuelta, repite, y «olvídate de que el código existe». En noviembre, Collins eligió vibe coding como palabra del año. Entre una fecha y otra, las herramientas mejoraron lo suficiente para que un fundador sin perfil técnico llegue hoy a un producto que funciona en un fin de semana. Es un cambio real y no lo cambiaría por lo de antes.

Lo que la velocidad esconde es a dónde se fue el tiempo. Dos mediciones de 2025 lo acotan. Veracode probó código generado por más de cien modelos y encontró que el 45 % de las muestras suspendía las pruebas de seguridad; en Java suspendía el 72 %, y en el 86 % de los casos relevantes faltaba la defensa contra cross-site scripting. Los modelos escribían código que compilaba y corría; no escribían código que se defendiera. Ese mismo verano, METR hizo un ensayo aleatorizado con desarrolladores experimentados de código abierto y midió que eran un 19 % más lentos con herramientas de IA mientras creían ir un 20 % más rápido. La distancia entre la velocidad que se siente y la que se mide es justo la que nota un fundador cuando el MVP funciona y aun así no puede salir.

Dónde se rompe de verdad un MVP hecho con IA

He leído suficientes de estos repositorios para saberme la lista de antemano. Nada es exótico; todo es trabajo que el prompt nunca pidió.

• Una autorización que es interfaz, no regla. La app esconde el botón de administrador; la API sirve los datos de administrador a quien los pida. En mayo de 2025 un investigador escaneó 1.645 aplicaciones hechas con Lovable y encontró que 170 exponían datos de usuarios por no tener seguridad a nivel de fila en Supabase. Las aplicaciones no estaban rotas. Estaban abiertas.
• Secretos dentro del repositorio. Claves de API confirmadas en git porque el agente las necesitaba para ejecutar, y después subidas a un GitHub público.
• Ningún muro entre entornos. Una base de datos, unas credenciales y un agente con permiso de escritura sobre ellas. Así fue como el agente de Replit borró una base de datos de producción en julio de 2025 en mitad de una prueba, después de recibir la orden de no tocar nada.
• Un modelo de datos con la forma de las conversaciones, no del negocio. Cada funcionalidad añadió su tabla; nada migra; el esquema es lo que dejó la última charla.
• Cero pruebas en los caminos que mueven dinero o datos. Pago, alta, permisos. Si existe alguna prueba, comprueba el camino feliz que el agente usó para verificarse a sí mismo.
• Sin observabilidad y sin techo de gasto. Si el producto llama a un LLM, nadie ve lo que cuesta una petición y nada impide que un bucle corra toda la noche.
• Dependencias sin fijar y un despliegue que solo funciona desde el portátil del fundador.

Cada punto son uno o dos días de trabajo sénior. El fundador que nos escribió ve el montón sin poder nombrarlo, y por eso «no puede ir a producción» le suena a veredicto sobre toda la base de código. Es un veredicto sobre siete piezas que faltan.

La objeción más fuerte, y tiene razón: el MVP ya ha hecho su trabajo

Alguien dirá que lo correcto es tirarlo y rehacerlo «bien». He visto ese consejo quemar doce meses de caja más de una vez, mucho antes de que la IA entrara en escena. Joel Spolsky llamó a la reescritura completa el peor error estratégico que puede cometer una empresa de software, en el año 2000, y el razonamiento no ha envejecido: el código viejo lo han probado usuarios reales y el nuevo no.

Un MVP hecho con IA ya ha hecho lo caro. Ha demostrado que alguien quiere el producto, ha fijado el vocabulario del dominio y ha dejado una referencia que funciona de cada pantalla y cada flujo. Eso es una especificación escrita en código, y vale más que la presentación a la que sustituyó. La interfaz suele sobrevivir. Los flujos sobreviven. El modelo de datos sobrevive como documentación de lo que el negocio necesita, aunque las tablas en sí no lo hagan.

El MVP no es el error. El error es tratarlo como el sistema de producción.

Esta película ya la hemos visto, con otro reparto

En 2012 el fundador llegaba con un prototipo que le había hecho una agencia a precio cerrado, o un primo que sabía PHP. La misma forma: la demo lucía, el primer cliente de pago encontraba el primer agujero de seguridad, y la pregunta era siempre la misma: ¿rescatar o reescribir? Los equipos que salieron bien no hicieron ni lo uno ni lo otro. Pusieron un perímetro alrededor del prototipo, sustituyeron las piezas que cargaban riesgo de una en una y siguieron sacando funcionalidades mientras tanto. Martin Fowler bautizó el patrón como higuera estranguladora en 2004.

Lo que la IA ha cambiado es la velocidad en los dos lados. El prototipo llega en días en vez de meses, y el arreglo también llega antes, siempre que el agente reciba lo único que la construcción original nunca tuvo: una especificación contra la que ejecutar. Un agente con un modelo de datos escrito, criterios de aceptación y una regla que diga «toda tabla lleva seguridad a nivel de fila» produce una base de código distinta a la de un agente al que se le dice «añade un panel». Lo vemos cada día en nuestro propio trabajo: el mismo modelo, la misma herramienta, y toda la diferencia está en lo que el ingeniero escribió antes.

Los primeros 30 días, en el orden que aguanta

Si el fundador que nos escribió fuera mi cliente, trabajaría en este orden. El orden importa más que la lista.

1. Auditoría de solo lectura, dos días. Inventario del repositorio: dependencias, rutas, tablas, dónde viven los secretos, qué hace de verdad el script de despliegue. Sin cambios. El resultado es un mapa de una página de lo que existe y una lista de lo que carga riesgo.
2. Cerrar el perímetro antes de tocar funcionalidades. Rotar todas las claves que alguna vez se hayan confirmado en git. Imponer la autorización en la capa de datos (seguridad a nivel de fila, no botones escondidos). Separar producción de todo lo demás y quitarle el permiso de escritura a cualquier agente.
3. Hacer el build reproducible. Dependencias fijadas, un solo comando para arrancar en local, un pipeline de integración continua que falle cuando falla una prueba. Hasta que esto exista, cada arreglo es una apuesta.
4. Pruebas solo en los caminos del dinero. Alta, pago, permisos, la consulta que sería una brecha si se filtrara. No cobertura: seguro. Si el producto llama a un modelo, el equivalente es una suite de evaluación que corre con cada cambio de prompt.
5. Observabilidad y techos de gasto. Logs con identificador de petición, seguimiento de errores y un límite duro a lo que la capa de modelo puede gastar al día.
6. Escribir la especificación que el MVP nunca tuvo. Modelo de datos, criterios de aceptación por funcionalidad, el plan por fases y los ficheros de contexto (CLAUDE.md, AGENTS.md) que convierten al agente de constructor de fin de semana en júnior disciplinado. Es el paso que los fundadores se saltan porque huele a papeleo. Es el paso que hace previsibles las seis semanas siguientes, y por eso lo vendemos por separado como un Blueprint que el fundador puede ejecutar con nosotros, con su propia contratación o con el mismo agente que escribió la primera versión.
7. Después, y solo después, funcionalidades. Sobre una base de código que ya puede recibirlas.

Un ingeniero sénior que ya lo haya hecho cubre los cinco primeros pasos en dos o tres semanas. En otro orden (primero funcionalidades, el perímetro después) el mismo trabajo se come un trimestre, porque cada funcionalidad cae sobre arena y hay que rehacerla.

Tres preguntas que deciden entre conservar y reescribir

• ¿El modelo de datos describe el negocio o la conversación? Si las entidades coinciden con cómo hablan tus clientes, consérvalo y migra. Si las tablas llevan nombre de prompt, rehaz el esquema y traspasa los datos.
• ¿Alguien puede dibujar en una pizarra el recorrido de la petición más arriesgada? Si nadie puede, la auditoría va antes que cualquier decisión.
• ¿El framework es uno que un ingeniero sénior elegiría hoy? Next.js, Django, un Postgres gestionado: conservar. Una pila generada para la que nadie contrata en el mercado: planifica la salida ahora y ejecútala más tarde.

La mayoría de los MVP hechos con IA que he visto pasan la primera pregunta y la tercera. Fallan la segunda, y ese fallo está a dos días de auditoría de quedar resuelto.

La demo se saltó producción. Tú no tienes por qué

La frase del fundador tenía media razón. El MVP tal como está no debe ir a producción, y ese nunca fue su trabajo. Su trabajo era demostrar el producto, y lo hizo más rápido que cualquier método que existiera hace tres años. Lo que necesita ahora es la instalación eléctrica, la fontanería y la licencia, en un orden conocido, de manos de alguien que ya las haya instalado antes.

Si esa es la pregunta que tienes delante, este es el equipo que ponemos en productos de startup: ingenieros sénior, validados por CTOs en activo con un 3 % de aceptación, que se hacen cargo de una base de código sin que nadie les dicte el spec y empiezan por el perímetro la primera semana. O empieza por el Blueprint, y sigue construyendo con quien quieras.