Resumo Técnico: CodeTeam

Declaração do Problema

O artigo aborda o desafio de geração de Linguagem Natural para Repositório (NL2Repo): construir um repositório de software inteiro a partir de um documento de requisitos em linguagem natural. Diferente da geração de código ao nível de função (ex: HumanEval), o NL2Repo exige horizontes de planejamento longos, interfaces entre arquivos estáveis e depuração iterativa de inconsistências que só se manifestam durante a integração do sistema.

As abordagens existentes enfrentam três lacunas críticas neste domínio:

1. Falta de Contratos Verificáveis por Máquina: Os métodos anteriores frequentemente carecem de uma especificação formal e legível por máquina da estrutura do repositório antes do início da codificação.
2. Inconsistência Entre Arquivos: Agentes têm dificuldade em manter a consistência de interface entre múltiplos arquivos durante a implementação.
3. Déficits de Coordenação: Os fluxos de trabalho atuais muitas vezes falham em coordenar a implementação de contextos delimitados contra um plano global com escalonamento consciente de dependências e reparo iterativo.

Embora benchmarks como RepoBench e FEA-Bench foquem em conclusão ou mudanças incrementais dentro de bases de código existentes, o cenário NL2Repo (geração do zero) exige design arquitetural, gerenciamento de dependências e empacotamento a partir de um espaço de trabalho vazio.

Metodologia: O Framework CodeTeam

O CodeTeam é um framework multi-agente impulsionado por LLM que separa planejamento, tomada de decisão e implementação em estágios distintos e coordenados. Ele utiliza um Esboço de Design de Software (SDS - Software Design Sketch) como um contrato central verificável por máquina.

1. Estágio de Planejamento: Competição de Arquitetos e Seleção do CTO

• Agentes de Arquitetura: Múltiplos agentes de Arquitetura ($N=4$) elaboram esboços de SDS concorrentes e independentes. Esses esboços definem a stack tecnológica, a estrutura de arquivos, as interfaces públicas e um plano de alocação de desenvolvedores (especificando o tamanho da equipe e a propriedade dos arquivos).
  • Fundamentação RAG: Opcionalmente, os arquitetos recuperam referências de design de um corpus curado de repositórios públicos para fundamentar seus esboços, evitando a convergência de design e a ausência de módulos.
  • Mecanismos de Diversidade: Os arquitetos usam preferências de design aleatórias e recebem apenas resumos de alto nível de candidatos anteriores para garantir soluções diversas.
• Agente CTO: Um agente de Diretor de Tecnologia (CTO) avalia os candidatos com base na validade estrutural, consistência de interface, implementabilidade e adequação à equipe. Ele seleciona o melhor SDS e o normaliza em um contrato canônico e acionável por máquina (formato JSON) que serve como a "única fonte da verdade".

2. Estágio de Implementação: Execução Consciente de Dependências

• Agentes Desenvolvedores: Com base no plano selecionado pelo CTO, agentes Desenvolvedores específicos são instanciados. Cada agente possui um subconjunto específico de arquivos.
• Contexto e Escalonamento: Os desenvolvedores operam sob um escalonador consciente de dependências. Eles recebem um contexto compacto contendo o arquivo alvo, fragmentos relevantes do SDS e breves informações de interface para dependências (assinaturas, invariantes), em vez de conteúdos de arquivos completos.
• Coordenação Baseada em Git: Os agentes trabalham em branches isoladas. Ao concluir um arquivo, eles realizam o commit das alterações com uma mensagem estruturada de update_reason. Isso permite que outros agentes atualizem seus breves de interface sem acessar o conteúdo total dos arquivos, mantendo a consistência entre arquivos.

3. Estágio de Reparo: Iteração Impulsionada por QA

• Agente de QA: Um agente de Garantia de Qualidade (QA) executa testes leves gerados contra as camadas de dependência concluídas.
• Loop de Feedback: Se ocorrerem falhas, o agente de QA diagnostica a causa raiz (ex: incompatibilidade de interface, símbolo ausente) e encaminha a solicitação de reparo para o proprietário específico do arquivo de origem. Arquivos dependentes são recolocados na fila apenas se a mudança de interface se propagar.
• Terminação: O loop continua até que nenhuma falha seja detectada, um limite seja atingido ou os recursos se esgotem.

Principais Contribuições

