Conduzir uma refatoração em grande escala

Migrar sessenta chamadas de uma antiga API interna para a nova é exatamente o tipo de tarefa em que um agente é imbatível: mecânica, repetitiva, sem nenhuma decisão a tomar. É também o tipo de tarefa que produz o pior resultado possível quando é lançada de uma só vez. Você recebe um diff de 1.400 linhas tocando sessenta e dois arquivos, a suíte de testes exibe onze falhas, e você não tem como saber se essas onze falhas vêm de um erro sistemático repetido sessenta vezes ou de três casos particulares legítimos. O diff é grande demais para ser revisado, entrelaçado demais para ser parcialmente desfeito e demorado demais para ser regenerado e descartado sem dor.

O problema não é a capacidade do agente, é a granularidade da verificação. Em uma refatoração, a pergunta que você deve poder responder a qualquer momento é: "o repositório ainda está consistente?". Um diff monolítico só permite responder uma vez, no final, quando todos os erros estão misturados. O método consiste, portanto, em impor uma sequência de etapas em que cada uma seja commitável isoladamente, verificável isoladamente e reversível isoladamente — e em fazer dessa sequência uma restrição do prompt, não uma esperança.