Project Prometheus: Bridging the Intent Gap in Agentic Program Repair via Reverse-Engineered Executable Specifications

Título do Projeto

Project Prometheus: Preenchendo a Lacuna de Intenção na Reparação de Programas Agêntica via Especificações Executáveis Reversas

1. O Problema: A "Lacuna de Intenção" (Intent Gap)

O campo de Reparação Automática de Programas (APR) evoluiu de traduções neurais de máquina para fluxos de trabalho agênticos (multi-estágio). No entanto, os agentes atuais, apesar de suas capacidades avançadas de raciocínio, sofrem de uma falha fundamental: a Lacuna de Intenção.

• Definição: É o desalinhamento entre o patch gerado pelo agente e a intenção original do desenvolvedor.
• Causa: Soluções atuais dependem de resumos em linguagem natural ou amostragem adversarial. Essas abordagens são descritivas, não prescritivas. Elas introduzem ambiguidade, levando os agentes a "adivinhar" condições de contorno ou a realizar modificações estruturais invasivas e desenfreadas (comportamento do tipo "Berserker").
• Consequência: Os agentes tendem a gerar correções sintaticamente corretas, mas semanticamente erradas, ou a reescrever funcionalidades inteiras desnecessariamente para satisfazer uma interpretação vaga do problema.

2. Metodologia: O Framework Prometheus

O Prometheus propõe uma mudança de paradigma: priorizar a Inferência de Especificação antes da geração de código. Em vez de pedir ao LLM para "consertar o bug", o sistema primeiro pede para "reversar a especificação ausente".

O framework utiliza uma arquitetura de três agentes especializados:

A. O Arquiteto (Spec Inference)

• Função: Realiza a inferência de intenção reversa a partir de relatórios de falha em tempo de execução (stack traces, logs).
• Técnica: Utiliza Desenvolvimento Orientado a Comportamento (BDD) e a sintaxe Gherkin (Given-When-Then) como contrato executável.
• Processo: O agente analisa a causa raiz e sintetiza um cenário estruturado que define o comportamento esperado, transformando o erro de execução em um contrato semântico determinístico.

B. O Engenheiro (RQA Loop - Garantia de Qualidade de Requisitos)

• Função: Valida a especificação gerada pelo Arquiteto.
• Mecanismo (Sanduíche de Verificação):
  1. Verificação Negativa: A especificação Gherkin deve falhar no código defeituoso ($C_{buggy}$).
  2. Verificação Positiva: A especificação Gherkin deve passar no código corrigido pelo desenvolvedor ($C_{fixed}$), que atua como um "Oráculo de Verdade" (Proxy Oracle) no ambiente experimental.
• Objetivo: Garantir que a especificação capturou corretamente a intenção do desenvolvedor antes que qualquer código seja gerado. Se falhar, a especificação é regenerada.

C. O Reparador (Enlightened Repair)

• Função: Executa a modificação do código.
• Diferencial: Opera em um modo "Iluminado", condicionado à especificação BDD validada.
• Estratégia: Em vez de uma busca cega, o agente realiza uma "reparação cirúrgica", focando em correções mínimas e precisas que satisfazem estritamente o contrato semântico, evitando refatorações desnecessárias.

3. Contribuições Principais

1. Framework Prometheus: Uma arquitetura multi-agente que integra engenharia reversa de especificações BDD no ciclo de reparo.
2. Método RQA (Requirement Quality Assurance): Um mecanismo inovador que utiliza o código de referência (ground truth) como oráculo para validar a qualidade das especificações inferidas, isolando o impacto da precisão da intenção.
3. Evidência Empírica: Demonstração de que a precisão da especificação é mais crítica do que o tamanho do modelo para reparos complexos.
4. Comparação com SOTA: Validação quantitativa contra ferramentas de reparo agêntico de ponta (TSAPR, RepairAgent).

4. Resultados Experimentais

O framework foi avaliado em 680 defeitos reais do benchmark Defects4J v3.0.1 (16 projetos Java).

• Taxa de Correção Total: 93,97% (639/680 defeitos corrigidos corretamente).
• Taxa de Resgate (Rescue Rate): 74,4%. O framework conseguiu reparar 119 bugs complexos que um agente forte "cego" (sem especificação) falhou em resolver.
• Comparação com SOTA: Nos 160 bugs difíceis onde o agente cego falhou, o Prometheus recuperou 119, superando o TSAPR (22) e o RepairAgent (27) em 4,4 vezes.
• Análise Qualitativa:
  • Redução de Alucinação: Especificações explícitas impediram agentes de criar variáveis inexistentes ou lógica incorreta.
  • Prevenção de "Berserker": Evitou reescritas agressivas de código, focando em correções mínimas.
  • Superação do Ground Truth: Em alguns casos (ex: JxPath-6), o agente guiado por BDD produziu correções mais robustas (tratando arrays) do que a correção original do desenvolvedor (que tratava apenas Collections).

5. Significado e Conclusão

O artigo desafia a tendência atual de treinar modelos cada vez maiores para reparos cegos. As descobertas indicam que:

1. A Intenção é o Gargalo: O principal obstáculo na APR não é a capacidade de gerar código, mas a clareza na formulação do problema.
2. Especificação > Código: A capacidade de alinhar o código a especificações executáveis verificadas (seja pré-existentes ou reversas) é mais valiosa do que apenas aumentar a escala do modelo.
3. Mudança de Paradigma: O futuro da APR reside na Reparação Baseada em Especificação. O agente deve atuar como um "arquiteto" que define o contrato antes de atuar como "engenheiro" que escreve o código.
4. Custo vs. Benefício: Embora a fase de verificação (Engenheiro) tenha um custo computacional elevado (devido à necessidade de compilar e executar testes em ambientes legados), o investimento em "pensar" (inferir especificações) antes de "codificar" reduz drasticamente o custo de gerar milhares de patches inválidos.

Em suma, o Prometheus demonstra que agentes de IA podem transcender a geração de código superficial e atuar como mantenedores de software de alto nível, desde que guiados por contratos de intenção rigorosos e verificáveis.