Modernizar um sistema legado parece uma tarefa ideal para IA: trocar padrões antigos, atualizar tipos e deixar o código mais legível. O risco aparece quando a mudança melhora a aparência e altera o contrato que usuários, integrações e rotinas já dependiam.
100 arquivos, cinco modelos e 630 verificações ocultas
Os pesquisadores selecionaram intencionalmente 100 dos 482 arquivos PHP do WordPress 4.0, distribuídos por quatro faixas de tamanho e escolhidos para cobrir os 48 tipos de regra identificados. Cinco modelos receberam um arquivo completo por vez e a instrução de migrá-lo para PHP 8.3 preservando entradas, saídas, efeitos colaterais e compatibilidade de chamadas. Não receberam contexto do repositório, testes, erros nem feedback de execução [1][2].
Cada saída foi avaliada com 630 checks ocultos e 511 achados de modernização detectados pelo Rector. Havia duas referências: o arquivo original sem alteração e o próprio Rector, uma ferramenta determinística baseada em regras. O desenho mede a primeira resposta de um assistente em cenário de arquivo único; não mede um agente iterativo trabalhando no repositório completo [1][2].
O melhor modelo terminou abaixo da opção de não mudar
Dos 100 arquivos originais, 83 passavam em todos os checks. O melhor modelo deixou 59 compatíveis. Entre os cinco modelos, 32 a 51 arquivos que funcionavam foram quebrados, enquanto no máximo 10 arquivos incompatíveis foram reparados. O Rector quebrou 7 e reparou 6, terminando com 82 arquivos compatíveis [1][2].
A comparação importante não é IA contra ferramenta tradicional em qualquer projeto. É a presença de um baseline explícito: quando 83 arquivos já funcionam, uma transformação precisa provar que o valor da mudança compensa o risco criado. Sem essa referência, a equipe pode confundir volume de edição com progresso.
Só 37 dos 511 achados exigiam mudança para PHP 8.3
O paper classifica 37 achados como obrigatórios, 85 como depreciações e 389 como opcionais. Nos arquivos compatíveis que não continham mudança obrigatória, os modelos quebraram de 36% a 60%; o Rector, 8%. Parte relevante das regressões veio de arquivos que deixaram de carregar, muitas vezes por declarações de tipo rejeitadas pelo próprio PHP [1][2].
Isso não significa que modernização seja inútil. Dezesseis dos 26 arquivos com achados obrigatórios já falhavam sem mudança, e os modelos repararam alguns. A conclusão mais defensável é operacional: modernização, preservação e reparo são métricas diferentes e precisam aparecer separadas.
Um contrato de modernização que não premia mudança por si só
- Defina o comportamento que precisa permanecer antes de escolher a transformação.
- Classifique mudanças como obrigatórias, deprecações ou opcionais; não trate todas como dívida equivalente.
- Execute o original e o candidato sobre a mesma suíte e registre regressões, reparos e casos inconclusivos.
- Use lint e checagens estáticas como gates iniciais, sem confundi-los com equivalência de comportamento.
- Dê ao agente contexto de dependências e feedback de execução quando o trabalho real permitir.
- Promova apenas os bytes avaliados, com rollback e observabilidade proporcionais à criticidade.
Limites, conflito de interesse e contraponto
- A amostra é proposital, favorece arquivos ricos em padrões e cobre um único projeto legado e um único alvo de runtime.
- O cenário é de arquivo único, sem contexto do repositório ou feedback de execução; um fluxo agentic iterativo pode obter outro resultado.
- Houve uma geração por modelo e arquivo, portanto a variabilidade entre execuções não foi medida.
- Os checks foram escritos antes das saídas e o segundo autor revisou análises sem saber qual modelo produziu cada resultado, mas isso não equivale a replicação independente.
- O paper é um preprint recente, ainda sem revisão por pares indicada no registro. Os autores disponibilizam o pacote de replicação no Zenodo [3].
- Não identificamos conflito comercial direto declarado; as afiliações acadêmicas e profissionais permanecem as informadas pelos autores.
A regra prática: preserve primeiro, modernize com propósito
Legado não é sinônimo de erro. Parte dele é conhecimento operacional codificado em comportamentos que ninguém documentou por completo. A IA pode acelerar a leitura e a transformação, mas a aprovação precisa recompensar resultado preservado — não apenas um diff que parece mais atual.
Nota editorial e de responsabilidade
Números, população, método, modelos, limites e disponibilidade do pacote de replicação foram atribuídos às fontes diretas. O artigo separa resultados reportados pelos pesquisadores de interpretação editorial e recomendações profissionais. Pontos de vista pessoais e profissionais do autor não são fatos universais nem garantia de resultado. O conteúdo é informativo e não substitui avaliação técnica, jurídica, regulatória, financeira ou de segurança. Autores, WordPress, PHP, Rector, modelos e instituições citados pertencem aos respectivos titulares; não há patrocínio ou endosso. Tech Human e Trustyu atuam comercialmente em desenvolvimento e governança de produtos digitais. Pesquisa, estrutura e redação tiveram assistência de IA; Fernando Parreiras autorizou a pauta, a auto-revisão factual e a publicação em 31/10/2026, sem revisão humana independente adicional. O paper permanece em acompanhamento e o artigo poderá receber correções se houver nova versão, revisão por pares, contestação ou replicação relevante.