A IA realmente melhora a produtividade dos desenvolvedores?

Imagine um desenvolvedor que começou a usar IA no trabalho cotidiano. Uma mudança fica pronta mais rápido do que o normal, mas o pull request precisa de duas rodadas extras de revisão. A ferramenta melhorou a produtividade ou apenas deslocou o trabalho para a etapa seguinte?

Esse trade-off aparece em pesquisas confiáveis. Experimentos controlados mostram conclusão mais rápida de tarefas e mais trabalho concluído, enquanto estudos em repositórios familiares e organizações com uso intenso de IA mostram trabalho mais lento, retrabalho e maior carga de revisão. A diferença não se resume a uso “bom” ou “ruim” da IA: limites da tarefa, contexto da base de código, dificuldade de verificação e capacidade do sistema de entrega influenciam o resultado.

A resposta depende do que sua equipe desenvolve, de quem usa a ferramenta e do que acontece depois da primeira versão do código. Este artigo compara os estudos mais fortes, explica por que seus resultados diferem e mostra como testar o impacto da IA sem reduzir produtividade a volume de código.

A resposta curta: a IA pode melhorar a produtividade de desenvolvedores, mas apenas nas condições certas

A IA pode de fato melhorar a produtividade de desenvolvedores. Os ganhos mais claros aparecem em trabalhos delimitados, com resultado verificável e capacidade de revisão suficiente para absorver o volume gerado. Esses resultados valem para tarefas e populações específicas, não para todo desenvolvedor ou toda base de código.

O estudo DORA de 2025 mostra por que essa distinção importa no nível do sistema. Em um survey com quase 5.000 profissionais de tecnologia, mais de 80% perceberam aumento de produtividade com IA. Entretanto, maior adoção de IA foi associada tanto a maior throughput de entrega quanto a maior instabilidade. Uma equipe pode movimentar mais trabalho e tornar a entrega menos confiável. Como o estudo é observacional e boa parte das evidências de produtividade vem de autorrelato, ele identifica um padrão amplo, mas não prova que a IA causou nenhum dos resultados.

Velocidade de programação é apenas uma camada. Acompanhe trabalho concluído, qualidade, retrabalho, espera e experiência do desenvolvedor. Então faça três perguntas: trabalhos comparáveis terminaram mais rápido? O ganho sobreviveu à revisão e à entrega? Quanto a equipe pagou em retrabalho, estabilidade ou atenção?

Abordagens consolidadas de métricas de produtividade de desenvolvedores e o framework SPACE já tratam produtividade como algo multidimensional. Aplique essa disciplina à IA, apresente medidas conflitantes e delimite cada afirmação por tarefa, população, medida e período.

O que mostram os estudos mais fortes

A leitura mais clara é esta: tarefas controladas costumam apresentar bons resultados; o trabalho em repositórios ativos é mais complicado.

Os estudos abaixo mediram resultados diferentes, com ferramentas e populações diferentes. Suas porcentagens não são intercambiáveis.

Estudo	Contexto	Resultado	Limite
RCT do GitHub Copilot	95 participantes; acesso randomizado ao Copilot em uma tarefa de JavaScript.	Usuários do Copilot terminaram 55,8% mais rápido.	Evidência causal, mas limitada a uma tarefa de 2022. Sem dados de equipe ou qualidade de longo prazo.
Três experimentos empresariais de campo	4.867 desenvolvedores em três experimentos empresariais randomizados.	O acesso à IA aumentou as tarefas concluídas em 26,08%.	Evidência em escala, mas a contagem de tarefas não mede qualidade nem resultados do produto.
Estudo DORA 2025	Quase 5.000 profissionais; survey observacional e mais de 100 horas de pesquisa qualitativa.	Mais de 80% relataram maior produtividade. A adoção se associou a mais throughput e instabilidade.	Visão ampla do sistema, mas correlação e autorrelatos não provam causalidade.
RCT da METR do início de 2025	16 desenvolvedores experientes; 246 tarefas reais em repositórios familiares.	O acesso à IA tornou o trabalho 19% mais lento.	Evidência causal em trabalho real, mas com amostra pequena e ferramentas do início de 2025.
Estudo de uma empresa com ampla adoção de IA	802 desenvolvedores; 196.212 pull requests em uma empresa.	O throughput de pull requests aumentou; a carga de revisão quase dobrou.	Mostra pressão downstream, mas a adoção não foi randomizada e o volume de PRs não é uma medida completa.

Um RCT empresarial do Google estimou separadamente cerca de 21% menos tempo para concluir uma tarefa complexa com IA. Isso reforça a evidência de velocidade em um contexto empresarial, embora o estudo tenha ocorrido em uma única empresa com ferramentas internas e uma estimativa imprecisa.

Os estudos controlados mediram tempo ou tarefas concluídas sob acesso randomizado. Os estudos de repositórios revelaram retrabalho e pressão de revisão que uma tarefa delimitada talvez nunca mostre. A DORA acrescenta um terceiro nível: associações amplas entre adoção e resultados do sistema de entrega. Lidos em conjunto, eles respondem a partes diferentes da pergunta; calcular a média de suas porcentagens criaria uma estimativa de retorno que nenhum deles mediu.

