01 · Contexto
Qué está ocurriendo
El 22 de octubre, Google publicó el complemento de código abierto Elephant-Goldfish Model bajo licencia Apache 2.0. Su flujo comienza con una sesión que conserva contexto para discutir y documentar el diseño, sin escribir código. Después, sesiones sin ese historial examinan comprensión, debilidades y preparación para implementar. La integración inicial apunta a Antigravity; otros entornos se presentan como trabajo futuro, no como compatibilidad ya disponible.
Análisis editorial: la separación es interesante porque obliga a que una decisión sobreviva fuera de la conversación donde nació. Si una persona nueva no puede entender por qué una API concede un permiso, el problema quizá está en la especificación. Un documento explícito permite discutir supuestos antes de convertirlos en múltiples archivos difíciles de revisar. El valor no está en simular una reunión de agentes, sino en producir decisiones comprobables.
02 · Impacto
Por qué importa
Nuestra lectura es que un flujo de diseño previo puede reducir cambios por malentendidos, pero introduce otra obligación: mantener la especificación alineada con el producto real. Un plan prolijo también puede estar equivocado. Separar sesiones no demuestra independencia técnica entre revisores ni elimina sesgos compartidos por un modelo. Para AppSec, las preguntas importantes siguen siendo quién puede realizar cada operación, sobre qué recursos y bajo qué condiciones. Una revisión que solo confirma nombres de archivos puede omitir estas fronteras. El método debería aportar una base de discusión y trazabilidad, no convertirse en una aprobación automática ni en una barrera documental desproporcionada para cambios pequeños.
03 · Recomendaciones
Qué conviene hacer
- Probar el enfoque con una función acotada y reversible. Antes de implementar, describir objetivo, exclusiones, actores, recursos, errores esperados y criterio de aceptación. Mantener una lista breve de dudas abiertas, con responsable de resolverlas; no ocultarlas detrás de una redacción aparentemente definitiva.
- Pedir a un revisor que explique el diseño con sus propias palabras y proponga casos que lo contradigan. Complementar la revisión asistida con una persona que conozca las reglas del negocio. Registrar qué observaciones se aceptaron, cuáles se descartaron y por qué.
- Traducir cada decisión relevante a una prueba o comprobación observable. Incluir accesos indebidos, entradas inválidas, interrupciones y reintentos cuando correspondan. Si una propiedad no puede verificarse, declararla pendiente en vez de asumirla por consenso entre agentes.
- Al finalizar el piloto, comparar retrabajo, defectos detectados y esfuerzo de revisión con el proceso anterior. Conservar el control humano sobre cambios de alcance y despliegues. Adoptar únicamente las etapas que aporten evidencia útil al tamaño y riesgo del proyecto.