Um artigo de trabalho de Harvard oferece uma forma útil de avaliar uma afirmação comum sobre produtividade: mais código escrito com IA deverá significar mais software entregue. Em 718 empresas que utilizam a plataforma de análise de engenharia Jellyfish, Fiona Chen e James Stratton estimam que a adoção de agentes de programação foi seguida por aumentos de 30% nas linhas de código, 20% nos commits e 23% nos pull requests por trabalhador ativo. As suas métricas de issues e epics do Jira concluídos não mostraram um aumento estatisticamente significativo. A versão atual do artigo tem a data de 4 de agosto de 2026; os dados sobre eventos de trabalho terminam em março de 2026.

A discrepância é relevante para os responsáveis de engenharia porque um pull request entra numa fila para revisão, testes e possível revisão do código. No mesmo estudo, o tempo decorrido entre a submissão e a integração de um pull request aumentou, segundo a estimativa, 49% após a adoção de agentes. Os pedidos de alterações tornaram-se mais frequentes e aumentaram os comentários por pull request. Estes resultados apontam para mais trabalho de revisão, embora não mostrem que todas as alterações escritas por agentes sejam fracas nem identifiquem uma taxa de defeitos medida.

A grande mudança

  • O que mudou: Neste estudo ao nível das empresas, a adoção de agentes de programação coincidiu com muito mais atividade de programação e revisões de pull requests mais exigentes, sem um aumento estatisticamente significativo de issues ou epics resolvidos.
  • Porque é importante: Linhas, commits e pull requests medem o trabalho que entra no processo de produção. O trabalho resolvido é uma medida posterior. Uma equipa que avalie os agentes apenas pelo volume de código pode não detetar a carga que chega à revisão.
  • O que acompanhar: Se as empresas conseguem aumentar a capacidade de revisão e se os dados posteriores mostram ganhos no trabalho concluído. Este artigo de trabalho acompanha a adoção inicial até março de 2026 e não permite determinar os efeitos a longo prazo.

Assistentes e agentes produziram estimativas diferentes

Os autores distinguem assistentes, que respondem com sugestões de código enquanto um programador trabalha, de agentes, que podem assumir uma tarefa de nível superior e executar várias etapas antes de o programador aprovar o resultado. Medem a adoção de assistentes através da ativação de licenças empresariais do GitHub Copilot e do Cursor. Para os agentes, combinam dados de utilização do Claude Code com sinais como contas de bots e assinaturas de ferramentas em commits ou pull requests. Algumas utilizações individuais ou ferramentas não integradas podem escapar a estas medidas. A estimativa dos agentes é a associação adicional em torno da adoção de agentes, comparada com o período anterior de adoção de assistentes; não é uma estimativa para cada indivíduo que utiliza um agente.

Os resultados dos assistentes foram menores: aumentos estimados de 12% nas linhas, 9% nos commits e 5% nos pull requests. Apenas o resultado dos commits foi estatisticamente significativo nas principais estimativas do artigo. A adoção de agentes mostrou aumentos significativos nas três medidas de atividade de programação. Um commit regista uma atualização de código; um pull request submete uma alteração para revisão. Nenhum prova que uma funcionalidade tenha chegado aos utilizadores. O artigo usa issues do Jira resolvidos e epics maiores como medidas de resultados numa fase posterior, com base no fluxo de trabalho registado em que as equipas marcam o trabalho como concluído após revisão, testes e implementação. O estado no Jira é uma aproximação da entrega, e não uma medição independente do que os utilizadores receberam.

Para os agentes, o aumento estimado dos issues resolvidos foi de 0,12 por trabalhador-mês, face a uma base de 3,67, com um erro-padrão de 0,17. O resultado não é estatisticamente diferente de zero. A conclusão de epics também não mostrou alterações significativas. Os autores indicam que o intervalo de confiança exclui um aumento na conclusão de issues superior a 12% da média de base durante o período estudado. Esta conclusão é mais restrita do que afirmar que os agentes não produzem software útil: continuam a ser possíveis ganhos modestos, e a contagem de issues não capta todas as alterações de valor ou qualidade. Os autores testaram se a dimensão dos issues se alterou usando medidas previstas da duração das tarefas e não encontraram indícios dessa alteração na amostra.

