Desenvolvimento do Microsoft Copilot Cowork: nove engenheiros, 1.211 pull requests e o gargalo da verificação

A Microsoft afirma que nove engenheiros integraram 1.211 pull requests durante o desenvolvimento do Copilot Cowork em 21 de outubro, com agentes escrevendo a maior parte do código. Um pull request propõe alterações para revisão antes da integração. Essa distinção importa: a manchete mede alterações integradas, enquanto a produtividade também depende de sua utilidade, confiabilidade e custo de manutenção.

Publicado em 2 de novembro, o relato de engenharia descreve uma equipe mudando a forma como especifica, revisa e opera software. Sua tensão central contrapõe a expansão da capacidade de implementação à capacidade limitada de verificação. Gerar mais alterações só cria valor quando a organização consegue determinar quais delas merecem chegar aos usuários.

A pesquisa da Anthropic sobre agentes e a pesquisa do Google sobre entrega de software oferecem pontos de referência úteis, sem validar de forma independente os resultados da Microsoft. Ambas direcionam a atenção aos sistemas que envolvem as ferramentas de IA. Para líderes de engenharia, a pressão recai sobre práticas de revisão, arquitetura e responsabilização à medida que a produção de código se torna mais fácil de ampliar.

O que o marco do desenvolvimento do Copilot Cowork realmente mede

Segundo o relato de engenharia do Copilot Cowork da Microsoft, a equipe de backend atingiu esse total diário após iniciar o trabalho em janeiro. Os engenheiros mantiveram a responsabilidade pelos requisitos e pelas decisões de maior risco. Verificações automatizadas e revisores agentes examinaram as alterações. A Microsoft também descreve uma alteração sensível em que revisores humanos identificaram quatro problemas bloqueadores que os revisores agentes não detectaram.

Um pull request integrado registra atividade aceita; seu valor para o negócio ainda exige evidências separadas.

Uma organização pode dividir um recurso em muitas alterações ou combinar trabalhos relacionados em uma submissão maior. Ambas as abordagens modificam a contagem. Nenhuma delas estabelece quanto valor para o cliente o trabalho entregou. Comparar equipes apenas por totais, portanto, corre o risco de recompensar diferenças de empacotamento em vez de diferenças no desempenho de engenharia.

Alterações menores podem facilitar a revisão porque cada proposta levanta uma questão mais restrita. No entanto, uma coleção de alterações individualmente compreensíveis ainda pode produzir um efeito combinado inesperado. Às vezes, a unidade relevante de avaliação passa a ser a versão, o fluxo de trabalho do cliente ou o serviço ao longo do tempo.

Considere um assistente hipotético de agendamento que lê uma solicitação, verifica a disponibilidade e prepara um convite para reunião. Cada componente pode passar em seus próprios testes enquanto o fluxo completo lida incorretamente com um cancelamento. Contar alterações bem-sucedidas de componentes deixaria de captar o problema real do cliente.

Esse exemplo ilustra por que o marco merece atenção sem se tornar uma meta universal. A contagem sugere um processo de integração excepcionalmente intenso. Ela não revela uma medida padronizada de complexidade de recursos, benefício para o cliente ou esforço necessário para manter o sistema resultante.

O momento também importa. Esse relato descreve um modelo operacional que surgiu por meio de desenvolvimento contínuo, e não uma breve demonstração de código gerado. Os leitores devem avaliar suas alegações como um estudo de caso de produção de uma empresa, com todo o contexto e as limitações de seleção inerentes a esse formato.

A engenharia do Copilot Cowork, consequentemente, levanta uma questão de gestão que vai além da velocidade de programação: quais evidências devem justificar a aceitação de uma alteração? Respostas diferentes implicam necessidades diferentes de pessoal. Uma equipe que enfatiza resultados de testes locais se organizará de maneira distinta de outra que exige revisão de segurança, evidências operacionais e verificações dos resultados para o cliente.

O total diário não pode responder a essa pergunta para outra organização. Mas torna mais difícil adiá-la. Quando a implementação se expande, critérios fracos de aceitação se tornam uma restrição operacional, em vez de um inconveniente ocasional.

Para compradores, a distinção é igualmente prática. O ritmo de desenvolvimento de um fornecedor descreve sua capacidade de modificar o produto. O comprador ainda precisa de evidências de que essas mudanças melhoram os fluxos de trabalho dos quais os funcionários dependem.

Líderes de engenharia enfrentam um problema de capacidade de verificação

