Elephant-Goldfish Model de Google: revisa el diseño antes de programar

15 min de lectura · 2 de noviembre de 2026
Última revisión 2 de noviembre de 2026

Un agente de IA puede implementar «añadir exportación CSV» sin preguntar quién puede exportar qué registros. Las decisiones que faltan se toman igualmente. Las descubres al leer el código.

Elephant-Goldfish Model (EGM) de Google es un plugin de código abierto para revisar diseños de software antes de implementarlos. Un agente con contexto del proyecto prepara la especificación; otras sesiones, con contexto nuevo, cuestionan lo que explica el documento. El equipo de ingeniería resuelve las decisiones pendientes y aprueba el diseño. El proceso resulta útil cuando una funcionalidad aún contiene decisiones que, de otro modo, el agente tendría que inventar.

Google anunció la publicación del plugin el 22 de octubre de 2026 y afirma que miles de sus ingenieros lo usan a diario para entregar código de producción. Es una declaración de adopción, no una medición de cuánto reduce los defectos.

Fuentes revisadas el 2 de noviembre de 2026. Examinamos el anuncio de Google y la revisión 403d8881 del repositorio. No ejecutamos EGM en un proyecto de cliente. El ejemplo, el cálculo de costes y el piloto que siguen son ilustrativos.

¿Qué es Elephant-Goldfish Model de Google?

Elephant-Goldfish Model separa el diseño de su revisión mediante historiales de conversación distintos. El README del proyecto asigna el contexto del proyecto al Elephant, la revisión del documento desde una sesión nueva a los Goldfish y las decisiones de arquitectura a la persona responsable. EGM reúne instrucciones y habilidades para agentes; no es un modelo de lenguaje recién entrenado.

Qué información recibe cada participante y quién decide
Participante	Contexto disponible	Responsabilidad
Elephant	Requisitos, arquitectura, conversación y decisiones registradas.	Cuestionar la propuesta y redactar el diseño.
Goldfish	Documento, instrucciones de revisión y referencias pertinentes, sin la conversación previa de diseño.	Detectar supuestos implícitos, ambigüedades y riesgos de implementación.
Responsable de ingeniería	Objetivos del producto, restricciones y hallazgos de la revisión.	Resolver las decisiones, asumir la responsabilidad y aprobar la especificación.

La metáfora del elefante no promete memoria ilimitada. La habilidad de redacción contempla expresamente una sesión nueva y pide al agente que relea las alternativas descartadas en el resumen inicial. Las decisiones escritas conservan el contexto. Nuestra guía sobre contexto del repositorio para agentes de programación desarrolla la disciplina de ingeniería necesaria para ese traspaso.

La regla de no programar también tiene un alcance concreto: las instrucciones de ejecución de EGM prohíben implementar código de producción durante el diseño, pero permiten código ilustrativo identificado como tal en Markdown o en un archivo de trabajo. Un ejemplo de interfaz puede ayudar a cerrar una decisión sin convertir la sesión en una tarea de implementación.

¿Cómo se conectan brainstorm, draft y review?

EGM convierte la conversación sobre una funcionalidad en una especificación que otra sesión pueda entender. La guía oficial del proceso describe una secuencia básica y permite utilizar cada habilidad por separado cuando convenga.

egm-brainstorm: explorar requisitos y alternativas, someter la idea a revisores con contexto nuevo y guardar el enfoque acordado en concepts_brief.md.
egm-draft: elaborar design_draft.md sección por sección, con el problema, el sistema existente, los cambios propuestos y el plan de implementación.
egm-review: examinar el diseño en etapas separadas y decidir qué hallazgos resolver antes de aprobarlo.

Tras la aprobación humana, pide al agente que implemente una parte delimitada del plan. Guarda la especificación aprobada en el control de versiones, normalmente bajo docs/designs/. Si estás eligiendo un proceso más amplio de desarrollo basado en especificaciones, nuestra guía de GitHub Spec Kit para producción aborda esa decisión.

¿Qué ocurre en las cinco etapas de revisión?

La habilidad de revisión actual de EGM ejecuta cinco etapas. Examina el enfoque arquitectónico, la comprensión, la calidad del diseño, la complejidad innecesaria y la preparación para implementar. Los hallazgos sobre exportación CSV de la tabla son ejemplos de qué buscar, no resultados de una revisión ejecutada.

