SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

O artigo apresenta o SWE-CI, o primeiro benchmark em nível de repositório baseado no ciclo de Integração Contínua, que avalia a capacidade de agentes de LLM em manter a qualidade do código ao longo de evoluções complexas e de longo prazo, superando as limitações das abordagens estáticas de correção única.

O essencial

Imagine que você está construindo uma casa.

A maioria dos testes de inteligência artificial (IA) para programação hoje em dia funciona assim: você entrega um plano de uma sala de estar e pede para a IA construir apenas essa sala. Se a sala ficar bonita e as portas abrirem, a IA passa no teste. Isso é como os benchmarks atuais (como o SWE-bench): eles olham para um "instantâneo" (uma foto) do trabalho.

Mas a vida real não é assim. Na vida real, você constrói a sala, depois decide mudar a cozinha, depois precisa instalar um sistema de segurança, e anos depois, a família cresce e você precisa adicionar um segundo andar. O problema é que, se a IA construiu a sala de estar de um jeito frágil e mal planejado, adicionar o segundo andar pode fazer a casa inteira desmoronar.

O que é o SWE-CI?

Os autores deste paper criaram o SWE-CI, que é como um "simulador de vida real" para IAs de programação. Em vez de pedir para a IA construir apenas uma sala, eles dizem: "Aqui está uma casa que existe há 233 dias. Ela passou por 71 reformas. Sua tarefa é continuar reformando essa casa por mais um tempo, mantendo tudo funcionando, sem derrubar o telhado".

Aqui estão os conceitos principais, explicados de forma simples:

1. O Problema: A Ilusão da "Reparação Rápida"

Imagine um mecânico de carros.

• O teste antigo: O carro não liga. O mecânico dá um tapa no painel e o carro liga. Teste aprovado!
• O problema: O mecânico usou fita adesiva e pregos. Daqui a uma semana, o carro quebra de novo, e dessa vez é pior.
• A realidade: Um bom mecânico (ou um bom programador) não apenas faz o carro ligar agora; ele conserta o motor de forma que ele continue funcionando daqui a 6 meses, mesmo com novas peças sendo adicionadas.

O SWE-CI quer testar se a IA é um "mecânico de fita adesiva" ou um "engenheiro de verdade".

2. A Solução: O Ciclo de "Construção Contínua"

O SWE-CI não deixa a IA trabalhar sozinha de uma vez só. Eles criaram um sistema de dois agentes (dois robôs trabalhando juntos), como se fosse uma equipe de arquitetura e construção:

• O Arquiteto (Architect): Ele olha para a casa, vê o que falta (ex: "precisamos de uma janela maior") e escreve um plano de alto nível. Ele não mexe nos tijolos, ele apenas diz o que precisa ser feito.
• O Programador (Programmer): Ele pega o plano do Arquiteto e começa a construir. Ele coloca os tijolos, pinta a parede e instala a janela.

Depois que o Programador termina, eles testam. Se algo quebrar, o Arquiteto analisa o erro, faz um novo plano e o Programador tenta de novo. Eles fazem isso em várias rodadas (como um ciclo de "Construção Contínua" ou Continuous Integration), simulando meses de trabalho real.

3. A Pontuação: "EvoScore" (Pontuação de Evolução)

Como eles sabem se a IA é boa? Eles não olham apenas se o código funciona no final. Eles olham para como a IA construiu.

• Se a IA faz um conserto rápido que quebra tudo na próxima rodada, ela perde pontos.
• Se a IA faz um trabalho limpo que facilita as próximas reformas, ela ganha pontos extras.

É como se você avaliasse um aluno não apenas pela nota da prova de hoje, mas por quão fácil é para ele aprender a matéria do ano que vem. Se ele estudou "decoreba", ele vai falhar no futuro. Se ele entendeu a lógica, ele vai brilhar.

4. O Que Eles Descobriram?

Eles testaram 18 IAs diferentes e descobriram coisas interessantes:

