Google divide la elaboración de especificaciones con IA en dos roles en su plugin EGM

Pasas media hora hablando con una IA sobre una nueva función. Hace preguntas, acepta las decisiones y redacta una especificación detallada. Le pides que la revise: todo parece convincente. Sin embargo, tras el lanzamiento descubres que un evento duplicado del servicio de pagos amplía dos veces una suscripción. En la conversación, todos daban por sentada la protección contra duplicados, pero nunca quedó recogida en el documento.

Elephant-Goldfish Model, o EGM, aborda este problema: es un plugin de código abierto para elaborar y revisar documentos técnicos con ayuda de la IA. Un agente recopila las decisiones y otros revisan el resultado sin el historial de la conversación. El objetivo práctico es detectar omisiones antes de la implementación, cuando corregirlas todavía cabe en unas pocas líneas de la especificación.

Por qué el revisor debe olvidar la conversación

EGM tiene dos roles. El «Elefante» conserva el contexto del proyecto y prepara el documento. Los «Peces dorados» reciben el documento y el código fuente relacionado, pero no la conversación previa. El desarrollador decide qué observaciones aceptar, resuelve las contradicciones y aprueba el diseño antes de empezar a programar. Así se describe el proceso en el repositorio de Google.

La ausencia del historial es una condición de la revisión. Si una decisión solo resulta comprensible para quienes participaron en un chat largo, a la persona que deba implementarla después puede faltarle información. Un revisor que llega de nuevas debe evaluar lo que realmente está escrito, sin poder completar mentalmente el documento con acuerdos anteriores.

Aun así, es fácil interpretar la expresión «contexto cero» de forma demasiado literal. El revisor recibe materiales con los que trabajar. Se aísla el historial de la conversación, no toda la información sobre el sistema. Por eso, la calidad de la especificación y la selección del código fuente siguen siendo importantes.

Cómo funciona con un ejemplo de pagos

Imaginemos que un equipo añade el procesamiento de notificaciones de pago. La primera versión del documento dice: recibir el evento, localizar al usuario y ampliar la suscripción. Basta para demostrar la función. Para un servicio en producción, quedan preguntas pendientes.

¿Qué ocurre si el mismo evento llega dos veces? ¿Y si la base de datos guarda la ampliación, pero el servidor no llega a confirmar la recepción a tiempo? ¿Y si la notificación de cancelación del pago llega antes que la de pago completado? Son ejemplos de posibles preguntas de revisión, no un informe sobre los resultados de EGM.

El autor del documento puede haber hablado de los reintentos en el chat y dar el asunto por resuelto. Un revisor sin ese historial ve una laguna: la especificación no incluye reglas para gestionar eventos duplicados. Un ingeniero tendrá que definir cómo reconocerlos, dónde guardar el resultado del procesamiento y qué comportamiento se considera correcto tras un fallo.

El responsable de producto también tiene trabajo aquí. Los reembolsos, las cancelaciones de suscripciones y la entrega repetida de notificaciones afectan a las promesas hechas al usuario. Estas decisiones no pueden quedar por completo a criterio del agente que escribe el código. Primero, el equipo acuerda el comportamiento del producto; después, lo documenta de modo que otra persona u otro agente pueda revisarlo.

Qué probar y cuáles son los límites

El sitio web de EGM describe las etapas de discusión de la idea, elaboración del documento y revisión. También presenta herramientas para documentar un proyecto existente y detectar discrepancias entre la especificación y el código. Un punto de partida razonable es una sola función con decisiones discutibles: pagos, permisos de acceso o tareas en segundo plano.

Antes de la revisión, conviene dejar por escrito las restricciones y los criterios de aceptación. Después, analizar las observaciones, corregir el documento y solo entonces pasar a la implementación. Para evaluar su utilidad, se pueden contar las lagunas confirmadas que se detectaron antes de programar y medir el tiempo dedicado a la revisión. Es una propuesta de evaluación, no métricas publicadas sobre la eficacia del plugin.

EGM no ofrece fundamentos para prometer la eliminación de errores de arquitectura. Agentes distintos pueden compartir las mismas ideas equivocadas, y una observación convincente puede resultar incorrecta. Las rondas adicionales también requieren tiempo y consumen tokens. El coste de la revisión debe guardar proporción con el coste de un posible error.

El proyecto se distribuye bajo Apache 2.0; sus autores señalan expresamente que no es un producto con soporte oficial de Google. La revisión requiere contextos nuevos para los subagentes, y el proceso no sustituye las pruebas ni el criterio de ingeniería: estas limitaciones se enumeran explícitamente en el README.

EGM propone un hábito útil: antes de implementar, entregar la especificación a alguien que no haya participado en su discusión. Si no se puede implementar sin explicaciones verbales, el documento todavía necesita trabajo.