La verdad incómoda de las apps que te monta la IA al mes tres

La demo sale perfecta. Escribes una frase, esperas dos minutos y tienes una aplicación funcionando con su diseño bonito y todo. Es real, no es truco, y sigue pareciéndome increíble.

El mes tres es otra película. Y esa parte no la enseña nadie porque no da vídeos buenos.

Voy con la tesis: el problema de las apps generadas por IA no es la calidad del código, que suele ser correcta. Es que se genera sin memoria de las decisiones. Y una aplicación es, sobre todo, un montón de decisiones que tienen que seguir siendo coherentes entre sí durante meses.

¿Qué pasa con el código que genera la IA a los tres meses?

Que sigue funcionando, y que cada cambio nuevo cuesta más que el anterior.

Ese es el patrón exacto. Y como es gradual, no lo ves venir. La primera semana pides cambios y salen al momento. El primer mes, casi igual. El segundo empiezas a notar que hay que repetir las cosas dos veces. El tercero pides algo pequeño y se rompe otra cosa que no tenía nada que ver.

El motivo tiene nombre y es la falta de contexto acumulado. Cuando un humano construye algo, va tomando decisiones y las recuerda: aquí decidí resolverlo así, este caso raro lo tratamos aquí, esto está separado por este motivo. Cuando lo genera un modelo pieza a pieza, cada pieza está bien hecha, pero nadie lleva el hilo de por qué se hizo así.

Así que acabas con tres formas distintas de hacer lo mismo dentro de la misma aplicación. Cada una correcta. Todas juntas, un follón.

Los cuatro sitios donde se nota

Duplicación de lógica. La regla de "un usuario solo ve sus cosas" está en cuatro sitios distintos porque se generó cuatro veces. Cambias el criterio y arreglas tres de los cuatro. El cuarto te muerde dentro de dos semanas.

Los casos raros. Lo que se genera cubre el camino normal, que es lo que le pediste. ¿Qué pasa si el usuario le da dos veces al botón? ¿Si el archivo pesa demasiado? ¿Si se va la conexión a medias? Nada de eso está contemplado, y son justo las cosas que hacen que una demo no sea un producto.

Las dependencias. Se meten librerías para resolver cosas puntuales. En tres meses tienes un puñado, algunas resolviendo lo mismo, y ninguna que tú hayas elegido a conciencia. Cuando una se rompe o se queda vieja, no sabes ni por qué estaba ahí.

El día que tienes que entenderlo tú. Este es el gordo. Llega el momento en el que algo falla y necesitas saber cómo funciona tu propia aplicación. Y no lo sabes, porque nunca lo supiste. Lo escribiste pidiéndolo, no construyéndolo.

Lo que sí funciona bien

Que no parezca que vengo a decir que esto no vale, porque vale muchísimo.

Para validar una idea es imbatible. Tienes algo tocable en una tarde, se lo enseñas a cinco personas, y descubres en una semana lo que antes tardabas dos meses en descubrir. Ese uso es puro beneficio y no tiene contraindicaciones.

Para herramientas internas de vida corta, igual. Algo que usas tú, dos meses, para una cosa concreta, y luego se tira. La deuda no importa porque no hay futuro donde pagarla.

Para aprender cómo se monta algo, también. Ver una aplicación funcionando y poder preguntarle por qué está hecha así enseña bastante más rápido que un tutorial.

Donde duele es en la tercera categoría: lo que empieza como prueba, funciona, se queda, y de repente tiene usuarios de verdad y no puedes tirarlo. Conté lo que aprendí de una app que acabé tirando a la basura y el error fue exactamente ese.

Lo que hago yo ahora

Cuatro cosas. Ninguna es técnica y todas se pueden hacer sin saber programar.

Uno: decido desde el principio si esto es de usar y tirar o de mantener. Si es de mantener, cambio la forma de trabajar entera. Voy despacio, por partes, revisando. Si es de tirar, le doy caña y no miro atrás. El error caro es no decidirlo y descubrirlo por accidente.

Dos: pido que documente mientras construye. Cada vez que se resuelve algo importante, un archivo con qué se decidió y por qué. Es el equivalente a la memoria que le falta. Cuesta un minuto por decisión y es la diferencia entre poder retomar el proyecto o no.

Tres: cada cierto tiempo, una pasada de limpieza. Le pido explícitamente que busque duplicaciones y cosas que se hacen de dos formas distintas. No es glamuroso y es lo que evita que la bola crezca.

Cuatro: reviso lo que hace, aunque no lo entienda del todo. No hace falta entender cada línea. Sí hace falta ver qué archivos ha tocado y preguntar por qué cuando algo no cuadra. Aceptar cambios a ciegas durante tres meses es exactamente cómo se llega al desastre.

Sobre el enfoque general de montar cosas sin programar, con lo que sí y lo que no, lo tengo aquí: crear apps sin programar.

Dónde encaja cada herramienta

Lovable (enlace de afiliado: así me ayudas a seguir creando contenido) y Bolt son buenísimos para la primera versión. Te dan algo funcionando muy rápido y con buena pinta, que para enseñar una idea es justo lo que quieres.

Lo que les cuesta es el mantenimiento largo, que es de lo que va todo este post. No es un defecto de producto: están optimizados para arrancar, y arrancar y mantener son problemas distintos.

Mi patrón, cuando algo pasa de prueba a cosa real, es sacarlo de ahí y llevarlo a un proyecto normal de archivos donde pueda trabajar con un asistente que lo lea entero cada vez. Ahí es donde el contexto acumulado deja de perderse. La comparación entre plataformas la tengo en Base44 frente a Lovable, con precios y perfiles.

¿En qué me estaría equivocando?

En el ritmo, seguro. Esto mejora muy rápido.

El problema que describo es de memoria y de contexto, y es exactamente el problema en el que más se está trabajando. Cada versión nueva mantiene mejor la coherencia de un proyecto grande. Es posible que buena parte de lo que cuento aquí esté resuelto en un año. Compruébalo antes de creerme.

Y me equivoco también si tu proyecto no va a llegar al mes tres. La inmensa mayoría no llega, y no por fracaso: es que muchas cosas se montan para un momento concreto y se acaban. Preocuparte de la deuda técnica de algo que vas a tirar es como preocuparte por el mantenimiento de un coche de alquiler.

Lo que no creo que cambie es lo del punto cuatro. El día que algo se rompe, alguien tiene que entender cómo funciona. Puede ser un asistente muy bueno con la documentación delante, no tienes que ser tú. Pero esa documentación tiene que existir, y hoy solo existe si la pides.

El resumen

Las apps que monta la IA no están mal hechas. Están hechas sin memoria.

Si tú pones la memoria (decidiendo el destino del proyecto, documentando las decisiones y limpiando de vez en cuando), el mes tres es perfectamente llevadero. Si no la pones, el mes tres es el mes en que abandonas y no sabes muy bien por qué.

Si no tienes claro si tu idea aguanta más allá de la primera versión o con qué deberías montarla, hice un test corto que te orienta.

Hacer el test de IA