Google publicó el 22 de octubre Elephant-Goldfish Model, un complemento de código abierto diseñado para organizar la planificación del desarrollo de software con agentes de IA. La idea central es sencilla: una sesión conserva el contexto y la intención del proyecto, mientras agentes separados reciben el documento de diseño y buscan ambigüedades, supuestos ausentes y lagunas. La escritura de código debe llegar después de aclarar y revisar el planteamiento, no sustituir esas tareas.
Google afirma que el complemento se desarrolló inicialmente para sus ingenieros y que lo utilizan miles de empleados. Es una cifra comunicada por la empresa, no una medida independiente de la calidad del software. El repositorio utiliza la licencia Apache 2.0 y añade otra salvedad: no se trata de un producto con soporte oficial de Google. La distinción importa a los equipos que estén pensando en incorporarlo a su trabajo diario de desarrollo.
¿Por qué conservar el contexto y empezar también de cero?
El nombre Elephant-Goldfish describe un reparto de funciones. Elephant es una sesión rica en contexto que conserva el historial, la arquitectura y las pequeñas decisiones tomadas durante la conversación. Goldfish parte de una situación relativamente nueva: lee la especificación sin apoyarse en las explicaciones acumuladas durante la planificación. No se trata de 2 modelos recién entrenados ni del anuncio de un nuevo sistema de entrenamiento de modelos.
La organización aborda un problema conocido del trabajo en equipo, incluso sin IA. Quienes han debatido una cuestión durante mucho tiempo pueden saber qué quieren decir aunque su documento no lo explique bien. Un lector nuevo deja al descubierto esa distancia al interpretar una frase de otra manera. El método intenta provocar ese momento de forma deliberada, antes de que una especificación ambigua se convierta en archivos y funciones que después resulten más difíciles de cambiar.
Separar las conversaciones no garantiza una revisión correcta. Un agente puede pasar por alto un defecto, dar demasiada importancia a un detalle menor o aceptar un diseño incompleto. La ventaja potencial está en la estructura: la revisión tiene su propia función y su propio material de entrada, en vez de diluirse en la conversación que produjo el plan. Los ingenieros siguen teniendo que valorar qué objeciones son válidas y qué cambios mejoran la solución. El número de agentes no es por sí solo un certificado de calidad.
3 etapas antes del código
El anuncio de Google describe 3 etapas de diseño conjunto. Primero, los desarrolladores definen el problema y debaten alternativas, con la norma de no escribir código durante esa fase. Después elaboran un documento Markdown que recoge el problema, el enfoque técnico, las alternativas consideradas y un plan detallado de implementación. Por último, agentes separados revisan si el documento es claro y está listo para llevarse a la práctica.
El cambio de enfoque va más allá de añadir otro comando a una herramienta de desarrollo. El progreso queda representado por un documento que otra persona puede entender y cuestionar, en lugar de medirse únicamente por la cantidad de código que produce un agente. Para un equipo, podría facilitar un debate temprano sobre los criterios de éxito, los cambios previstos en archivos y lo que queda fuera del alcance. Son decisiones de producto e ingeniería, aunque la IA ayude a expresarlas.
El enfoque también crea un documento al que los equipos pueden volver cuando cambia la implementación. Una especificación escrita no garantiza que el código la respete, pero aporta una base para compararlos. Sin un registro de la decisión original, puede resultar difícil distinguir un cambio deliberado de una desviación involuntaria. Por tanto, su posible valor va más allá de la primera generación de código y abarca la explicación de por qué se eligió la solución.
La revisión empieza por comprender
En el proceso de revisión de Google, un agente separado debe explicar primero la arquitectura y la intención del documento. Si no logra describirlas con precisión, eso indica que persisten ambigüedades. A continuación, revisores escépticos buscan casos límite, dependencias ocultas y lagunas lógicas. Otra comprobación examina si el diseño está listo para implementarse y si contiene la información necesaria para avanzar.
La secuencia importa porque una lista larga de comentarios puede parecer exhaustiva incluso cuando el revisor ha entendido mal el problema. Exigir una explicación desplaza la atención de si el texto suena profesional a si otra persona o agente podría actuar a partir de él. Cuando la comprensión falla, corregir una frase clave puede ser más útil que añadir una página de instrucciones. Cuando es correcta, puede examinarse el diseño en sí.
Que un diseño esté listo para implementarse también requiere una interpretación cuidadosa. Un documento detallado puede despejar dudas sobre archivos, estructuras de datos e interfaces, pero no sustituye las pruebas del código resultante. Tampoco examina de manera independiente todas las condiciones de producción. Establece un plan definido de implementación, sin constituir una aprobación integral de seguridad ni garantizar la ausencia de defectos.
Un complemento abierto con responsabilidad de los desarrolladores
Google presenta el complemento como parte de un enfoque que conserva el criterio humano en ingeniería. La documentación del repositorio incluye vías de instalación para Antigravity, Claude Code y Codex, además de indicaciones para otros entornos. Los equipos necesitan documentación adecuada a su entorno y versión. Una lista de opciones de instalación no garantiza un comportamiento o soporte idénticos en todos los espacios de trabajo.
El anuncio de lanzamiento no aporta una comparación cuantitativa que establezca cuántos errores evita el complemento o cuánto tiempo ahorra en cada proyecto. Una planificación adicional podría reducir las correcciones posteriores, pero también exige tiempo, lectura y decisiones sobre los comentarios. Ese coste puede ser más perceptible en una tarea pequeña; aclarar las cosas pronto puede tener otro peso en un cambio que afecte a varios sistemas. La decisión depende del alcance.
Para los equipos de Israel, la relevancia reside principalmente en los procesos de trabajo con herramientas de desarrollo existentes. El anuncio no ofrece una vía de acceso específica para Israel ni promete soporte dedicado en hebreo. Una enseñanza más amplia es que las instrucciones deberían bastarse por sí solas cuando un agente está a punto de realizar un cambio. Un documento que dependa de la memoria de una conversación puede perder su sentido cuando cambian la herramienta, el desarrollador o el revisor.
La noticia es la publicación de una herramienta que asigna a la planificación y la revisión un papel explícito en los procesos con agentes. No pide a los ingenieros que dejen de comprender sus sistemas. Ofrece una forma de examinar si esa comprensión se ha plasmado por escrito para que otros puedan utilizarla. Si funciona, una conversación larga deja de ser el único lugar donde reside la intención: hay un documento, lectores críticos y una persona responsable de la decisión final.