Google anunció el 22 de octubre de 2026 el plugin abierto Elephant-Goldfish Model (EGM) para desarrollar software a partir de especificaciones. Recuperamos ese anuncio con su documentación actual: la idea central es separar la sesión que acumula decisiones de diseño de las sesiones que las cuestionan. El equipo humano conserva la decisión final.
EGM es un paquete de procedimientos y recursos para agentes, con licencia Apache 2.0. Su nombre no identifica unos pesos de modelo nuevos. El repositorio también advierte que no es un producto oficialmente soportado por Google.
Una sesión recuerda y otra examina lo escrito
El «elefante» mantiene contexto del sistema, requisitos y decisiones para elaborar una especificación. Los «peces» son revisores con contexto nuevo: examinan el documento y el código disponible sin heredar la conversación que condujo al diseño.
La separación pretende descubrir supuestos que el diseñador ha dado por entendidos. No convierte a los revisores en jueces infalibles: una sesión distinta también puede compartir errores del modelo o recibir una especificación incompleta. El artefacto que se revisa debe expresar las decisiones relevantes.
El anuncio describe tres fases: explorar el problema con egm-brainstorm, redactar el documento con egm-draft y revisarlo con egm-review. El repositorio actual amplía las herramientas de revisión y resolución. En su flujo básico, el documento se presenta para aprobación y después orienta la implementación; no sustituye las pruebas del código resultante.
Qué debe comprobar la revisión
El anuncio distingue comprensión del diseño, crítica de sus puntos débiles y preparación para implementarlo. Una sesión puede intentar explicar la arquitectura con sus propias palabras; otras cuestionan dependencias y casos límite; la comprobación final busca que rutas, estructuras e interfaces estén suficientemente definidas.
Ejemplo hipotético propio, no ejecutado por Puntoes: un equipo prepara la cancelación de pedidos de una tienda. La sesión de diseño recoge los estados permitidos. Un revisor aislado pregunta qué ocurre si el envío y la cancelación llegan a la vez, y quién puede autorizar cada transición. El equipo resuelve esa regla y define sus pruebas antes de dar por terminado el documento. Una aprobación automática no acredita que la concurrencia esté resuelta en producción.
El soporte actual tiene diferencias entre entornos
El anuncio del 22 se centraba en Antigravity y situaba otros entornos en el futuro. La documentación del repositorio consultada el 26 de octubre ya incluye Antigravity, Claude Code, Codex, Claude Cowork y ChatGPT Work. No permite fechar todos esos añadidos el día del anuncio.
Según el propio proyecto, Antigravity, Claude Code y Codex pasan comprobaciones automatizadas de instalación, aislamiento y flujo completo. Cowork y ChatGPT Work tienen vías de instalación con lagunas abiertas de verificación de trazas en la nube. Son evidencias y límites declarados por sus autores; Puntoes no ha reproducido esas pruebas.
También hay una condición funcional: la revisión necesita una herramienta que cree subagentes con contexto nuevo. Si el entorno no la ofrece, las skills de revisión se detienen, en lugar de simular aislamiento dentro de la misma conversación. Instalar solo la carpeta de skills tampoco basta: se necesitan las personas de revisión y los recursos del paquete.
Cuándo puede compensar
EGM aporta una estructura para discutir cambios que requieren decisiones explícitas. Su propia guía aconseja elegir el procedimiento según el problema, sin imponer todo el recorrido a una corrección sencilla. Más sesiones y revisiones pueden consumir tiempo, contexto y llamadas al modelo; la licencia del plugin no hace gratuito el servicio utilizado.
No hemos instalado EGM ni medido mejoras de calidad. Para valorarlo, conviene comprobar si el documento identifica decisiones y riesgos que antes quedaban implícitos. Como explicábamos sobre la portabilidad de Agent Skills, compartir recursos no garantiza que todos los entornos puedan ejecutarlos igual.