Qué hacer cuando las correcciones de la IA siguen rompiendo su app

Su aplicación funcionaba al principio, y ahora cada cambio que hace su herramienta de IA rompe otra cosa. Antes de la siguiente petición de corrección, guarde un punto de restauración (una versión del proyecto a la que pueda volver) y pruebe un prompt nuevo y más específico. Si el mismo tipo de fallo sigue volviendo, cinco preguntas de sí o no le ayudan a decidir si seguir con los prompts, hacer una pausa y añadir una prueba, o pedir a un ingeniero que lo revise antes del siguiente cambio.

El tutorial de Amir Gabay en freeCodeCamp, publicado el 5 de octubre de 2026 describe el bucle de correcciones de los agentes de programación con IA: algo se rompe en una aplicación creada con un agente, usted le pide al agente que lo corrija y el error sigue ahí o aparece un segundo error. El tutorial afirma que no se trata de una peculiaridad de un solo producto.

La página de buenas prácticas de la documentación de Claude Code dice que, si ha corregido a Claude más de dos veces por el mismo problema en una misma sesión, debería empezar de nuevo con un prompt más específico. Como consejo, un prompt nuevo y más específico es lo primero que conviene probar cuando una corrección no se sostiene. Escríbalo de forma que un desconocido pueda repetir el error: la página, los pasos que lo provocan, lo que esperaba y lo que vio.

Guarde un punto de restauración antes de ese prompt, y antes de cada corrección posterior. En git, la herramienta que conserva el historial de versiones de un proyecto, guardarlo lleva un comando, otro marca lo que cambió la corrección y otros dos lo muestran y lo deshacen. Ejecutamos los cuatro, en este orden, el 29 de octubre de 2026 con git 2.50.1. El proyecto de demostración tenía un carrito que funcionaba en src/cart.js y src/format.js, ya guardado con un commit:

git tag before-fix-1
git add -A
git diff --stat --cached before-fix-1
git restore --source before-fix-1 --staged --worktree .

La primera línea da a la versión actual el nombre before-fix-1. Una petición de corrección de una sola línea cambió después cart.js y format.js y añadió un archivo nuevo, src/tax.js. La segunda línea marca todos los cambios, archivos nuevos incluidos, para el siguiente commit, y la tercera compara esos cambios marcados con el punto de restauración. Listó los tres archivos: "3 files changed, 3 insertions(+), 2 deletions(-)". En una segunda ejecución omitimos git add -A y comparamos con git diff --stat before-fix-1: la lista mostró solo cart.js, y tras deshacer, git status --short seguía mostrando ?? src/tax.js: el archivo nuevo se quedó atrás.

Compare esa lista con lo que pidió. Una petición de una sola línea que toca tres archivos, uno de ellos nuevo, merece una segunda mirada antes de aceptarla. La última línea devolvió el proyecto a su estado anterior: git status --short no mostró nada y el nuevo tax.js desapareció. Dé a cada punto de restauración su propio nombre (before-fix-2, before-fix-3), para poder volver a la última versión que funcionaba. Haga commit de sus propios cambios antes de etiquetar: el último comando devuelve todos los archivos a la versión etiquetada.

Si el mismo tipo de fallo sigue volviendo, use las cinco preguntas de abajo como regla práctica para decidir qué hacer a continuación. Copie esta lista de comprobación en una aplicación de notas o en un documento, responda a cada pregunta con sí o no y cuente los síes.

1. ¿Corregir una cosa rompe algo cercano?
2. ¿Ha vuelto a aparecer un error que ya corrigió?
3. ¿No hay nada, como una prueba automatizada (un script que comprueba una función por usted), que le indique si la aplicación sigue funcionando después de un cambio?
4. ¿Le costaría explicar, en dos frases, qué cambió la herramienta en su última corrección?
5. ¿Dependen ya de la aplicación usuarios reales, dinero o datos personales?

La documentación de Claude Code enumera pruebas, scripts y capturas de pantalla como formas de verificación y dice: «Si no puede verificarlo, no lo publique». La pregunta 3 plantea si existe algo de ese tipo para su aplicación. La pregunta 4 es donde ayuda el punto de restauración. La lista de git diff --stat muestra qué archivos cambió la herramienta desde el punto de restauración, y cuántas líneas.

Qué hacer con la puntuación:

• 0 síes: siga escribiendo prompts y guarde un punto de restauración (una versión a la que pueda volver) antes de cada cambio.
• 1 sí, o 2 síes sin incluir la pregunta 5: haga una pausa. Guarde una copia del proyecto, anote en qué preguntas respondió que sí y pida a la herramienta que escriba una prueba para lo que se acaba de romper antes de que cambie cualquier otra cosa.
• Cualquier otra combinación (3 o más síes, o 2 síes que incluyan la pregunta 5): pida a un ingeniero que lo revise antes del siguiente cambio.

Estas franjas son una regla práctica, no un umbral medido. Dan más peso a la pregunta 5 que a las demás. Cuando la herramienta diga que la prueba nueva pasa, pida ver el comando de la prueba y su salida completa. Compruebe los recuentos de pruebas ejecutadas, que pasaron, que fallaron y omitidas.

Si usuarios reales o dinero ya dependen de la aplicación, lea los controles de seguridad por nivel. Fijan el nivel según quién puede abrir la aplicación, qué datos contiene y si se mueve dinero.

Cuando la puntuación apunte a un ingeniero, entréguele lo que ya tiene, para que nadie empiece adivinando. Empiece con cuatro cosas:

• sus respuestas a las cinco preguntas, con sus fechas;
• las listas de git diff --stat de las últimas correcciones;
• el nombre del último punto de restauración en el que la aplicación aún funcionaba;
• una nota breve de lo que se rompió después de cada corrección, en el orden en que ocurrió.

Nuestra revisión de lanzamiento de 60 minutos traza la misma línea: si no puede explicar qué hace un cambio, es trabajo para un ingeniero.

Siguiente paso

Fuentes

Consultadas el 10 de octubre de 2026: tutorial de Amir Gabay en freeCodeCamp, 5 de octubre de 2026; documentación de Claude Code, página de buenas prácticas, sin fecha visible.