Por Canuto  

Google abrió el código de Elephant-Goldfish Model, un plugin que hace que los agentes de IA documenten un diseño y lo sometan a revisores independientes antes de programar. La propuesta busca detectar ambigüedades temprano, aunque las pruebas no incluyen métricas de precisión y ya hay reportes de límites de uso y problemas de aislamiento.
***

  • EGM no es un modelo de IA: organiza habilidades, revisores y documentos para que el agente redacte una especificación antes de escribir código.
  • Su revisión tiene cinco etapas y usa subagentes nuevos; las pruebas registradas incluyen 15 revisores en Codex y 16 en Antigravity CLI.
  • El proyecto no publica benchmarks de precisión, y reportes de uso y filtraciones de archivos de instrucciones muestran límites por resolver.

Google propone revisar el diseño antes de dejar que la IA escriba código

Google abrió el código de Elephant-Goldfish Model (EGM), un plugin que cambia el orden habitual de trabajo de los agentes de programación: primero deben redactar una especificación y después someterla a revisión, antes de empezar a producir código. La propuesta intenta descubrir supuestos equivocados y ambigüedades cuando todavía están en un documento de diseño, en vez de esperar a que aparezcan dentro de una implementación o un pull request.

El proyecto no es un nuevo modelo de lenguaje ni incluye pesos propios. En su lugar, aporta instrucciones, habilidades y perfiles de revisión que se ejecutan con el modelo y la cuota disponibles en el agente que use cada persona; el repositorio indica, además, que no se trata de un producto oficialmente soportado por Google. MarkTechPost describió el lanzamiento y los materiales del proyecto como una herramienta para estructurar el trabajo de agentes de codificación.

Una etapa de diseño antes de la programación

El nombre representa dos papeles distintos dentro del flujo: el Elefante conserva el contexto amplio del proyecto y redacta la especificación, mientras cada Goldfish es un subagente nuevo, sin el historial de conversación de la sesión principal. La separación pretende reducir el riesgo de que quienes evalúan el documento hereden las suposiciones que guiaron su redacción, aunque el método depende de que el agente anfitrión pueda lanzar subagentes independientes.

La especificación funciona como punto de control entre una idea y su ejecución técnica. El agente principal puede mantener decisiones previas y detalles del proyecto para elaborar el documento, pero no debe escribir código durante esa etapa; luego, los revisores reciben el borrador y los archivos que este menciona, y buscan problemas antes de que el equipo apruebe el diseño. La decisión final sobre las compensaciones y la aprobación sigue en manos de la persona usuaria. El blog de código abierto de Google presenta el marco como una forma de desarrollar con IA con las personas intencionalmente involucradas.

El plugin reúne siete habilidades, nueve perfiles de revisión, seis lentes para explorar ideas y una revisión estructurada en cinco etapas. Esas cifras describen componentes del sistema, no resultados de calidad: la información disponible no incluye una prueba comparativa que demuestre cuánto mejora la precisión del código o cuántos errores evita frente a otros métodos.

La herramienta se distribuye bajo la licencia Apache 2.0 y no requiere comprar un modelo específico, pero tampoco elimina los costos de inferencia. Como los agentes ejecutan el trabajo con la cuota del modelo anfitrión, las rondas de análisis y las llamadas de subagentes pueden incrementar el consumo; el material disponible destaca la intensidad de uso de tokens como una de las desventajas del proceso.

Del brainstorming a una especificación verificable

El primer comando, /egm-brainstorm, ayuda a precisar la idea y convoca un grupo de revisores que la examina desde seis ángulos: YAGNI, costo de tokens, experiencia de usuario, migración, observabilidad y deuda técnica. La salida es un archivo llamado concepts_brief.md, pensado para dejar por escrito las decisiones iniciales antes de convertirlas en un diseño más formal.

Después, /egm-draft transforma ese resumen en un documento de diseño dentro de docs/designs/. El proceso construye la especificación sección por sección, lo que permite revisar sus componentes sin saltar de inmediato a la implementación; en esta lógica, el documento no es un trámite, sino el objeto que debe exponer los requisitos, las rutas de archivos y las decisiones técnicas que el equipo quiere validar.

El tercer comando, /egm-review, activa la revisión de los subagentes y permite que los hallazgos se clasifiquen como Blocker, Major o Nit. La secuencia contempla una sola reauditoría por etapa como máximo, de modo que el proceso no plantea rondas ilimitadas de correcciones; el equipo puede usar las categorías para distinguir obstáculos que impiden avanzar de observaciones menos críticas.

Una vez que existe código, /egm-drift-report compara la implementación con la especificación para señalar diferencias entre lo aprobado y lo construido. La documentación recomienda repetir ese informe semanalmente, pero la función no reemplaza la revisión previa: busca detectar desvíos posteriores, mientras EGM intenta que los problemas de comprensión o diseño aparezcan antes de que la programación los convierta en cambios más costosos.