1. Elas estão melhorando: As IAs mais novas estão ficando muito boas em manter códigos por longos períodos, muito melhor que as antigas.
2. Elas têm "personalidades" diferentes: Algumas IAs (como as da Anthropic/Claude) são mais cuidadosas e pensam no longo prazo. Outras (como algumas da Kimi ou GLM) tendem a ser mais rápidas, mas cometem mais erros que quebram o código no futuro (como usar a fita adesiva).
3. O maior desafio é o "Efeito Dominó": O maior problema das IAs hoje é o regressão. Isso significa que, ao tentar consertar uma coisa nova, elas quebram algo que já funcionava. Em testes de longo prazo, a maioria das IAs falha em evitar isso. É como tentar adicionar uma nova janela e, sem querer, fazer a parede inteira desabar.

Resumo Final

O SWE-CI é um novo "campo de provas" que diz: "Não basta fazer o código funcionar agora. Mostre-me que você consegue cuidar desse código por meses, fazendo mudanças constantes sem estragar nada".

É a diferença entre um consertador de emergência e um engenheiro de software sênior. O paper mostra que as IAs estão evoluindo rápido, mas ainda precisam aprender a pensar no futuro antes de colocar o primeiro tijolo.

Resumo técnico

Resumo Técnico: SWE-CI

1. O Problema

Os agentes impulsionados por Grandes Modelos de Linguagem (LLMs) demonstraram capacidades notáveis em tarefas de engenharia de software automatizadas, como a correção de bugs estáticos (ex: benchmarks SWE-bench). No entanto, existe uma lacuna fundamental entre esses benchmarks e a realidade do desenvolvimento de software:

• Paradigma Estático vs. Evolução Real: A maioria dos benchmarks atuais utiliza um protocolo de "instantâneo" (snapshot), onde o agente recebe um requisito único e produz uma solução de uma só vez (one-shot).
• Invisibilidade da Manutenibilidade: Nesse modelo, uma correção frágil e hardcoded pode passar nos testes da mesma forma que um código limpo e extensível. A diferença na qualidade de manutenção só se torna visível quando o código precisa evoluir com novos requisitos, mudanças de interface e iterações de longo prazo.
• Custo da Manutenção: A literatura estabelece que atividades de manutenção representam 60% a 80% do custo total do ciclo de vida do software. Atualmente, não existem benchmarks robustos que avaliem a capacidade dos agentes de sustentar a qualidade do código ao longo de evoluções complexas e contínuas.

2. Metodologia

O paper propõe o SWE-CI (SoftWare Engineering – Continuous Integration), o primeiro benchmark em nível de repositório baseado no ciclo de Integração Contínua (CI).

A. Formalização da Tarefa (Paradigma Baseado em Evolução)
Diferente dos benchmarks tradicionais que mapeam Base -> Requisito -> Solução, o SWE-CI adota um loop iterativo:

1. Requisito Dinâmico: O requisito ($r_i$) é gerado dinamicamente com base na lacuna funcional entre o códigobase atual ($c_i$) e o códigobase alvo/ôráculo ($c^*$).
2. Loop de Evolução: O agente modifica o código ($c_{i+1} = code(c_i, r_i)$), e o processo se repete. Isso permite que as consequências de decisões anteriores se acumulem, tornando a qualidade da tomada de decisão de longo prazo observável.

B. Métricas de Avaliação

• Normalized Change ($a(c)$): Uma métrica granular que mede o progresso em relação à base e ao alvo.
  • Se o agente melhora a base, a pontuação é normalizada pela lacuna total até o alvo.
  • Se o agente causa regressão (quebra testes que passavam antes), a pontuação é normalizada negativamente em relação à base.
  • A escala varia de -1 (pior regressão) a 1 (solução completa).
• EvoScore (Evolution Score): Uma métrica agregada que calcula a média ponderada dos Normalized Changes ao longo das iterações.
  • Utiliza um fator de peso $\gamma \ge 1$ para dar maior importância às iterações posteriores.
  • Lógica: Um código verdadeiramente manutenível é aquele que permanece fácil de modificar à medida que a evolução avança. O EvoScore recompensa agentes que evitam "dívida técnica" e puna aqueles que obtêm ganhos rápidos, mas acumulam problemas que dificultam modificações futuras.