1. Framework CodeTeam: Um novo sistema multi-agente para NL2Repo que integra competição de SDS, fundamentação RAG opcional, normalização de contrato guiada por CTO, alocação de desenvolvedores específica para o projeto, execução consciente de dependências, coordenação baseada em Git e reparo impulsionado por QA.
2. Avaliação Abrangente: Uma avaliação rigorosa no benchmark SketchEval (comparando variantes de Engenharia de Prompt e Fine-Tuning Supervisionado contra CodeS e outros baselines) e um protocolo de validação externa no NL2Repo-Bench (testes baseados em execução).
3. Insights de Ablação: Análise sistemática demonstrando que a geração com aumento de recuperação (RAG) e a alocação dinâmica de desenvolvedores são os principais drivers de desempenho, enquanto a coordenação baseada em Git fornece estabilidade complementar.

Resultados Experimentais

Desempenho no SketchEval (Similaridade Estrutural)

• Engenharia de Prompt (PE): O CodeTeam alcançou um SketchBLEU geral de 51,7%, superando o baseline mais forte, CodeS (PE), por 4,1 pontos absolutos (8,6% relativo).
• Fine-Tuning Supervisionado (SFT): O CodeTeam alcançou 60,9%, superando o CodeS (SFT) em 2,9 pontos.
• Análise de Subpontuação: As melhorias foram mais pronunciadas em Correspondência Estrutural e Correspondência de Fluxo de Dados, indicando melhor integridade de repositório e consistência entre arquivos em comparação com a sobreposição de tokens de superfície.
• Escalabilidade de Dificuldade: A lacuna de desempenho aumentou significativamente em repositórios Hard (dependências densas), onde o CodeTeam melhorou em 4,7 pontos em relação ao CodeS (PE).

Desempenho no NL2Repo-Bench (Baseado em Execução)

• Taxa de Aprovação (Pass Rate): O CodeTeam alcançou a maior taxa média de aprovação de testes em ambos os cenários: 34,6% (PE) e 42,3% (SFT).
• Análise de Erros: O CodeTeam reduziu significativamente os erros de empacotamento (de 34,2% para 22,1%) e os erros de importação (de 28,7% para 19,4%) em comparação ao CodeS. Isso confirma que o contrato SDS previne efetivamente omissões estruturais (ex: falta de __init__.py ou nomes de pacotes incorretos).
• Mudança nos Modos de Falha: À medida que os erros estruturais diminuíram, a proporção de erros de lógica aumentou, sugerindo que o CodeTeam aborda com sucesso falhas organizacionais, deslocando o gargalo para a correção semântica.

Achados do Estudo de Ablação

• RAG (Geração Aumentada por Recuperação): Remover o RAG causou uma queda relativa de 8,1% no SketchBLEU. Ele melhorou principalmente o estágio de planejamento (sucesso de parse do SDS e validade estrutural) e a diversidade do plano.
• Alocação Dinâmica de Desenvolvedores: Remover este mecanismo causou a maior queda (9,9% relativo). É crítico para alinhar o tamanho da equipe e a propriedade dos arquivos com a estrutura modular do repositório, reduzindo rodadas de QA e incompatibilidades de interface.
• Coordenação Git: Remover isso causou uma queda menor, mas consistente (2,9% relativo), atuando como um mecanismo reativo para estabilizar o desvio de interface durante os reparos.

Significância e Alegações

O artigo afirma que NL2Repo não é meramente uma tarefa de geração de código de contexto longo, mas um processo de engenharia de software coordenado.

• Fluxo de Trabalho sobre Capacidade do Modelo: Os resultados sugerem que fluxos de trabalho multi-agente estruturados (planejamento, especialização de papéis, reparo iterativo) fornecem benefícios mensuráveis mesmo quando o modelo de base é ajustado (fine-tuned). O fluxo de trabalho compensa as limitações de consistência entre arquivos que o prompting puro ou o SFT não conseguem resolver totalmente.
• Contratos Explícitos: O SDS serve como um contrato verificável por máquina que vincula fronteiras de arquivos e dependências, permitindo o roteamento preciso de reparos e evitando o "retrabalho em cascata" comum em sistemas de agente único ou de coordenação frouxa.
• Implantação Prática: O estudo demonstra que investir tokens no planejamento arquitetural inicial (geração de SDS) e na alocação dinâmica reduz o retrabalho subsequente. Também sugere que um número limitado de iterações de QA (2 a 3 rodadas) captura a maioria das melhorias de qualidade, tornando o framework viável para cenários de recursos limitados.

Os autores concluem que o CodeTeam demonstra como a geração de repositórios baseada em LLM pode se tornar mais estruturada, inspecionável e extensível ao tratar os agentes como uma equipe de desenvolvimento coordenada, em vez de geradores de código isolados.