elephant-goldfish : Google cadre le coding spec-first
Google publie elephant-goldfish, un plugin open source qui impose une revue de spec en cinq étapes avant le code.
Google publie elephant-goldfish, aussi appelé Elephant-Goldfish Model ou EGM, un plugin open source pensé pour la conception logicielle avec des agents de code. L’idée est simple : faire rédiger une spécification avant le code, puis la faire relire par des agents qui n’ont pas accès à la conversation initiale.
Selon Google, le plugin a d’abord été développé en interne pour ses ingénieurs, avant d’être rendu public. Le groupe affirme que des milliers de Googlers l’utilisent chaque jour pour livrer du code de production Google.
Ce qui change concrètement
EGM pousse une approche de Spec-Driven Development, ou développement piloté par la spécification. Au lieu de demander directement à un agent de coder une fonctionnalité, tu lui fais d’abord produire un brouillon de spec. Cette spec devient l’objet central du travail.
La différence vient surtout des sessions dites Goldfish. La documentation de Google les décrit comme des sessions sans contexte, utilisées strictement pour valider des spécifications. Autrement dit, les reviewers lisent le brouillon et les sources référencées, mais pas la discussion qui a mené à ce brouillon. Cela limite un biais fréquent avec les agents : valider une solution parce qu’elle paraît cohérente avec l’échange précédent, et non parce que la spec est claire, complète et prête à implémenter.
Le dépôt officiel présente un workflow intégré avec cinq étapes de revue. Dans le skill de revue, ces étapes sont nommées :
- Initial Zoom Out Review : prise de recul initiale sur l’objectif et le cadrage.
- Comprehension Review : vérification de la compréhension par un reviewer qui découvre la spec.
- Design Critique : critique de la conception proposée.
- Intermediate Zoom Out Review : nouvelle prise de recul après les premiers retours.
- Implementation Readiness : validation du niveau de préparation avant passage au code.
Le même skill indique qu’un rapport consolidé peut exécuter les cinq étapes sans pause intermédiaire. La documentation décrit aussi une orchestration plus fine avec un Comprehension Test par le sous-agent egm-comprehension, puis une Critic Review avec les reviewers egm-design, egm-structural et egm-style. Pour une équipe produit ou engineering, l’intérêt est clair : demander à l’agent de prouver que la spec tient debout avant de lui confier l’implémentation.
Comment l'essayer
Le dépôt elephant-goldfish-model est public sur GitHub. Il mentionne une licence Apache 2.0. Le fichier plugin.json indique Google comme éditeur et une version 0.1.1 du plugin.
La documentation de démarrage donne plusieurs chemins d’installation. Pour Antigravity CLI, la commande indiquée est : agy plugin install https://github.com/google/elephant-goldfish-model. Pour Claude Code, Google indique d’ajouter le marketplace avec claude plugin marketplace add google/elephant-goldfish-model, puis d’installer claude plugin install egm@egm. Pour Codex CLI, la documentation mentionne codex plugin marketplace add google/elephant-goldfish-model, puis codex plugin add egm@egm.
Pour l’extension OpenAI, le manifeste précise que requires_local_executor vaut true et que les reviews exigent des sous-agents isolés. La page sur les environnements indique aussi que Antigravity IDE standalone n’est pas supporté. Elle liste notamment Claude Cowork, Antigravity CLI, Antigravity App, Antigravity IDE et omplus Muse parmi les environnements testés ou documentés. ChatGPT desktop et Codex desktop sont décrits avec un plugin EGM publié et une liste desktop-only.
Côté prix, Google ne communique pas de tarif spécifique pour le plugin dans ces pages. Côté disponibilité en France, aucune restriction géographique France ou Europe n’est indiquée dans la documentation officielle consultable publiquement sur GitHub.
Pour qui, et pour quoi faire
EGM vise surtout les équipes qui utilisent déjà des agents de code pour accélérer l’écriture logicielle, mais qui veulent mieux contrôler la phase amont. Le plugin peut être utile à un lead dev, un architecte, un engineering manager ou un product engineer qui doit transformer un besoin métier en tâche fiable pour un agent.
Exemple concret : tu veux faire modifier un module de facturation interne. Au lieu de demander à l’agent de coder directement, tu lui fais rédiger une spec qui décrit le comportement attendu, les contraintes, les fichiers concernés et les critères de validation. Les reviewers Goldfish examinent ensuite la spec sans connaître la conversation initiale. S’ils ne comprennent pas l’intention, s’ils trouvent un angle mort de design ou si l’implémentation paraît prématurée, le problème remonte avant la génération de code.
Ce mécanisme est particulièrement intéressant pour les tâches où une erreur de compréhension coûte cher : refonte d’API, migration, logique de permissions, workflow métier, changement de modèle de données. Il peut aussi servir de rituel d’équipe : une spec validée par revue agentique devient un meilleur point de départ pour une pull request générée ou assistée.
Si ton entreprise structure ses premiers usages d’agents, le guide NXUS sur comment faire travailler un agent IA dans son entreprise peut aider à cadrer les rôles, les contrôles et les limites humaines à conserver.
Limites et points de vigilance
EGM ne remplace pas une revue humaine. Une revue sans contexte est utile pour tester la clarté d’une spec, mais elle peut aussi passer à côté d’informations implicites que l’équipe connaît. Il faut donc choisir avec soin les sources à référencer dans la spec : documentation, contraintes produit, tickets, décisions d’architecture.
Autre point : le plugin dépend des environnements compatibles et de leur capacité à lancer des sous-agents isolés. Si ton poste ou ton outil ne permet pas cette isolation, l’intérêt du modèle Goldfish diminue. La documentation signale d’ailleurs des différences de support selon les harnesses, avec un cas explicitement non supporté pour Antigravity IDE standalone.
Enfin, la version indiquée dans le manifeste est 0.1.1. C’est un signal à prendre en compte pour un usage en entreprise : verrouille les versions, teste sur un dépôt non critique et documente le comportement attendu avant intégration dans un workflow de production.
L'avis NXUS
EGM répond à un vrai problème des agents de code : ils peuvent produire vite, mais sur une intention mal cadrée. Le principe de revue sans contexte est pertinent, car il teste la lisibilité de la spec comme le ferait un développeur qui arrive sur le sujet.
Pour l’adopter, commence par un cas limité : une petite fonctionnalité, une correction bien bornée ou une refonte locale. Compare ensuite la qualité des specs, le nombre d’allers-retours et les erreurs évitées avant d’en faire un standard d’équipe.
Le bon usage n’est pas de déléguer la décision à l’agent. C’est de forcer une meilleure préparation avant le code, puis de garder une validation humaine sur l’architecture, la sécurité et les impacts métier.
Sources
Source : GitHub
Rudy Molinillo
