Cuando el agente rompe lo que ya funcionaba

De todo lo que me ha pasado programando con agentes, lo que más horas me ha comido no es que el agente escriba mal lo nuevo. Es que, al arreglar una cosa, rompa otra que ya funcionaba. Aquí cuento cómo me pasó con una aplicación web pequeña, cómo acabé una tarde entera persiguiendo el mismo fallo en círculo y qué hago ahora para que no vuelva a pasar.

Estaba construyendo con Claude Code una aplicación de avisos: los clientes abren incidencias, adjuntan capturas y reciben un correo cuando algo cambia; el técnico lo ve y lo gestiona todo. La programa Claude Code; yo decido, reviso cada cambio y pruebo. Tenía ya en marcha las cuentas, los usuarios y los avisos, y me tocaba la parte de comentarios, adjuntos y correos.

Revisaba lo nuevo con cuidado, en cambios pequeños y leyendo las diferencias, no el resumen del agente. Así que lo nuevo entraba bien. El problema que vino no estaba en lo nuevo, sino en lo viejo.

La promesa es la más cómoda de todas: «si algo falla, se lo dices y lo arregla». Y es verdad que lo arregla. Le describes el fallo en lenguaje normal, «cuando adjunto una captura de más de un mega no se guarda», y a los pocos minutos el fallo ha desaparecido.

Lo que no dice la promesa es qué más ha cambiado para que desaparezca.

Durante un par de semanas trabajé con un método que parecía razonable: probaba la parte nueva, encontraba un fallo, se lo describía al agente, revisaba sus cambios, comprobaba que el fallo había desaparecido y seguía. Lo que no hacía era volver a probar todo lo demás. Eran unas cuarenta cosas que comprobar a mano entre pantallas, usuarios y estados, y no iba a repasarlas cada vez que tocaba una coma.

El ejemplo más retorcido de aquellos días:

• Le pedí que los adjuntos grandes se redujeran de tamaño al subirlos. Lo hizo, y funcionaba.
• Dos días después me di cuenta de que ya no llegaban los correos de aviso cuando el cliente adjuntaba una captura: el cambio en los adjuntos había tocado la función que preparaba el correo.
• Le pedí que arreglara los correos. Lo hizo, y funcionaban. Pero para arreglarlo cambió cómo se guardaba el estado del aviso al crearse, y los avisos nuevos empezaron a salir como «cerrados».
• Le pedí que arreglara los estados. Lo hizo, y los estados volvieron a estar bien. Y los adjuntos grandes volvieron a no guardarse.

Vuelta al principio. Cada arreglo, por separado, era correcto: resolvía exactamente lo que yo le había pedido. El problema es que nadie miraba lo que no le había pedido.

Un domingo me pasé una tarde entera, unas cuatro horas, dando vueltas a ese círculo. Tenía algo de hipnótico: el agente, muy educado, reconocía el problema, proponía una solución, la aplicaba, y yo probaba justo lo que había fallado. Bien. Siguiente.

Lo que pasaba por debajo tiene nombre en programación: una regresión, que es cuando un cambio hace que vuelva a fallar algo que ya funcionaba. No es exclusivo de los agentes; le pasa a cualquier programador. Pero el agente lo acelera, porque cambia mucho y muy rápido, y porque cuando le pides un arreglo tiende a buscar el camino más corto hasta que desaparezca ese síntoma concreto. A veces ese camino atraviesa el jardín del vecino.

Además, a esas alturas la conversación era larguísima. El agente llevaba horas de historial y empezaba a olvidar decisiones del principio de la tarde. Es el problema del contexto que conté en los problemas de trabajar con agentes: cuanto más larga la sesión, más se diluye lo importante.

A las ocho de la tarde cerré con tres fallos abiertos, uno más de los que tenía al empezar. De todos los problemas de los agentes que me he encontrado, este es el que más desmoraliza, porque parece que avanzas.

