Desenvolvimento orientado a especificações com EGM

Por que isso importa

Uma funcionalidade pode passar nos testes e ainda implementar a regra errada. Se ninguém definiu o que acontece quando um produto vendido é excluído, o agente pode entregar uma exclusão perfeitamente funcional que destrói o histórico de pedidos. Planejar melhor começa por tornar essas decisões explícitas.

O vídeo apresenta o Elephant-Goldfish Model, ou EGM, que separa quem desenvolve a proposta de quem a questiona. Minha leitura é que o ganho está em obrigar o plano a sobreviver fora da conversa que o produziu. Isso interessa especialmente a quem mantém sistemas existentes, nos quais uma mudança aparentemente pequena atravessa estoque, permissões e relatórios.

O caso demonstrado é do AI LABS. O roteiro abaixo acrescenta uma proposta de avaliação: escolher uma mudança relevante, registrar regras verificáveis, exigir evidências dos revisores e medir o trabalho adicional. O projeto está no GitHub do Google, mas declara que não é um produto oficialmente suportado pela empresa. Essa distinção ajuda a dimensionar a responsabilidade de quem o adota. Repositório oficial do EGM.

Pontos principais

• 00:31 O planejamento produz também critérios de conclusão. A utilidade prática é permitir que alguém confira a entrega sem depender da memória da conversa.
• 01:34 O Elephant concentra o histórico do projeto e conduz as decisões. Esse conhecimento precisa virar documentação que outra pessoa consiga compreender.
• 02:06 Os Goldfish recebem o plano e o código, sem a conversa anterior. Isso cria uma oportunidade de encontrar premissas que ficaram implícitas.
• 03:40 O vídeo questiona a revisão feita na mesma conversa. Um revisor separado pode contestar escolhas que o autor já passou a tratar como resolvidas.
• 04:12 O humano seleciona os achados úteis. Quantidade de observações não equivale a qualidade, e discordâncias exigem decisão de produto.
• 06:19 Na instalação demonstrada, o agente escreveu uma instrução incorreta sobre subagentes. O episódio mostra por que arquivos gerados também precisam de revisão.
• 07:23 O bootstrap documenta o sistema existente por diretório. No exemplo, foram criados 28 READMEs, um custo de preparação que precisa entrar na avaliação.
• 08:26 O canal identifica que gerar documentação não garante sua consulta. Ele ajusta as instruções do projeto para encaminhar o agente aos arquivos relevantes.
• 10:36 O brainstorm expõe dúvidas e submete a proposta a revisores antes de consolidar o conceito. É o momento de resolver escolhas de negócio.
• 11:39 A elaboração do design inclui jornadas críticas, limites e alternativas. Esses elementos ajudam a conectar o comportamento desejado aos testes posteriores.
• 12:42 A revisão acontece em cinco rodadas. Cada rodada oferece uma oportunidade de corrigir o plano antes de autorizar a implementação.
• 13:46 O relatório de drift compara documentação e código. Uma divergência pede investigação: tanto a implementação quanto o documento podem estar desatualizados.
• 14:18 Segundo o canal, a análise encontrou exclusão de produtos já vendidos, contrariando a regra documentada de apenas ocultá-los.
• 14:49 O processo completo é apresentado como mais adequado a mudanças importantes. Correções simples podem não justificar tantas etapas.

Como aplicar

Desenvolvimento orientado a especificações: escolha o piloto

Eu começaria por uma alteração com consequência concreta quando dá errado: cancelamento de pedidos, permissões de acesso ou baixa de estoque. Trocar o texto de um botão oferece pouco espaço para avaliar o benefício de várias revisões.

Defina uma pergunta para o piloto: “A revisão encontra uma falha relevante que nosso planejamento habitual deixou passar?”. Registre o plano inicial antes de receber os achados. Assim você consegue identificar o que a revisão realmente acrescentou.

Confira a instalação atual

A gravação mostra uma configuração específica daquele momento. Na documentação consultada para este rascunho, a instalação do plugin para Claude Code usa estes comandos no terminal:

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

Depois, inicie uma nova sessão. A documentação do EGM orienta instalar o plugin completo, pois copiar apenas as skills deixa de fora arquivos necessários. Consulte o procedimento correspondente ao seu ambiente antes de reproduzir a instalação. Guia de instalação do EGM.

Confira o que foi alterado no projeto. Se aparecer uma instrução sobre capacidade de subagentes, verifique o comportamento da versão instalada. A solução mostrada no vídeo não deve virar uma edição automática em qualquer ambiente.

Escreva regras que possam falhar em um teste

Como exercício inspirado no exemplo do vídeo, considere uma loja que precisa preservar o histórico de vendas. Antes de pedir implementação, proponha esta matriz para discussão:

| Situação | Comportamento esperado | Evidência a verificar | | --- | --- | --- | | Excluir produto sem vendas | Exclusão permitida ao responsável autorizado | Teste de integração da operação | | Excluir produto com vendas | Exclusão bloqueada; arquivamento disponível | Tentativa pela interface e pela API | | Consultar pedido antigo | Dados históricos continuam disponíveis | Consulta após arquivar o produto | | Venda e exclusão simultâneas | A regra permanece válida | Teste de concorrência no banco usado pelo projeto |

Essas são regras propostas para o exercício, não resultados obtidos pelo canal. Seu sistema pode precisar de decisões diferentes, mas elas devem ficar explícitas. “Preservar histórico” sozinho ainda deixa muita interpretação aberta.

Faça o documento viajar sem a conversa

Se o projeto já tem uma especificação útil, experimente revisá-la antes de documentar todo o repositório. O guia atual permite usar as etapas conforme a necessidade, sem impor a sequência completa a toda tarefa. Guia de fluxo do EGM.

Dê ao revisor o documento, as referências necessárias e perguntas objetivas. Um pedido possível é:

Revise este plano e o código referenciado. Para cada problema, indique a regra afetada, a evidência, um cenário de falha e como verificar a correção. Separe defeitos demonstráveis de dúvidas que dependem de decisão humana.

Peça que o relatório identifique os arquivos consultados. Isso ajuda a perceber se a crítica se apoia no sistema ou apenas em recomendações genéricas. Também facilita descobrir referências que estavam faltando.

Transforme achados em decisões e testes

Para cada observação, registre uma decisão: corrigir, investigar ou aceitar com justificativa. Vincule os achados aceitos a um critério de conclusão. No exemplo da loja, esconder o botão de exclusão não basta se a API continua permitindo apagar o produto vendido.

Após implementar, execute os testes correspondentes e use a comparação entre código e documentação para procurar divergências. Quando uma diferença for intencional, atualize a especificação. Quando contrariar a regra aprovada, corrija o código. Um relatório sem divergências não substitui a execução dos testes.

Meça o custo completo

Anote tempo de espera, consumo do modelo, minutos de leitura humana e mudanças concretas no plano. Em um exemplo hipotético, 30 minutos de execução e 40 minutos de triagem representam 70 minutos do fluxo, mesmo que parte disso aconteça enquanto você faz outra coisa.

Meu critério de adoção seria encontrar riscos relevantes com evidências e gerar testes úteis dentro de um custo aceitável para aquela mudança. Se a saída produzir principalmente sugestões de estilo e repetição de requisitos, reduza o escopo da revisão no próximo piloto. A quantidade de agentes não é uma medida de qualidade.