Secuencia actual de revisión con hallazgos ilustrativos
Etapa	Pregunta principal	Ejemplo de hallazgo
1. Primera revisión global, Zoom Out	¿Resuelve el problema real aprovechando el sistema existente?	El nuevo servicio de exportación duplica la consulta del módulo de facturas.
2. Comprensión	¿Puede alguien sin la conversación previa explicar la propuesta y el comportamiento actual?	El documento habla de «cuenta» sin distinguir entre cuenta de usuario y tenant.
3. Revisión crítica	¿Dónde fallan el diseño, los supuestos o las dependencias?	La solicitud de exportación puede elegir un tenant sin acreditar pertenencia.
4. Revisión global intermedia, Zoom Out	¿Han añadido las correcciones una arquitectura evitable?	Se incorporaron una cola y almacenamiento de objetos a una exportación acotada sin demostrar su necesidad.
5. Preparación para implementar	¿Puede el agente continuar sin inventar decisiones de diseño pendientes?	El plan omite qué ocurre al superar el límite de filas y la firma del método de autorización existente.

El revisor de comprensión debe explicar con sus propias palabras tanto la propuesta como la descripción del sistema actual. Si no puede explicar una sección, la revisión queda bloqueada. Si su explicación difiere de tu intención, busca la conexión que falta en el documento.

La revisión puede detenerse entre etapas o generar un informe consolidado. La evaluación de preparación informa la decisión del responsable de ingeniería. No autoriza un despliegue.

¿Por qué EGM busca sobreingeniería dos veces?

La segunda revisión Zoom Out tiene sentido porque las críticas también pueden añadir complejidad. El estándar de Zoom Out pide descartar funcionalidades especulativas, evitar infraestructura prematura y reutilizar componentes existentes. Después de revisar los detalles, hay que volver a contrastar el diseño con el problema que debía resolver.

Imagina que un revisor pregunta qué ocurrirá si la exportación alcanza millones de filas. La pregunta es útil. Necesitar una cola de tareas depende del requisito de producto, de la infraestructura existente y de los límites de ejecución medidos. Un límite explícito puede cubrir la necesidad actual; un volumen mayor puede justificar un proceso en segundo plano.

Exigiríamos que cada componente propuesto resolviera una restricción observada o un requisito acordado. Registra también por qué descartaste una alternativa. Así evitarás que el siguiente revisor reabra la misma discusión y amplíe el diseño sin mejorarlo.

Ejemplo: una exportación CSV limitada al tenant

Una especificación útil de exportación resuelve quién accede a qué registros, qué contiene el archivo y cómo responde el sistema al superar los límites. Este ejemplo original y abreviado corresponde a una aplicación NestJS hipotética. Los nombres de archivo, los permisos y los límites son supuestos. Sustitúyelos por datos verificados del repositorio antes de pedir al agente que implemente nada.

Supongamos que la aplicación ya autentica la pertenencia a cada organización cliente, o tenant, y dispone de un repositorio de facturas y un codificador CSV probado. Producto solicita una exportación síncrona de hasta 1.000 facturas. Ese máximo es una decisión de producto para el ejemplo; no es un benchmark ni un umbral de rendimiento seguro para cualquier aplicación.

Decisiones que «añadir exportación CSV» deja abiertas
Decisión	Especificación del ejemplo	Comprobación de aceptación
Acceso	Exigir `invoices.export`. Obtener el tenant de la pertenencia verificada en el servidor. No aceptar un parámetro de tenant elegido por el cliente.	Un usuario del tenant A no puede exportar filas del tenant B; la falta de permiso devuelve 403.
Selección	Filtrar `issued_at` desde una fecha y hora UTC inclusiva hasta otra exclusiva. Rechazar intervalos mal formados o invertidos con 400.	Incluir las filas que coinciden exactamente con el inicio y excluir las que coinciden con el final.
Salida	Exportar solo `invoice_id, issued_at, total_minor, currency`, ordenados por `issued_at` y después por `invoice_id`. Reutilizar el codificador CSV.	El orden de columnas y filas coincide con los datos de prueba; no aparecen notas del cliente ni campos adicionales.
Límite	Consultar como máximo 1.001 filas coincidentes. Si hay más de 1.000, devolver 422 con `EXPORT_LIMIT_EXCEEDED` antes de enviar cabeceras o bytes del CSV.	Exactamente 1.000 filas se exportan; 1.001 generan una respuesta de error completa, nunca una descarga parcial.
Resultado vacío	Devolver 200 con la fila de cabeceras CSV y ningún registro.	Una selección vacía autorizada produce una descarga válida y predecible.