Quando a capacidade de implementação se expande, o recurso escasso passa a ser a confiança justificada no que é entregue.

A confiança tem várias fontes: um requisito preciso, testes significativos, revisão bem informada e evidências do serviço em execução. Essas fontes respondem a perguntas diferentes. Um teste pode estabelecer o comportamento esperado para entradas selecionadas sem comprovar que o próprio requisito atende ao cliente.

A pesquisa do Google sobre desenvolvimento de software assistido por IA oferece uma comparação mais ampla. As conclusões do DORA de 2025 associam a adoção de IA a maior volume de entrega, ao mesmo tempo em que enfatizam a organização ao redor. A pesquisa descreve a IA como algo que amplia pontos fortes e fracos existentes.

Essa perspectiva sustenta uma interpretação cautelosa do marco da Microsoft. Uma equipe com responsabilidades claras e controles de lançamento confiáveis tem onde direcionar capacidade adicional de implementação. Já uma equipe com responsabilidades não resolvidas pode acumular mais propostas que ninguém consegue aprovar com confiança.

A pressão, portanto, recai primeiro sobre gerentes de engenharia e equipes de plataforma. Eles determinam quem é responsável pelos critérios de aceitação, quais alterações exigem atenção especializada e como um lançamento pode ser revertido. Essas decisões se tornam mais importantes quando as propostas chegam mais rápido.

Especialistas em segurança enfrentam um problema relacionado de alocação. Revisar toda alteração com a mesma intensidade consome atenção independentemente do risco. Revisar apenas arquivos de segurança óbvios deixa passar comportamentos introduzidos em outros pontos. A tarefa difícil é conectar alterações às permissões, aos dados e às ações de clientes que elas afetam.

Os gerentes de produto também assumem mais responsabilidade. Solicitações ambíguas se tornam caras quando o software pode ser produzido antes que divergências venham à tona. Uma implementação polida pode criar impulso em torno de um requisito mal compreendido, tornando a correção politicamente mais difícil, mesmo quando alterar o código continua tecnicamente simples.

É aqui que as organizações devem distinguir espera de deliberação necessária. Alguns atrasos refletem informações ausentes ou um revisor sobrecarregado. Outros atrasos protegem uma decisão irreversível. Tratar ambos como desperdício incentiva as equipes a remover salvaguardas apenas porque elas desaceleram um painel.

Uma resposta gerencial útil é examinar onde a incerteza entra no processo. Se revisores perguntam repetidamente o que um recurso deve fazer, o requisito precisa de trabalho. Se questionam repetidamente os efeitos da implantação, o processo de lançamento precisa de melhor visibilidade.

Esses são diagnósticos organizacionais, não argumentos a favor de processos ilimitados. Cada controle adicional tem um custo. O padrão deve ser se ele responde a uma questão consequente que outro controle deixa sem solução.

A história do desenvolvimento do Copilot Cowork torna esse dilema excepcionalmente visível. Líderes de engenharia agora precisam explicar como expandirão a capacidade de verificação junto com a capacidade de implementação. Comprar acesso a um agente de programação não resolve essa decisão operacional.

Para compradores corporativos, a questão correspondente diz respeito à qualidade das mudanças. Lançamentos mais rápidos se tornam úteis quando os funcionários enfrentam menos interrupções, permissões mais claras e conclusão de tarefas mais confiável. A frequência de lançamentos, por si só, deixa esses resultados em aberto.

A migração do Copilot Cowork para Rust separa linguagem de arquitetura

A Microsoft relata que a migração do Copilot Cowork para Rust reduziu o tempo mediano de resposta do primeiro turno de 7,9 segundos para 2,7 segundos em uma janela de comparação. Ela também atribui parte da melhoria à transferência do loop do agente e não faz nenhuma alegação sobre custo por turno.

Uma migração pode melhorar um serviço sem estabelecer que a linguagem de programação causou todas as melhorias.

Um runtime é o mecanismo de software que executa o trabalho de uma aplicação. Transferir esse mecanismo entre linguagens pode alterar gerenciamento de memória, agendamento, implantação e comportamento de inicialização. Se diversos elementos mudam juntos, a medição resultante captura seu efeito combinado.

A distinção importa porque debates sobre linguagens de programação frequentemente comprimem um projeto arquitetural em uma disputa simples. Esse enquadramento produz uma manchete clara, mas oferece uma base fraca para a decisão de investimento de outra equipe. A questão relevante é qual mecanismo aborda o próprio gargalo da equipe.

