Resumo Técnico: Engenharia de Harness de IA

Declaração do Problema

Embora os modelos de base tenham demonstrado capacidades significativas na geração automatizada de código, agentes autônomos de engenharia de software permanecem pouco confiáveis em cenários de desenvolvimento realistas. A visão predominante atribui essa lacuna exclusivamente às limitações do modelo (codificação, raciocínio, planejamento ou uso de ferramentas). No entanto, os autores argumentam que essa formulação é incompleta. A engenharia de software é uma atividade com estado e de longo horizonte, exigindo gerenciamento de contexto, memória do projeto, interfaces de ferramentas, rastros de execução e verificação. Quando os modelos de base operam em ambientes projetados para humanos, esses suportes são frequentemente implícitos, inacessíveis ou instáveis. Consequentemente, os agentes improvisam ou exigem intervenção humana para preencher essas lacunas. O problema central não é apenas a capacidade do modelo, mas a falta de um substrato de tempo de execução que media como um agente observa um projeto, age sobre ele, recebe feedback e estabelece a conclusão da tarefa.

Metodologia

O artigo propõe a Engenharia de Harness de IA, um substrato de tempo de execução que envolve um agente baseado em modelo de base e gerencia a interação entre o modelo e o ambiente de software. A metodologia é estruturada em torno de três componentes principais:

1. O Framework de Harness de IA

O harness é definido como uma camada de tempo de execução que gerencia onze responsabilidades específicas de componentes:

1. Especificação da Tarefa: Definição de objetivos, requisitos e critérios de sucesso.
2. Seleção de Contexto: Exposição de conteúdo relevante do projeto.
3. Acesso a Ferramentas: Declaração de ferramentas disponíveis e comandos permitidos.
4. Memória do Projeto: Fornecimento de arquitetura legível pelo agente e falhas conhecidas.
5. Estado da Tarefa: Manutenção de hipóteses, arquivos inspecionados e próximos passos.
6. Observabilidade: Exposição de logs, rastros e erros de tempo de execução.
7. Atribuição de Falhas: Separação entre observação, comportamento esperado e diagnóstico.
8. Verificação: Mapeamento de requisitos para evidências determinísticas.
9. Permissões: Restrição de ações arriscadas e exposição de portões de aprovação.
10. Auditoria de Entropia: Detecção de encargos de manutenção (por exemplo, documentação desatualizada, resíduos).
11. Registro de Intervenção: Log de assistência humana e sua evitabilidade.

2. A Escala Controlada H0–H3

Para separar empiricamente a contribuição do harness da do modelo, os autores propõem uma escala de ablação de quatro níveis onde o suporte de tempo de execução é progressivamente exposto:

• H0 (Base Mínima): O agente recebe apenas a descrição da tarefa e os arquivos do repositório.
• H1 (Harness de Ferramentas): Adiciona registro de ferramentas, registro de comandos de teste e protocolos de uso de ferramentas.
• H2 (Harness de Contexto–Memória): Adiciona memória do projeto legível pelo agente, arquivos de estado da tarefa e protocolos de seleção de contexto.
• H3 (Harness de Observabilidade–Verificação): Adiciona verificações de comportamento determinísticas, protocolos de reprodução de bugs, protocolos de atribuição de falhas e modelos de relatórios de verificação.

3. Protocolo de Avaliação Baseado em Rastros

A avaliação desloca o foco do sucesso simples da tarefa para a produção de evidências auditáveis. Cada execução do agente é tratada como um episódio que produz um pacote de episódio contendo:

• Oito Tipos de Rastro: Rastros de ação, ferramenta, contexto, verificação, atribuição de falhas, intervenção, entropia e resultado.
• Taxonomia de Resultados de Cinco Etiquetas:
  • Sucesso Verificado Autônomo: Requisitos atendidos com evidência suficiente, sem intervenção humana.
  • Sucesso Verificado Assistido: Correção correta, mas progresso/verificação chave dependeu de humanos.
  • Sucesso Não Verificado: Correção parece correta, mas o agente produziu evidência insuficiente.
  • Falha: Comportamento necessário ou testes falharam.
  • Inválido Inseguro: Testes enfraquecidos, edições destrutivas ou tarefa contornada.

