Mantener una aplicación creada por IA: entender lo que has encargado construir

El vibe coding funciona hasta el día en que alguien debe retomar la aplicación. Dos testimonios, uno de un fundador y otro de un desarrollador francés, describen el mismo muro. Lo que lo derriba cabe en un documento que has revisado y validado.

Mantener una aplicación creada por IA tropieza con un momento que describe un fundador en Reddit (r/vibecoding, agosto de 2026): «Y de repente, lo difícil ya no es construir. Es entender lo que has construido». Enumera las señales: una función que existe en dos lugares, un componente que hace demasiado, archivos que nadie se atreve a borrar.

El muro llega después de la entrega

La construcción no avisa. Las primeras semanas son emocionantes: describes, la herramienta produce, la pantalla responde. El muro se levanta después, en la vigésima modificación, cuando una petición sencilla obliga a entender tres lugares del producto antes de tocar uno solo. En ese punto, la IA sigue produciendo código y lo que falta es el sentido del conjunto. Nadie del equipo puede decir por qué existe una regla ni qué rompe si se elimina.

Cuando varias manos tocan el mismo producto

El mismo muro aparece antes si son dos. Un desarrollador cuenta en Reddit (r/developpeurs, mayo de 2026): «Mi jefe interviene en los proyectos en los que trabajo haciendo vibe coding. Resultado: los proyectos no tienen ninguna estructura, mantenerlos es un infierno». Precisa que es el único desarrollador de formación de la empresa. Dos personas que describen sus intenciones a una IA, cada una por su lado, producen dos mitades de aplicación que no comparten ninguna regla. La calidad de cada mitad no cambia nada.

La especificación es la memoria del producto

Un software guarda dos cosas: el código que funciona y la razón por la que funciona así. La segunda vive en la cabeza de quien lo construyó y se borra en unos meses. Un documento de requisitos validado la fija por escrito, en tu idioma: qué debe hacer el producto, para quién, con qué reglas y qué no debe hacer. Ese documento se relee en un cuarto de hora un año después. Es el tema de tus especificaciones valdrán más que tu código y la razón por la que exigimos validación humana antes de cada etapa de construcción.

Lo que se regenera y lo que no

Con un documento que describe el producto y pruebas escritas antes del código, una parte perdida puede reconstruirse: vuelves a pedir que se construya la etapa y las pruebas dicen si el resultado se sostiene. Sin ese documento, la única memoria es el propio código, y releerlo requiere la competencia que intentaste evitar al encargar la construcción a la IA. La diferencia se ve el día en que quieres cambiar de proveedor, herramienta o motor: el código se rehace, el conocimiento de tu oficio no.

Lo que hacen mejor las herramientas de generación rápida

Para un prototipo que muestras a un socio y tiras la semana siguiente, todo lo anterior es peso innecesario: Lovable, Bolt o v0 te darán una pantalla viva en una tarde y no echarás de menos ningún documento porque nada sobrevivirá. La frontera entre las dos situaciones es la que describimos en prototipo en una tarde, producto en una semana. Se cruza sin avisar el día en que un primer cliente usa lo que has creado.

Retomar un producto ya construido

Si ya estás al otro lado del muro, reconstruir no debe ser tu primer impulso. Existe un proceso de recuperación: revisar lo existente, extraer las reglas que esconde, escribir el documento de requisitos que faltaba y después avanzar por etapas verificadas. Maestro lo ofrece sobre un software existente, incluso construido por otra persona, y contamos lo que da ese trabajo sobre una herramienta envejecida en renovar un software de negocio. El costo de poner orden se compara con el de un año de mantenimiento, que cuantificamos en cuánto cuesta el mantenimiento de una aplicación.

La prueba de los seis meses

Abre tu aplicación y elige al azar una regla de negocio: un cálculo de descuento, una condición de envío de correo o un estado que bloquea una acción. Intenta escribirla en tres frases sin mirar el código y después pide lo mismo a quien construyó contigo. Si las dos versiones difieren, o si no sale ninguna, ya conoces el estado de la memoria de tu producto. Escribir esas tres frases cuesta diez minutos por regla y conviene hacerlo hoy, no el día en que alguien deba tomar el relevo.