El apartado de implementación debe conectar estas decisiones con el código real. Una lista de archivos ilustrativa podría empezar así:

Modify src/invoices/invoices.controller.ts
  GET /api/invoices/export?from=...&to=...
  Reuse the existing authentication and permission guards.

Create src/invoices/invoice-export.service.ts
  buildCsv(principal: TenantPrincipal, range: ExportRange)
    -> Promise<InvoiceExport>
  InvoiceExport: { filename: string; csv: string }
  Complete authorization, selection and limit checks before response output.

Modify src/invoices/invoices.module.ts
  Register the export service with existing invoice dependencies.

Create test/invoices-export.e2e-spec.ts
  Exercise tenant boundaries, permissions, dates, columns and limits.

El fragmento está incompleto de forma deliberada: un plan real debe identificar los guards y los métodos del repositorio, definir ExportRange y la correspondencia entre errores y respuestas, y concretar la codificación, el nombre de archivo, las cabeceras de caché y el comportamiento ante fallos. Un revisor con contexto nuevo debería detectar esas omisiones. Añadir rutas de archivo que parezcan plausibles no basta para poder ejecutar un diseño.

Para el piloto, elimina la regla del tenant de una copia y el comportamiento con 1.001 filas de otra. Pregunta a los revisores qué ocurrirá en esos casos. Un hallazgo útil identifica la decisión ausente y su consecuencia; asumir una política sin advertirlo cuenta como una omisión no detectada.

¿Cuándo está listo un plan para implementarse?

El estándar de preparación para implementar de EGM exige decisiones de diseño cerradas, una lista explícita de archivos, cambios precisos y pruebas concretas. También pide fases incrementales que mantengan el proyecto compilable y comprobable. Ese es el objetivo de calidad del plan, no una promesa de que el código generado será correcto al primer intento.

Verifica las referencias: cada ruta, método y estructura existentes deben coincidir con la revisión del código consultada. Distingue claramente los símbolos nuevos de los ya existentes.
Resuelve el comportamiento: define autorización, errores y compatibilidad donde corresponda. «Gestionar los errores adecuadamente» deja la decisión pendiente.
Vincula requisitos y comprobaciones: especifica resultados observables, incluidos los casos límite y de fallo. Nombrar un archivo de pruebas sin decir qué debe comprobar no es suficiente.
Ordena el trabajo: indica las dependencias entre fases y las comprobaciones necesarias antes de continuar.

Después de implementar, aplica QA independiente al código generado por IA. Una especificación bien revisada también puede implementarse mal.

¿Cómo se instala y se utiliza EGM?

Instala el plugin EGM completo en un entorno de programación capaz de crear subagentes con contexto nuevo. La guía de instalación y capacidades de los entornos advierte que copiar solo el directorio de habilidades deja fuera los perfiles de revisión y los estándares documentales. Estos son los comandos de instalación documentados que comprobamos el 2 de noviembre de 2026.

Claude Code

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

Codex

codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm

Antigravity CLI

agy plugin install https://github.com/google/elephant-goldfish-model

Inicia una sesión nueva tras instalarlo. En Claude Code y Antigravity CLI, utiliza el prefijo /egm:. Por ejemplo:

/egm:egm-brainstorm Design a tenant-scoped invoice CSV export.
/egm:egm-draft
/egm:egm-review design_draft.md

Ejecuta estos pasos de forma sucesiva y responde a las preguntas de diseño entre uno y otro. Usa la ruta del borrador que devuelva el agente. En Codex, elige la habilidad EGM correspondiente en el selector de habilidades.

