Copilot Memory en disponibilidad general (GA) y Dreaming reescribe la memoria cada noche. ¿Quién revisa qué?

Cuando un agente de programación aprende que su equipo ejecuta las pruebas con un comando concreto, o que un revisor siempre rechaza cierto patrón, ¿adónde va ese conocimiento y quién puede leerlo?

GitHub respondió en parte a esa pregunta el 28 de octubre. Copilot Memory ya está en disponibilidad general (GA) en los planes de pago de Copilot, y una nueva capacidad llamada Dreaming, en preview pública, revisa trabajo pasado para mejorar sesiones futuras. Juntas convierten la memoria de los agentes en una parte mantenida del entorno de desarrollo en lugar de un efecto secundario de un chat largo.

Qué hace cada pieza

Copilot Memory guarda preferencias personales y convenciones del repositorio, como comandos de prueba o cómo debe comprobar Copilot su trabajo. GitHub afirma que Copilot “genera y cura memorias de forma autónoma” a partir de las interacciones, en dos ámbitos: personal y de repositorio. Los usuarios pueden ver y eliminar sus preferencias personales; el acceso a las memorias de repositorio sigue la configuración de acceso al repositorio de Copilot Memory.

Dreaming funciona de tres maneras. Cura memorias personales a partir de conversaciones con agentes. Gestiona memorias de repositorio y propone actualizaciones de skills y archivos de instrucciones personalizados. Y convierte el feedback recurrente de revisión de código que los desarrolladores aceptaron en guía para futuras revisiones. Es opt-in: las organizaciones lo habilitan por política, los usuarios lo habilitan para sí mismos y sus ejecuciones consumen créditos de IA.

GitHub informa que, en sesiones de preview de Copilot CLI en las que el agente usó memoria, el 93% mostró mejor adherencia a las preferencias de los desarrolladores y el 42% mostró flujos de trabajo más eficientes. Son observaciones de GitHub de su propio preview, sin un método publicado; interprételas como una señal de que la memoria cambia el comportamiento, que es justo por lo que necesita atención.

Dos tipos de memoria, dos niveles de revisión

La decisión de diseño más importante del lanzamiento pasa fácilmente desapercibida. Dreaming propone cambios en skills y archivos de instrucciones versionados mediante pull requests, de modo que el equipo los revisa como cualquier otro cambio. Los cambios en las memorias en sí, personales y de repositorio, los hace Copilot directamente.

Esa división es razonable y deja un hueco. Las memorias de repositorio definen cómo trabaja el agente para todos los que tienen acceso, y las escribe el agente a partir de lo que observó. Si se memoriza una convención equivocada (un comando obsoleto, una solución temporal que alguien usó una vez, un patrón que prefería un solo revisor), se aplica en silencio en sesiones posteriores hasta que alguien lo nota.

Sostuvimos que la memoria de los agentes es almacenamiento de datos empresarial, incluso cuando nadie la llama base de datos, y que el problema difícil es qué deberían olvidar los agentes. El lanzamiento de GitHub hace concretas esas preguntas para cada repositorio con Copilot.

Qué configurar antes de habilitar Dreaming

1. Lea las memorias de repositorio periódicamente. Asigne al propietario del repositorio la revisión de lo que Copilot ha memorizado en el ámbito del repositorio, como se revisa un archivo CODEOWNERS. Elimine lo que esté mal o desactualizado.
2. Mantenga las reglas duraderas en archivos, no en la memoria. Una convención que importa (cómo ejecutar las pruebas, qué bibliotecas están prohibidas, qué requiere un lanzamiento) pertenece a un archivo de instrucciones versionado o a un skill, donde los cambios se revisan. La memoria debería guardar lo útil pero barato de perder.
3. Compruebe qué puede contener la memoria. Asegúrese de que las memorias no puedan capturar secretos, datos de clientes ni URL internas que no deberían persistir; pregunte a GitHub cómo se delimitan las memorias entre forks y repositorios privados en su organización.
4. Revise los pull requests de Dreaming como cambios de política. Una propuesta que convierte comentarios de revisión aceptados en guía permanente es una regla de equipo escrita por observación. Pregunte si los comentarios de los que aprendió reflejan al equipo o a un revisor prolífico.

El cambio es que el contexto ya no es algo que se escribe una vez y se recupera. Se mantiene de forma continua, en parte por el agente. Las partes que pasan por revisión seguirán siendo fiables. Las que no, necesitarán un responsable que las lea.