Nove engenheiros integraram 1.211 pull requests à branch principal do backend do Copilot Cowork em 21 de outubro de 2026, segundo o relato de engenharia da Microsoft. O número registra mudanças integradas naquele dia. A Microsoft também informou 4.581 pull requests na semana de 12 de outubro, uma contagem de período diferente.
Como a equipe organizou o trabalho dos agentes
A Microsoft diz que agentes escreveram a maior parte do código, enquanto engenheiros definiam as tarefas, a arquitetura e os limites de segurança, além de decidir o que podia chegar à produção. Para dar direção ao trabalho, a equipe exigia uma especificação em Markdown antes de cada mudança: o que ela deveria fazer, como avaliar o resultado e o que não poderia quebrar. Um agente podia ajudar a redigir a especificação a partir de uma descrição falada, mas uma pessoa a revisava antes da implementação.
Os agentes trabalhavam em cópias separadas do repositório, cada um com uma tarefa ligada a uma especificação. A equipe relata ter passado de um agente para cinco e, depois, para dezenas. Agentes revisores também faziam uma primeira análise. Em uma mudança sensível, porém, revisores humanos encontraram quatro problemas bloqueadores que os agentes haviam deixado passar. A mediana do tempo até uma primeira revisão útil foi de cerca de 4,5 minutos em uma amostra de pull requests recentes, segundo a Microsoft.
O relato descreve ainda uma barreira entre o modelo e as operações do Microsoft 365. O agente rodava em um contêiner sem credenciais de usuário; um host confiável, fora desse ambiente, cuidava de identidade, políticas, aprovações, execução de ferramentas e auditoria. O modelo podia planejar e solicitar ações, mas o host decidia o que executar. A Microsoft afirma que toda operação do Microsoft 365 passava por esse host.
Como os testes acompanharam a migração para Rust
A equipe registrou o comportamento da implementação em Python para comparar a versão em Rust. Geradores executavam o Python com entradas definidas e guardavam as saídas em arquivos JSON; os testes em Rust reproduziam esses resultados. A Microsoft relata cerca de 430 conjuntos de casos de teste. Um exemplo tinha 48 casos, e o teste conferia a quantidade antes da reprodução para impedir que um conjunto vazio passasse sem testar nada.
A primeira leva de testes deixou escapar um detalhe: a implementação em Python entregava certos eventos em uma ordem específica, embora essa regra não estivesse documentada. A primeira versão em Rust não preservou a ordem, e os testes não a detectaram. A equipe diz que corrigiu o problema. O episódio mostra por que reproduzir resultados conhecidos depende também de identificar quais comportamentos precisam ser registrados.
A migração foi concluída em 10 de outubro, quando o último cluster passou para Rust, segundo a Microsoft. No dia anterior, a equipe havia apagado o ambiente de execução em Python, que abrangia cerca de 8 mil arquivos e 4,9 milhões de linhas, incluindo testes e código gerado.
O que a comparação de latência permite concluir
Em uma comparação de 12 horas no fim de setembro, a Microsoft registrou o tempo até o primeiro token no primeiro turno em clusters Python e Rust. p50 é a mediana; p90 é o valor abaixo do qual ficaram 90% das observações.
| Percentil do tempo até o primeiro token | Python | Rust |
| p50 | 7,9 s | 2,7 s |
| p90 | 14,5 s | 6,2 s |
A comparação não isola o efeito da linguagem: durante a migração, o loop do agente também saiu do contêiner e passou para o serviço em Rust. A Microsoft diz que essa mudança contribuiu de forma importante para os tempos menores. A empresa também afirma que ainda não mediu adequadamente o custo por turno e não atribui à migração uma redução de custos.
Onde o fluxo de programação pode exigir uma transferência manual
Um usuário do Power Platform relatou que um agente do Copilot Studio, orientado por exemplos e instruções do projeto, ajudou no desenvolvimento de Logic Apps, mas que ainda era preciso copiar manualmente o resultado final. É uma experiência individual, não uma descrição geral das capacidades do Copilot Cowork.
Em outra discussão sobre o produto, usuários divergiram sobre o que a orquestração em várias etapas acrescentaria: alguns disseram que resumos ou apresentações já podiam ser feitos com o Copilot comum; outros apontaram valor potencial em encadear etapas entre documentos e e-mails ou ao longo de uma análise. São opiniões sobre usos possíveis, não uma comparação de produto testada.