Comprueba las capacidades reales de tu entorno. La guía consultada distingue Antigravity CLI, App y la extensión de VS Code del IDE independiente de Antigravity, que carece de la herramienta de delegación necesaria. Cowork y ChatGPT Work tienen vías de instalación con lagunas de verificación documentadas. Si no hay subagentes con contexto nuevo, EGM detiene la revisión; pedir a la misma conversación que finja ser un Goldfish no aporta esa separación.

Separar contextos y limitar los permisos de las herramientas son requisitos distintos. Revisa los controles de permisos del entorno para los revisores. Una instrucción de dedicarse solo al diseño no aísla por sí misma el sistema de archivos.

¿Cuánto cuesta EGM y cuándo ahorra tiempo?

El código fuente de EGM se publica bajo la licencia Apache 2.0. Ejecutarlo consume la cuota de tu agente o uso de API, además del tiempo de revisión del equipo. El repositorio también aclara que EGM no es un producto con soporte oficial de Google.

El procedimiento de pruebas del proyecto describe comprobaciones de la estructura del plugin y de determinadas rutas de ejecución nativa. No establece una reducción general de defectos que lleguen a producción ni del tiempo de entrega. Las preguntas frecuentes oficiales reconocen que la revisión puede convertirse en un cuello de botella y recomiendan medir hallazgos útiles y trabajo rehecho.

Un cálculo hipotético del tiempo de ingeniería permite valorar el intercambio:

Supón un valor del tiempo de ingeniería de 90 € por hora.
20 minutos adicionales de revisión cuestan 30 €. Añade un uso supuesto del agente de 6 €: 36 € en total.
Si el proceso evita 45 minutos de trabajo posterior, ese tiempo vale 67,50 €. El beneficio neto supuesto es de 31,50 €.
El punto de equilibrio es 36 € / 90 € × 60 = 24 minutos de esfuerzo evitado.

Son valores elegidos para el ejemplo, no tarifas de Wavect, precios de EGM ni ahorros medidos. Cuando los sustituyas por tus cifras, incluye todo el tiempo adicional de redacción, revisión, resolución y documentación. Mide también el plazo de entrega: una revisión breve que espera dos días a su responsable puede retrasar el lanzamiento.

¿Cómo probaríamos EGM con un equipo real?

Evaluaríamos EGM con una funcionalidad acotada y criterios de aceptación conocidos, comparando después el proceso completo con la forma habitual de trabajar del equipo. Empieza comprobando la revisión de la especificación antes de confiar en sus veredictos. Proponemos esta evaluación con omisiones deliberadas cuya detección puedes verificar.

Fija la referencia: registra las revisiones del repositorio y del plugin, el entorno, el modelo, los permisos y la versión de la especificación revisada.
Comprueba la separación: introduce una frase de prueba inofensiva solo en la conversación del autor. Pide a un revisor que explique el diseño a partir de los documentos entregados. Si aparece la frase, habrá una filtración de contexto; que no aparezca es solo una comprobación básica, no una prueba de aislamiento perfecto.
Introduce omisiones conocidas: crea copias separadas del ejemplo de exportación sin la regla del tenant o sin el comportamiento al superar el límite. Repite las revisiones en sesiones nuevas y registra los problemas detectados, los omitidos y los hallazgos incorrectos.
Revisa a los revisores: una persona de ingeniería debe clasificar cada hallazgo como una decisión realmente pendiente, una aclaración útil o trabajo innecesario. Exige una justificación antes de añadir una dependencia o componente.
Implementa y mide: compara cambios aceptados, esfuerzo humano total, uso del agente, trabajo reabierto y defectos detectados mediante las mismas pruebas de aceptación. Repetir ejecuciones y usar tareas comparables reduce el riesgo de confundir un resultado favorable con una mejora fiable.

Define los criterios de éxito antes de ejecutar el piloto. En este ejemplo, exige que se detecten las omisiones de acceso y límite introducidas, que no queden decisiones de alto impacto sin resolver al aprobar el diseño y que se respete un máximo acordado de esfuerzo adicional. Si falla, reduce el proceso, cambia las instrucciones de revisión o deja de usarlo para esa clase de tarea.

¿Cuándo compensa utilizar el proceso completo?

Usaríamos EGM completo cuando queden decisiones importantes de diseño y resolverlas tarde resulte costoso. Elige un proceso más ligero si el comportamiento ya está claro. Así sigues la recomendación del proyecto de utilizar las habilidades de forma selectiva y decides su adopción a partir de la evidencia de tu equipo.

