A IA aumenta a produtividade da empresa? Onde o trabalho passa a esperar

Alargar a avenida não encurta a viagem se o cruzamento continua um só. Os carros chegam mais depressa à esquina e esperam ali, em fila. Com a IA na empresa, acontece algo parecido.

A IA aumenta a produtividade de quem a usa; a da empresa depende de onde o trabalho espera depois. Um estudo com empresas de software mediu os dois lados, e o que achou mostra onde a fila se formou. O que ele mostra, e o que não mostra, vem a seguir.

O que o estudo mediu, e quem mediu

O estudo se chama "Artificial Intelligence in the Firm: Bottlenecks in Software Production". Os autores são Fiona Chen e James Stratton, doutorandos da Universidade Harvard. É um Job Market Paper, um working paper de doutorando, sem indicação de revisão por pares em periódico; a versão atual é de 4 de agosto de 2026, e a primeira, de 7 de janeiro de 2026.

Os dados vêm da Jellyfish, uma plataforma de análise de engenharia, e são de clientes que consentiram o uso em pesquisa. A Jellyfish leu o manuscrito só para verificar se ele não revelava informação proprietária e não o revisou quanto ao conteúdo científico.

O financiamento declarado no artigo vem de três fontes: a Stripe Economics of AI Fellowship, um programa da Harvard Kennedy School e o Schmidt Sciences AI at Work Program. Quem forneceu os dados vende medição de engenharia, e vale saber quem mediu antes de ler o que se mediu.

A amostra tem 725.938 trabalhadores em 718 empresas, de janeiro de 2021 a março de 2026: cerca de 300 milhões de eventos de trabalho, entre atividade no GitHub, issues do Jira e eventos do Google Calendar. Os autores compararam as empresas pelo momento em que cada uma adotou ferramentas de IA de código, e mediram separadamente os assistentes e os agentes. Os números deste artigo são do efeito dos agentes.

Os dados de trabalho foram cruzados com dados do LinkedIn, de onde vêm os números de emprego. O desenho tem nome técnico, diferenças em diferenças escalonado: em termos simples, compara-se o que mudou nas empresas depois de adotar a ferramenta com o que mudou, no mesmo período, nas que ainda não tinham adotado.

Um limite, dito logo: são times de software. Não é amostra de pequenas e médias empresas, nem do Brasil, nem de funções fora de software.

O que subiu: o volume

Começamos pelo que confirma a crença, porque ela tem fundamento. Nas 718 empresas do estudo, com agentes de IA, as linhas de código adicionadas subiram 1.494 por trabalhador por mês, 30% sobre a média-base de 5.017. Os commits, que registram cada alteração no código, subiram 20%, e os pull requests, 23%.

Pull request, ou PR, é o pedido para incorporar um trecho de código ao produto. Antes de entrar, alguém precisa conferir e aprovar. Vale guardar esse detalhe, porque o resto do estudo gira em torno dele.

Os autores escrevem que as duas tecnologias, assistentes e agentes, aumentam a produtividade de codificação. Quem acredita que a IA aumenta a produção de quem a usa tem razão, e o estudo concorda. Dois cuidados, ainda assim: a unidade é o trabalhador (worker, no original), e não o engenheiro; e linha de código mede volume, não valor.

O que não subiu: o que sai pela porta

Para medir trabalho concluído, os autores usaram as issues do Jira, unidades de trabalho de engenharia consideradas concluídas quando o código associado vai para produção. É o mais perto que o estudo chega do que a empresa de fato entregou.

Com agentes, essa medida subiu 0,12 issue por trabalhador por mês, sobre uma base de 3,67, sem significância estatística. O intervalo de confiança de 95% permite descartar, para os agentes, um ganho maior que 12% da média-base. O tamanho de cada pull request não mudou de forma significativa, e não há sinal de mudança no tamanho das issues, o que afasta a leitura de que cada entrega teria ficado maior.

Medida, por trabalhador por mês	Média-base	Efeito dos agentes de IA
Linhas de código adicionadas	5.017	+1.494 (+30%)
Commits	22,58	+4,57 (+20%)
Pull requests	5,34	+1,22 (+23%)
Trabalho concluído (issues do Jira)	3,67	+0,12, sem significância estatística; ganho acima de 12% descartado