As garantias de concorrência do Rust fornecem uma referência técnica concreta. Concorrência significa que partes separadas de um programa podem progredir de forma independente. Rust usa regras de propriedade e verificação de tipos para detectar muitos erros de memória e concorrência antes da execução.

Essas garantias têm limites. Elas não estabelecem que uma resposta contém a informação empresarial correta, que uma operação tem permissão ou que os usuários recebem eventos na sequência esperada. Segurança da linguagem e correção da aplicação se sobrepõem apenas parcialmente.

Um serviço de agendamento ilustra a diferença. Seu código pode lidar com a memória de forma segura e ainda selecionar o calendário errado. Suas tarefas podem ser executadas sem uma condição de corrida de dados e ainda enviar um convite antes da aprovação. Uma garantia no nível da linguagem não pode fornecer uma regra de produto ausente.

Evidências de migração, portanto, exigem várias camadas. Uma camada trata do uso de recursos e do tempo de resposta. Outra trata do comportamento sob tráfego realista. Outra trata de saber se a substituição preserva obrigações que antes eram implícitas.

Uma comparação controlada, idealmente, manteria constantes as condições de carga de trabalho e infraestrutura enquanto documentaria as alterações em avaliação. Migrações de produção raramente oferecem uma separação experimental perfeita. Essa limitação deve moldar a atribuição, e não apagar medições operacionais úteis.

Para desenvolvedores que leem o relato sobre a migração do Copilot Cowork para Rust, a implicação prática é analítica. Determine se o problema relevante envolve agendamento de execução, sobrecarga de inicialização, comportamento de memória ou design da aplicação antes de generalizar o resultado.

Para compradores, a linguagem em si geralmente importa menos do que o resultado do serviço. Respostas iniciais mais rápidas são valiosas, mas não estabelecem conclusão mais rápida de uma tarefa inteira. Um sistema pode começar a responder mais cedo e ainda levar mais tempo para produzir uma entrega correta.

A mesma distinção se aplica à economia. Uma melhoria de latência não estabelece automaticamente um custo operacional menor. Uso de infraestrutura, chamadas de modelo, novas tentativas e trabalho de suporte afetam todos o cálculo.

Isso torna a migração um estudo de caso útil sobre atribuição. Ela mostra por que um resultado de engenharia deve manter seu contexto arquitetural quando se torna uma alegação pública de desempenho.

A revisão por agentes precisa de uma base independente para confiança

Adicionar revisores aumenta a confiança apenas quando suas verificações fornecem evidências úteis e suficientemente independentes.

Um agente de IA é um sistema orientado por modelos que seleciona ações e usa ferramentas em direção a um objetivo. Um revisor de agentes pode inspecionar uma mudança proposta, identificar preocupações e solicitar correções. Seu julgamento continua sendo uma saída a ser avaliada, especialmente quando o agente autor forneceu grande parte da explicação ao redor.

Os padrões de fluxos de trabalho de agentes da Anthropic descrevem sistemas que separam a geração da avaliação. A empresa recomenda designs simples, critérios de avaliação claros e complexidade adicional apenas quando ela melhora os resultados. Isso oferece uma comparação útil com o papel crescente da revisão automatizada.

Um avaliador tem um trabalho mais fácil quando o sucesso pode ser observado diretamente. Um cálculo numérico pode ser verificado por meio de uma computação independente. Um fluxo de trabalho sensível a permissões exige um tipo diferente de evidência porque a ação correta depende de identidade, política e contexto.

O perigo central é o mal-entendido compartilhado. Um autor e um revisor podem concordar porque ambos interpretaram um requisito ambíguo da mesma maneira. Essa concordância não resolve a ambiguidade. Um modelo ou prompt separado ajuda apenas se trouxer uma diferença relevante de evidência ou raciocínio.

Os testes têm uma limitação semelhante. Um teste escrito junto com uma implementação pode reproduzir as premissas da implementação. Sua aprovação estabelece consistência entre esses artefatos. Não estabelece necessariamente consistência com o comportamento pretendido.

Evidências independentes podem vir de um contrato existente, comportamento observado, requisito aprovado ou um caso de falha cuidadosamente selecionado. A fonte certa depende da mudança. A distinção importante diz respeito a se a evidência pode contradizer a implementação.