Cinco etapas para someter el diseño a crítica

La primera fase, llamada Zoom Out Inicial, revisa el documento de manera general y busca fallas de alto nivel. En la segunda, la Prueba de Comprensión, un revisor parafrasea el diseño; si no logra describirlo correctamente, el sistema interpreta esa discrepancia como una señal de ambigüedad que conviene resolver antes de continuar.

La tercera fase es una revisión crítica en la que distintos perfiles buscan vacíos, problemas de estructura, decisiones débiles y casos límite. Después, el Zoom Out Intermedio vuelve a examinar la arquitectura una vez aplicadas las correcciones, para comprobar que los cambios no hayan introducido contradicciones o alterado el planteamiento general del diseño.

La quinta y última etapa, Preparación para Implementación, verifica elementos concretos como rutas de archivos, estructuras de datos y firmas. La revisión avanza en orden y permite como máximo una reauditoría por fase, según la descripción del proyecto; así, el control pasa de preguntas amplias sobre el diseño a comprobaciones más cercanas al trabajo que requerirá la implementación.

El aislamiento de contexto es una condición central, no un detalle opcional: si el anfitrión no puede iniciar un subagente, EGM se detiene, porque una revisión dentro de la misma conversación no cuenta como revisión Goldfish. La independencia puede ayudar a que los evaluadores no repitan los razonamientos del agente principal, aunque los reportes disponibles también advierten que ese aislamiento no está garantizado de la misma manera en todos los entornos.

Compatibilidad, pruebas y límites reportados

La cobertura inicial del lanzamiento describió soporte para Antigravity, mientras que la guía actual de entornos enumera Antigravity CLI y App, Claude Code, Claude Cowork, Codex, ChatGPT, omp y Muse. La documentación identifica pruebas automatizadas de extremo a extremo para Antigravity CLI, Claude Code y Codex, y establece que Claude Code requiere la versión 2.1.271 o posterior.

El registro de pruebas citado por el proyecto informa que Antigravity CLI 1.4.5 ejecutó 16 revisores nativos en el orden previsto. Para Codex 0.163.0, el registro consigna 15 revisores nativos y dos pruebas en vivo completadas en 573,13 segundos; otra suite de Codex CLI, con el ZIP v0.1.0, terminó con aprobación en 482,30 segundos.

Esos resultados describen ejecuciones del flujo, pero no equivalen a un benchmark que mida la exactitud de las revisiones o su ventaja frente a herramientas competidoras. El material no publica métricas de precisión, por lo que las cifras disponibles permiten observar que ciertos entornos completaron las pruebas registradas, pero no establecer cuántos errores reales detectan ni si el método mejora sistemáticamente el software producido.

También hay límites operativos documentados. Una ejecución de Claude Cowork se detuvo entre las etapas cinco y siete por un límite de uso, mientras el issue número 237 reporta que el archivo AGENTS.md se filtra en el contexto de revisores de Codex; para Claude Code, la documentación señala que los revisores reciben únicamente las herramientas Read, Grep y Glob, y que los archivos CLAUDE.md quedan excluidos de su contexto.

Qué distingue a EGM de otras herramientas

El proyecto compara su enfoque con GitHub Spec Kit, Kiro Specs y Superpowers. Según la tabla publicada, EGM es un plugin con licencia Apache 2.0, mientras Spec Kit y Superpowers usan MIT y Kiro es comercial; sus flujos también difieren en cómo organizan las fases de definición, planificación, revisión y ejecución.

La diferencia que EGM destaca es que sus subagentes revisan la especificación con contexto fresco antes de que exista código. La tabla describe a Spec Kit como un flujo de constitución, especificación, planificación, tareas, implementación y convergencia, y a Kiro como un proceso de requisitos, diseño y tareas; para ambos, no se divulga allí una revisión equivalente de especificaciones por subagentes nuevos.

Superpowers, de acuerdo con esa misma comparación, usa subagentes principalmente durante la implementación y para revisar código por tarea, no para someter el diseño a una auditoría previa equivalente. La distinción no demuestra por sí sola que un sistema sea más eficaz que otro: señala el momento en que cada herramienta concentra la revisión y el tipo de material que pone frente a los agentes.

En conjunto, EGM propone una disciplina de trabajo: mantener el contexto del proyecto en un agente, pedir a revisores separados que cuestionen el diseño y recién después pasar a programar. Su valor dependerá de que los equipos acepten el costo de esas rondas y de que los entornos mantengan el aislamiento prometido; por ahora, la evidencia publicada muestra pruebas de funcionamiento, pero no una medición comparativa de calidad.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados