Google divide a elaboração de especificações com IA em dois papéis no plugin EGM

Você passa meia hora discutindo uma nova funcionalidade com uma IA. Ela faz perguntas, concorda com as decisões e escreve uma especificação detalhada. Você pede uma revisão: tudo parece convincente. Depois do lançamento, porém, descobre que um evento duplicado do serviço de pagamentos prorroga uma assinatura duas vezes. Na conversa, todos davam como certa a proteção contra duplicatas, mas ela não entrou no documento.

O Elephant-Goldfish Model, ou EGM, busca resolver esse problema: é um plugin de código aberto para elaborar e revisar documentos técnicos com ajuda da IA. Um agente reúne as decisões; outros revisam o resultado sem o histórico da discussão. O objetivo prático é detectar omissões antes da implementação, enquanto a correção ainda cabe em poucas linhas da especificação.

Por que o revisor precisa esquecer a conversa

O EGM tem dois papéis. O "Elefante" preserva o contexto do projeto e prepara o documento. Os "Peixinhos dourados" recebem o documento e o código-fonte relacionado, mas não a conversa anterior. O desenvolvedor escolhe quais observações aceitar, resolve contradições e aprova o projeto antes de começar a programar. É assim que o processo é descrito no repositório do Google.

A ausência do histórico é uma condição da revisão. Se uma decisão só faz sentido para quem participou de um chat longo, pode faltar informação a quem for implementá-la depois. Um revisor que chega sem esse histórico deve avaliar o que está de fato escrito, sem completar mentalmente o documento com acordos anteriores.

Ainda assim, é fácil interpretar a expressão "contexto zero" de forma literal demais. O revisor recebe materiais para trabalhar. O que se isola é o histórico da discussão, não toda a informação sobre o sistema. Por isso, a qualidade da especificação e a seleção do código-fonte continuam importantes.

Como isso funciona em um exemplo de pagamentos

Imagine que uma equipe esteja adicionando o processamento de notificações de pagamento. A primeira versão do documento diz: receber o evento, localizar o usuário e prorrogar a assinatura. Isso basta para demonstrar a funcionalidade. Para um serviço em produção, ainda há perguntas a responder.

O que fazer se o mesmo evento chegar duas vezes? E se o banco de dados salvar a prorrogação, mas o servidor não conseguir confirmar o recebimento a tempo? E se a notificação de cancelamento do pagamento chegar antes da notificação de pagamento bem-sucedido? Esses são exemplos de possíveis perguntas de revisão, não um relato dos resultados do EGM.

O autor do documento pode ter discutido as novas tentativas no chat e considerado o assunto encerrado. Um revisor sem esse histórico vê uma lacuna: a especificação não contém regras para tratar eventos duplicados. Um engenheiro terá de definir como identificar duplicatas, onde armazenar o resultado do processamento e qual comportamento considerar correto após uma falha.

O responsável pelo produto também tem trabalho aqui. Reembolsos, cancelamentos de assinaturas e novas entregas de notificações afetam as promessas feitas ao usuário. Essas decisões não podem ficar inteiramente a critério do agente que escreve o código. Primeiro, a equipe define o comportamento do produto; depois, registra esse comportamento de forma que outra pessoa ou agente possa revisá-lo.

O que experimentar e quais são os limites

O site do EGM descreve as etapas de discussão da ideia, elaboração do documento e revisão. Também apresenta ferramentas para documentar um projeto existente e encontrar divergências entre a especificação e o código. Um ponto de partida razoável é uma única funcionalidade com decisões controversas: pagamentos, permissões de acesso ou tarefas em segundo plano.

Antes da revisão, é útil registrar as restrições e os critérios de aceitação. Depois, analisar as observações, corrigir o documento e só então avançar para a implementação. Para avaliar o benefício, é possível contar as lacunas confirmadas encontradas antes da programação e medir o tempo gasto na revisão. Essa é uma proposta de avaliação, não métricas publicadas sobre a eficácia do plugin.

O EGM não oferece fundamento para prometer a eliminação de erros de arquitetura. Agentes separados podem compartilhar os mesmos equívocos, e uma observação convincente pode estar errada. Rodadas adicionais também levam tempo e consomem tokens. O custo da revisão deve ser proporcional ao custo de um possível erro.

O projeto é distribuído sob a licença Apache 2.0; os autores ressaltam que ele não é um produto com suporte oficial do Google. A revisão exige contextos novos para os subagentes, e o processo não substitui testes nem o julgamento de engenharia — essas limitações estão explicitamente listadas no README.

O EGM propõe um hábito útil: antes da implementação, entregar a especificação a alguém que não participou de sua discussão. Se não for possível implementá-la sem explicações verbais, o documento ainda precisa de trabalho.