C. Protocolo de Avaliação Dual-Agente
Para simular equipes de software reais, o SWE-CI utiliza dois agentes colaborando em um loop de CI:

1. Agente Arquiteto: Analisa os testes falhos, identifica causas raízes e gera um documento de requisitos de alto nível (focado em comportamento esperado, não implementação).
2. Agente Programador: Implementa as mudanças baseadas nos requisitos do Arquiteto, seguindo um ciclo de compreensão, planejamento e codificação.

• O objetivo final é passar em todos os testes associados ao commit alvo após múltiplas rodadas de iteração.

D. Curadoria de Dados
O dataset consiste em 100 tarefas extraídas de repositórios Python reais do GitHub.

• Critérios: Repositórios com >3 anos de manutenção, >500 estrelas, licenças permissivas e testes unitários.
• Estrutura: Cada tarefa conecta um commit base a um commit alvo (ôráculo), cobrindo em média 233 dias e 71 commits consecutivos de história evolutiva real.
• Ambiente: Cada amostra inclui um ambiente Docker pré-construído para garantir reprodutibilidade.

3. Contribuições Principais

1. Mudança de Paradigma: Transição da avaliação de correção funcional estática para a avaliação de manutenibilidade dinâmica e de longo prazo.
2. SWE-CI Benchmark: A criação do primeiro conjunto de dados em nível de repositório focado no ciclo de CI, com tarefas complexas que exigem dezenas de rodadas de análise e codificação.
3. Métrica EvoScore: Introdução de uma métrica sensível ao tempo que penaliza a acumulação de dívida técnica e recompensa designs que facilitam futuras evoluções.
4. Protocolo Dual-Agente: Um framework de avaliação que separa a definição de requisitos da implementação, mimetizando fluxos de trabalho profissionais de CI.

4. Resultados Experimentais

Os autores realizaram experimentos com 18 modelos de diferentes provedores, consumindo mais de 10 bilhões de tokens.

• Progresso Acelerado: Modelos mais novos (pós-2026) mostram ganhos significativos em relação aos predecessores, indicando uma evolução rápida das capacidades de manutenção de código. A série Claude Opus liderou consistentemente.
• Viés de Provedor: Diferentes provedores têm estratégias de treinamento distintas.
  • Modelos como MiniMax, DeepSeek e GPT tendem a priorizar ganhos de longo prazo (alta EvoScore com $\gamma > 1$).
  • Modelos como Kimi e GLM tendem a focar em retornos de curto prazo.
• Desafio das Regressões: A maioria dos modelos falha em evitar regressões em cenários de manutenção de longo prazo.
  • A taxa de "zero-regressão" (nenhum teste quebrado durante todo o processo) foi inferior a 0,25 para a maioria dos modelos.
  • Apenas dois modelos da série Claude Opus superaram a taxa de 0,5.
  • Conclusão: Embora os LLMs sejam bons em correções pontuais, eles ainda lutam para manter a estabilidade do código em desenvolvimento contínuo e multi-rodada.

5. Significado e Impacto

O SWE-CI preenche uma lacuna crítica na avaliação de IA para engenharia de software. Ao focar na manutenibilidade e não apenas na correção funcional, o benchmark oferece um diagnóstico mais realista sobre a prontidão dos agentes de IA para tarefas industriais complexas.

Os resultados indicam que, embora haja progresso, os modelos atuais ainda não são totalmente confiáveis para substituir desenvolvedores humanos em ciclos de desenvolvimento contínuo de longo prazo, principalmente devido à dificuldade em gerenciar a estabilidade do código e evitar a degradação da qualidade ao longo do tempo. O SWE-CI estabelece uma nova direção para o desenvolvimento de agentes de IA capazes de "pensar" a longo prazo e gerenciar dívida técnica.