Pilotar una refactorización a gran escala

Migrar sesenta llamadas de una antigua API interna a la nueva es exactamente el tipo de tarea en la que un agente es imbatible: mecánica, repetitiva, sin decisiones que tomar. Es también el tipo de tarea que produce el peor resultado posible cuando se lanza de golpe. Recibe un diff de 1400 líneas que toca sesenta y dos archivos, la suite de tests muestra once fallos y no tiene forma de saber si esos once fallos proceden de un error sistemático repetido sesenta veces o de tres casos particulares legítimos. El diff es demasiado grande para revisarlo, está demasiado entrelazado para deshacerlo parcialmente y es demasiado largo de regenerar para descartarlo sin dolor.

El problema no es la capacidad del agente, sino la granularidad de la verificación. En una refactorización, la pregunta a la que debe poder responder en todo momento es: «¿sigue siendo coherente el repositorio?». Un diff monolítico solo permite responder una vez, al final, cuando todos los errores están mezclados. El método consiste, por tanto, en imponer una secuencia de etapas en las que cada una se pueda commitear por separado, verificar por separado y deshacer por separado, y en convertir esa secuencia en una restricción del prompt, no en una esperanza.