Resumo Técnico: Direcionabilidade via Restrições para Supervisão Escalável de Agentes de Codificação

Declaração do Problema

À medida que os agentes de codificação ganham a capacidade de gerar milhares de linhas de código funcional, o principal gargalo em pipelines de alto risco mudou da capacidade para a verificação. A supervisão humana é insuficiente para auditar vastas bases de código devido às limitações de comprimento de contexto; nem humanos nem modelos conseguem manter todo um repositório em memória de trabalho. Além disso, diretrizes fracamente aplicadas tendem a sofrer deriva conforme o contexto cresce, e agentes sem restrições introduzem riscos de segurança significativos (ex: backdoors, exfiltração de segredos), além de erodirem a escalabilidade do código.

O scaffolding de agentes atual, como o Model Context Protocol (MCP), muitas vezes exacerba isso ao saturar o contexto do agente com payloads brutos, tornando a verificação cada vez mais custosa e difícil. O artigo argumenta que confiar em instruções baseadas em prompts é inerentemente falho porque prompts são consultivos e propensos a falhas adversariais (ex: injeção de prompt indireta).

Metodologia: Direcionabilidade via Restrições

Os autores propõem um sistema construído sobre o princípio de que agentes de codificação devem ser direcionados não por prompts, mas por restrições externas e verificáveis, semelhantes às utilizadas há décadas para gerenciar equipes de engenharia humana. A metodologia consiste em três pilares principais:

1. Restrições de Substrato

Em vez de prompts consultivos, o sistema impõe regras estritas via ferramentas que se recusam a executar código que as viole.

• Aplicação Estática e em Tempo de Execução: O sistema utiliza linters rigorosos (Ruff com regras de segurança/bandit), verificadores de tipo (Pyrefly) e validadores de contrato em tempo de execução (Beartype, modo estrito do Pydantic, Jaxtyping).
• Estruturas Imutáveis: Dataclasses são congeladas (frozen), possuem slots (slotted) e são apenas por palavra-chave (keyword-only); coleções são restritas a tuplas e mapeamentos em vez de listas/dicionários mutáveis.
• Arquitetura: Uma separação estrita entre um módulo core/ puro e um módulo runners/ impuro.
• Documentação Local: Invariantes e convenções estão incorporadas diretamente nas docstrings de nível de módulo em vez de documentos externos centralizados (ex: ARCHITECTURE.md), garantindo que o código e sua especificação estejam co-localizados.

2. Isolamento de Ambiente (Camada de Máquina)

Para evitar injeção de prompt indireta e acesso não autorizado à rede, o agente opera em um ambiente altamente isolado:

• Virtualização: O agente opera dentro de uma Máquina Virtual (VM) ou um container restrito (Podman sem root) com um sistema de arquivos somente leitura e capacidades reduzidas.
• Filtragem de Rede: Um proxy de rede restringe a saída a uma pequena lista de permissões de domínios confiáveis (ex: PyPI, GitHub) via regras nftables que descartam tráfego para intervalos de IP privados.
• Proxy de Inferência: Uma camada semântica intercepta todas as chamadas do modelo (prompts e respostas) para detectar injeções de prompt indiretas e reescrever o conteúdo antes da entrega.

3. Princípio de Projeção via CLI

Para abordar o problema do comprimento de contexto, o sistema emprega um "princípio de projeção": agentes não precisam de detalhes de implementação brutos, mas sim de um mapa topológico do repositório.

• CLI de Documentação: Uma ferramenta de CLI leve, de menos de 200 linhas de código (construída sobre griffe), projeta informações relevantes sob demanda.
  • docs module X: Renderiza APIs públicas e blocos de invariantes.
  • docs symbol X.Y: Renderiza assinaturas, campos de dataclass e docstrings.
• Protocolo de Revisão: Em vez de revisar todo o código, um modelo pequeno e confiável (o "revisor") inspeciona funções uma a uma. O revisor recebe o código-fonte da função mais seu cabeçalho de módulo específico e docstrings relevantes, mantendo o contexto dentro dos limites de tokens do revisor.

Principais Contribuições

1. Esboço de Sistema: Um design de sistema ponta a ponta onde cada componente (lançador de VM, proxy de rede, proxy de inferência, CLI de docs) é pequeno (menos de 100 linhas de código para a maioria dos componentes) e inspecionável.
2. Convenções de Substrato: Um conjunto de convenções específicas de Python (tipagem estrita, dataclasses congeladas, invariantes locais) projetadas para tornar a supervisão tratável, tornando os contratos textualmente visíveis sem necessidade de prosa.
3. Experimento Controlado: Um experimento 2×2 avaliando o impacto do substrato restrito e do CLI de docs em um modelo pequeno e confiável (Gemma 4 e4b, classe 8B) encarregado de detectar 11 backdoors estratificados em um código Python sintético de 500 linhas.

Resultados Experimentais

O experimento mediu o recall (revocação) de um pequeno modelo revisor na detecção de backdoors em quatro condições:

• C1 (Sem restrições, Sem ferramentas): 54,5% de recall.
• C2 (Sem restrições, Com CLI de Docs): 81,8% de recall.
• C3 (Substrato Restrito, Sem ferramentas): 81,8% de recall.
• C4 (Substrato Restrito + CLI de Docs): 90,9% de recall.

Principais Descobertas:

• Contribuições Independentes: Tanto o substrato restrito quanto o CLI de docs contribuíram independentemente para a melhoria do recall.
• Detecção de Backdoor: O sistema foi particularmente eficaz contra backdoors que violavam invariantes globais (L5) ou fluxos entre múltiplos arquivos (L3), que eram frequentemente perdidos na configuração sem restrições.
• Precisão: As restrições sozinhas (C3) reduziram ligeiramente a precisão (88,9%), pois o revisor sinalizava excessivamente funções ao receber invariantes sem ferramentas de verificação eficientes. A adição do CLI de docs (C4) restaurou a precisão para 95,7%, mantendo o alto recall.
• Protocolo de Múltiplas Passagens: Um protocolo de revisão de múltiplas passagens (fazendo perguntas focadas sequencialmente) foi crítico; uma abordagem de passagem única resultou em menor desempenho devido à fixação do modelo em descobertas iniciais.

Significância e Alegações

O artigo afirma que a direcionabilidade via restrições oferece um caminho escalável para supervisionar agentes de codificação. Ao deslocar o fardo da verificação do raciocínio interno do modelo para contratos externos e executáveis e documentação localizada, o sistema permite que um revisor pequeno, de capacidade fixa, audite códigos que seriam, de outra forma, grandes demais ou complexos demais para verificar.

• Agnosticismo de Linguagem (em princípio): Embora o experimento tenha focado em Python (escolhido por oferecer o menor número de garantias padrão, maximizando o ganho potencial das restrições), os autores argumentam que os princípios se estendem a linguagens como Rust e linguagens vinculadas a verificadores como Lean.
• Modéstia: Os autores declaram explicitamente que o experimento de backdoor é preliminar e sintético, servindo como um exemplo de possibilidade e não como uma prova rigorosa em escala. Eles reconhecem que o esboço do sistema é uma proposta de design em progresso e que o par mais maduro (NVIDIA OpenShell) oferece um conjunto de recursos mais amplo, embora careça da inspeção específica de conteúdo semântico proposta aqui.
• Tese Central: O artigo postula que os mesmos métodos de engenharia testados em batalha usados para equipes humanas (controle de acesso, convenções estritas, ferramentas) transferem-se diretamente para agentes de codificação e são mais econômicos (em termos de tokens) do que o scaffolding de agentes recente.