Considere uma verificação automatizada que relata sucesso apesar de não receber nenhuma entrada relevante. Seu resultado se assemelha a uma inspeção bem-sucedida, mas não contém informações sobre a mudança proposta. Um símbolo visível de aprovação torna-se enganoso quando os usuários não conseguem saber o que a verificação realmente examinou.

É por isso que a qualidade da revisão não pode ser reduzida ao número de agentes atribuídos. Um pequeno conjunto de verificações com propósitos distintos pode oferecer mais confiança do que revisões amplas repetidas. O objetivo é cobrir modos de falha consequentes sem criar um fluxo ilegível de comentários.

O envolvimento humano também precisa de um papel específico. Pedir que alguém aprove uma mudança sem tempo ou contexto cria uma supervisão apenas nominal. Uma revisão eficaz exige uma decisão clara, evidência relevante e autoridade para rejeitar a proposta.

Para o desenvolvimento com Copilot Cowork, a lição mais ampla diz respeito à relação entre automação e responsabilidade. Um feedback automatizado mais rápido pode apoiar o julgamento humano, mas a organização ainda precisa de uma base explícita para aceitar riscos.

Essa base deve permanecer compreensível depois que os autores originais deixarem a conversa. Um registro pesquisável de requisitos e decisões ajuda futuros revisores a reconstruir a intenção. As equipes que gerenciam esse contexto podem explorar uma base de conhecimento pesquisável sem tratar documentos armazenados como prova de que o software se comporta corretamente.

A pesquisa sobre produtividade complica a manchete do pull request

O estudo de caso da Microsoft e a pesquisa independente sobre produtividade medem coisas diferentes, portanto suas conclusões não podem ser substituídas umas pelas outras.

O experimento de produtividade de desenvolvedores da METR oferece um contraponto útil. Em seu estudo do início de 2025, 16 desenvolvedores experientes de código aberto concluíram 246 tarefas. Permitir o uso de IA aumentou o tempo de conclusão em 19% nesse contexto, apesar de os participantes acreditarem que as ferramentas ajudaram.

Esse resultado diz respeito a desenvolvedores, repositórios, tarefas e ferramentas específicos. Ele não estabelece que a IA desacelera todas as equipes de engenharia. Também não pode avaliar diretamente um fluxo de trabalho posterior organizado em torno de muitos agentes simultâneos.

Posteriormente, a METR qualificou ainda mais o cenário. Sua atualização do experimento de produtividade de fevereiro de 2026 descreveu problemas de seleção e dificuldade para medir o tempo quando os desenvolvedores usavam agentes simultaneamente. Os pesquisadores consideraram os resultados mais recentes não confiáveis para estimar com precisão o efeito atual.

Juntas, essas fontes estabelecem um problema de medição, e não um veredito universal. O tempo de conclusão das tarefas, as mudanças integradas e a utilidade relatada pelos próprios usuários podem variar de formas diferentes. Uma avaliação sólida especifica qual resultado importa antes de interpretar um resultado.

Para um desenvolvedor individual, uma ferramenta pode reduzir o trabalho desagradável sem reduzir o tempo decorrido. Para uma organização, uma ferramenta pode ampliar o conjunto de projetos viáveis sem diminuir o esforço de manutenção. Esses benefícios merecem consideração, mas precisam de rótulos precisos.

Uma equipe também pode concluir mais trabalho porque escolhe tarefas menores. Isso pode melhorar a entrega ao reduzir espera e incerteza. Também pode inflar métricas de atividade enquanto grandes problemas dos clientes permanecem sem solução. A contagem sozinha não pode distinguir essas explicações.

O contrafactual também importa. Avaliar a produtividade exige alguma consideração sobre o que teria acontecido sem a ferramenta ou o processo. Um lançamento bem-sucedido estabelece que uma equipe entregou algo. Não estabelece de forma independente o grau de aceleração atribuível à IA.

O relato público da Microsoft fornece um exemplo operacional, em vez de uma comparação aleatorizada. Esse formato pode revelar mecanismos e modos de falha úteis. Ele não consegue isolar toda contribuição de especialização dos desenvolvedores, infraestrutura, suporte organizacional e capacidade do modelo.

A mesma cautela se aplica aos concorrentes. A orientação arquitetural da Anthropic explica uma abordagem de design, enquanto a pesquisa do Google descreve padrões mais amplos. Nenhuma delas estabelece qual fornecedor entrega o melhor resultado para uma carga de trabalho empresarial específica.

