Três ideias de notícias sobre agentes, transformadas em verificações: o que levamos para o nosso harness e o que deixamos de fora

Em uma semana, três ideias sobre agentes de IA circularam por todos os canais que eu leio. Karpathy sugeriu pedir a um modelo que escrevesse como um manual de aeronave. O Google Research publicou o Harness², um framework que melhora tudo ao redor do modelo em vez do próprio modelo. Engenheiros da OpenAI descreveram como removeram 800.000 linhas de código morto com um agente em duas semanas. As três são boas. As três também chegam na forma de "adicione uma linha mágica ao seu prompt", e um prompt é exatamente o que se desvia na próxima chamada. Então levamos as três para a nossa config aberta, github.com/AnastasiyaW/codex-claude-code-config, como verificações. Aqui está o que mantivemos, o que descartamos e por quê.

O manual de aeronave: duas regras de noventa

O padrão é o ASD-STE100, Simplified Technical English. A aviação o usa para que um mecânico leia um único significado em cada instrução. Em 2 de outubro, Karpathy ordenou formas de tornar a saída de modelos mais fácil de ler. Texto nesse estilo vem primeiro, depois um diagrama, depois uma página HTML interativa, e por último um vídeo explicativo personalizado. A escada é útil por si só. A maioria das respostas precisa do primeiro degrau, uma mudança de arquitetura precisa do segundo, e uma comparação com muitos números justifica o terceiro.

A linha "escreva em STE100 estrito" é mais fraca do que parece. O padrão completo tem um dicionário controlado de cerca de 900 palavras e dezenas de regras. O dicionário tem copyright, e os modelos não o conhecem de forma confiável. Peça conformidade estrita e você recebe uma imitação: frases picadas, não o padrão.

Duas regras carregam a maior parte do valor e não precisam de dicionário:

• Um conceito, um termo. Se o projeto diz "worker", toda frase diz "worker". Modelos gostam de sinônimos por variedade. Um leitor técnico então precisa descobrir se "worker", "handler" e "executor" são três coisas ou uma só.
• Frases curtas. O STE limita instruções a 20 palavras e descrições a 25.

Tornamos as duas mecânicas. scripts/term_drift_check.py pega o glossário do projeto e confere o que o agente escreveu contra ele. Uma entrada do glossário como обработчик* pega todas as formas da palavra, então a verificação também funciona em russo. Os linters STE existentes não fazem isso, porque o próprio padrão é para o inglês. Blocos de código, links e comentários são ignorados. O código de saída é 0 para limpo, 1 para achados e 2 quando a checagem não conseguiu rodar. Precisamos do terceiro estado porque uma checagem que silenciosamente não checou nada é pior do que nenhuma checagem.

A primeira versão teve exatamente esse problema. Um revisor independente, um agente separado com contexto novo, encontrou três maneiras de obter um resultado verde sem checar nada. Texto numa codificação que não é UTF-8, um bloco de código não fechado e um glossário sem sinônimos saíam todos limpos. Um segundo revisor encontrou mais cinco. Todos foram corrigidos, e o autoteste agora inclui casos que precisam falhar, para que um detector quebrado não passe em silêncio.

Harness²: o método sim, o auto-patcher não

A ideia por trás do Harness² é forte. Os pesos do modelo ficam fixos. O agente propõe edições ao que está ao redor dele: prompt de sistema, memória, orientação de ferramentas, skills, scripts, plugins. Ele roda as edições na tarefa, mantém o que ajudou e guarda a lição para a próxima vez. Em três benchmarks de trabalho profissional, uma rodada disso elevou o GLM-5 e o Gemini 3.5 Flash em até 11,5 pontos.

Não instalamos como está. No README, o executor dele roda com rede aberta e com o sandbox do Codex desligado, e não há protocolo para tarefas de holdout. Para um agente que edita as próprias regras, esse é o principal risco: ele melhora nas tarefas que já viu e quebra em silêncio as que não viu.

