Google ha publicado en GitHub Elephant-Goldfish Model (EGM), un plugin de código abierto para asistentes de programación que separa dos papeles: un agente con todo el contexto del proyecto redacta la especificación de diseño y varios agentes sin memoria de la conversación la revisan antes de escribir una sola línea de código. El repositorio, con licencia Apache 2.0, recibió su primer commit el 21/10/2026, etiquetó la versión 0.1.0 el 26/10/2026 y el 06/11/2026 ya iba por la 0.1.1. Funciona con Claude Code, Codex, Antigravity y otros entornos de agentes.
Las claves de Elephant-Goldfish Model en 20 segundos
- EGM es un plugin abierto (Apache 2.0) publicado en la cuenta de Google en GitHub.
- El «elefante» redacta el diseño con contexto; los «peces de colores» lo revisan sin memoria.
- Se basa en un ensayo de abril de 2026 del ingeniero de Google Dave Rensin.
- No es un producto con soporte oficial ni aporta pruebas de productividad.
Pese a lo que sugiere el nombre, EGM no es un modelo de lenguaje ni un sistema de memoria para modelos. Es un conjunto de instrucciones (skills, en la jerga de estos asistentes) y de perfiles de revisor escritos en Markdown que se instalan como plugin en el agente de programación que ya use el desarrollador. El propio README lo resume con una frase: «Design with an elephant. Review with a goldfish» (diseña con un elefante, revisa con un pez de colores; traducción propia). Al final del mismo documento aparece el aviso habitual en los repositorios de la organización: «This is not an officially supported Google product».
El proyecto llega en un momento en que muchos equipos buscan poner orden en el trabajo con agentes. La idea de escribir primero una especificación y generar el código después no es nueva, y noticias.ai ya repasó el desarrollo guiado por especificaciones con herramientas como Spec Kit y Kiro. Lo que añade EGM es un método concreto para revisar esa especificación con agentes que no han visto la conversación en la que nació.
Un elefante que recuerda y peces de colores que no
La metáfora procede de un ensayo que Dave Rensin, ingeniero distinguido de Google, publicó en Medium el 27/04/2026 y que Google Research incluye en su listado de publicaciones. Rensin define el elefante como la sesión de IA cargada de instrucciones y contexto, junto con el documento de diseño que ayuda a escribir. El pez de colores es una sesión nueva, sin memoria. Si esa sesión no es capaz de entender el sistema leyendo solo el documento, el documento está incompleto. El autor lo condensa así: «Feed the Elephant; test it against the Goldfish».
El plugin reparte el trabajo en tres papeles, tal como los describe el README:
| Papel | Qué conoce | Qué hace |
|---|---|---|
| Elefante | El proyecto, los requisitos y las decisiones previas | Analiza el problema y redacta la especificación |
| Peces de colores | El documento y el material que cita, sin la conversación anterior | Buscan supuestos no escritos, requisitos confusos y riesgos de implementación |
| Desarrollador | Los objetivos y las restricciones que importan | Decide los compromisos, aprueba el diseño y elige qué se construye |
Las siete skills cubren el ciclo completo: Brainstorm para discutir una idea y dejarla en un breve de concepto, Draft para convertirla en un documento de diseño sección a sección, Review para revisarlo, Resolve para trabajar las observaciones, Review loop para lanzar un grupo de revisores a medida, Bootstrap para documentar un código ya existente y Drift report para detectar en qué se ha separado la documentación del código actual. La revisión de diseño tiene cinco fases: una mirada general inicial, una de comprensión, la crítica del diseño, una segunda mirada general y la comprobación de que el plan se puede implementar.
Cada revisor tiene un perfil propio en la carpeta de agentes: un arquitecto escéptico que defiende la simplicidad, un lector ingenuo que señala siglas y términos sin definir, un crítico de diseño centrado en la arquitectura y los costes, un jefe técnico que exige instrucciones accionables, un auditor que contrasta el documento con el código y otros dos dedicados a la estructura y al estilo. El 05/11/2026 se sumó un revisor basado en TRIZ, un método de resolución de problemas que busca eliminar contradicciones técnicas. Las instrucciones prohíben a los revisores los halagos y les piden empezar por lo que falla.
Instalación y entornos compatibles
EGM se instala como plugin completo, porque las skills leen en tiempo de ejecución los perfiles de los revisores y las normas de documentación. En Claude Code, el README indica estos dos comandos:
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egmHay instrucciones equivalentes para la línea de comandos de Antigravity y de Codex, y un plugin publicado para las versiones de escritorio de ChatGPT y Codex. La documentación también recoge Claude Cowork, omp y Muse. El flujo básico se reduce a tres pasos: /egm-brainstorm con la descripción de la función que se quiere añadir (el ejemplo oficial es la entrega de webhooks), /egm-draft para generar el archivo design_draft.md y /egm-review design_draft.md para la revisión. En Claude Code y Antigravity los comandos llevan el prefijo /egm:.
Hay un requisito técnico que no se puede saltar. La revisión exige que el agente pueda crear subagentes con contexto limpio, y si no puede, EGM detiene el proceso en lugar de hacer la revisión en la misma sesión. Por ese motivo la versión independiente del IDE Antigravity no está soportada. Según la propia documentación, solo Antigravity CLI, Claude Code y Codex superan las pruebas automáticas de instalación y de flujo completo. Las pruebas unitarias del repositorio usan Python 3.10 o superior y validan el formato de los archivos, no el resultado de las revisiones. Anthropic, por su parte, ha recomendado hace poco usar menos subagentes y volver al bucle del agente principal, así que el enfoque de EGM depende de una capacidad que no todos los proveedores priorizan igual.
Lo que el proyecto no demuestra
EGM no viene acompañado de un artículo científico, de pruebas comparativas ni de mediciones de rendimiento. Su FAQ lo admite de forma directa: completar el flujo no demuestra por sí solo una mejora de productividad, y diseñar y revisar lleva tiempo que puede no compensar en cambios pequeños y bien conocidos. Recomienda medir en tareas propias el tiempo total, las observaciones útiles y el trabajo rehecho. También reconoce que el volumen de documentación puede convertirse en un cuello de botella para quien revisa.
Las cifras disponibles proceden del ensayo de Rensin y él mismo las presenta como anecdóticas. Escribe que, a los pocos meses de lanzar una herramienta interna, más de 100.000 empleados de Google la usaban de forma habitual, y que alrededor del 30 % de las sugerencias del revisor crítico le resultan muy valiosas, algo que considera suficiente para que el método compense. También advierte de que, al generar documentación para un código existente, la IA se equivoca en torno a la mitad de las veces en los directorios más profundos, porque solo cuenta con el código. Su texto habla de mejoras de productividad de 10 veces, pero no aporta mediciones que lo respalden.
Queda además la cuestión del aislamiento real de los revisores. La documentación explica que un contexto nuevo no garantiza que el entorno omita sus archivos de instrucciones, y cita una incidencia según la cual Codex CLI 0.166.0 entregaba al revisor los archivos AGENTS.md del proyecto y del usuario pese a estar configurado para no heredar turnos. En Claude, los adaptadores de revisor desactivan expresamente la lectura de CLAUDE.md. El proyecto insiste en que una revisión no sustituye a las pruebas ni al criterio humano.
La actividad del repositorio es alta para un proyecto tan joven: más de 150 commits en algo más de dos semanas y una treintena de autores distintos. Su política de contribuciones acepta código escrito con ayuda de IA, pero exige que una persona revise, entienda y defienda cada cambio, y obliga a pasar por el propio flujo de EGM los cambios de más de 100 líneas en las skills o los perfiles de revisor.
Preguntas frecuentes
¿Qué es Elephant-Goldfish Model de Google?
Es un plugin de código abierto para asistentes de programación como Claude Code, Codex o Antigravity. Un agente con contexto redacta la especificación de diseño y varios agentes sin memoria de la conversación la revisan antes de implementar.
¿Es un producto oficial de Google?
No. Se publica en la cuenta de Google en GitHub con licencia Apache 2.0, pero el README indica que no es un producto con soporte oficial de la compañía.
¿Qué necesita para funcionar?
Un agente de programación compatible que pueda crear subagentes con contexto limpio. Si no puede, la revisión se detiene, y por eso el IDE independiente de Antigravity no está soportado.
¿Mejora la productividad?
El proyecto no lo demuestra. Su FAQ dice que depende del cambio y aconseja medir en tareas propias el tiempo total, las observaciones útiles y el trabajo rehecho.
Fuentes:
- GitHub: repositorio google/elephant-goldfish-model (README, licencia e historial)
- GitHub: documentación de entornos compatibles de EGM
- GitHub: preguntas frecuentes de EGM
- Medium: Elephants, Goldfish and the New Golden Age of Software Engineering (Dave Rensin)
- Google Research: ficha de la publicación
