Microsoft: nueve ingenieros fusionaron 1,211 cambios de código en un día para crear Copilot Cowork

Microsoft detalló cómo un equipo pequeño construyó Copilot Cowork, una herramienta que realiza flujos de trabajo de varios pasos en nombre del usuario. El 21 de octubre, nueve ingenieros fusionaron 1,211 pull requests (propuestas de cambio de código que se incorporan al programa principal) en el código del servidor de la herramienta.

Según la empresa, los agentes de IA —programas que ejecutan tareas por su cuenta a partir de instrucciones— escribieron la mayor parte del código. Los ingenieros se encargaron de definir el trabajo y de juzgar los resultados.

El primer cambio de código se hizo el 13 de enero. Copilot Cowork llegó a los primeros clientes empresariales del programa Frontier el 30 de marzo y a disponibilidad general mundial el 16 de junio, unos cuatro meses y medio después, con varios modelos y 16 complementos, según Microsoft.

Primero la especificación, luego el código

Microsoft explica que el cuello de botella no era el agente, sino no saber con exactitud qué se quería. Una petición vaga producía código que parecía razonable, pero hacía lo incorrecto. Por eso el equipo adoptó una regla: nada de código sin una especificación previa en formato markdown que explique qué hace el cambio, cómo se sabrá que funciona y qué no debe romper.

Muchas de esas especificaciones empiezan hablando: alguien describe la función en voz alta, un agente la convierte en borrador y una persona lo edita.

Agentes con tareas acotadas y límites claros

Después, el equipo pasó a usar varios agentes a la vez, cada uno con una tarea y una especificación. Los cambios fusionados por mes subieron de 257 en enero a 2,754 en mayo. La semana más intensa antes de la disponibilidad general tuvo 783.

Microsoft sostiene que una tarea concreta produce menos errores y que el modelo se elige según calidad y costo: algunas tareas piden más razonamiento y otras funcionan con un modelo más rápido y barato.

En el diseño, el modelo corre en un contenedor sin credenciales del usuario. Un anfitrión de confianza, fuera del contenedor, maneja identidad, políticas, aprobaciones y herramientas, y toda operación en Microsoft 365 pasa por él. El modelo puede planificar y pedir lo que quiera, pero el anfitrión decide qué ocurre. Esa separación permitió, más adelante, reemplazar todo el anfitrión sin tocar al agente, algo que hicieron al pasar de Python a Rust, otros dos lenguajes de programación.

Revisiones automáticas, pero también humanas

Con nueve personas no se podía leer cada cambio. Varios ingenieros crearon sus propios agentes revisores, y cuando uno detectaba un problema que otro había pasado por alto, este último recibía una regla nueva. Microsoft indica que cada uno ha pasado por al menos 10,000 generaciones de mejora.

Una primera revisión útil suele llegar en pocos minutos; en una muestra de cambios recientes, la mediana fue de unos cuatro minutos y medio. Después vienen pasos más lentos y especializados, como revisar el flujo de llamadas del código, problemas operativos o la comparación con el código reemplazado.

La empresa reconoce que los revisores automáticos pueden fallar. En una ocasión, varios agentes revisaron un cambio en una de las partes más sensibles del producto y no hallaron problemas; personas del equipo leyeron el mismo cambio y encontraron cuatro fallas que bloqueaban su aprobación, todas corregidas antes de fusionarlo. Desde entonces, la revisión por agentes es el primer filtro y los cambios críticos reciben al menos una revisión humana.