O método limita cada conclusão. O acesso randomizado fortalece afirmações causais, mas captura somente o trabalho incluído no experimento. Estudos longitudinais observam um sistema mais amplo, enquanto escolhas de adoção dificultam a atribuição. Experimentos mostram se um ganho pode acontecer; evidências de campo mostram o que pode diluí-lo ou redirecioná-lo.

A unidade também importa. Tempo de tarefa, trabalho concluído e pull requests integrados são resultados diferentes, e nenhum prova que o cliente recebeu valor antes. Antes de aplicar uma porcentagem ao caso de negócio, identifique o resultado e pergunte se o contexto do estudo se parece com seu trabalho.

Por que os resultados mudam em contextos do mundo real

Mude o trabalho e o resultado também muda.

Uma implementação isolada, com linha de chegada clara, oferece ao assistente um problema restrito e ao desenvolvedor uma forma simples de conferir a resposta. Repositórios maduros carregam convenções não documentadas, histórico arquitetural, dependências ocultas e decisões sobre o que precisa continuar intocado. Essa diferença ajuda a explicar por que experimentos delimitados encontraram ganhos enquanto a METR observou mantenedores experientes levando mais tempo em bases conhecidas.

A experiência muda o destino do trabalho. Os experimentos empresariais encontraram ganhos maiores entre desenvolvedores menos experientes. A análise da Microsoft encontrou outro efeito no sistema: contribuidores periféricos produziram mais enquanto contribuidores centrais absorveram revisão e manutenção adicionais. O autor pode avançar mais rápido enquanto quem responde pela base fica mais ocupado.

Ferramentas mais novas mudam a pergunta sem apagar resultados anteriores. Um assistente de preenchimento de código de 2022, uma ferramenta empresarial de 2024 e um agente de programação mais recente têm capacidades diferentes. No experimento de acompanhamento com ferramentas mais novas, as estimativas brutas indicaram trabalho 18% mais rápido entre participantes que retornaram e 4% mais rápido entre novos participantes, mas ambos os intervalos de confiança incluíram zero. Problemas de seleção e medição de tempo impediram uma estimativa confiável. A atualização justifica testar novamente; ela não prova que a lentidão anterior desapareceu.

A verificação pode ser a verdadeira restrição. Gerar código plausível é barato. Confirmar se ele respeita regras de segurança, premissas operacionais e comportamentos fora dos arquivos alterados pode levar muito mais tempo. Quanto mais difícil for conferir a resposta, menos a velocidade de geração informa sobre produtividade.

A capacidade de revisão impõe outro limite. Produzir mais rápido perde valor quando testes, revisores e processos de release já estão saturados. Os estudos da Microsoft e da empresa com ampla adoção de IA mostram por que é necessário acompanhar para onde o trabalho foi.

O AI Capabilities Model da DORA identifica trabalho em pequenos lotes, foco no usuário e plataformas internas de qualidade entre sete capacidades que interagem com os resultados da IA. O modelo vem do mesmo programa de pesquisa de 2025, não de um experimento independente. Portanto, trate essas capacidades como hipóteses, não como uma receita garantida.

Por fim, acesso é um proxy fraco para uso. Um desenvolvedor pede explicações, outro gera testes e um terceiro delega uma mudança inteira. Colocar esses comportamentos no mesmo grupo pode esconder quais tarefas realmente melhoram ou pioram.

A percepção também não resolve a pergunta. Os desenvolvedores do experimento da METR esperavam que a IA ajudasse e acreditaram que ela havia ajudado, embora o tempo medido tenha aumentado. A experiência deles continua relevante, mas responde a uma pergunta diferente daquela respondida pelo tempo total.

Comece pelo estudo mais próximo da sua stack. Declare as diferenças e teste o resultado nos dados da sua própria entrega.

Produtividade não é apenas velocidade: qualidade, retrabalho e carga de revisão importam

Mais pull requests podem significar mais entregas. Também podem significar uma fila de revisão maior.

Na análise de código aberto da Microsoft, o período pós-Copilot foi associado a maior produção entre contribuidores periféricos e a mais retrabalho e manutenção pelos contribuidores centrais. O resultado trata da transferência de trabalho entre contribuidores, não da qualidade de toda mudança assistida por IA. Um aparente ganho na produção de código pode virar trabalho de limpeza para outra pessoa.

A empresa com ampla adoção de IA encontrou uma restrição parecida: o throughput de pull requests aumentou bastante enquanto a carga de revisão aproximadamente dobrou. A compensação ainda pode valer a pena. O throughput, sozinho, deixa a pergunta sem resposta.

Combine sinais imediatos de qualidade, como sucesso nos testes e aceitação da mudança, com o que acontece depois: revisões, trabalho reaberto, incidentes, falhas de mudança, problemas de manutenção e tempo gasto para explicar código desconhecido. Nenhum sinal basta sozinho. Juntos, eles mostram se a entrega se sustentou.