Contribuições Principais

1. Definição de Engenharia de Harness de IA: O artigo define o harness como um objeto de pesquisa distinto de frameworks de agentes, sistemas operacionais ou prompts, identificando suas onze responsabilidades de componentes e cinco princípios de design (por exemplo, recursos de tempo de execução explícitos, mediação rastreável, atribuição antes da recuperação).
2. A Escala H0–H3: Um instrumento de visibilidade controlada que permite aos pesquisadores isolar o impacto de suportes específicos de tempo de execução (ferramentas, memória, verificação) no desempenho do agente.
3. Protocolo de Avaliação Baseado em Rastros: Um método para converter execuções de agentes em pacotes de episódio auditáveis que capturam métricas de nível de processo (por exemplo, Taxa de Intervenção Humana sem Harness, Autonomia de Verificação) em vez de apenas resultados finais.
4. Validação Empírica: Uma instanciação do framework em uma tarefa de validação controlada (repoA-T1), demonstrando que os pacotes de episódio diferem sistematicamente na estrutura de evidência entre os níveis de harness.

Resultados

Na tarefa de validação controlada (repoA-T1), que envolveu corrigir um defeito de validação de login:

• Variação na Estrutura de Evidência: Todos os quatro níveis de harness (H0–H3) produziram uma correção funcional. No entanto, a estrutura de evidência variou sistematicamente:
  • H0 produziu apenas uma correção final e verificações do lado do avaliador.
  • H1 adicionou rastros de ferramentas e registros de testes direcionados.
  • H2 adicionou rastros de contexto sobre a memória do projeto e estados de tarefa atualizados.
  • H3 produziu o pacote mais abrangente, incluindo logs de reprodução de bugs, logs de atribuição de falhas, verificações de requisitos determinísticas e relatórios de verificação estruturados.
• Disciplina de Verificação: H3 impôs um fluxo de trabalho "reproduzir → atribuir → corrigir → verificar → relatar". Isso permitiu que o sistema distinguisse entre uma correção que apenas "parece certa" e uma alteração que é verificavelmente correta, atribuída e mantível.
• Preocupações de Tempo de Execução: O protocolo expôs com sucesso problemas de tempo de execução, como timeouts de regressão total, tratando-os como pontos de dados analisáveis em vez de falhas incidentais.

Significado e Alegações

O artigo afirma reformular a questão central da engenharia de software autônoma. O foco desloca-se de "Um modelo de base pode produzir uma correção?" para "O sistema modelo–harness–ambiente pode produzir uma alteração verificavelmente correta, atribuída e mantível?".

As implicações principais destacadas pelos autores incluem:

• Verificação como Capacidade de Tempo de Execução: A verificação deve ser uma parte explícita do harness, não apenas uma verificação humana externa.
• Memória Auditável: A memória do projeto só é útil se seu uso for rastreado e analisado.
• Atribuição de Falhas: Separar diagnóstico de ação previne "correções sortudas" e correções aleatórias.
• Gerenciamento de Entropia: Agentes autônomos devem ser responsabilizados pelos encargos de manutenção (resíduos, documentação desatualizada) introduzidos durante a execução.
• Ambientes Nativos de IA: Futuros repositórios de software devem evoluir para fornecer affordances explícitas e legíveis por agentes (por exemplo, mapas de arquitetura, registros de verificações determinísticas) em vez de depender de convenções humanas.

Os autores posicionam este trabalho como o início de um programa de pesquisa empírica para os sistemas de tempo de execução que agentes de software baseados em modelos de base exigirão, avançando além de melhorias centradas no modelo para engenharia centrada no sistema.