Google open-source Elephant-Goldfish : les specs doivent survivre à un critique sans contexte

En bref

Google a open-sourcé le plugin Elephant-Goldfish Model le 22 octobre sous licence Apache 2.0, un workflow que « des milliers de Googlers » exécutent déjà quotidiennement pour livrer du code en production.
Deux rôles d’agents, délibérément asymétriques : un Elephant tient une session à long horizon et n’écrit aucun code, tandis que des sessions Goldfish sans état n’héritent de rien et sont envoyées pour attaquer la conception.
La revue se fait en trois portes étagées — compréhension, revue antagoniste, maturité d’implémentation — chacune étant un go/no-go plutôt qu’un fil de commentaires.
L’affirmation qui mérite d’être testée est que c’est la qualité du contexte, et non celle du modèle, qui fait échouer les agents de codage. Si c’est vrai, la cible de revue la moins coûteuse est la spécification, pas le diff.

Le problème de vélocité que Google reconnaît

L’annonce ne commence pas par les capacités. Elle commence par un mode de défaillance. Les équipes outillées par l’IA « ont silencieusement introduit une crise de fiabilité potentielle en augmentant aussi la vélocité du slop, des bugs et de l’effondrement du contexte de session », écrit l’équipe, ajoutant que « la vitesse pure sans garde-fous structurés signifie que nous auto-scalons souvent nos erreurs plutôt que d’écrire simplement du code plus vite. » (Source : Google Open Source Blog — Introducing the Elephant-Goldfish Model plugin)

Cette phrase constitue tout l’argumentaire du plugin, et elle est d’une franchise inhabituelle pour une annonce d’éditeur. L’équipe — Brian Suchy, Jim Quinn, Elise Ewing et Dave Rensin — a construit le workflow en interne avant de le publier. Le cadrage de Rensin en est la pièce porteuse : « Le design est le nouveau code. » Si le design est l’artefact, alors c’est le design qu’il faut réviser, versionner et défendre.

Deux animaux, deux modes de défaillance

La métaphore traduit une tension d’ingénierie bien réelle. Un agent travaillant au sein d’une longue session accumule du contexte : l’intention d’origine, les compromis rejetés en chemin, la raison pour laquelle une table est dénormalisée. Cette accumulation est ce qui le rend utile et ce qui le rend aveugle. Il défendra ses propres décisions antérieures parce que ces décisions font partie du contexte sur lequel il raisonne.

L’Elephant est cette session, et il lui est interdit d’écrire du code. La phase un (egm-brainstorm) charge le contexte système et s’exécute sous une règle stricte de « no code » : le modèle interroge le développeur, débat des compromis et capture les micro-décisions. La phase deux (egm-draft) produit un document de conception Markdown couvrant la définition du problème, le plan technique, les alternatives envisagées et un plan d’implémentation qui énumère les fichiers précis à modifier.

Le Goldfish est l’inverse : une session sans état et sans contexte. Il n’a aucun parti pris sur la conception puisqu’il n’a aucun souvenir de l’avoir produite. La raison avancée par Google est celle des angles morts partagés — un relecteur qui hérite du contexte du concepteur hérite des erreurs du concepteur.

Le Goldfish Protocol, en trois portes

Le plugin automatise trois étapes de validation, et elles montent en exigence.

Vérification de compréhension. Un Goldfish frais lit l’intégralité du document de conception et doit expliquer l’architecture et l’intention à l’Elephant. S’il ne parvient pas à résumer le plan avec exactitude, le document est ambigu et repart pour un nouveau cycle de rédaction. C’est la porte la plus astucieuse, car elle convertit une question subjective — cette spécification est-elle bonne ? — en une question testable : un étranger informé peut-il la reconstruire ? C’est un test de lisibilité, pas un test de qualité.

Revue antagoniste. Plusieurs Goldfish endossent le rôle de relecteurs techniques sceptiques traquant les cas limites, les dépendances cachées et les lacunes logiques. Leur critique revient vers la session Elephant pour résolution. C’est ici qu’une spécification gagne ou perd ses prétentions en matière de gestion des défaillances, et c’est l’étape que la plupart des équipes sautent lorsqu’elles révisent directement du code généré.

Maturité d’implémentation. Un dernier Goldfish effectue un go/no-go strict : les chemins de fichiers, les structures de données et les signatures de fonctions sont-ils tous présents et non ambigus ? Tout élément manquant bloque la transmission. L’enjeu n’est pas l’exactitude mais la suffisance — si un agent pourrait transcrire le plan sans inventer de détails.

