Revisión de especificaciones con agentes: el modelo EGM

Revisión de especificaciones con agentes: un elefante y varios peces

El jueves 22 Google publicó en su blog de código abierto el plugin Elephant-Goldfish Model (EGM), y me ha gustado más de lo que esperaba. Es una forma concreta de hacer revisión de especificaciones con agentes antes de escribir una sola línea de código, justo donde yo creo que se ganan o se pierden los proyectos con IA.

Lo cuenta Google, y yo todavía no lo he probado. Lo que sigue es lo que he leído en su anuncio y en la web del proyecto, con mi opinión encima.

La idea: el elefante diseña, los peces dudan

El modelo se apoya en una metáfora sencilla:

• El elefante es una sesión de IA larga y con mucho contexto: conoce la arquitectura y la memoria del proyecto. Ahí no se escribe código. Se diseña, se debaten las decisiones y la IA te entrevista.
• Los peces (goldfish) son sesiones sin estado y sin contexto, que solo sirven para validar la especificación. Como no comparten los puntos ciegos de quien la diseñó, hacen de críticos objetivos y buscan huecos y casos límite.

El objetivo, según Google, es que la IA produzca el código que querías a la primera, cuando por fin pulsas Enter. Y la frase que resume todo el planteamiento: “Design is the new code”.

Cómo funciona el flujo

El plugin automatiza tres fases:

1. Brainstorm (egm-brainstorm): cargas el contexto del sistema y, con una regla de “nada de código”, diseñas la funcionalidad, discutes alternativas y cuestionas supuestos.
2. Borrador (egm-draft): se redacta un documento de diseño en Markdown con el problema, el plan técnico, las alternativas consideradas y un plan de implementación que enumera los ficheros concretos a tocar.
3. Revisión con goldfish (egm-review): aquí está lo interesante. Son tres pasos:
   • Comprobación de comprensión. Un goldfish lee el documento entero y tiene que explicárselo de vuelta al elefante. Si no es capaz de resumir el plan, el documento es ambiguo y toca seguir redactando.
   • Revisión antagonista. Varios goldfish hacen de revisores escépticos y buscan casos límite, dependencias ocultas y huecos lógicos. Sus críticas vuelven al elefante para resolverlas.
   • Comprobación de que está listo para implementar. Un último goldfish dice sí o no: mira que estén todas las rutas de ficheros, las estructuras de datos y las firmas de funciones, sin ambigüedad.

Según la web del proyecto, hay además un informe de desviaciones (egm-drift-report) para comparar cada semana el código con las specs y ver dónde se separan. Todo está bajo licencia Apache 2.0, con reglas en Markdown personalizables, personas de subagentes definidas y flujos de revisión listos para usar.

Por qué me parece buena idea

Lo que más me gusta es la comprobación de comprensión. Es una prueba muy simple y muy difícil de engañar: si alguien que no sabe nada del proyecto no sabe contarte lo que vas a construir, tu spec no está terminada. A las personas nos pasa igual cuando intentamos explicarle algo a un compañero nuevo.

Es una manera práctica de pasar el vibe coding a Spec-Driven Development: la velocidad deja de ser el problema cuando lo que se acelera es algo ya revisado. Y encaja con lo que contaba sobre la revisión del código generado por IA: la revisión humana se mueve del diff al diseño, que es donde cuesta menos arreglar las cosas.

Google dice que miles de sus ingenieros lo usan cada día para entregar código de producción. Es un dato suyo y no puedo comprobarlo, pero la idea no depende de él: puedes copiar el patrón sin instalar nada.

Lo que me llevaría a mi equipo

• Separa diseñar de revisar. Quien diseña con mucho contexto no ve sus propios huecos. Una sesión limpia, sin historial, sí.
• Pide al revisor que te explique la spec antes de criticarla. Si no la entiende, no hace falta seguir.
• Haz que la spec sea autosuficiente. Rutas de ficheros, estructuras de datos y firmas. Cuanto más cerrado, menos se inventa el agente.
• Vigila las desviaciones. Una spec que nadie compara con el código acaba siendo ficción.

Una cosa a tener en cuenta: según el anuncio, el plugin está pensado de momento para Antigravity, el entorno de Google, y dicen que vendrán otros entornos. Si no trabajas ahí, el método se puede aplicar igualmente con tus propios agentes y reglas.

Para cerrar

Para mí lo importante de EGM no es el plugin: es que una empresa de este tamaño ponga por escrito que el juicio humano es lo que de verdad importa y que el diseño es el nuevo código. Es la dirección en la que llevamos tiempo trabajando, y de esto va el taller que dimos en la TRG26.

Si en tu empresa quieres que los agentes de código trabajen a partir de specs revisadas y no de prompts sueltos, en onext te ayudamos a montarlo. Escríbeme desde onext.es y lo hablamos.