Escrevi outro dia que DHH, Tio Bob e Torvalds podem se dar ao luxo de não ler código porque décadas de entendimento de sistema já viraram reflexo neles - e que, pra quem não tem essa bagagem, "orquestrar" sem esse fundo é só delegação de raciocínio com nome bonito. Fica faltando a pergunta óbvia: e na prática, como isso funciona? Aqui vai o processo real que uso, sem place holder.
Dois agentes, papéis separados
Uso um agente com harness próprio pra escrever - Claude Code ou Codex - e outro, de família diferente, só pra auditar: Grok ou Gemini via Antigravity. A separação é proposital. Um agente auditando o próprio trabalho tende a validar as próprias escolhas; um agente de outra família, treinado diferente, lendo o relatório do primeiro, tende a pegar o que ficou de fora - cobertura de TDD que não fechou, teste unitário que testou o caminho feliz e ignorou borda, E2E que nunca rodou.
O jogo da batata quente
O ciclo antes de qualquer linha de código nascer é assim:
- Eu gero a ideia, a spec, e a forma como quero que seja feito - não só "o quê", mas restrição de como.
- O agente auditor traduz essa spec pra linguagem de agente - o formato que o agente escritor vai processar melhor - e devolve pra mim como e por que ele traduziu daquele jeito.
- O agente escritor lê, entende, e devolve o que entendeu ANTES de começar a desenvolver. Sem começar a codar em cima de uma leitura errada.
- Eu leio essa devolutiva, edito o que tiver errado, e repasso pro auditor.
Isso roda em loop - a batata quente entre eu, o auditor e o escritor - até a spec ficar madura o suficiente pra gerar código de verdade. Só depois disso o agente escritor entra de fato. O ponto não é velocidade nessa etapa - é garantir que ninguém comece a construir em cima de mal-entendido, porque mal-entendido em código gerado por agente escala muito mais rápido que mal-entendido em código escrito à mão.
As três ferramentas que fecham o ciclo
Depois que o código existe, entram duas ferramentas minhas, pensadas exatamente pra não depender de eu abrir o arquivo e ler linha por linha.
A guardrails cobre a saúde estática: escaneia arquivo grande, função longa, serviço inchado, código duplicado ou estruturalmente parecido, import violando arquitetura, TODO/FIXME esquecido. Ela guarda histórico de cada scan, compara versões, resume maturidade do projeto, e tem um comando (explain) que gera uma análise pronta pra outra IA revisar - ou seja, até a auditoria de saúde de código eu tercerizo pra ferramenta determinística, não pro meu olho cansado.
guardrails scan --path .
guardrails explain --path .
Scanned 36 file(s). Score 96/100. Findings 1.
Médiosrc/parser/generic-parser.js:1Regra: large_file Política: warn
Problema: File has 366 lines, above the limit of 220.
Ação sugerida: Split unrelated responsibilities into smaller modules.Esse é um scan real, rodado agora, num dos meus próprios projetos. Nota 96/100, um achado de severidade média - arquivo grande, sem risco crítico. O explain pega esse relatório e gera um segundo arquivo (.guardrails/analysis.md) com um prompt pronto pra mandar pro agente auditor, algo como "aqui estão as prioridades de inspeção, explique por que isso importa e o que perguntar antes de mexer - não proponha patch automaticamente". Ou seja, até o jeito de pedir a revisão pra IA é padronizado, não um prompt improvisado toda vez.
A qa cobre a metade dinâmica: roda a suíte de teste (Pest, PHPUnit, ou npm test, com auto-detecção), interpreta o resultado, guarda histórico de passou/falhou, e funciona como gate de CI - se a suíte quebrar, o pipeline para. Ela nasceu justamente pra eu parar de rodar teste manualmente e ficar catando resultado no olho.
qa run --path . 45 passed, 0 failed, 0 skipped (45 total)Report: .qa/report.md
Mesma coisa, rodado agora, nos testes da própria guardrails. Passou, então o pipeline segue; se falhasse, o qa sai com código de erro e o processo para ali, antes de qualquer coisa ir pra frente. Nenhuma das duas saídas acima teve intervenção minha - rodei o comando, copiei o que voltou.
Faltou uma peça que esqueci de mencionar da primeira vez: a ai-memory, do Fabio Akita. Ela existe porque agente de IA perde contexto quando a sessão acaba - e nesse processo eu troco de agente o tempo todo (escritor, auditor, sessões novas). A ai-memory mantém uma espécie de wiki persistente, compilada a partir de observações capturadas automaticamente entre as sessões, em markdown puro dentro de um repositório git - sem banco vetorial pra cuidar, sem eu ter que ficar mandando "lembra que a gente decidiu X" toda vez que abro uma sessão nova. E eu uso ela pra um propósito específico: peço explicitamente pra registrar cada decisão que tomamos no processo - não só o que foi feito, mas por que escolhemos aquele caminho e não outro. Sem isso, o loop de auditoria vira amnésico: o agente auditor da próxima sessão reabre uma decisão que a gente já discutiu e fechou há três dias, porque ele simplesmente não sabe que ela já foi tomada.
ai-memory search "cron PATH" 3 result(s) for "cron PATH": decisions/backup-e-persistencia-2026-09.md rank=-17.2274 Backup e persistência — repo, cron e artefato (2026-09-23) decisions/estrategia-redes-sociais-2026-09.md rank=-13.4864 Estratégia de Redes Sociais — Blog Demóstenes Albert (plano completo) sessions/17c58fb7-11e5-4ef9-a877-2f6f9df7657b.md rank=-9.6159 criamos uma artefato aqui, e fizemos um script no cron vamos perder isso depois?
Busca real, feita agora, nesse mesmo projeto. E o que tem dentro de uma dessas páginas de decisão não é resumo de reunião - é registro estruturado, com o que foi descartado e por quê:
###2. Snapshot diário do Claude Doc
Descartada a ideia inicial de SQLite não trackeado (complexidade de manter 2 fontes sincronizadas sem ganho real, já que o conteúdo é texto corrido, não dados tabulares). Optado por snapshot markdown, commitado no git. Por que não curl: o conector Claude Docs não é API REST pública - só existe dentro da sessão OAuth do claude CLI. Fazer via curl exigiria guardar token/cookie de sessão no script (pior em segurança) e depender de endpoint interno não documentado.
Repara no que ficou registrado: não só "o que" foi feito (snapshot em markdown), mas "o que foi descartado e por quê" (SQLite não trackeado, curl guardando token de sessão). Da próxima vez que um agente - ou eu - mexer nesse script, essa alternativa já rejeitada não volta pra mesa. Ninguém perde meia hora redescobrindo por que "a solução óbvia" não foi usada.
As três juntas são a versão automatizada, repetível, do teste que eu propus lá atrás: "você sabe o que quebra com input errado? funciona sem a IA no meio?". Só que em vez de eu perguntar isso mentalmente cada vez, a guardrails e a qa perguntam isso toda vez que rodam, de um jeito que não some quando eu tô cansado ou com pressa.
Onde isso pode quebrar
Não vou vender isso como sistema à prova de falha. O ponto fraco não é técnico, é humano: se eu parar de ler o relatório do auditor com atenção, ou deixar a spec vaga só pra andar mais rápido, o loop inteiro vira teatro - dois agentes conversando entre si e eu só clicando "ok" no meio. A ferramenta não troca meu julgamento por nada; ela só me deixa aplicar esse julgamento numa camada mais alta, com menos ruído, e com registro de histórico pra eu poder checar depois se a maturidade do projeto tá subindo ou caindo. Dev experiente não consome output livre - nem o do agente escritor, nem o do auditor.