Então tomamos o método como um piloto pequeno, com limites rígidos:

• um conjunto congelado de três a cinco tarefas, mais pelo menos uma tarefa de holdout na qual a mudança não foi ajustada;
• uma mudança por candidato, para que a causa seja óbvia;
• registros mecânicos por tarefa, e não uma opinião sobre o resultado;
• o candidato só vence com melhora estrita e sem regressão em segurança ou na tarefa de holdout;
• hooks ativos, permissões e guardrails nunca são alvo do piloto.

O comparador lê dois registros e escreve um veredito. Ele não roda agentes e não toca na config ativa. Um resultado aceito é evidência para uma revisão, não um deploy.

Código morto: a evidência vem da produção

Os números da OpenAI são impressionantes. Mais de 1.400 PRs mesclados e mais de 800.000 linhas removidas em cerca de duas semanas. Uma imagem de container ficou 48% menor, e o tempo mediano de CI caiu de cerca de dez minutos para quatro minutos e meio. Os prompts não foram o que fez funcionar. O processo foi.

Remover código é um tipo especial de mudança. Nada falha quando código inalcançável desaparece. Nada falha tampouco quando você se engana sobre ele ser inalcançável, até que a produção falhe. Então a prova precisa vir da produção: telemetria, o estado vivo das flags, cada ponto de chamada, incluindo os indiretos, o dono. A auditoria é somente leitura. Cada remoção é um pequeno PR rascunho com a evidência e o raciocínio na descrição. Killswitches e salvaguardas nunca são removidos pela palavra do agente.

Adicionamos isso como referência à skill refactoring-safely. A skill agora também é acionada quando alguém pede para remover código morto ou flags de feature obsoletas.

Comentários no código: a pesquisa diz algo um pouco diferente

Ao mesmo tempo, eu queria verificar uma ideia que já seguimos: se agentes escrevem e leem o código, a maioria dos comentários só desperdiça contexto. Temos essa regra desde 15 de outubro, e procurei pesquisa por trás dela. A resposta foi mais interessante do que "comentários são ruído".

• Comentários desatualizados puxam o código gerado em direção à implementação antiga.
• Modelos podem confiar mais num comentário do que no código que ele contradiz.
• Um comentário ausente pesou pouco nos estudos que encontrei.
• Um comentário correto sobre código não óbvio ajudou: em um estudo sobre código legado de mainframe, a acurácia foi de cerca de 84% para 90–96%.

As amostras são pequenas, e li dois dos artigos apenas como resumos, então eu trataria os números exatos com cuidado. A direção é clara, porém: um comentário que mente é mais perigoso do que um comentário que não existe. Então acrescentamos um requisito à regra. Se você muda o código, muda ou apaga o comentário ao lado dele no mesmo commit. Reafirmar o código sai. O motivo, a origem de um número e a armadilha que, de outra forma, o próximo agente "consertaria" ficam.

O que há no repositório agora

• docs/output-legibility.md: a escada de legibilidade e as duas regras, com uma linha de prompt que funciona melhor do que "escreva em STE100";
• scripts/term_drift_check.py: a checagem de glossário, com testes e um autoteste;
• docs/harness-improvement-pilot.md e seu comparador: o piloto limitado;
• references/dead-code-sweep.md na skill refactoring-safely;
• a regra de comentários atualizada em rules/quality-code.md.

Tudo está na release v2026.10.24, e a lista completa de mudanças está em UPDATES.md. Um agente pode pegar o que precisa direto do repositório: comece com CLAUDE.md e README.md, depois as skills listadas em skills-lock.json.

Se algo disso economizar um dia do seu trabalho, uma estrela no GitHub ajuda outras pessoas a encontrarem o repositório. Se algo quebrar, abra uma issue: foi daí que saiu, originalmente, a maioria das nossas regras.