"Sem aumento significativo" não quer dizer que a entrega caiu, nem que ficou parada. Quer dizer que, se houve ganho, o estudo não consegue separá-lo do acaso, e que um ganho acima de 12% está descartado. A avenida alargou; a viagem, até onde o estudo consegue ver, não encurtou na mesma medida.

Onde o trabalho passou a esperar

Se a produção subiu e a entrega não acompanhou, o trabalho a mais ficou em algum lugar. O estudo olhou para o trecho entre a submissão do pull request e o merge, o momento em que o código conferido é incorporado.

Com agentes, esse intervalo subiu 3,45 dias sobre uma média de 7,03 dias, 49% a mais. A medida inclui a espera: são dias entre o pedido e a incorporação, e não horas gastas revisando.

A parcela de pull requests que recebe pedido formal de mudança era de 13,00% e subiu 11,84 pontos percentuais, quase dobrando a taxa, nas palavras dos autores. Pedido de mudança quer dizer que o revisor devolveu o trabalho com ajuste antes de aprovar; não indica erro nem defeito. Os comentários por pull request subiram 35%, e a parcela de trabalhadores que comentam ou aprovam ao menos um pull request no mês subiu 14% (4,14 pontos percentuais sobre uma base de 29,42%).

No resumo, os autores escrevem que os ganhos de produtividade não passam inteiros para o software entregue nem para o emprego e que, no caso dos agentes, essa transmissão incompleta reflete um ponto de espera na revisão de código: os tempos de revisão aumentam. Nas entrevistas qualitativas do apêndice, anônimas e identificadas só pelo cargo, um engenheiro de software sênior diz: "Dá para gerar funcionalidades muito mais rápido agora, mas elas ainda precisam ser validadas e aprovadas por humanos" (tradução nossa). É a fala de um entrevistado, não um resultado estatístico, mas descreve bem o cruzamento.

Esta leitura é nossa, não dos autores: a fila mudou de lugar e se formou onde o trabalho é conferido.

E a revisão feita por IA?

A saída que parece óbvia, pôr IA também na revisão, já estava em curso. Em março de 2026, quase 80% das empresas da amostra tinham usado ferramentas de IA no processo de revisão de código.

Ainda assim, só 23,3% de todos os comentários de revisão eram gerados por IA, e só 10,8% dos pull requests recebiam ao menos um comentário gerado por IA.

Os autores escrevem que o ponto de espera persiste depois da adoção dessas ferramentas e que os revisores humanos continuam a ter papel central. Essa afirmação se apoia nos dados descritivos e nas entrevistas, não num teste estatístico próprio. O estudo não estima o efeito da revisão com IA sobre a espera: não diz que ela encurta a espera, nem que não encurta.

O que o estudo não mostra

O estudo não mostra que a IA não funciona: a produção de código subiu, e os autores dizem isso com todas as letras. Também não mede horas de revisão nem custo de retrabalho, e não fala de proposta, orçamento, post ou qualquer trabalho fora do software.

E não é um estudo da Universidade Harvard como instituição, nem artigo publicado em revista. É o trabalho de dois doutorandos, sem indicação de revisão por pares, e a versão citada aqui é a de 4 de agosto de 2026.

Ele também não serve de argumento para cortar equipe. Para os agentes, os autores estimam efeito zero preciso sobre o emprego total, descartando uma queda maior que 2,9%. A IA substitui tarefa, não substitui direção.

Do código para a mesa do fundador

Daqui em diante, o texto é leitura da Nortix. Nenhum dado do estudo é sobre pequenas e médias empresas, nem sobre proposta, orçamento ou post; o que se leva do software para outros negócios é a forma do achado, como hipótese, e não o número. É uma hipótese para testar na própria empresa, e a última parte deste texto mostra como.

Numa empresa de serviço, boa parte do que a equipe pode produzir com IA é texto: a proposta, o orçamento, o post, a resposta ao cliente. Cada um desses passa, em algum ponto, por alguém que confere antes de sair, e muitas vezes esse alguém é o fundador ou quem responde pelo preço, pelo cliente e pela palavra da empresa. Essa conferência tem motivo: é o papel que segura o nome da empresa, e alguém precisa cumpri-lo.

Quando a equipe passa a produzir mais depressa, esse cruzamento continua um só. As propostas chegam mais cedo à mesa de quem aprova e esperam ali.

A equipe sente que produziu mais, e produziu; quem aprova sente que tem mais coisa para ver, e tem. A empresa, olhando o que sai pela porta, pode não ver diferença.