Alors, et seulement alors, le code est écrit. (Source : Google Open Source Blog — Introducing the Elephant-Goldfish Model plugin)

Pourquoi réviser la spécification coûte moins cher que réviser le diff

Faisons l’économie. Un diff de 40 lignes est peu coûteux à lire et coûteux à raisonner, car raisonner exige de reconstruire l’intention à partir d’un artefact qui ne montre que le résultat. Une spécification de deux pages est coûteuse à écrire et peu coûteuse à relire — par dix critiques différents, en parallèle, à un coût humain marginal quasi nul.

C’est cette asymétrie qu’exploite le plugin. Les relecteurs sans état peuvent être multipliés car dupliquer une session sans contexte ne coûte que des tokens. L’auto-revue ne peut pas être multipliée de la même manière : trois copies d’un agent qui croit déjà que le plan est correct seront d’accord entre elles pour la même raison.

L’autre bascule concerne l’endroit où les erreurs sont détectées. Un chemin d’erreur manquant repéré dans la spécification coûte un paragraphe. La même lacune repérée en revue coûte une réécriture. Repérée en production, elle coûte un incident — l’économie qui domine désormais les opérations d’agents, comme le montre explicitement la pile de boucles de rétroaction de DigitalOcean en vendant le rejeu de simulation comme ligne de produit.

Ce que la publication ne tranche pas

L’adoption n’est pas une preuve. « Des milliers de Googlers utilisent ce plugin chaque jour » est une affirmation de distribution, pas un résultat mesuré, et Google ne publie aucun avant/après sur les taux de défauts, le temps de revue ou les reprises. Traitez le workflow comme une hypothèse dotée de solides a priori.

Le plugin cible d’abord Antigravity, les autres environnements étant « à venir », si bien que l’expérience prête à l’emploi est mono-fournisseur. Le dépôt fournit bien la matière première pour le porter — règles Markdown personnalisables, personas de sous-agents définies, workflows de revue structurés — mais tout autre harnais est un portage à faire soi-même.

Il existe aussi un écart de fidélité que personne n’a comblé. Une spécification parfaite dépend encore de l’agent de codage qui l’implémente fidèlement, et le protocole s’arrête à la transmission. La réponse de Google est qu’une spécification assez détaillée pour passer la porte de maturité laisse peu de place à l’invention. C’est plausible et non démontré ; la vérification de maturité confirme que l’information est présente, pas que l’implémenteur l’a utilisée.

Enfin, la règle du « no code » est une discipline imposée par un prompt de persona, pas par un compilateur. Le plugin peut empêcher un Elephant d’écrire du code ; il ne peut pas empêcher un développeur d’ouvrir un second terminal et de sauter les trois phases. Les outils de processus qui reposent sur la retenue sont toujours adoptés de manière inégale.

Le véritable pari

Lisez cette publication comme une déclaration sur le déplacement des coûts. Si les agents génèrent du code plus vite que les humains ne peuvent le lire, la revue devient le goulot d’étranglement, et réviser davantage de code n’est pas une réponse soluble. Déplacer la revue en amont vers un document petit, lisible et éprouvé par l’adversité est la seule version qui passe à l’échelle — même si cela signifie que l’artefact le plus important du dépôt n’est plus exécutable.

FAQ

S’agit-il d’un produit Google ? Non. C’est un plugin open source sous Apache 2.0, à l’origine interne, publié sans engagement de support. Le dépôt est google/elephant-goldfish-model et la documentation se trouve sur egm.dev.

Remplace-t-il la revue de code ? Il la déplace en amont. Les trois portes Goldfish révisent la conception ; la revue de code classique s’applique toujours au diff produit par l’agent d’implémentation.

Pourquoi appeler le relecteur un poisson rouge ? Mémoire zéro. Une session sans état ne peut pas être loyale à la conception qu’elle révise, et c’est précisément l’objectif — la métaphore nomme le mécanisme, pas une insulte sur l’intelligence.

Puis-je l’utiliser en dehors d’Antigravity ? Le dépôt fournit des règles Markdown personnalisables et des définitions de personas, donc le portage est prévu. Antigravity est simplement la cible de première classe à la sortie.

Pour aller plus loin

— The Agent Report