As medidas de fluxo completam a análise. Acompanhe o tempo de ciclo de PR de ponta a ponta, a espera por revisão, o número de rodadas e o tempo até o merge. Se a revisão virar a restrição, use práticas de code review para examinar responsabilidades, tamanho das mudanças, distribuição de revisores e capacidade.

A pergunta útil é se a revisão adicional compra velocidade de entrega suficiente para compensar. Deixe esse custo visível antes de decidir.

Como líderes de engenharia devem medir o impacto da IA na produtividade de desenvolvedores

Prepare a mensuração antes de implantar a ferramenta. Caso contrário, você tentará reconstruir o baseline quando expectativas e formas de trabalho já tiverem mudado.

1. Registre a hipótese. Identifique a classe de tarefa, o benefício esperado e o limite aceitável. Por exemplo: “A assistência de IA reduzirá o tempo mediano de manutenções delimitadas sem aumentar rodadas de revisão ou falhas após o merge.”
2. Capture um baseline. Meça o mesmo fluxo antes da implantação e registre pessoas, repositório, composição das tarefas, pressão de release e mudanças de processo que possam afetar o resultado.
3. Compare trabalhos semelhantes. Separe mudanças delimitadas de trabalhos dependentes de contexto, features planejadas de interrupções e repositórios maduros de código mais novo. Informe qualquer mudança nessa composição.
4. Combine velocidade e medidas posteriores. Acompanhe tempo e throughput junto de espera por revisão, rodadas, taxa de retrabalho, estabilidade e experiência. Uma visão de tempo de ciclo mostra se a programação mais rápida sobrevive à integração e à entrega.
5. Registre como a IA foi usada. Quando possível, diferencie trabalho assistido e não assistido e anote ferramenta, modo e categoria de tarefa. Analise as condições no nível da equipe e mantenha dados de uso fora de rankings individuais.
6. Escolha antes a janela de avaliação. Analise o período inicial e meça novamente depois da adaptação da equipe. O atrito inicial pode desaparecer, enquanto custos de manutenção demoram mais para surgir.
7. Olhe além da média. Compare os mesmos percentis e a mesma composição de tarefas ao longo do tempo. Uma mediana mais rápida pode esconder uma cauda crescente de trabalhos lentos ou intensivos em revisão.

Defina antecipadamente qual resultado justificará ampliar, ajustar ou interromper o piloto. Assim, a equipe não muda o critério depois de conhecer os dados. Isso também obriga o caso de negócio a declarar um custo aceitável: quanta revisão adicional, se houver, compensa uma determinada melhora no tempo de entrega? Um piloto sem regra de decisão pode produzir um dashboard e ainda deixar a pergunta original sem resposta.

O framework de ROI da DORA de 2026 chama a revisão adicional de verification tax e a necessidade de processos downstream absorverem mais produção de pipeline adaptation. Sua curva J é um modelo de planejamento com profundidade e duração imprevisíveis, não evidência de que toda adoção se recuperará ou produzirá retorno.

Converse com os desenvolvedores sobre carga cognitiva, confiança, frustração e trabalhos que as métricas operacionais não capturam. Use essas respostas junto do comportamento observado. No estudo da METR, percepção e tempo avançaram em direções opostas. É justamente por isso que você precisa dos dois.

Um dashboard de antes e depois pode revelar uma mudança sem provar sua causa. Alterações simultâneas em pessoas, políticas, repositórios e produto continuam sendo explicações possíveis. A força da conclusão deve acompanhar a força da comparação.

A DevStats oferece uma visão neutra de uso de IA, que pode ser analisada junto de medidas de entrega e qualidade. Essas visões ajudam a organizar a avaliação; o desenho da comparação define o que você pode afirmar.

Exemplo do relatório AI Usage da DevStats. Esses sinais de atividade mostram adoção, não produtividade; leia-os junto de tempo de ciclo, carga de revisão, retrabalho e estabilidade.

Então, sua equipe deve investir em ferramentas de programação com IA?

Sim, se você puder avaliar a adoção como uma mudança no sistema, em vez de presumir um ganho de produtividade.

Comece com tarefas delimitadas e verificáveis, nas quais as evidências são mais fortes e o baseline é visível. Tenha mais cautela com trabalhos que exigem muito contexto em repositórios maduros ou equipes cujos revisores já estão sobrecarregados.

Depois, responda a uma pergunta: o sistema de entrega inteiro melhorou? Trabalho comparável mais rápido é um ganho. Código produzido mais rápido, seguido por aumento desproporcional de revisão, retrabalho ou instabilidade, indica apenas uma mudança de gargalo. Se o resultado variar conforme a tarefa, você descobriu onde a ferramenta deve ser usada.

O resultado precisa mostrar um trade-off que a equipe compreenda e considere vantajoso. Um resultado inconclusivo também é útil: restrinja o caso de uso, ajuste o fluxo ou espere antes de ampliar a adoção.

A IA pode melhorar a produtividade de desenvolvedores. Seu sistema de entrega decide se esse potencial sobrevive ao trabalho real. Se a programação fica mais rápida enquanto revisão e retrabalho aumentam, a IA não eliminou o gargalo. Apenas o mudou de lugar.