É aqui que gestão e IA se cruzam de um jeito que mexe com receita. Proposta pronta que espera aprovação não vira contrato enquanto espera, e orçamento que volta duas vezes para ajuste chega ao cliente depois. Nada disso é falha de quem confere.

A velocidade foi acrescentada num trecho, e o trecho seguinte ficou do mesmo tamanho.

Como olhamos para isso na Nortix

Na Nortix, o trabalho é implementação de IA e geração de receita para PMEs, e a forma como a gente olha uma empresa começa antes da ferramenta. O primeiro passo tem nome, Raio-X de Processos: mapear, área por área, por onde cada tarefa passa, quem a toca e onde ela espera. Depois vêm a Matriz de Priorização, que pesa impacto contra esforço, e a Validação com o Fundador.

Na nossa leitura, é aqui que a Validação com o Fundador pesa: acelerar um trecho não basta se ninguém olhou o que vem depois dele. Decidir o que continua passando pelo fundador, e o que pode sair dele com segurança, é decisão dele. A gente faz isso com o fundador, não por ele, e só então chega a Implementação e Retorno.

O caminho completo de como implementar IA na empresa está no nosso guia sobre o tema; por que essa ordem vem antes da escolha de ferramenta está em outro texto, sobre estrutura antes de ferramenta.

Um exercício para a próxima segunda-feira

Dá para ver isso na própria empresa sem contratar ninguém e sem mudar nada por enquanto. Escolha um tipo de trabalho que a equipe já produz com ajuda de IA, como proposta, orçamento ou post. Durante duas semanas, anote três coisas por item: o dia em que ficou pronto, o dia em que saiu e se voltou para ajuste antes de sair.

Não precisa de ferramenta nova: uma planilha com uma linha por item e três colunas resolve. O que se anota é o caminho do trabalho, não o desempenho de quem o fez, e vale dizer isso à equipe antes de começar.

No fim, compare as datas. Se a maior parte do tempo está entre "pronto" e "saiu", a produção já anda depressa e o trabalho espera em outro trecho. Se muita coisa volta para ajuste, a pergunta seguinte é o que o ajuste costuma corrigir.

Duas semanas não dão conclusão estatística, e nem é essa a ideia. Dão um primeiro desenho de onde o trabalho espera, e isso já basta para escolher o que olhar primeiro.

O exercício não pede para ninguém conferir menos. Pede só para ver onde a fila se forma. A pergunta que importa deixa de ser se a IA aumenta a produtividade da empresa e passa a ser onde, na empresa, o trabalho espera.

Perguntas frequentes

A IA aumenta a produtividade?

De quem a usa, no estudo de Chen e Stratton, sim: os autores escrevem que assistentes e agentes aumentam a produtividade de codificação. A produtividade da empresa é outra medida, e no mesmo estudo o trabalho concluído não teve aumento estatisticamente significativo.

O ganho de produtividade com inteligência artificial aparece no resultado da empresa?

Pode não aparecer na mesma medida, quando o trabalho a mais encontra um ponto de passagem que não cresceu junto. No estudo, esse ponto foi a revisão de código. Fora do software, que esse ponto exista é leitura nossa, não dado, e onde ele fica só se descobre olhando a empresa.

A IA na empresa dá resultado?

Depende de onde o ganho de velocidade cai e do que vem depois dele. O estudo mostra que acelerar a produção não garante, sozinho, mais entrega. Não mostra que a IA não funciona.

O estudo vale para empresas que não são de software?

Não diretamente. A amostra é de times de software, em empresas clientes da Jellyfish, sem recorte de PME nem do Brasil. O que se leva para outros negócios é a forma do achado, como hipótese, e não o número.

O estudo foi revisado por pares?

Não há indicação disso. É um working paper de doutorandos, na versão de 4 de agosto de 2026, com dados de uma plataforma que vende análise de engenharia, que leu o texto só para checar informação proprietária.

Fontes

1. Fiona Chen e James Stratton (Harvard University), "Artificial Intelligence in the Firm: Bottlenecks in Software Production", Job Market Paper, versão de 04/08/2026 (1ª versão 07/01/2026), dados da Jellyfish. https://fion.ac/jellyfish.pdf
2. Página pessoal de Fiona Chen, que lista o artigo como Job Market Paper. https://fion.ac/