Por que não se pode confiar em um agente de IA para revisar o próprio trabalho: um relatório que declarava -9.500 linhas quando o código na verdade cresceu +21.489

• Divergência entre o relatório e o git diff: foi declarada uma "redução de ~9.500 linhas", mas o commit real envolveu 206 arquivos com crescimento líquido de +21.489 linhas (+34.934 / -13.445)
• Precisão do fact-checking de um livro feito por um enxame: foram verificadas ~150 afirmações em 20 capítulos (69.293 palavras), identificando 13 distorções ocultas de estatísticas e datas
• Funil de compressão do meta-casebook: 11,67 GB de sessões JSONL brutas comprimidas 160 vezes até 73,8 MB de resumos (147 lotes, 860 cartões únicos)
• Largura ideal da onda paralela: 8-14 subagentes simultâneos (ao disparar 44 workers de uma vez, a onda inteira trava nos limites do provedor)

Quando um projeto acumula "objetos divinos" (`God objects`) — todo o banco de dados em um único arquivo, o bot inteiro em outro —, a refatoração manual leva semanas. Lancei um enxame de 25 subagentes sobre uma base de código assim, organizado em quatro fases: fechar brechas de segurança, reanimar contêineres, desmontar monólitos e migrar funcionalidades. Um dia e meio depois, o orquestrador entregou um relatório brilhante: `database.py`, com 1.004 linhas, foi dividido em 15 arquivos de modelos; `report_bot.py`, com 1.759 linhas, em 11 módulos; foram escritos "185+ testes"; e a mensagem do commit trazia a linha `Net reduction: ~9500 lines of code`.

Meio ano depois, decidi verificar cada número desse relatório com comandos do `git`. Descobri que o trabalho estrutural tinha sido executado com perfeição, mas quase todos os números do relatório viviam em uma realidade paralela.

Por que as afirmações estruturais do enxame conferem arquivo por

arquivo, enquanto os números de linhas e horas estão errados?

O comando `git show --shortstat` no commit de refatoração revelou: 206 arquivos alterados, 34.934 inserções e 13.445 remoções — um crescimento líquido da árvore de +21.489 linhas, exatamente onde o agente havia declarado uma redução de 9.500 linhas. Os tamanhos originais dos arquivos também diferiam do relatado (`883`, `1.696` e `650` linhas em vez de `1.004`, `1.759` e `904`), e o diff continha apenas 164 funções `test_*`, não "185+".

Ainda assim, todas as afirmações estruturais conferiram até o último arquivo: o pacote de modelos terminou com exatamente 15 módulos, e o antigo `database.py` havia mesmo se tornado um wrapper de compatibilidade retroativa de 8 linhas (`from .models import *`). Uma segunda passagem independente do enxame encontrou e dividiu depois outros 9 arquivos com mais de 1.000 linhas que não apareciam na primeira lista (hoje, de 313 arquivos com 98.264 linhas, resta apenas um módulo de 1.013 linhas).

A distorção numérica surge de três causas: perda de contexto em reinícios de sessão, relato da intenção antes de checar a saída real da ferramenta, e dupla contagem na agregação. Quando um script que montava um casebook a partir de 860 sessões somou o campo `time_saved` de cartões de um mesmo projeto — em que cada sessão havia estimado separadamente a economia do projeto inteiro em "40 horas" — o resultado foi a cifra comicamente inflada de 44.683 horas economizadas. Qualquer agregado numérico gerado por um enxame precisa ser recalculado por um script a partir dos registros primários, nunca aceito como está no relatório.

Como funciona um pipeline de auditores somente leitura e corretores, e

por que comprimir os logs de sessão 160 vezes?

Para evitar que o executor avalie o próprio trabalho, dividimos os papéis: primeiro atuam 5 auditores paralelos somente leitura (segurança, bugs, qualidade, código morto, duplicações), com as ferramentas de escrita fisicamente desativadas e um contrato obrigatório `modifications_made: false` no cabeçalho YAML; depois, 3 corretores atuam sobre esses relatórios, que trazem números exatos de linha e cenários de reprodução (como uma condição de corrida de `row_factory` em uma conexão SQLite compartilhada).

O mesmo esquema de verificação independente, aplicado a um manuscrito de livro com 20 capítulos (69.293 palavras), checou 150 afirmações e flagrou 13 alucinações (uma citação invertida — "91% satisfeitos" transformada em "90% insatisfeitos" —, um acordo de licenciamento de US$ 2,4 bilhões rotulado erroneamente como aquisição, e uma previsão de mercado para 2032 de US$ 37 bilhões citada no lugar do valor atual de US$ 4 bilhões). E para fazer um enxame processar um arquivo de 11,67 GB de logs JSONL brutos, escrevemos um pré-processador de resumos:

```python SKIP_TOOLS = { "Read", "Glob", "Grep", "LS", "TodoWrite", "ToolSearch", "NotebookRead", "BashOutput", "KillShell", "Monitor", "TaskOutput" }

# Mantemos apenas mutações (Write/Edit), comandos Bash e criação de subagentes,

# e cortamos a saída das ferramentas com o limite TOOLRES_CAP = 250 caracteres. ```

Isso comprimiu o corpus 160 vezes — de 11,67 GB para 73,8 MB (147 lotes de `MAXKB=900`, `MAXN=6`), permitindo que um pipeline com IDs de lote estáveis sobrevivesse a três quedas por limites de API e ainda assim reunisse 860 cartões.

Por que o próprio verificador também pode errar diante de APIs novas e

ondas grandes demais?

Um agente verificador é tão probabilístico quanto qualquer outro e pode errar nas duas direções. Ao implementar 173 métodos de uma grande Bot API (ampliando a cobertura da CLI de 19 para 163 comandos, documentada em uma referência de 2.977 linhas), os verificadores cruzavam cada método com 4-5 SDKs de código aberto.

Ao se deparar com um recurso real e recém-lançado que ainda não existia nas bibliotecas antigas, o enxame declarou por unanimidade que era uma "alucinação do explorador"; foi preciso provar que era real rodando testes automatizados contra um fork recém-atualizado. De quebra, descobriu-se um limite de paralelismo: disparar 44 verificadores de uma vez fez a onda inteira travar nos limites da API, enquanto lotes de 8-14 agentes rodavam sem perdas.

Um orquestrador de enxames com aceitação independente e separação de auditores está integrado ao [Nomad AI](https://nomadnet.ai) e ao serviço em nuvem [agent.nomadnet.ai](https://agent.nomadnet.ai). É possível aprender a gerenciar enxames multiagente na [Hamidun Academy](https://academy.hamidun.com) (teste de 72 horas), e os scripts de compressão de logs e os prompts dos revisores estão disponíveis no [Vibe Club](https://hamidun.com/club).