La IA rompe mi aplicación en cada cambio: por qué una metodología supera a un modelo mejor

Pides una corrección y recibes tres fallos. El reflejo es cambiar de herramienta, después de modelo y después otra vez de herramienta. Lo que cuentan quienes salieron del bucle cabe en un hábito de escritura que cuesta una línea por petición.

Un usuario escribe en Reddit (r/lovable, junio de 2026) que su consumo de créditos bajó aproximadamente a la mitad el día que añadió «no toques nada más» a cada petición. Cuando la IA rompe tu aplicación en cada cambio, el alcance de la petición es lo primero que conviene mirar, antes de elegir el modelo.

El bucle que todos describen

El relato típico circula repetido de forma idéntica en varios hilos el mismo día (agosto de 2026): se pide reparar el acceso, el acceso se repara y los datos desaparecen; se pide reparar los datos, aparecen tres archivos con una dependencia de la que nadie ha oído hablar y ya no funciona nada. Su autor dice haber pasado por ocho herramientas antes de detenerse. Un desarrollador francés describe el mismo mecanismo visto desde el otro lado (r/developpeurs, mayo de 2026): su responsable interviene con vibe coding en los proyectos a su cargo, los proyectos se quedan sin estructura y el mantenimiento se vuelve un infierno. Ambos describen un producto cuyo alcance nunca se escribió en ninguna parte.

Lo que hace una IA cuando nadie acota la petición

El autor del primer testimonio sobre créditos lo escribe con precisión: a la IA le gusta ayudar, así que pides un cambio y mejora otros cuatro que no habías mencionado, la mitad de los cuales se rompen; después gastas créditos deshaciendo su generosidad. Una IA que recibe una frase y un proyecto entero toma el proyecto entero como terreno de juego. No tiene ninguna frontera escrita: nada le dice que la pantalla de acceso, la tabla de clientes y el cálculo de descuentos debían permanecer intactos. Cada vuelta del bucle amplía la superficie que cree tener que mejorar y descubres los daños varios días después, en una pantalla que no habías vuelto a abrir desde el cambio. Encontrar qué petición produjo qué fallo cuesta entonces más que el propio fallo.

El alcance, la solución más barata

Acotar la petición cuesta una línea y se practica en cualquier herramienta, incluidas las que recomendamos para maquetas rápidas. Nombra el archivo o la pantalla afectada, di qué debe permanecer idéntico y pide la lista de lo que se ha tocado antes de aceptar. En una aplicación de tres pantallas, esta disciplina suele bastar y la herramienta de chat sigue siendo el camino más rápido. Alcanza su límite el día que tu producto tiene quince pantallas, permisos distintos según las cuentas y reglas de cálculo que solo tú conoces: ya no puedes mantener en la cabeza la lista de lo que debe quedar intacto.

Lo que fija una prueba escrita antes del código

Una prueba escrita antes de construir es una frase verificable: «un cliente eliminado desaparece de la lista, pero sus facturas siguen siendo consultables». Una vez establecida esa frase, vale para todos los cambios siguientes, incluidos los que pedirás dentro de seis meses. En Maestro, Félix escribe las pruebas de una etapa antes de que Amélie escriba una sola línea, y un cambio que rompe una frase ya establecida se detiene ahí, con el nombre de lo que ha roto. La memoria de lo que debe hacer el producto vive en el documento de requisitos y en esas pruebas, no en tu recuerdo de la conversación de anteayer.

La red inferior: volver a la versión anterior

Aun así, algunas cosas pasarán. La segunda protección consiste en poder volver atrás sin negociar con la herramienta: Maestro conserva una versión de tu producto en cada hito y la línea de tiempo permite recuperar con un clic el estado de anoche, incluidos los documentos. Un cambio se convierte entonces en una apuesta cuyo coste máximo conoces. Esta capacidad falta en varios generadores mediante prompts, donde volver atrás depende de lo que la plataforma haya querido conservar, y es una de las cinco trampas documentadas de la construcción con IA.

En la práctica

Esta noche, toma el último cambio que rompió algo y escribe en una frase qué debería haber quedado intacto. Acabas de escribir tu primera prueba. Haz lo mismo con los tres comportamientos de los que depende tu actividad (el registro, el pago y la exportación de tus datos) y guarda esas frases en un documento que releas antes de cada petición. Un modelo mejor acortará el bucle; no lo abrirá por ti.