Ferramentas de inteligência artificial para programação já conseguem gerar trechos de código em poucos segundos. O problema é que velocidade não resolve, por si só, requisitos mal definidos, decisões arquiteturais esquecidas e falhas que passam de uma sessão para outra. Para enfrentar esse cenário, o Google abriu o Elephant-Goldfish Model plugin, uma metodologia que separa a construção do entendimento da revisão crítica antes da implementação. A proposta foi apresentada no Google Open Source Blog em 22 de outubro de 2026.
O nome faz referência a dois comportamentos complementares. O Elephant, ou elefante, representa uma sessão de IA com contexto longo, memória do projeto e visão arquitetural. O Goldfish, ou peixe dourado, representa uma sessão sem contexto anterior, usada para examinar uma especificação com distanciamento. Juntos, eles formam um fluxo de desenvolvimento orientado por projeto, com a pessoa desenvolvedora no papel de quem define a intenção e avalia as decisões importantes.
Por que separar design e código
Assistentes de código são bons em transformar instruções em alterações concretas, mas podem começar a programar antes que o problema esteja suficientemente compreendido. Uma conversa longa também cria um risco menos visível: a mesma sessão que ajudou a tomar uma decisão passa a revisar essa decisão com os mesmos pressupostos e pontos cegos. Se uma dependência foi esquecida no início, o agente pode continuar tratando a premissa como verdadeira por dezenas de mensagens.
O Elephant-Goldfish Model tenta reduzir esse efeito com uma divisão explícita. Primeiro, uma sessão com bastante contexto entrevista a pessoa usuária, registra as escolhas e organiza o desenho da solução. Depois, instâncias sem a memória da conversa original recebem o documento e tentam encontrar ambiguidades, casos extremos e dependências ausentes. A revisão não é uma etapa genérica de correção de estilo. Ela funciona como um teste de compreensão e de prontidão para implementação.
Essa abordagem é relevante para quem usa ferramentas de IA no trabalho diário porque muda o ponto de controle. Em vez de acompanhar cada linha sugerida pelo modelo, o desenvolvedor pode concentrar a atenção na definição do problema, nas alternativas descartadas e na aprovação do plano. O código continua precisando de testes e revisão humana, mas a discussão sobre o que deve ser construído acontece antes de o agente modificar vários arquivos.
O que o plugin do Google acrescenta
O plugin é a implementação aberta do método EGM. Segundo o Google, ele nasceu dentro da empresa e passou a ser distribuído sob a licença Apache 2.0. O pacote reúne regras em Markdown, personas para subagentes e fluxos estruturados de revisão. A intenção é automatizar a passagem de contexto entre as sessões, coordenar os ciclos de validação e gerar documentos de design que possam orientar a implementação.
O lançamento tem como foco inicial o Antigravity, ambiente de desenvolvimento citado pelo Google. A empresa afirma que outros ambientes deverão ser contemplados posteriormente. Isso significa que a ideia não é apenas conversar com um assistente sobre arquitetura, mas incorporar uma sequência reutilizável ao processo de desenvolvimento. O repositório também pode ser adaptado por equipes que queiram modificar as regras, os papéis dos revisores ou o formato dos documentos.
As três etapas do fluxo Elephant-Goldfish
1. Brainstorm sem escrever código
A primeira fase usa o comando egm-brainstorm. A regra central é não produzir código. A sessão Elephant recebe o contexto do sistema e trabalha como uma parceira de análise: faz perguntas, explora objetivos, discute restrições e coloca em dúvida decisões que ainda não foram justificadas. O resultado esperado é um entendimento compartilhado do problema, não um protótipo apressado.
Na prática, essa fase pode esclarecer quem usa o recurso, qual comportamento é considerado correto, que dados entram e saem, quais integrações já existem e que riscos não podem ser aceitos. Também é o momento de comparar caminhos possíveis. Para uma equipe brasileira que mantém um produto em produção, isso ajuda a registrar questões como compatibilidade com versões antigas, impacto em infraestrutura e necessidade de documentação para pessoas que trabalham em fusos horários diferentes.
2. Draft da especificação com contexto
A segunda fase usa o comando egm-draft. A sessão Elephant transforma as decisões em um documento Markdown com a definição do problema, o plano técnico, as alternativas consideradas e um roteiro detalhado de implementação. A especificação deve indicar os arquivos que serão alterados, as estruturas de dados envolvidas e as assinaturas de funções necessárias.
Essa exigência parece burocrática, mas cumpre uma função importante. Uma instrução como melhorar o login deixa espaço demais para interpretação. Já um documento que descreve o fluxo de autenticação, os estados de erro, a origem dos dados, os limites de permissão e os testes esperados dá ao agente uma superfície de trabalho verificável. O plano também se torna um artefato que uma pessoa pode ler sem reconstruir toda a conversa com o modelo.
3. Revisão adversarial sem memória anterior
A terceira fase usa o comando egm-review e aciona o Goldfish Protocol. As sessões Goldfish são deliberadamente sem estado anterior. Elas recebem a especificação e cumprem três verificações. Na checagem de compreensão, o revisor precisa explicar a arquitetura e a intenção do plano. Se não consegue fazer isso, a documentação ainda está ambígua.
Na revisão antagônica, diferentes instâncias assumem o papel de críticas técnicas. Elas procuram casos extremos, dependências escondidas, contradições e lacunas lógicas. O retorno é encaminhado à sessão Elephant, que pode revisar o documento com o contexto completo do projeto. Por fim, a checagem de prontidão para implementação avalia se há informação suficiente para uma decisão de vai ou não vai. O objetivo é verificar se caminhos de arquivo, estruturas e assinaturas estão claros, e não apenas se o texto parece convincente.
O que muda para quem desenvolve com IA
A diferença mais importante está na relação entre contexto e independência. Contexto é valioso para criar uma solução coerente, porque permite considerar decisões antigas e restrições do sistema. Porém, o mesmo contexto pode formar uma bolha de confirmação. Uma sessão sem memória não conhece as justificativas que levaram à especificação e, por isso, pode fazer perguntas básicas que uma equipe acostumada ao projeto deixou de fazer.
O método também estabelece uma fronteira mais clara para a automação. A IA pode ajudar a explorar alternativas, redigir o plano e simular uma revisão, mas o julgamento sobre prioridades e riscos continua humano. O Google descreve esse papel como uma mudança de gerente de cada detalhe para revisor executivo. A expressão não elimina a responsabilidade técnica. Ela sugere que a pessoa deve revisar decisões de alto impacto e os critérios de aceitação, em vez de tentar supervisionar cada token produzido.
Para equipes pequenas, um fluxo desse tipo pode funcionar como uma memória operacional. Para equipes maiores, pode padronizar o mínimo que uma mudança precisa explicar antes de entrar no código. Em ambos os casos, o ganho potencial está menos em gerar mais linhas por hora e mais em evitar retrabalho causado por uma especificação que nunca foi realmente compartilhada.
Limites e cuidados antes de adotar
O plugin não transforma uma resposta de IA em verdade técnica. Uma revisão Goldfish pode deixar passar um problema, sugerir uma mudança inadequada ou não perceber uma restrição que não foi incluída no documento. A independência entre sessões reduz alguns pontos cegos, mas não substitui especialistas, testes automatizados, análise de segurança nem validação com usuários.
Também é preciso observar o custo operacional. Cada etapa acrescenta tempo, chamadas de modelo e manutenção de regras. Um projeto simples pode não precisar de três ciclos formais para cada alteração. O melhor uso tende a estar em mudanças que atravessam vários módulos, alteram contratos de API, lidam com dados sensíveis ou serão mantidas por muitas pessoas. A equipe deve adaptar o nível de rigor ao risco, sem transformar o processo em uma sequência automática que ninguém lê.
Outro ponto é a dependência do ambiente. O anúncio posiciona o plugin primeiro no Antigravity, enquanto a expansão para outras ferramentas ainda é futura. Antes de prometer adoção ampla, vale confirmar a compatibilidade com o editor, o agente de programação, o sistema de controle de versão e as políticas de segurança da empresa. Como o projeto é aberto, essas regras podem ser estudadas e modificadas, mas a adaptação ainda exige trabalho técnico.
Por que a ideia importa agora
A popularização de agentes que planejam e alteram software aumenta o valor de uma especificação que possa ser examinada por pessoas e máquinas. Quando a geração de código fica mais rápida, o gargalo passa a ser decidir o que merece ser construído e provar que a decisão foi compreendida. O Elephant-Goldfish Model propõe uma resposta concreta: usar uma sessão longa para construir intenção e sessões sem memória para desafiar essa intenção.
O resultado não é uma promessa de código perfeito depois de pressionar Enter. É um processo para tornar erros de entendimento mais visíveis antes da implementação. Para quem desenvolve no Brasil com ferramentas de IA, o plugin merece acompanhamento porque oferece um modelo prático de revisão que pode ser testado em projetos reais, adaptado ao português e integrado a rotinas existentes. A contribuição mais importante do EGM talvez seja lembrar que, em um fluxo automatizado, o documento de design não é um intervalo entre a ideia e o código. Ele é o principal lugar onde a decisão técnica pode ser discutida, contestada e melhorada.
