Desde el 25 de septiembre de 2026, el agentic autofix de GitHub usa Copilot Memory cuando la función está habilitada. En la práctica, una sesión de corrección puede revisar memorias existentes para obtener contexto útil del repositorio y, después de producir una corrección, puede guardar el patrón de esa solución como memoria para utilizarlo más adelante. El beneficio potencial es que las correcciones futuras reflejen mejor las convenciones y los patrones de desarrollo seguro ya observados en el proyecto. Para quienes revisan estos cambios, sin embargo, esto añade otra capa de trabajo: además de comprobar el diff, conviene considerar qué contexto persistente pudo influir en la propuesta.
Qué cambió en agentic autofix
Agentic autofix ya funcionaba como un flujo de remediación guiado por un agente. Al asignar una alerta de code scanning a Copilot, el agente puede explorar archivos relevantes de la base de código, generar una corrección, validar el resultado e iterar antes de abrir una pull request para revisión. La integración anunciada el 25 de septiembre incorpora Copilot Memory a ese ciclo para los clientes que lo hayan habilitado.
Según el changelog de GitHub, agentic autofix ahora revisa las memorias existentes en busca de contexto que pueda ayudar a resolver alertas de seguridad. Cuando crea una corrección, también guarda el patrón utilizado como memoria para uso posterior. GitHub afirma además que estas memorias pueden ayudar a resolver alertas adicionales y proporcionar a funciones compatibles de Copilot, como code review y cloud agent, patrones de desarrollo seguro específicos del repositorio.
Por qué esto cambia la revisión de las correcciones
Antes de esta integración, evaluar una corrección automática ya exigía verificar si el parche eliminaba realmente el problema sin introducir regresiones. Con memoria persistente, la propuesta también puede reflejar convenciones inferidas de trabajos anteriores. Eso puede mejorar la consistencia, pero convierte parte del contexto en información reutilizable entre interacciones.
Para la revisión humana, el punto principal es no tratar la repetición de un patrón como prueba de que sigue siendo correcto. Una solución que funcionó antes puede ser inapropiada para otro componente, otro flujo de datos o otra frontera de confianza. GitHub documenta que los hechos a nivel de repositorio almacenados por Copilot Memory incluyen citas al código que los respalda y se vuelven a validar contra la rama actual antes de usarse. Esa validación ayuda a reducir el riesgo de contexto obsoleto, pero no sustituye la revisión de la pull request.
Qué revisar en una pull request creada por agentic autofix
- Si la vulnerabilidad quedó realmente corregida: verifica la relación entre la alerta original, su causa raíz y el cambio propuesto. La validación automática es una evidencia útil, pero debe leerse junto con el diff y los resultados de análisis presentados.
- Si el patrón aprendido encaja en ese contexto: busca abstracciones, helpers, convenciones o decisiones de arquitectura que puedan haberse reutilizado. Un patrón adecuado en un módulo puede no serlo en otro.
- Si aparecieron cambios laterales: agentic autofix puede explorar archivos más allá del punto inicial de la alerta. Revisa alcance, llamadas relacionadas, configuración, pruebas y efectos indirectos.
- Si las pruebas cubren el comportamiento relevante: valida rutas de éxito y fallo, entradas hostiles, autorización, manejo de errores y casos límite coherentes con la vulnerabilidad.
- Si la corrección cambia fronteras de confianza: presta especial atención a autenticación, autorización, serialización, consultas, archivos, comandos, red, secretos y validación de entrada.
- Si la explicación del agente coincide con el código: no uses el resumen de la pull request como sustituto de leer el parche. La descripción debe coincidir con el cambio real y con los resultados de validación.
Copilot Memory no es solo un historial de correcciones
Copilot Memory puede guardar hechos a nivel de repositorio, como convenciones de código, decisiones de arquitectura, comandos de build y reglas específicas del proyecto, además de preferencias a nivel de usuario. La documentación indica que las funciones compatibles pueden compartir este conocimiento. Por ejemplo, información aprendida en una interacción puede ayudar más adelante a otra función de Copilot a interpretar el mismo repositorio.
Existen límites de alcance importantes. Los hechos a nivel de repositorio solo pueden utilizarse en operaciones dentro del mismo repositorio y sus propietarios pueden revisarlos y eliminarlos. GitHub también informa que los hechos o preferencias almacenados que no se utilicen se eliminan automáticamente después de 28 días, aunque el plazo puede reiniciarse cuando una entrada se valida y se usa de nuevo correctamente.
Gobernanza: habilitar, revisar y eliminar memorias
Copilot Memory está en vista previa pública. Para suscripciones de Copilot gestionadas por una organización o empresa, la documentación actual indica que la función está desactivada por defecto hasta que un administrador habilita la política. Después, los usuarios pueden desactivarla en sus propias configuraciones. Los administradores y propietarios de repositorios también disponen de controles para revisar y eliminar hechos almacenados a nivel de repositorio.
Esto importa a los equipos de seguridad porque el contexto reutilizado pasa a formar parte del entorno que puede influir en futuras sugerencias. Una práctica útil es tratar la curación de memorias como parte de la gobernanza de Copilot: eliminar hechos incorrectos u obsoletos y mantener instrucciones explícitas para requisitos que no deberían depender solamente de inferencias automáticas.
Cómo puede adaptarse el proceso de revisión
La integración no elimina las etapas tradicionales de secure code review. Cambia el origen de parte del contexto utilizado para generar el parche. Por eso, los equipos que adopten agentic autofix pueden añadir tres preguntas a la checklist de revisión: qué convención parece haber guiado esta corrección, si esa convención sigue siendo válida para esta ruta de código y si existe algún hecho de Copilot Memory que debería corregirse o eliminarse.
También conviene distinguir memoria de instrucciones normativas. GitHub presenta Copilot Memory como conocimiento aprendido a lo largo del tiempo, mientras que las instrucciones personalizadas siguen siendo el mecanismo explícito para las reglas que un equipo quiere que Copilot siga. Para controles críticos, requisitos de seguridad y decisiones de arquitectura obligatorias, unas instrucciones versionadas y revisables son una referencia más clara que depender solo de lo aprendido por el agente.
Qué queda abierto durante la vista previa pública
Tanto agentic autofix como Copilot Memory continúan en vista previa pública y pueden cambiar. La actualización del 25 de septiembre confirma la integración y la reutilización de patrones de corrección, pero no convierte cada memoria en una regla de seguridad garantizada. Su valor práctico está en aportar más contexto al agente, mientras que la decisión sobre si una corrección es adecuada sigue perteneciendo al proceso de revisión y merge del equipo.