Al día siguiente cambié tres cosas. Ninguna es un truco; son las de siempre, las que los programadores llevan décadas usando.

Pruebas automáticas mínimas. Una prueba automática es un pequeño programa que comprueba que otra parte del programa hace lo que debe: «si un cliente adjunta una captura de dos megas, se guarda», «si se crea un aviso, su estado es abierto», «si un usuario pide el aviso de otro, no lo ve». Se ejecutan todas con una orden y en segundos te dicen qué ha dejado de funcionar.

Le pedí al agente que escribiera pruebas para todo lo que ya funcionaba, empezando por lo que se había roto alguna vez y por los permisos. Las reviso con más cuidado que el propio código, por una razón: una prueba mal hecha te da una tranquilidad falsa. En la primera tanda encontré dos pruebas que comprobaban algo que siempre era verdad, pasara lo que pasara. A las dos semanas tenía 23 pruebas que se ejecutan en unos diez segundos. Cómo se hacen los tests con IA sin que te engañen lo cuento en Pruebas automáticas escritas por la inteligencia artificial.

La regla nueva: el agente ejecuta todas las pruebas antes de darme por terminado un cambio, y yo no acepto nada si alguna falla. Y cuando aparece un fallo nuevo, antes de arreglarlo, se escribe una prueba que lo reproduzca. Así ese fallo ya no puede volver sin que me entere.

Cambios guardados en pasos pequeños. Cada paquete de cambios que se guarda en el historial del repositorio se llama commit. Antes el agente guardaba uno al terminar cada tarea, que a veces eran horas de trabajo. Ahora guarda uno por cada arreglo o cada paso que funciona, con las pruebas en verde. Cuando algo se rompe, sé qué paso lo rompió.

Volver atrás sin pena. Esta me costó más en lo emocional que en lo técnico. Cuando un arreglo empieza a enredarse, en vez de pedir un arreglo del arreglo, vuelvo a la última versión que funcionaba y lo intento de otra forma, con una sesión nueva y una explicación más clara. En esas dos semanas volví atrás cinco veces. Cada vez sentía que tiraba trabajo. Cada vez, el segundo intento salió mejor y más rápido que seguir parcheando.

Con las tres cosas juntas, el famoso círculo de adjuntos, correos y estados se resolvió en poco más de una hora. Las pruebas enseñaron que los tres fallos venían del mismo sitio: una función que el agente había ido retocando para cada síntoma y que ya no hacía bien ninguna de sus tres cosas. Volví a la versión anterior a esos cambios y le pedí que la separara en tres.

Lo que empezó como un apaño es ya una costumbre con cualquier agente de programación:

1. Antes de pedir el primer arreglo, que haya al menos una prueba para lo que no puede romperse nunca.
2. Cada fallo nuevo, primero una prueba que lo reproduzca y luego el arreglo.
3. Un commit por cada paso que funciona.
4. Si el tercer arreglo del mismo fallo no lo resuelve, volver atrás y empezar esa parte con una sesión limpia.
5. Sesiones cortas: cuando la conversación se hace larga, la cierro y empiezo otra con el resumen de lo decidido.

«Pídele el arreglo y listo» es verdad para el fallo que le pides. Para el resto del programa es humo, salvo que tengas algo que vigile el resto por ti. Y ese algo no es el agente: son las pruebas.

Lo que me costó: de las 21 horas de aquellas dos semanas, 10 se fueron en depurar, 6 en revisar y solo 5 en pedir cosas nuevas. La mitad del tiempo, arreglando. Unas seis de esas horas me las habría ahorrado con pruebas desde el principio.

Lo que gané: desde que las tengo, las pruebas han cazado nueve fallos antes de que yo los viera en pantalla. Si tienes un proyecto hecho a base de pedir y aceptar, date una tarde para escribirle pruebas antes de pedirle nada más. Es la tarde mejor invertida que conozco.