Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository

1. O Problema

A rastreabilidade entre artefatos de software (como propostas de funcionalidades, discussões e código-fonte) é fundamental para a manutenção e compreensão de sistemas. A literatura existente foca predominantemente em propostas aceitas (que resultam em mudanças de código implementadas). No entanto, as propostas rejeitadas (declined proposals) são frequentemente ignoradas, apesar de conterem insights valiosos sobre alternativas de design, decisões de compromisso rejeitadas e critérios implícitos de aceitação.

O desafio central abordado neste trabalho é a recuperação de links de rastreabilidade entre propostas rejeitadas e o código-fonte relevante. Diferente das propostas aceitas, onde o código implementado serve como âncora direta, nas propostas rejeitadas o código discutido não existe no repositório. Isso torna a tarefa de identificar qual parte do código atual seria afetada ou onde a implementação deveria ocorrer extremamente difícil, exigindo inferência semântica sobre a estrutura do projeto e a intenção da discussão.

2. Metodologia

Os autores propõem um pipeline orientado por Modelos de Linguagem de Grande Escala (LLMs) para estabelecer esses links. O estudo foi realizado no repositório oficial da linguagem Go, utilizando um conjunto de dados de propostas (issues) que passaram por um processo rigoroso de revisão.

O pipeline proposto consiste em três fases principais:

• Fase 0: Decisão de Granularidade (Granularity Decision):
  O LLM analisa o texto completo da proposta rejeitada para determinar o nível de granularidade do código ao qual ela se refere. São definidos três níveis:

  1. Diretório: Mudanças na estrutura de pacotes (criar, mover, renomear arquivos/pacotes).
  2. Arquivo: Adições ou modificações dentro de arquivos existentes (novas funções, tipos, constantes).
  3. Função: Modificações na lógica interna ou documentação de funções/métodos específicos.

• Fase 1: Localização (Localization):
  Baseado na granularidade definida na Fase 0, o pipeline executa uma localização hierárquica inspirada na técnica Agentless. O LLM navega pela estrutura do repositório (representada de forma compacta, similar ao comando tree) para identificar os diretórios, arquivos e, se necessário, assinaturas de funções relevantes. Isso substitui métodos tradicionais baseados em recuperação de informação (IR) por embeddings, permitindo um raciocínio contextual sobre a estrutura do projeto.

• Fase 2: Decisão de Link (Link Decision):
  O LLM recebe pares (proposta, elemento de código localizado) e classifica se existe uma relação de relevância (Sim/Não), gerando o link final de rastreabilidade.

Configuração Experimental:

• Modelo: DeepSeek-V3.1 (modo não-pensativo, temperatura 0.0).
• Dados: 341 propostas rejeitadas do Go (após filtragem).
• Avaliação: Métricas de precisão, recall e F1-score, além de uma análise de falhas qualitativa e quantitativa. Um estudo preliminar comparou o pipeline com métodos baseados em RAG (Retrieval-Augmented Generation) em propostas aceitas para validar a abordagem.

3. Principais Contribuições

1. Nova Tarefa de Pesquisa: É o primeiro estudo a focar especificamente na recuperação de links de rastreabilidade entre propostas rejeitadas e código-fonte, tornando o conhecimento tácito de discussões não implementadas acessível.
2. Abordagem Orientada por LLM: Desenho e avaliação de um pipeline que utiliza LLMs para determinar a granularidade e localizar código, superando as limitações de métodos baseados apenas em similaridade textual.
3. Análise de Falhas Detalhada: Uma investigação profunda sobre por que o pipeline falha, identificando padrões específicos nas discussões que dificultam a recuperação de links.
4. Reprodutibilidade: O pacote de replicação completo (dados, prompts, scripts) foi tornado público.

4. Resultados

• Desempenho Geral: O pipeline alcançou uma acurácia de 0,836 na seleção correta da granularidade do código e uma precisão média de 0,643 na geração de links corretos.
• Desempenho por Granularidade:
  • Arquivo: Melhor desempenho (Acurácia: 0,887; Precisão: 0,688).
  • Diretório: Desempenho moderado (Acurácia: 0,696; Precisão: 0,529).
  • Função: Desempenho mais baixo (Acurácia: 0,407; Precisão: 0,253). A dificuldade em prever a granularidade correta no nível de função impactou diretamente a precisão dos links.
• Comparação com Baseline: Em um estudo preliminar com propostas aceitas, o pipeline baseado em LLM superou consistentemente métodos baseados em RAG (embeddings) em termos de F1-score e precisão.
• Análise de Falhas (RQ2):
  • A falha não está correlacionada com o comprimento da discussão.
  • Fator Crítico 1 (Granularidade Correta): Quando a granularidade é correta, a precisão depende da explicitação da referência ao código. Referências diretas (ex: nome do arquivo) levam a alta precisão (0,841), enquanto referências implícitas caem para 0,408.
  • Fator Crítico 2 (Falha na Granularidade): As principais causas de erro na seleção de granularidade foram:
    1. Orientação de Implementação Insuficiente (42,9% dos casos): A discussão diz "o que" fazer, mas não "como" ou "onde".
    2. Sugestões de Implementação Conflitantes.
    3. Orientação Oculta: Informações chave escondidas em discussões longas.

5. Significado e Implicações

Este trabalho demonstra que é viável automatizar a recuperação de conhecimento de discussões de software que não resultaram em código, o que é crucial para:

• Evitar a repetição de erros: Desenvolvedores podem consultar por que uma ideia foi rejeitada anteriormente.
• Racionalização de Design: Manter o histórico de decisões de design, mesmo as negativas, enriquece a documentação do projeto.
• Melhoria de Ferramentas de MSR (Mining Software Repositories): Sugere que futuros sistemas de recuperação de rastreabilidade devem incorporar etapas de decisão de granularidade e processamento semântico profundo (LLMs) em vez de depender apenas de similaridade de texto.

O estudo aponta que para melhorar a eficácia, futuras ferramentas devem focar em enriquecer o contexto das propostas (adicionando propostas relacionadas ou comentários de código) e em resumir discussões para destacar informações críticas de implementação, mitigando o ruído causado por discussões longas e ambíguas.