Para líderes de engenharia, a implicação é resistir a transformar um número memorável em uma fórmula de dimensionamento de equipe. Decisões sobre quadro de pessoal exigem evidências sobre entrega sustentada, qualidade, carga de suporte e o trabalho que permanece fora do processo medido.

A história também deixa em aberto uma questão econômica. O custo total do trabalho aceito inclui geração, avaliação, infraestrutura, atenção humana e correção após o lançamento. Mais atividade de implementação pode coexistir com uma economia melhor ou pior.

Portanto, o desenvolvimento com Copilot Cowork deve ser avaliado como um exemplo específico de trabalho reorganizado. Sua contribuição mais forte é estimular perguntas melhores sobre evidências, em vez de fornecer uma taxa de conversão universal entre engenheiros e agentes.

Três sinais tornarão o modelo de desenvolvimento mais fácil de avaliar

As próximas evidências úteis dizem respeito a resultados sustentados, verificação repetível e ao custo total do trabalho aceito.

O primeiro sinal é um acompanhamento que conecte a atividade de desenvolvimento à confiabilidade em produção. Nos próximos meses, a divulgação de falhas de lançamento, reversões ou problemas recorrentes de clientes ajudaria os leitores a interpretar o volume de mudanças integradas.

Uma melhoria na confiabilidade junto com uma entrega sustentada fortaleceria o argumento a favor do modelo operacional. O aumento do trabalho de reparo o tornaria mais complexo. Qualquer um dos resultados forneceria mais valor para decisões do que outro registro isolado de atividade.

A comparação deve usar definições consistentes. Uma mudança nas práticas de relatório pode fazer um serviço parecer mais saudável sem alterar seu comportamento. Os leitores devem buscar uma janela de medição estável e uma explicação clara do que conta como falha.

O segundo sinal é a evidência de que as práticas de verificação se transferem para além da equipe original. Uma avaliação documentada, uma configuração de teste reproduzível ou um caso comparável de produção ajudariam a distinguir uma abordagem amplamente útil de um resultado dependente de condições incomuns.

A replicação não exige que outra equipe iguale o total diário. Ela exige mostrar que capacidade adicional de implementação produz resultados aceitos sem sobrecarregar revisão e operações. Cargas de trabalho diferentes devem razoavelmente produzir níveis de atividade diferentes.

Se outras equipes reproduzirem os benefícios sob restrições diferentes, o caso se tornará mais geral. Se o sucesso depender fortemente de infraestrutura especializada ou expertise concentrada, sua aplicabilidade se tornará mais limitada. Isso ainda seria uma informação útil para compradores e líderes de engenharia.

O terceiro sinal é uma análise econômica confiável. O custo por tarefa de cliente concluída com sucesso conectaria as mudanças de engenharia à realidade operacional do produto. Também revelaria se novas tentativas e trabalho corretivo absorvem aparentes ganhos de eficiência.

Uma divulgação útil explicaria quais custos entram no cálculo. Excluir a revisão ou a infraestrutura responderia a uma pergunta mais restrita. Incluí-las ajudaria as organizações a comparar a abordagem com seu processo existente.

Estas são prioridades de observação, não compromissos anunciados de divulgação. A Microsoft não prometeu todas as medições discutidas aqui. A ausência delas deixaria partes do caso sem solução, em vez de estabelecer automaticamente uma falha.

Para compradores empresariais, a ação imediata é pedir aos fornecedores evidências vinculadas a um fluxo de trabalho real. Escolha uma tarefa que os funcionários realizam, defina um resultado aceitável e examine como o sistema lida com exceções. Mantenha a atividade de desenvolvimento separada do sucesso do cliente.

Para líderes de engenharia que avaliam o desenvolvimento com Copilot Cowork, use o marco para tornar mais precisas as perguntas por trás de suas próprias decisões de adoção. Identifique o que sua equipe tem dificuldade de verificar, onde a intenção se perde e quais resultados justificam automação adicional. Compare o trabalho aceito ao longo de um período significativo, incluindo o esforço necessário para corrigi-lo. Leia o relato de engenharia subjacente junto com a pesquisa sobre produtividade, pois eles respondem a perguntas diferentes. Em seguida, examine se sua organização consegue explicar por que uma mudança merece ser lançada. Quando a implementação se torna mais fácil de ampliar, essa explicação se torna uma responsabilidade central da engenharia. Que evidência convenceria sua equipe de que mais código gerado se tornou software mais confiável?