AIDiveO plano que ninguém revisou
O Elephant-Goldfish Model (EGM) do Google é um plugin gratuito do Claude Code em que revisores sem memória leem o seu plano antes de qualquer código ser escrito. Nós o instalamos e levamos uma feature real do nosso próprio app do plano ao código funcionando: um sistema de reservas para uma lista de presentes da família, feito com Next.js e um banco de dados do Notion, rodando numa cópia do repositório.
O planejador encontrou a race condition sozinho. As falhas que importavam eram duas que ele nunca viu: os pais podiam ler nos logs da própria hospedagem quem reservou o quê, e um cookie salvo no navegador podia ser reenviado para cancelar a reserva de outra pessoa. Só os revisores sem memória as encontraram. A feature construída a partir do plano revisado teve um único vencedor em todas as trinta corridas pelo último presente, contra um substituto do Notion. E num conserto pequeno, a revisão custa muito mais do que o próprio conserto, então você a pula.
O fluxo abaixo tem cinco passos: instalar, brainstorm e draft, revisão, resolve, construção. A última seção dá a regra para saber quando pular tudo isso.
O que é o EGM, e a instalação em dois comandos
Quando você pede ao Claude Code para planejar uma feature, o agente que escreveu o plano é o mesmo a quem você pede para conferi-lo, e ele não enxerga os próprios pontos cegos. O EGM, o Elephant-Goldfish Model, é o plugin gratuito do Google para esse problema. O repositório afirma com todas as letras que não é um produto oficialmente suportado pelo Google.
O elefante é o agente com quem você vem conversando: ele guarda a conversa inteira e escreve o plano com você. Os peixinhos-dourados são agentes revisores sem memória. Eles leem só o plano e o seu código, como um colega que revisa um pull request sem ter participado da reunião de design. Podem ler o seu código, mas não alterá-lo, não veem as notas do seu projeto, e a decisão final sobre cada ponto levantado é sua. A ideia vem de Dave Rensin, que escreveu que, se não tomarmos cuidado, não estamos só escrevendo código mais rápido, estamos produzindo nossos erros em massa.
A instalação roda na pasta do projeto, com dois comandos:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project
O primeiro adiciona o repositório do Google como marketplace de plugins, uma lista de onde o Claude Code pode instalar plugins. O segundo instala o plugin só para este projeto. Os dois devolveram um check verde em cerca de cinco segundos; abra uma nova sessão para o plugin carregar. A documentação pede o Claude Code 2.1.271 ou mais recente, porque os revisores dependem da configuração omitClaudeMd, que esconde as notas do seu projeto deles.
Depois adicione uma linha ao seu CLAUDE.md para que os relatórios caiam numa única pasta, em vez de na raiz do repositório:
EGM artifact directory: docs/egm
Os comandos não custam nada até você digitar um: nenhum deles é carregado na sua sessão por conta própria. O limite é que os peixinhos-dourados só leem documentos. Eles não rodam o seu app, e usam o mesmo modelo que você, então podem compartilhar os mesmos pontos cegos.
O brainstorm e o draft numa feature real
O brainstorm serve para quando você está prestes a construir algo em que uma decisão errada vai custar caro depois. Nosso app é uma lista de presentes da família: os parentes marcam o que compraram, e a lista fica num banco de dados do Notion. Tudo rodou numa cópia do repositório, sem acesso à lista real.
A feature: deixar um parente reservar um presente para que ninguém compre o mesmo presente duas vezes, impedir que os pais vejam quem reservou o quê, e permitir um cancelamento. Você digita o comando de brainstorm seguido da feature em uma frase:
/egm:egm-brainstorm Let a relative reserve a gift on the list so two people never buy the same one. Parents must not see who reserved what. A reservation can be cancelled.
Antes de perguntar qualquer coisa, ele leu o código e apontou que o app não sabe quem é ninguém, porque todo mundo entra com uma única senha compartilhada. Depois faz perguntas em várias rodadas, e um pequeno enxame de peixinhos-dourados examina a ideia antes de qualquer seção ser escrita. Você responde como o dono do produto. A nossa resposta: uma senha compartilhada, o parente digita só o primeiro nome, e nada que o identifique vai para um lugar que os pais consultem. O enxame levantou algo que não tínhamos nomeado: a antiga rota de edição, que ainda deixaria qualquer um alterar uma quantidade à mão.
O planejador também nomeou sozinho a race condition: parentes apertando reservar no mesmo instante. Uma race condition é quando duas requisições leem o mesmo valor antigo e as duas escrevem, de modo que uma atualização se perde em silêncio, e a documentação do Notion não oferece nenhuma forma de somar um número de modo atômico.
Em seguida, /egm:egm-draft docs/egm/concepts_brief.md escreve o documento de design uma seção por vez: o plano escrito de cada arquivo antes de qualquer código. Ele parou para perguntar quinze vezes. Você aprova uma seção, ou escolhe entre opções de arquitetura, cada uma listada com a forma como falha. Uma das escolhas foi onde fica a reserva de um parente; escolhemos um cookie assinado no próprio navegador dele, para que nada com o nome dele chegue ao servidor. O draft chegou a admitir, nos seus próprios limites conhecidos, que a correção dele para a race não funcionava, porque os dois parentes leriam o mesmo valor. Você termina esta etapa com um documento de design aprovado no seu repositório.
A revisão cega: nove revisores, duas falhas que o planejador não viu
A revisão serve para quando você e o seu agente acham que o plano está sólido, que é exatamente quando você não consegue ver o que falta. Você digita /egm:egm-review docs/egm/gift-reservations.md; ele pergunta se os revisores devem ler mais alguma coisa e depois pergunta o modo. O modo consolidado roda todas as etapas sem parar e devolve uma única lista de ações já unificada.
As cinco etapas são Initial Zoom Out Review (o design resolve o problema certo), Comprehension Review (um recém-chegado entenderia), Design Critique (estrutura e redação), Intermediate Zoom Out Review e Implementation Readiness, que lê o seu código de verdade e confere cada passo do plano contra ele. Cada etapa envia peixinhos-dourados novos que nunca viram a conversa.
No nosso design, ele rodou nove revisores em 7 minutos e 24 segundos e não tocou no documento; só escreveu relatórios.
| Resultado da revisão | Quantidade |
|---|---|
| Subagentes revisores | 9 |
| Achados brutos | 77 |
| Blocker / Major / Nit | 1 / 42 / 34 |
| Itens de ação unificados | 12 |
Ele não encontrou a race: todo achado sobre a race citava de volta a admissão do próprio planejador. Encontrou duas falhas que ninguém tinha levantado:
- Privacidade. Os pais são donos da conta de hospedagem e dos logs de requisições dela, e esses logs, com a hora e o presente, permitiriam descobrir quem reservou o quê.
- Segurança. Uma cópia salva do cookie do navegador podia ser reenviada para cancelar a reserva de outra pessoa.
Ele também pegou detalhes de código que só apareceriam na hora da construção, como os parâmetros de rota do framework serem assíncronos e um build que ficaria quebrado durante boa parte do plano. Sobre a race que já era conhecida, a correção dele foi enfraquecer o objetivo, um conselho contra o qual vale a pena reagir.
Resolve: você decide, até contra os revisores
O passo resolve é onde uma pilha de achados vira uma decisão. /egm:egm-resolve transforma cada relatório numa única tabela, cada problema com uma sugestão: escalar, contestar, recusar ou propor uma correção. Você aceita uma correção ou a contesta com o seu motivo, e ele aplica apenas o que você aceitar. Você pode responder sozinho aos problemas escalados e deixar que ele aceite o resto automaticamente.
O nosso listou trinta e sete problemas, e o resolve já tinha conferido os revisores contra o código: marcou um achado como errado, um arquivo chamado de não utilizado que a página de login ainda importa.
O grande foi a race. O Blocker propunha reescrever o objetivo como "reduz compras duplicadas, mas não as impede". Nós contestamos e pedimos exatamente um vencedor, com o Notion como único armazenamento e sem nomes. O agente se recusou a fingir: "O Notion não tem como fazer isso. Não tem escrita condicional nem incremento atômico." Ele ofereceu algumas saídas, e escolhemos um claim ledger: uma lista de notas anônimas na própria página do presente no Notion, uma por reserva, lidas em ordem para decidir quem ficava com ele. Isso também fechou a falha do cookie, já que o navegador agora guarda só a sua própria reserva, e por isso você só pode cancelar o que reservou.
O limite: essa correção veio depois da revisão, então nenhum peixinho-dourado a leu, e ela depende de o Notion manter uma única ordem para escritas simultâneas, o que a documentação dele não promete. O design manda rodar a verificação da race numa cópia do banco de dados real antes de publicar.
Construir conforme o plano numa sessão nova, e testar a race
O risco na hora de construir é um agente que improvisa no meio do caminho e se afasta do que você decidiu. Abra uma sessão nova, uma conversa nova que só conhece o que está nos seus arquivos, e entregue o design a ela:
Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.
O nosso trabalhou sozinho por 7 minutos e 56 segundos, alterou 24 arquivos, e a suíte voltou com Tests 216 passed (216). Ele avisou onde saiu do plano (uma versão mais antiga do test runner, porque a mais nova exigia um pacote mais novo) e perguntou antes de atualizar. Também encontrou um teste instável na própria configuração e o tornou previsível.
Depois teste você mesmo o caminho arriscado, porque uma suíte verde só prova o que alguém pensou em testar. Dois parentes no último presente no mesmo segundo, repetido trinta vezes com tempos diferentes: toda vez exatamente uma reserva passou e o outro foi avisado de que o presente já tinha sido pego. A visão dos pais mostrou o presente como completo, sem nenhum nome, e um cancelamento o devolveu ao estado anterior.
Esses testes rodam contra um substituto do Notion que se comporta como ele, sem soma atômica e com atrasos aleatórios. Essa é a regra geral para serviços externos em testes: faça um fake, mas torne o fake tão hostil quanto o real. Antes de publicar, rode a verificação da race do próprio design numa cópia do banco de dados real; o arquivo de teste até documenta o caso em que os dois parentes ganhariam.
Quando pular: a regra
No mesmo app, o README ainda dizia que não havia login nenhum, embora o site tenha uma senha: um conserto de uma linha. O Claude Code puro conferiu o código e corrigiu em segundos, sem nenhum plugin.
| Caminho | Custo (preços de API, Sonnet 5.5) | Tempo |
|---|---|---|
| Correção do README, Claude Code puro | $0.0455 | 10 s |
| EGM brainstorm, draft, review, resolve (antes de qualquer código) | $7.10 | 32 min |
O README do Google diz a mesma coisa: "Use quando uma feature precisa de decisões de design antes da implementação. Para a correção de um bug pequeno e claro, use seu fluxo de código normal." O FAQ acrescenta que concluir o fluxo não prova um ganho de produtividade, e um pequeno piloto num blog de programação concluiu que a revisão não acrescentou nada numa feature que um plano simples já resolvia.
O EGM compensa onde um erro se esconde fora da conversa, como os logs dos pais e o cookie reenviável aqui. No problema que o planejador já conhecia, a decisão que o resolveu foi nossa. A regra: antes de digitar o prompt de construção, pergunte se um erro aqui toca em dados, privacidade, permissões ou dinheiro de outra pessoa. Se tocar, rode a revisão antes de construir.