Criterios de uso que proponemos
Trabajo	Enfoque sugerido	Motivo
Funcionalidad nueva con permisos o límites de acceso a datos	Probar el proceso completo de diseño y revisión.	Un comportamiento sin definir puede exigir cambios costosos al implementarlo.
Cambio que afecta a varios módulos existentes	Contrastar la especificación con el código actual.	Compatibilidad y responsabilidades requieren decisiones explícitas.
Especificación existente y detallada	Empezar por las etapas de revisión pertinentes.	Reescribir un documento útil aporta poco por sí solo.
Corrección pequeña con una prueba fallida precisa	Usar el proceso habitual de corrección, pruebas y revisión.	El comportamiento esperado puede estar ya decidido.
Idea de producto sin validar	Comprobar la necesidad del usuario antes de detallar la implementación.	Un diseño coherente no demuestra demanda de clientes.

Nuestra recomendación

Elige una funcionalidad cuyas decisiones pendientes puedas identificar. Usa EGM para hacerlas revisables, mantén acotada la implementación y mide si la revisión adicional compensa su coste. Conserva las alternativas descartadas para que la siguiente sesión entienda las decisiones sin tener que reconstruir la conversación.

El servicio de adopción de IA de Wavect puede ayudarte a definir ese piloto a partir de tu repositorio y tus criterios de aceptación.

Tras implementar, la habilidad de EGM para detectar desviaciones puede contrastar los documentos de diseño con el código actual e informar de las discrepancias. Utiliza esos hallazgos para mantener el diseño y revisar las desviaciones junto con los resultados de las pruebas.

Preguntas frecuentes sobre Elephant-Goldfish Model

¿EGM es un nuevo modelo de lenguaje de Google?

EGM es un plugin de código abierto que reúne habilidades, perfiles de revisión y estándares documentales para agentes de programación. No incluye nuevos pesos de modelo. El entorno que elijas aporta el modelo de lenguaje y las herramientas. Evalúa la configuración completa, incluidos el modelo, los permisos y las instrucciones de revisión, para decidir si el proceso ayuda a tu equipo.

¿Elephant y Goldfish deben utilizar modelos distintos?

La separación que define el método es la del contexto de conversación. Un Goldfish no debe heredar la conversación que produjo el diseño. Puedes evaluar el uso de otro modelo como decisión adicional, pero eso no sustituye el requisito. Dos modelos con la misma especificación incompleta pueden pasar por alto el mismo problema; conserva pruebas de aceptación concretas y revisión humana.

¿Puedo utilizar un documento de diseño existente?

Sí. La habilidad de revisión acepta un documento y permite elegir las etapas que responden a tu necesidad actual. Comprueba que el texto explique el sistema y enlace el código en el que se apoya. Si falta un plan de implementación, revisa primero el diseño de la funcionalidad; no des por resueltos detalles de implementación que aún no están definidos.

¿Tengo que aceptar todas las sugerencias de los revisores?

No. El responsable de ingeniería decide sobre la arquitectura. Contrasta cada hallazgo con el requisito y el código actual; después resuélvelo o registra por qué corresponde otra decisión. La segunda etapa Zoom Out ayuda cuando las críticas han añadido componentes innecesarios. Ni un informe más largo ni una arquitectura más complicada demuestran un resultado mejor.

¿El contexto nuevo garantiza una revisión sin sesgos?

El contexto nuevo elimina la conversación anterior como fuente de conocimiento implícito. No garantiza razonamiento independiente, referencias completas ni conclusiones correctas. Los revisores pueden compartir limitaciones del modelo e interpretar mal el mismo requisito. Utiliza criterios explícitos, contrasta los hallazgos con el repositorio y conserva la responsabilidad humana sobre las decisiones importantes.

¿Qué hacer si la implementación cambia el diseño?

Registra el requisito modificado o la desviación justificada en el documento de diseño y enlaza el cambio de implementación. El informe de desviaciones de EGM puede ayudar a detectar diferencias entre documentación y código. Que un informe no encuentre problemas no demuestra corrección: ejecuta las pruebas de aceptación y revisa el comportamiento afectado antes de aceptar el cambio.