Mais trabalho chegou aos revisores

As métricas de revisão oferecem um mecanismo plausível para a diferença nos resultados. Após a adoção de agentes, o artigo estima mais 3,45 dias entre a submissão e a integração de um pull request, face a uma base de 7,03 dias, um aumento de 49%. Trata-se de tempo de calendário no processo de revisão, e não de uma medição cronometrada dos minutos de revisão ativa de uma pessoa. A percentagem de pull requests que recebeu um pedido formal de alterações subiu cerca de 12 pontos percentuais, face a uma base de 13%; os comentários por pedido aumentaram 0,58 face a uma base de 1,66, ou 35%. A percentagem de trabalhadores que reviu pelo menos um pull request num mês aumentou cerca de quatro pontos percentuais, face a uma base de 29%, um aumento relativo de 14%. As estimativas comparáveis para assistentes não mostraram aumentos significativos na duração da revisão, nos pedidos de alterações ou nos comentários.

Só com estes metadados, o artigo não consegue determinar porque é que um revisor pediu alterações. Mais submissões podem sobrecarregar uma fila de revisão fixa; uma alteração na qualidade do código ou nos padrões de revisão também pode aumentar o escrutínio. Os autores não encontraram um aumento significativo na dimensão média dos pull requests, o que enfraquece uma explicação simples para os comentários adicionais. Não inspecionaram o conteúdo do código nem contaram diretamente os defeitos no trabalho gerado por agentes. O seu modelo de produção em duas etapas explica como escrever código mais depressa e alterar a revisão necessária por rascunho podem, em conjunto, limitar o trabalho concluído. O modelo é uma interpretação das observações, não um teste separado que isole qualquer um dos mecanismos.

As ferramentas de revisão com IA também se tinham difundido na amostra: quase 80% das empresas tinham utilizado uma até março de 2026. Ainda assim, o artigo atribui 23,3% dos comentários de revisão à IA e encontra pelo menos um comentário de IA em 10,8% dos pull requests. Por conseguinte, a adoção de uma ferramenta de revisão não significa que a revisão tenha passado a ser automática nestas empresas.

O que o desenho pode estabelecer

Os investigadores analisam cerca de 300 milhões de eventos de trabalho entre janeiro de 2021 e março de 2026 em 718 empresas clientes da Jellyfish que aceitaram participar, abrangendo 725 938 trabalhadores. Comparam os resultados antes e depois de as empresas adotarem assistentes ou agentes com os resultados das empresas que os adotaram mais tarde ou ainda não os tinham adotado, usando um desenho escalonado de diferenças-em-diferenças. Os controlos por empresa e mês de calendário abrangem algumas diferenças estáveis e tendências temporais comuns. A inferência continua a depender de quão comparáveis seriam as trajetórias dessas empresas sem a adoção. As empresas maiores adotaram primeiro, e alterações não observadas podem ter afetado tanto a adoção como o trabalho de engenharia. O estudo é observacional; as suas estimativas não devem ser interpretadas como um teste aleatorizado nem como uma previsão para todas as equipas de software.

O resultado sobre o emprego exige a mesma prudência. Usando o emprego total associado ao LinkedIn e os trabalhadores ativos na Jellyfish para medir o emprego em engenharia, os autores não conseguiram atribuir uma alteração significativa à adoção de agentes durante o período observado. Isso não revela o que acontecerá com a contratação após um período de ajustamento mais longo ou no mercado de trabalho em geral.

Cobertura anterior da BIG CHANGE analisou um relato de engenharia separado sobre programação com IA e entrega fiável. Este estudo acrescenta uma perspetiva entre empresas e medidas distintas da atividade de programação, da revisão e do trabalho resolvido. A lição prática é acompanhar conjuntamente essas etapas ao avaliar agentes: um primeiro rascunho mais rápido altera o volume de trabalho à espera nas etapas seguintes, e este artigo ainda não mostra um aumento correspondente de issues ou projetos concluídos.

Fontes e leituras adicionais