Framework IBM Classifica Mudanças de Código com 84% de Recall

A IBM Research publicou um framework para rotular mudanças de código em hunks de diff. O paper no arXiv "Beyond Summaries: Structure-Aware Labeling of Code Changes with Large Language Models" avalia quatro LLMs em um benchmark curado manualmente, relatando 84% de recall e 81% de precisão.

O pipeline funciona em dois estágios. Primeiro, o modelo atribui um rótulo a cada hunk: renomeação, movimentação, modificação de lógica, refatoração ou mudança estrutural. Segundo, uma passagem de refinamento captura relações entre hunks: propagação de renomeação entre arquivos e mudanças de tipo. A abordagem usa few-shot prompting sem infraestrutura de análise estática, tornando-a portável em monorepos poliglotas.

Quatro LLMs atingiram 84% de recall e 81% de precisão em patches naturais e sintéticos. Extração de metadados relacionais alcançou alta precisão; atributos cross-hunk como propagação de renomeação provaram ser mais difíceis de avaliar objetivamente.

O valor operacional é o roteamento de revisão. Nem todo patch necessita revisão manual: diffs de propagação de renomeação procedem para aprovação automatizada; hunks de modificação de lógica sinalizam para revisão. Um estudo de 15.451 instâncias de refatoração geradas por agente IA em 12.256 pull requests em projetos Java open-source encontrou que a saída do agente foi dominada por edições de baixo nível: Change Variable Type (11,8%), Rename Parameter (10,4%) e Rename Variable (8,5%) representam 30,7% de todas as instâncias. Estas carregam baixo risco. Erros de lógica em código gerado por IA aparecem 1,75 vezes mais frequentemente do que em código escrito por humanos. Rotular separa renomeações de mudanças de lógica, abordando a lacuna entre volume e risco real.

Os bots de revisão de PR atuais perdem essa distinção. Ferramentas como PR-Review alcançam F1 scores acima de 21% para mudanças de lógica mas apenas 16,45% para mudanças organizacionais — onde os próprios revisores humanos discordam mais. Sem contexto de tipo de mudança, as ferramentas tratam código legado intencionalmente estruturado como equivalente a código desordenado. Os revisores carecem de sinais sobre a intenção autoral.

Limites de contexto permanecem abertos. Propagação de renomeação em codebases grandes dispersa hunks em dezenas de arquivos. O pipeline de dois estágios lida com isso parcialmente; precisão e recall em diffs com 200+ hunks não são caracterizados.

Para equipes de engenharia implantando ferramentas de código assistidas por LLM, essa abordagem de rotulação é infraestrutura fundamental. O design de few-shot se integra em endpoints de CI, mas as equipes devem definir taxonomia de rótulos e construir regras de roteamento. As figuras de 84%/81% suportam automação da faixa de renomeação hoje; trate rótulos de modificação de lógica como sinal de triagem, não veredicto final.