Artificial Intelligence in the Firm: Bottlenecks in Software Production — síntese em português (31/10/2026)

Autores: Fiona Chen e James Stratton
Instituição: Harvard University, conforme afiliação dos autores
Versão do estudo analisada: 31 de outubro de 2026, 120 páginas
Revisão desta síntese: versão 2, 1º de novembro de 2026
Natureza da publicação: manuscrito acadêmico identificado como Job Market Paper; o documento consultado não informa publicação em periódico nem certifica revisão por pares
Fonte original: Endereço corrente do PDF disponibilizado pela autora

Este artigo é uma síntese editorial do estudo de Fiona Chen e James Stratton, elaborada em etapas e revisada com apoio do ChatGPT 6.1 Sol Extra High. A autoria e os resultados da pesquisa original pertencem integralmente aos pesquisadores. O texto não constitui uma publicação oficial da Harvard University nem dos autores do estudo.

Os resultados e as páginas desta síntese referem-se à cópia de 31/10/2026. O endereço da autora é atualizável e pode apresentar uma edição posterior.

IA produz mais código. Por que as entregas de software crescem menos?

Uma análise do estudo de Fiona Chen e James Stratton sobre adoção de assistentes e agentes, os limites da revisão e a diferença entre acelerar tarefas e ampliar a produção das organizações.

A adoção de inteligência artificial na engenharia de software coloca duas perguntas diferentes na mesma discussão. A primeira é quanto mais código uma equipe consegue produzir. A segunda é quanto desse trabalho se transforma em software concluído, validado e disponibilizado para uso. Uma resposta positiva à primeira não determina, por si só, a resposta à segunda.

Fiona Chen e James Stratton investigam essa passagem entre atividade e resultado em empresas reais, acompanhando registros de desenvolvimento, gestão de tarefas, revisão de código e emprego. A contribuição central da pesquisa está em observar etapas complementares do processo produtivo, em vez de avaliar apenas o desempenho de uma ferramenta em uma tarefa isolada.

Os resultados são compatíveis com ganhos relevantes de capacidade de programação, especialmente quando se observam commits e submissões de código para revisão. Entretanto, os aumentos estimados no número de trabalhos concluídos são menores e estatisticamente incertos. A revisão se torna mais demorada após a adoção de agentes, enquanto os dados não permitem atribuir às ferramentas uma mudança estatisticamente detectável no emprego agregado de engenharia durante o horizonte acompanhado.

Isso interessa às decisões de investimento porque a capacidade de gerar código constitui um insumo da produção de software. Ela não mede diretamente receita, utilidade para o cliente ou retorno financeiro. Para compreender o resultado organizacional da IA, o estudo acompanha o que acontece depois que o código é escrito.

Sumário

1. O estudo em perspectiva executiva
2. O que os dados representam
3. Como a pesquisa identifica os efeitos da adoção
4. Mais código, mais submissões e menos crescimento nas entregas
5. O gargalo da revisão
6. Qualidade do código submetido e qualidade do software final
7. Como muda o trabalho e onde os efeitos são diferentes
8. O que foi observado sobre emprego
9. O modelo econômico dos gargalos
10. O que a calibração permite inferir
11. Ajuste organizacional e cenários futuros
12. O que a pesquisa não permite concluir
13. O significado para a gestão de tecnologia
14. Conclusão
15. Referência bibliográfica

As páginas citadas correspondem à posição no PDF de 120 páginas, contando a capa como página 1. “Figura” e “Tabela”, sem outra indicação, referem-se às figuras e tabelas principais; as peças suplementares são identificadas como “do Apêndice D” ou “do Apêndice E”.

1. O estudo em perspectiva executiva

A pesquisa distingue duas gerações de ferramentas. Assistentes oferecem sugestões e respostas durante a programação. Agentes executam sequências mais longas de ações com autonomia parcial, a partir de uma instrução. As análises usam janelas diferentes: até 16 meses depois da adoção de assistentes e até 12 meses depois da adoção de agentes.

Há seis resultados que orientam a leitura.

• A produção intermediária aumenta. No último mês de cada janela, a adoção de assistentes está associada a aumentos estimados de 25,5% nos commits e 25,2% nos pull requests abertos por trabalhador. Para agentes, os aumentos adicionais estimados são 36,0% e 35,7%. Esses efeitos são estatisticamente significativos a 5%.
• Os ganhos em trabalhos concluídos são menores. As estimativas são de 2,0% em issues e 1,7% em epics para assistentes; para agentes, 13,7% e 18,0%. Nenhuma dessas estimativas finais é estatisticamente significativa a 5%.
• Há ganhos depois da revisão. Pull requests efetivamente integrados à base de código também aumentam: 24,0% com assistentes e 26,0% com agentes. Portanto, a revisão não impede toda a expansão da produção.
• A revisão fica mais demorada com agentes. O intervalo entre abertura e merge de um pull request aumenta 56,1%, na estimativa do mês 12. Há aumento tanto da espera até o primeiro comentário humano quanto do intervalo posterior até a integração.
• Não se detecta mudança no emprego agregado de engenharia. Os intervalos de incerteza ainda admitem variações economicamente relevantes; o resultado não estabelece que o efeito verdadeiro seja exatamente zero.
• Os cenários de longo prazo são exercícios condicionais. Eles dependem da evolução da capacidade de revisão, da demanda por software e de hipóteses sobre a adaptação das empresas. Não são resultados observados nem probabilidades atribuídas ao futuro.

Fontes: seções 4 a 6, pp. 27–46; Figuras 6–13, pp. 54–61; Figura 10 do Apêndice D, p. 81.

Uma diferença decisiva: o efeito dos agentes é estimado em relação a uma situação na qual as empresas tipicamente já utilizavam assistentes. As duas colunas de resultados não constituem um teste simultâneo entre tecnologias em condições idênticas. Tampouco se deve somar seus percentuais para anunciar um ganho acumulado observado.

2. O que os dados representam

2.1 Uma base de atividades de empresas, não um experimento de laboratório

A fonte principal é a Jellyfish, plataforma que integra dados usados pelas empresas para acompanhar suas equipes de engenharia. A pesquisa trabalha com clientes que autorizaram o uso dos dados para fins científicos e que atendem às condições necessárias à análise.

O conjunto descrito reúne 655 empresas e 720.542 trabalhadores, entre janeiro de 2021 e agosto de 2026. A referência a aproximadamente 445 milhões de eventos combina diferentes tipos de registros. Ela não significa 445 milhões de observações independentes de um experimento, nem 720.542 programadores usando IA simultaneamente.

A Tabela 1 informa cobertura de controle de versões e gestão de tarefas para todas as empresas desse conjunto. O calendário está disponível para 192 empresas, equivalentes a 29,3% da amostra. Dados de RH existem apenas para parte dos trabalhadores. Os autores complementam as informações com perfis profissionais e características empresariais obtidos por meio da Revelio Labs.

Esses totais descrevem o acervo analítico apresentado no manuscrito. Cada estimativa utiliza os registros pertinentes ao indicador, à tecnologia, à janela de observação e às condições de cobertura. O documento não fornece uma contagem completa de empresas, trabalhadores e observações para cada regressão. Consequentemente, seria incorreto atribuir automaticamente os totais de 655 empresas e 720.542 trabalhadores a todos os resultados.

Fontes: seção 2, pp. 8–13; Tabelas 1–3, pp. 62–64.

2.2 Que empresas e profissionais aparecem

As empresas são predominantemente estabelecidas e de porte médio ou grande. Em janeiro de 2023, a média era de aproximadamente 1.677 trabalhadores no total, segundo a Revelio, e 249 profissionais ativos no Jellyfish. A idade média das empresas era de 19,4 anos. A dispersão é elevada, com uma cauda de empresas muito maiores.

Há empresas que vendem licenças de software, operadoras de serviços digitais e organizações que desenvolvem software como insumo de suas próprias operações. Portanto, a pesquisa não se restringe a fornecedores de software empresarial, embora esse ambiente tenha presença importante.

Na classificação de ocupações disponível, 76,6% dos trabalhadores estão em engenharia de software. O restante inclui dados e pesquisa, produto e design, outras engenharias e funções administrativas ou comerciais. O número total de trabalhadores não deve ser apresentado como se todos fossem desenvolvedores.

A diversidade de empresas amplia o interesse organizacional dos resultados. Ainda assim, a amostra não é aleatória: reúne clientes de uma plataforma de análise de engenharia que consentiram no uso científico dos dados e dispõem das integrações necessárias.

2.3 Do código à entrega: o significado dos indicadores

Um commit salva uma alteração. Um pull request, ou PR, submete um conjunto de alterações para revisão. O merge integra as alterações à base compartilhada. Essa integração não implica necessariamente que a funcionalidade já esteja em produção.

Os autores interpretam a resolução de issues e epics como aproximação de trabalho concluído e disponibilizado, com apoio nas práticas descritas pelos sistemas e nas entrevistas. Essa interpretação é mais próxima do resultado final do desenvolvimento do que a contagem de commits, mas continua dependente da forma como as empresas mantêm seus registros.

Uma issue também pode representar correção de bug ou outra tarefa técnica. Assim, “issues resolvidas” não é sinônimo de “novas funcionalidades”, e nenhuma das duas expressões mede automaticamente valor econômico.

Fontes: pp. 9–11 e 26–27; Figura 1, p. 49.

2.4 Entrevistas e dados complementares

O trabalho inclui entrevistas qualitativas com 21 profissionais de engenharia, gestão de engenharia, produto e áreas relacionadas. Elas ajudam a interpretar o processo de aquisição das ferramentas e os mecanismos organizacionais. Não constituem uma amostra representativa para estimar a frequência de experiências ou problemas.

Os autores também apresentam uma pesquisa com 100 engenheiros recrutados pela Prolific, utilizada para comparar a distribuição declarada do tempo com a distribuição imputada a partir dos registros de trabalho. Esses 100 participantes não devem ser confundidos com os trabalhadores do painel Jellyfish.

O manuscrito informa apoio financeiro de programas ligados à Stripe, Harvard Kennedy School e Schmidt Sciences. Informa também que a Jellyfish revisou o documento para verificar a ausência de divulgação de informações proprietárias, e não para avaliar seu conteúdo científico. Essa revisão contratual não equivale a revisão acadêmica por pares.

Fontes: p. 1; pp. 11 e 36; Apêndice C, pp. 68–71.

3. Como a pesquisa identifica os efeitos da adoção

3.1 Diferenças-em-diferenças com adoção em momentos distintos

Comparar uma empresa antes e depois de adotar IA seria insuficiente: ela poderia estar crescendo por outros motivos. Comparar empresas adotantes e não adotantes em um único momento também seria insuficiente, porque elas podem ser diferentes desde o início.

O desenho de diferenças-em-diferenças com adoção escalonada procura combinar as duas comparações. Empresas adotam as ferramentas em meses diferentes; as trajetórias de quem adotou mais cedo são confrontadas com as de quem ainda não havia adotado. A análise é organizada em observações por empresa e mês, com efeitos apresentados em meses relativos à adoção.

A especificação principal incorpora:

• características permanentes de cada empresa, por meio de efeitos fixos de empresa;
• condições comuns de cada mês, por meio de efeitos fixos de calendário;
• controles que permitem trajetórias distintas relacionadas ao tamanho inicial;
• controles para a expansão da cobertura dos dados após a entrada no Jellyfish.

Os erros-padrão são agrupados por empresa, coerentemente com o nível em que a adoção é definida. A dimensão da base de eventos não elimina a incerteza entre empresas.

Os estudos de evento acompanham oito meses anteriores à adoção e até 16 meses posteriores para assistentes ou 12 para agentes. As estimativas destacadas nas tabelas deste artigo correspondem ao último mês de cada janela, salvo indicação expressa em contrário.

Fontes: seção 4.2, pp. 27–29.

3.2 O que precisa ser verdadeiro para interpretar os resultados causalmente

A hipótese central é a de tendências paralelas: sem a adoção, empresas que adotaram em momentos distintos teriam seguido trajetórias comparáveis nos indicadores analisados, dadas as condições controladas.

Os autores argumentam que diferenças no tempo de avaliação, contratação, aprovação jurídica, segurança e realização de pilotos geram variação no momento da adoção que pode ser pouco relacionada à trajetória produtiva. As entrevistas mostram processos que vão de uma aprovação rápida a vários meses.

Essa é uma justificativa para o desenho, não uma randomização. Empresas maiores adotam mais cedo, o que motiva os controles de tamanho. Os coeficientes anteriores à adoção e os testes de robustez ajudam a avaliar a plausibilidade das comparações, mas não demonstram que todo fator não observado tenha sido eliminado.

Mudanças simultâneas de gestão, equipe ou estratégia continuam sendo uma preocupação possível. A leitura causal deve permanecer vinculada às hipóteses do desenho, inclusive quando os resultados parecem intuitivos.

3.3 Como se reconhece a adoção

Para assistentes, a data de adoção combina os primeiros sinais de ativação de licenças empresariais de GitHub Copilot e Cursor. Para agentes, os pesquisadores combinam a integração com Claude Code e rastros em contas de bots, mensagens de commits e descrições de PRs. Ferramentas de revisão são identificadas por sinais próprios.

O procedimento oferece uma cobertura mais ampla do que depender apenas de uma API. Contudo, não observa toda utilização: uma licença individual, uma ferramenta não integrada ou um uso sem assinatura reconhecível pode escapar da detecção.

A primeira adoção observada também não significa uso intenso por toda a equipe. Na Figura 5, os coeficientes estimados para a taxa de adoção individual são de +37,58 pontos percentuais no mês 16 para assistentes e +35,30 pontos percentuais no mês 12 para agentes, entre os profissionais que já programavam na janela de referência. Eles representam aumentos estimados nessa coorte fixa, e não uma contagem direta de usuários entre todos os trabalhadores do acervo. O nível observado dessa taxa no mês correspondente tampouco pode ser reconstruído somando mecanicamente o coeficiente à média inicial, porque falta considerar a trajetória contrafactual.

As taxas empresariais também têm interpretação delimitada. Em julho de 2026, os autores identificam adoção de agentes em 98,3% das empresas consideradas nessa medição. Isso não representa a taxa de adoção de todas as empresas do mercado.

Fontes: seção 2.4, pp. 13–17; Figura 5, p. 53; Apêndice F.1, pp. 99–101.

3.4 Robustez e estimativas por usuário

Regressões com efeitos fixos de empresa e tempo podem produzir comparações problemáticas quando a adoção é escalonada e os efeitos variam entre grupos e períodos. O estudo confronta sua estimativa principal com quatro abordagens alternativas desenvolvidas para esse problema.

O exercício, concentrado no efeito dos agentes sobre linhas de código, apresenta padrões e magnitudes semelhantes. Outras especificações variam o grupo de comparação, os controles, a composição do painel e a mensuração por trabalhador ou no total da empresa. O efeito final estimado em linhas por trabalhador varia de 38,3% sem os controles a 73,8% no painel balanceado; a especificação principal informa 44,0%. A mensuração do total empresarial produz 77,6%.

A direção do resultado é relativamente persistente nesses exercícios, mas a magnitude não é invariável. Além disso, a robustez demonstrada para linhas de código não certifica automaticamente cada resultado de emprego ou revisão.

Os autores ainda usam a adoção empresarial como instrumento para a adoção individual. O objetivo é estimar efeitos por usuário, distinguindo a difusão da ferramenta de outras mudanças ao longo do tempo. As estimativas finais em linhas de código são elevadas, de 161,8% para assistentes e 172,1% para agentes, mas imprecisas e não significativas a 5%.

A interpretação individual exige uma hipótese adicional forte: a adoção da empresa só afetaria a produção de um trabalhador por meio do uso que ele próprio faz da ferramenta. O próprio estudo reconhece que isso pode falhar quando colegas que não usam IA recebem mais código para revisar. A subdetecção de usuários também pode inflar o efeito atribuído a cada usuário observado.

Há ainda uma inconsistência de apresentação na primeira etapa dessa análise: para assistentes, o corpo do manuscrito informa adoção de 22,02% dos trabalhadores ativos no mês 16, enquanto a legenda da Figura 5 do Apêndice D informa 0,251, ou 25,1%. Essa divergência é distinta da mudança de denominador em relação à coorte de codificadores da Figura 5 principal. A documentação não permite reconciliá-la integralmente. Os efeitos de 161,8% e 172,1% são mantidos como estimativas reportadas pelos autores; não foram recalculados escolhendo uma das taxas nem por uma divisão simples, que tampouco reproduziria toda a especificação instrumental.

Esses números não devem ser lidos como um ganho comprovado de produtividade pessoal aplicável a qualquer desenvolvedor. O estudo tampouco encontra um padrão temporal claro que permita separar aprendizagem, evolução dos modelos e mudanças no perfil de quem adota.

Fontes: seções 4.4–4.5, pp. 31–33; Figuras 4–5 do Apêndice D, pp. 75–76.

4. Mais código, mais submissões e menos crescimento nas entregas

4.1 Os principais resultados quantitativos

Percentuais informados pelos autores em relação à média anterior à adoção em cada análise. Os valores absolutos e as médias impressas no manuscrito são arredondados; recalcular os percentuais a partir deles pode produzir pequenas diferenças. As colunas usam tratamentos, períodos e referências distintos.

Fontes: pp. 29–34; Figuras 6–7, pp. 54–55; Figura 10 do Apêndice D, p. 81.

As linhas de código chamam atenção, mas são uma medida ruidosa, sensível à extensão e ao estilo das implementações. A evidência de aumento da produção intermediária não depende apenas delas: commits e PRs abertos também crescem, com estimativas mais precisas.

No caso dos agentes, o efeito final é de aproximadamente 9,51 commits adicionais por trabalhador e mês, diante de uma média inicial de 26,43, e 1,73 PR adicional, diante de uma média de 4,83. Para assistentes, os valores correspondentes são 4,73 commits, diante de 18,55, e 0,888 PR, diante de 3,52.

Essas medidas não permitem concluir que cada unidade tenha a mesma utilidade ou complexidade. Elas indicam que a atividade produtiva se expandiu por mais de um critério de mensuração.

4.2 O que significa um efeito de 13,7% não significativo

Para issues resolvidas após a adoção de agentes, a estimativa final é de 0,350 unidade adicional por trabalhador e mês, com erro-padrão de 0,220, diante de uma média inicial de aproximadamente 2,55.

O sinal estimado é positivo. A incerteza, entretanto, é suficiente para que um intervalo de confiança de 95% inclua zero. Os autores informam que podem excluir aumentos superiores a 30,7% nesse indicador. Isso limita a interpretação de ganhos muito grandes, sem estabelecer que o efeito verdadeiro seja nulo.

Para epics, a estimativa de 18,0% também é imprecisa; o limite superior informado é de 41,5%. Portanto, a restrição quantitativa mais clara ao crescimento de entregas aplica-se a issues, e não indistintamente a todo conceito de resultado final.

Há ainda uma distinção estatística: uma estimativa significativa para PRs e outra não significativa para issues não constitui, sozinha, um teste de diferença entre os dois efeitos. O argumento do estudo combina as magnitudes estimadas, os intervalos de incerteza, a integração de código e as evidências do processo de revisão.

Fonte: seção 4.6, pp. 33–34.

4.3 Ganhos depois da revisão e trabalho ainda não integrado

A contagem de merges oferece uma evidência contrária à interpretação de que todo o código adicional permanece bloqueado. Com assistentes, o crescimento de PRs integrados, de 24,0%, fica próximo ao crescimento de PRs abertos, de 25,2%.

Com agentes, a expansão de merges, de 26,0%, é menor que a de aberturas, de 35,7%. Os autores comparam os efeitos absolutos e calculam uma relação de aproximadamente 62,7% entre merges e aberturas adicionais, diante de uma relação inicial de 86,1%.

Essa razão relaciona estimativas de fluxos agregados. Ela não acompanha uma coorte individual de PRs até seu destino e não demonstra que os demais PRs tenham sido rejeitados ou sejam inúteis. Parte pode permanecer pendente ao fim do período observado.

Além disso, o software pode ser integrado antes de ser implantado. A diferença entre merges e issues resolvidas preserva a relevância de etapas posteriores ou de outras exigências para concluir uma tarefa.

Fonte: p. 30; Figura 10 do Apêndice D, p. 81.

4.4 Último mês e média do período não são equivalentes

Os percentuais mais citados referem-se ao fim das janelas. Eles não descrevem um ganho médio constante durante todo o primeiro ano.

A Figura 6 informa, para agentes, um efeito agregado do período de 0,79 PR adicional por trabalhador e mês, comparado com 1,73 no mês 12. Para issues, a Figura 7 informa 0,16 no efeito agregado, comparado com 0,35 no mês 12.

A diferença pode refletir a expansão gradual do uso dentro das empresas e outros componentes dinâmicos. A análise instrumental não isola um crescimento claro do efeito por usuário ao longo do tempo. Por isso, não é possível atribuir toda a progressão à aprendizagem ou à melhoria tecnológica.

Fontes: pp. 32–33; Figuras 6–7, pp. 54–55.

5. O gargalo da revisão

5.1 Três intervalos diferentes

A revisão conecta o código submetido ao código aceito na base compartilhada. A pesquisa distingue o intervalo total até a integração e dois componentes aproximados por comentários humanos.

Fontes: seção 5.2, pp. 37–38; Figura 10, p. 58.

“Revisão ativa” é um intervalo decorrido, não uma medição de horas de atenção contínua do revisor. Entre o primeiro comentário e o merge podem ocorrer correções pelo autor, novas interações, esperas e outras atividades.

O primeiro comentário também é uma aproximação observável do início da revisão. Um profissional pode ler código sem comentar imediatamente. O indicador não registra diretamente cada momento em que alguém começa a examinar um PR.

Os três aumentos apresentados na tabela são estatisticamente significativos a 5%. Contudo, seus valores não devem ser somados: o tempo total considera um conjunto mais amplo de PRs com integração observada, enquanto a decomposição depende de PRs que receberam comentário. As médias iniciais são, respectivamente, 3,56, 2,78 e 3,98 dias. A diferença de amostras explica por que os componentes publicados não recompõem a média geral.

5.2 Mais chegadas, capacidade limitada e maior esforço

O mecanismo investigado tem duas partes.

Primeiro, o aumento da produção faz chegar mais código à revisão. Se a capacidade dos revisores não cresce no mesmo ritmo, aumenta a fila. Esse canal pode surgir mesmo sem piora da qualidade do código submetido.

Segundo, as submissões podem exigir mais iterações de verificação e correção. Nesse caso, a capacidade efetiva da revisão cai: o mesmo trabalho de revisão produz menos aprovações por unidade de tempo. A espera pode aumentar ainda mais.

A combinação de mais tempo até o primeiro comentário e mais tempo posterior ao primeiro comentário é coerente com esses dois canais. Ela não identifica perfeitamente cada causa, mas fornece evidências mais específicas do que simplesmente observar um prazo total maior.

O estoque de PRs abertos também aumenta na Figura 10. Esse resultado complementa as evidências de congestionamento, sem revelar sozinho a utilidade ou a dificuldade de cada alteração acumulada.

5.3 O que mostram comentários e pedidos de alteração

Após a adoção de agentes, a estimativa final indica:

• mais 0,629 comentário por PR, erro-padrão de 0,221, equivalentes a 38,6% sobre a média de 1,63 comentário; efeito significativo a 5%;
• mais 4,61 pontos percentuais na proporção de PRs com comentário, erro-padrão de 3,06 pontos, sobre uma média de 35,17%; aumento relativo de 13,1%, sem significância a 5%;
• mais 1,07 ponto percentual na proporção de PRs formalmente bloqueados por pedido de alteração, erro-padrão de 0,751 ponto, sobre uma média de 2,77%; aumento relativo de 38,5%, sem significância a 5%.

A distinção entre percentual e ponto percentual é material. A proporção de PRs bloqueados não aumenta 38,5 pontos percentuais: o efeito estimado é de aproximadamente um ponto percentual sobre uma base pequena.

Comentários também podem registrar dúvidas, requisitos de estilo, documentação, integração ou preferências de implementação. A convergência dos indicadores é compatível com mais esforço de revisão e possível deterioração do insumo submetido, mas não transforma cada comentário em um defeito confirmado.

Para assistentes, o estudo não encontra o mesmo aumento de duração total, fila e tempo posterior ao primeiro comentário. Isso impede tratar todo uso de IA como se produzisse o padrão observado com agentes.

Fontes: pp. 37–38; Figura 10, p. 58; Figura 11 do Apêndice D, p. 82.

5.4 Por que não basta deslocar qualquer pessoa para revisar

A revisão depende de conhecimento localizado. Em 82,8% das revisões observadas, o revisor já havia feito commits ou aberto PRs naquela base de código. No exercício de comparação dos autores, que atribui as revisões a PRs aleatórios da mesma empresa e mês, essa familiaridade seria de 17,2%.

A senioridade também aparece na divisão do trabalho: profissionais seniores realizam 75,7% das revisões de PRs escritos por seniores, ante 32,8% das revisões de PRs escritos por juniores.

Essas estatísticas são descritivas, e não efeitos da IA. Elas sustentam a ideia de que a substituição entre programar e revisar encontra restrições de experiência e familiaridade. Não demonstram que juniores sejam incapazes de revisar nem estabelecem uma regra universal de aprovação.

Fonte: seção 5.1, pp. 36–37; Figura 9, p. 57.

5.5 A revisão com IA já existe, mas adoção não significa cobertura integral

Em julho de 2026, 79,1% das empresas haviam utilizado ferramentas de IA na revisão. Entretanto, 23,3% dos comentários de revisão eram gerados por IA e 10,8% dos PRs recebiam ao menos um comentário de IA.

Os três percentuais têm denominadores distintos. Nenhum deles mede diretamente a parcela de todo o código efetivamente examinada por IA, a profundidade dessa análise ou a proporção de aprovações automatizadas.

O estudo mostra que a adoção de ferramentas de revisão coexistia com participação humana relevante e com o gargalo observado. Ele não apresenta, nessa seção, um experimento causal isolando o efeito dessas ferramentas sobre a revisão. Assim, os resultados não demonstram que revisar com IA seja ineficaz, nem que uma geração futura dessas ferramentas eliminará a restrição.

Fonte: seção 5.3, p. 39; Figura 11, p. 59.

6. Qualidade do código submetido e qualidade do software final

A pesquisa não observa o conteúdo integral dos commits. O diagnóstico sobre a qualidade do código submetido se apoia em sinais do processo: comentários, pedidos de alteração e tempo até a conclusão da revisão. Os autores interpretam a combinação desses sinais como compatível com uma deterioração do insumo que chega aos revisores.

A qualidade do software final é investigada separadamente, pelo número de bugs registrados no Jira por trabalhador. Nesse indicador, não aparece mudança estatisticamente significativa depois da adoção de assistentes ou agentes.

As estimativas finais são de −0,122 bug reportado por trabalhador e mês para assistentes, com erro-padrão de 0,078, e −0,062 para agentes, com erro-padrão de 0,150. Os sinais pontuais são negativos, mas não justificam anunciar melhoria comprovada da qualidade.

Esse resultado é relevante porque contraria a leitura de que mais comentários na revisão comprovam mais falhas no software entregue. É possível que a revisão intercepte problemas antes da implantação; também há limitações no que os registros de bugs conseguem captar. O estudo não identifica essas possibilidades como uma decomposição causal da qualidade.

Os autores verificam ainda se os comentários aumentaram apenas porque os PRs ficaram maiores. Não encontram mudança significativa no número médio de linhas adicionadas por PR. Essa análise enfraquece uma explicação mecânica simples, mas não mede toda a complexidade de uma alteração.

Também não se encontram mudanças detectáveis nas aproximações de tamanho das issues. Essas aproximações usam descrições textuais classificadas por IA e modelos treinados em dados anteriores à adoção. A ausência de mudança nesses indicadores não certifica que cada tarefa preservou a mesma dificuldade ou o mesmo valor.

O alcance da evidência: há sinais de maior esforço para revisar as submissões dos agentes; não há demonstração de aumento de defeitos em produção, perda de segurança ou deterioração geral da arquitetura.

Fontes: seção 4.6, pp. 33–34; p. 38; Figuras 8–9 e 12 do Apêndice D, pp. 79–80 e 83.

7. Como muda o trabalho e onde os efeitos são diferentes

7.1 Programar ocupa apenas parte da jornada

Antes de examinar a mudança tecnológica, o estudo estima a composição do trabalho. Na imputação feita com registros do Jellyfish, escrever código corresponde a 40,8% do tempo; revisão, a 17,7%; e a categoria ampla de gestão, a 41,5%. Na pesquisa com 100 engenheiros, os percentuais declarados são 30,8%, 21,8% e 47,4%, respectivamente.

A imputação associa sinais de trabalho a categorias e atribui a cada sinal o intervalo desde o sinal anterior, limitado a duas horas. Ela não funciona como um cronômetro de atividades. A categoria de gestão também reúne planejamento e outras interações; não corresponde apenas ao trabalho de pessoas com cargo de gestor.

Apesar da diferença entre as duas fontes, ambas mostram que a programação é apenas uma parcela da jornada. Uma ferramenta que acelera essa parcela não multiplica automaticamente a capacidade de todas as demais atividades.

O estudo não detecta alteração relevante no número total de reuniões por trabalhador. Há estimativas positivas para reuniões identificadas como revisão, mas elas são imprecisas. A disponibilidade de calendário é parcial, e reuniões de revisão identificáveis são raras. Não se pode concluir, a partir desse indicador, que a alocação de tempo tenha permanecido inalterada.

Fontes: pp. 36–38; Figura 9, p. 57; Figura 17 do Apêndice D, p. 88.

7.2 Atividade inicial, senioridade e área técnica

Os efeitos relativos sobre produção de código são maiores entre trabalhadores com menor atividade de programação antes da adoção. Isso não equivale a dizer que a IA beneficia mais os menos qualificados: menor quantidade inicial de PRs pode refletir funções com mais gestão ou revisão.

Os resultados são um pouco maiores entre seniores, que programavam menos inicialmente, mas a diferença por senioridade é pequena e não significativa. Há pouca variação sistemática entre áreas como front-end, back-end e outras especialidades técnicas.

Também aparece pouca heterogeneidade nos resultados de revisão conforme as características de quem escreveu o código. Portanto, o estudo não estabelece uma divisão simples em que um grupo produz todo o código adicional e outro absorve todo o custo.

As comparações são percentuais sobre a média inicial de cada grupo. Um aumento relativo maior, partindo de uma base menor, não demonstra que o aumento absoluto seja maior. Além disso, nem todos os trabalhadores puderam ser classificados em cada dimensão.

Fonte: seção 5.4.1, p. 40; Figuras 18–19 do Apêndice D, pp. 89–90.

7.3 Intensidade de uso e características das empresas

Entre empresas com adoção de agentes, o aumento estimado de PRs por trabalhador é de 21,4% no terço com menor difusão, 41,9% no intermediário e 67,0% no de maior difusão.

A associação é informativa, mas a intensidade é medida nos seis meses posteriores à adoção. Não é uma característica predeterminada nem uma dose de uso distribuída aleatoriamente. Empresas com resultados melhores podem ampliar mais rapidamente a utilização, e outras características podem influenciar ambos os resultados.

Por tamanho, setor e uso do software como produto ou insumo, o trabalho não encontra diferenças consistentes entre as duas gerações de ferramentas. Isso limita a possibilidade de eleger um setor ou porte como beneficiário universal.

A complexidade da base de código produz um padrão mais alinhado ao mecanismo de revisão. Para agentes, o tempo até o merge aumenta 69,7% no terço de empresas com mais repositórios, contra 25,4% no terço com menos repositórios. O crescimento de PRs abertos é de 30,0% e 64,3%, respectivamente. O número de branches apresenta um gradiente semelhante.

Os efeitos sobre issues resolvidas permanecem parecidos entre esses grupos. O resultado sugere dificuldades de revisão mais fortes em bases organizacionalmente complexas, mas repositórios e branches são aproximações, não uma avaliação completa da complexidade técnica.

Fontes: seção 5.4.2, p. 40; Figuras 20–25 do Apêndice D, pp. 91–96.

7.4 O que não foi medido sobre aprendizagem

As evidências de familiaridade com o código mostram a importância do conhecimento específico para revisar. Elas não medem perda de capacidade cognitiva, deterioração da aprendizagem, redução de domínio técnico ou dependência psicológica das ferramentas.

A pesquisa tampouco acompanha a formação de novos especialistas ao longo de muitos anos. Seu modelo supõe restrições ligadas à senioridade, mas não estima um processo completo de aquisição ou perda de conhecimento.

A mudança de horas entre programação e revisão, apresentada adiante, é uma inferência do modelo calibrado. Ela não deve ser relatada como uma medição direta de cada jornada posterior à adoção.

8. O que foi observado sobre emprego

8.1 Engenharia: efeitos não detectáveis, com intervalos relevantes

O indicador principal de emprego de engenharia é o número de trabalhadores ativos no Jellyfish em cada empresa e mês. É uma aproximação baseada na plataforma, não uma folha de pagamento.

As faixas reproduzem a apresentação percentual aproximada do manuscrito para coeficientes em log. Não são conversões exponenciais exatas.

Não há efeito significativo a 5% em nenhuma das duas análises. Entretanto, especialmente para agentes, o intervalo admite reduções relevantes. A formulação adequada é que a pesquisa não detecta uma mudança atribuível à adoção no período analisado, dentro da precisão disponível.

Fonte: seção 4.7, pp. 34–36; Figura 8, p. 56.

8.2 Emprego total, senioridade e movimentações

Com dados da Revelio, os autores examinam também o emprego total das empresas, incluindo funções fora da engenharia. As estimativas finais em log são −0,001 para assistentes, com erro-padrão de 0,031, e +0,039 para agentes, com erro-padrão de 0,033. Nenhuma é significativa a 5%.

A separação entre profissionais juniores e seniores também não revela efeitos significativos sobre os respectivos estoques de emprego. Essa análise utiliza a classificação da Revelio e abrange os trabalhadores das empresas, não exclusivamente programadores.

O quadro de contratações e saídas contém algumas diferenças que uma narrativa de “nenhum efeito em nada” perderia:

• para assistentes, há aumento estimado nas contratações, estatisticamente significativo a 5%, associado sobretudo a profissionais seniores;
• para agentes, não se detecta mudança significativa nas contratações ou saídas totais;
• não aparece a redução de contratações de juniores documentada em alguns outros estudos;
• as saídas de seniores após a adoção de agentes apresentam aumento com evidência apenas marginal, sem significância a 5%.

Os indicadores de contratações e saídas usam logaritmo de um mais a contagem. Seus coeficientes não devem ser convertidos mecanicamente em percentuais exatos de pessoas contratadas ou desligadas.

Fontes: pp. 35–36; Figuras 13–16 do Apêndice D, pp. 84–87.

8.3 Por que esse resultado não resolve o debate sobre empregos

O horizonte é curto para transformações organizacionais. Empresas podem alterar a combinação de tarefas antes de contratar ou dispensar pessoas, e os dados não acompanham todos os ajustes posteriores.

O desenho também identifica efeitos de equilíbrio parcial: o que muda na empresa que adota, em comparação com as demais na estrutura de análise. Se parte de sua expansão vier de clientes antes atendidos por concorrentes, pode haver efeitos sobre o emprego fora dela.

Assim, os resultados não demonstram ausência de deslocamento no mercado inteiro, proteção permanente a juniores ou inevitabilidade de demissões futuras. Eles delimitam o que foi detectado em empresas e períodos específicos.

9. O modelo econômico dos gargalos

9.1 Duas etapas complementares

O modelo formaliza uma ideia econômica: aumentar a capacidade de uma atividade pode produzir pouco resultado adicional quando outra atividade necessária não consegue acompanhá-la.

Os autores representam a produção de software por duas etapas, programação e revisão. Em uma notação simplificada:

Y = (1/n) × min{C, R}.

Aqui, Y representa o software produzido; C e R, os insumos de código e revisão colocados no processo; e n, a quantidade de alterações aprovadas necessária a uma unidade de resultado final.

A função usa o menor dos dois insumos porque eles são tratados como complementos perfeitos. Código adicional sem revisão correspondente não se transforma em produção final. Essa estrutura, conhecida como função de Leontief, é uma simplificação analítica, e não uma afirmação de que todos os processos reais operam de forma idêntica.

As capacidades das etapas dependem da produtividade e do trabalho alocado: produtividade de programação multiplicada por horas de programação; produtividade efetiva de revisão multiplicada por horas de revisão.

A segunda produtividade é afetada pela necessidade de refazer ou corrigir código. No modelo, uma probabilidade maior de problemas implica mais rodadas até a aprovação. A capacidade efetiva de revisão pode cair mesmo se a velocidade básica com que o revisor examina uma rodada permanecer constante.

Fontes: seção 3, pp. 17–26; demonstrações no Apêndice G.1, pp. 103–107.

9.2 O limite à realocação

As mesmas pessoas podem programar e revisar. O modelo não pressupõe dois quadros profissionais completamente separados.

Entretanto, parte da revisão exige profissionais seniores. A combinação entre a proporção de seniores disponíveis e a parcela de revisão que demanda essa experiência determina um teto para a participação do trabalho alocado à revisão.

A aceleração da programação e o aumento das exigências de correção empurram a organização na mesma direção: mais capacidade de revisão. O teto limita até onde esse deslocamento pode ir.

Esse mecanismo encontra apoio nas evidências de familiaridade com a base de código e senioridade dos revisores. Ainda assim, sua representação em um único teto reduz uma realidade mais complexa, na qual experiência, produto, arquitetura e distribuição do conhecimento podem importar de maneiras distintas.

9.3 Curto, médio e longo prazo têm significados específicos

A proposição de curto prazo, na qual o ganho de programação pode ter repasse nulo ao resultado, é uma conclusão do modelo sob trabalho totalmente fixo. Ela não é uma estimativa de que a adoção de IA produziu efeito zero sobre entregas em todas as empresas observadas.

Mesmo com realocação interna ideal, o repasse pode ser incompleto: parte do trabalho antes empregado em escrever código precisa ser deslocada para revisar. Se a capacidade de revisão encontra um teto, aumentos adicionais de programação deixam de ampliar o fluxo final.

9.4 Por que a demanda importa para o emprego

No longo prazo, produzir mais por hora permite tanto expandir a produção quanto reduzir as horas necessárias. O saldo depende de quanto o mercado absorve de software adicional quando seu custo e preço mudam.

Os autores acrescentam uma demanda linear e uma empresa com poder de mercado que escolhe produção e emprego. Nesse modelo, o trabalho total é a soma do trabalho de programação e de revisão; não representa o quadro de todas as funções da empresa, que aparece separadamente nos dados da Revelio. Mantêm hipóteses como retornos constantes de escala e salário dado. A elasticidade-preço da demanda governa o equilíbrio entre expansão e deslocamento de trabalho.

Para pequenas mudanças na produtividade, a formulação teórica apresenta um limiar de elasticidade igual a 3 para o trabalho total de programação e revisão. Para o choque discreto calibrado no estudo, o limiar calculado é 3,68; para trabalho de programação, 6,83. São exercícios distintos, e seus números não são intercambiáveis.

O modelo, portanto, não determina uma redução universal do emprego quando a produtividade cresce. Sob demanda suficientemente elástica, a expansão pode superar a economia de trabalho por unidade produzida.

Fontes: pp. 23–26 e 44–45; Figura 12, p. 60; Apêndice G.3.1, pp. 110–111.

10. O que a calibração permite inferir

10.1 Produtividade por hora e alocação não observadas diretamente

Os registros permitem contar código, revisões e tarefas, mas não medir perfeitamente quantas horas produziram cada resultado. Os autores usam o modelo para inferir mudanças nesses parâmetros.

A calibração combina seis momentos empíricos, como a expansão de PRs abertos e integrados, issues resolvidas, a trajetória da fila e a proporção de submissões com comentário. A estimação por distância mínima procura os parâmetros que aproximam as relações do modelo desses resultados, respeitando as restrições de trabalho.

Fonte: seção 6.2, pp. 42–43; Tabela 5, p. 66; Apêndice G.2, pp. 108–109.

O ganho de 73,7% não é a observação direta de que todos os engenheiros passaram a escrever 73,7% mais código por hora. Ele é o parâmetro de produtividade recuperado sob o modelo. Sua magnitude supera o crescimento dos PRs porque a calibração infere simultaneamente uma redução do trabalho destinado à programação.

As parcelas iniciais de 65,7% para programação e 34,3% para revisão referem-se ao universo restrito de programação mais revisão usado na calibração. Elas não são a divisão da jornada inteira e não contradizem os 40,8% de programação na imputação mais ampla.

10.2 A aproximação de problemas por comentários

A ligação empírica entre qualidade e produtividade de revisão merece atenção. A calibração aproxima a probabilidade de problemas pela parcela de PRs que recebem comentário, que passa de cerca de 35,2% para 39,8%.

Um comentário não é necessariamente um bug. A passagem entre comentário observado e probabilidade de problema é uma hipótese de mensuração do modelo. Ela permite estimar os parâmetros, mas limita a interpretação literal da queda de 7,0% como uma medição independente da eficiência dos revisores.

A documentação também não permite decompor causalmente o aumento dos comentários entre interações humanas, participação de bots e mudanças nas práticas de revisão. O critério de primeiro comentário humano é explícito na decomposição temporal, mas isso não transforma a contagem geral de comentários em medida exclusiva de esforço humano ou de defeitos. A maior presença de revisão automatizada é uma explicação possível para parte da mudança no registro de comentários, sem que o estudo tenha estimado sua contribuição separadamente.

Existe ainda uma questão de compatibilidade entre as medidas. No modelo simplificado, o tempo em revisão corresponde ao inverso da produtividade efetiva. O coeficiente calibrado de −0,073 em log implicaria um aumento de aproximadamente 7,6% nesse inverso, enquanto o intervalo observado depois do primeiro comentário aumenta 58,5%. Esse intervalo não integra diretamente os seis momentos usados para ajustar a calibração, que recupera a produtividade de revisão por meio do proxy de comentários.

A comparação não permite substituir a queda calibrada por outro percentual nem rejeitar formalmente o modelo. O intervalo observado é tempo de calendário, inclui correções e esperas e se refere à subamostra com comentários; a equivalência com tempo contínuo de um revisor é uma simplificação teórica. Sem medidas comparáveis em uma amostra comum e sua incerteza conjunta, a diferença permanece uma questão metodológica aberta. Consequentemente, a queda calibrada de 7,0% não deve ser apresentada como explicação quantitativa direta de todo o aumento de 58,5% do intervalo denominado revisão ativa.

Fontes: p. 19; p. 37; Tabela 5, p. 66; Apêndice G.2, pp. 108–109. O valor de 7,6% é uma comparação aritmética baseada no coeficiente impresso, não uma estimativa adicional produzida pelos autores.

As mudanças estruturais de trabalho também dependem dessa ligação. Por isso, não podem ser usadas como uma comprovação adicional inteiramente independente dos indicadores que alimentaram a calibração.

10.3 O que explica a diferença entre capacidade e entrega

O parâmetro n absorve parte da diferença entre alterações de código e trabalho final concluído. Ele pode representar mudanças na fragmentação do trabalho, como abrir mais PRs para executar a mesma tarefa, ou restrições de outras etapas, como gestão e testes.

O estudo não identifica separadamente essas explicações. Um aumento estimado de n não comprova que uma parcela conhecida do código seja inútil, nem mede diretamente um gargalo de gestão.

Na decomposição dos autores, 62,4% da diferença em log entre o choque de produtividade de programação e o resultado final é explicada pelo mecanismo produtivo de realocação e acúmulo na fila; 37,6% fica no termo residual de fragmentação.

Essas parcelas pertencem à decomposição do modelo. Elas não significam que 62,4% de todos os atrasos de uma empresa sejam causados pela revisão. O repasse informado, de 0,233 em termos logarítmicos, tampouco é uma divisão simples entre os percentuais 13,7 e 73,7.

Fonte: pp. 42–43.

10.4 O teste de ajuste não certifica o modelo

O teste de restrições sobreidentificadoras apresenta estatística J de 2,914 e valor-p de 0,233, com dois graus de liberdade. Isso significa que as restrições testadas não são rejeitadas nos níveis convencionais.

Não rejeitar não prova que o modelo seja a única explicação dos dados. Os erros-padrão estruturais também são calculados supondo covariâncias nulas entre os momentos, conforme a nota da Tabela 5.

Esses limites são especialmente relevantes quando os parâmetros alimentam cenários muito distantes do período observado.

11. Ajuste organizacional e cenários futuros

11.1 O que muda apenas com mais realocação interna

Mantendo fixo o trabalho total de programação e revisão e a tecnologia disponível, os autores calculam a divisão do trabalho que equilibraria as duas atividades. A alocação inferida já está próxima dessa combinação: 50,8% em programação e 49,2% em revisão, contra um equilíbrio de aproximadamente 50,6% e 49,4%.

Nesse exercício, o aumento de issues resolvidas seria de 14,1%, pouco acima da estimativa empírica de 13,7%. A capacidade adicional de simples redistribuição interna aparece limitada dentro da calibração.

Os autores examinam também um contrafactual em que n não tivesse aumentado. Com a alocação equilibrada, o resultado seria de 33,8% acima da referência anterior.

O contraste não demonstra que uma intervenção específica de gestão produziria 33,8%. O termo residual pode incluir fragmentação e outras restrições não identificadas separadamente. O exercício mostra a importância quantitativa das hipóteses sobre a conversão entre código e entrega.

Fonte: seção 6.3.1, pp. 43–44.

11.2 O cenário de emprego flexível com tecnologia fixa

Para avaliar decisões de escala e emprego, o estudo utiliza elasticidades de demanda obtidas de pesquisas anteriores sobre aplicativos móveis, software de varejo e jogos de console. A faixa é de 1,50 a 3,73, com média de 2,27.

Esses parâmetros não são estimados nas empresas do Jellyfish. Sua transferência para outros produtos, sobretudo software empresarial e desenvolvimento interno, é uma hipótese relevante.

Na elasticidade média, o exercício de longo prazo produz:

• +16,1% de produção final;
• −13,2% no trabalho total de engenharia representado no modelo, somando programação e revisão;
• −33,2% de trabalho de programação;
• +24,9% de trabalho de revisão.

São resultados do modelo para programação e revisão, não movimentações observadas no quadro completo das empresas. Além de permitir ajuste desse trabalho, esse exercício mantém n no nível anterior à adoção, enquanto o exercício de realocação interna mantém seu valor posterior. Logo, a diferença entre 14,1% e 16,1% não deve ser atribuída exclusivamente à liberdade de alterar o quadro de pessoal.

Fontes: pp. 44–45; Figura 12, p. 60; Tabela 6, p. 67; Apêndice G.3.1, pp. 110–111.

11.3 Como se constrói a trajetória tecnológica

O estudo usa como referência os horizontes de tarefas de software que modelos de fronteira conseguem concluir com 50% de sucesso, segundo a série da METR utilizada pelos autores. Trata-se de duração equivalente de tarefas para especialistas humanos, não de garantia de sucesso em produção.

No ajuste apresentado no manuscrito, esse horizonte dobra aproximadamente a cada 129 dias. Para relacioná-lo à produtividade de programação, os autores utilizam dois pontos inferidos: o efeito de assistentes, colocado na mediana de adoção de abril de 2024, e o efeito adicional de agentes, colocado em maio de 2025.

Os fatores de produtividade utilizados são aproximadamente 1,35 para assistentes e mais 1,74 para agentes, resultando em um fator acumulado de 2,34 em relação à referência anterior à IA. Esse empilhamento é uma construção do cenário.

Os fatores vêm de estimativas recuperadas ao fim das respectivas janelas de acompanhamento, mas são posicionados nas datas medianas de adoção para ajustar a trajetória. Abril de 2024 e maio de 2025 funcionam, portanto, como âncoras convencionais da simulação; não são as datas em que esses efeitos de fim de janela foram diretamente medidos. Esse posicionamento é uma hipótese adicional da extrapolação.

A extrapolação pressupõe uma relação exponencial estável. Nela, cada duplicação do horizonte técnico corresponde a 19,7% de crescimento da produtividade de programação. O parâmetro de produtividade chegaria a 8,93 vezes a referência em 2028 e 41 vezes em 2031.

Esses fatores são projeções de um parâmetro do modelo. Eles não são taxas observadas de crescimento da produção de código, nem uma promessa sobre a evolução dos modelos comerciais. A relação é estendida a partir de poucos pontos e pode mudar com tarefas, ferramentas e organizações.

Fontes: seção 6.3.2, pp. 45–47; Figura 13, p. 61; Apêndice G.3.2, pp. 111–112.

11.4 Dois cenários de revisão até 2031

Variações simuladas em relação à referência pré-IA da Figura 13. A coluna de trabalho abrange as duas atividades do modelo e não todo o emprego da empresa medido pela Revelio. Esses cenários não usam necessariamente a mesma referência e as mesmas hipóteses do exercício de tecnologia fixa da Figura 12.

O segundo cenário representa uma situação extrema em que a IA melhora as duas etapas que compõem o modelo. Os autores o tratam como um limite superior no exercício, lembrando que decidir o que construir, testar e coordenar com clientes também pode gerar restrições.

O primeiro cenário também incorpora escolhas substantivas. O Apêndice G.3.3 fixa um teto de participação da revisão de 0,823, mantém o trabalho total de programação e revisão no nível inicial até dezembro de 2026 e permite ajustes a partir de janeiro de 2027. A velocidade de ajuste fecha metade da distância ao nível desejado por ano, com transição suavizada.

O termo residual n segue uma curva ajustada aos resultados e depois fica constante. No cenário de revisão fixa, os autores impõem ainda que a produção não caia abaixo de seu máximo já alcançado. O trabalho de engenharia representado no modelo é recalculado para sustentar esse nível.

Esse último procedimento evita uma retração que surgiria na trajetória básica de ajuste sob demanda linear. Portanto, o platô de produção não resulta apenas da tecnologia e do teto de revisão: sua forma também reflete uma convenção explícita da simulação.

Mesmo os trechos do gráfico referentes a 2026 incluem valores modelados, não apenas observações. Não há, nesses exercícios, uma distribuição de probabilidades que permita chamar os dois resultados de intervalo estatístico de previsão. Seus “limites” são cenários definidos por hipóteses, não fronteiras comprovadas de todos os futuros possíveis.

Fontes: pp. 46–47; Figura 13, p. 61; Apêndice G.3.3, pp. 112–113.

12. O que a pesquisa não permite concluir

12.1 Generalização e seleção

Clientes de uma plataforma de análise de engenharia podem ter práticas de registro, gestão e adoção tecnológica distintas das de outras empresas. O consentimento para pesquisa e a exigência de integração com ferramentas também selecionam a amostra.

O perfil de empresas estabelecidas limita a extrapolação para startups pequenas ou novas. Não há fundamento para tratar os resultados como estimativas representativas do Brasil, de Portugal ou de toda a engenharia de software mundial.

As médias empresariais, por sua vez, podem ocultar efeitos bastante diferentes em equipes, produtos e indivíduos. As análises de heterogeneidade ajudam, mas não esgotam essa diversidade.

12.2 Adoção observada não cobre todo o uso

A identificação por licenças, bots e assinaturas é incompleta. Primeira utilização detectada pode ocorrer depois da primeira utilização real; algumas ferramentas podem não ser reconhecidas.

O estudo argumenta que certas falhas de mensuração tenderiam a reduzir os efeitos agregados estimados. Para a análise instrumental, subcontar usuários pode fazer o movimento contrário, aumentando o efeito calculado por usuário detectado. A direção e o tamanho do viés não devem ser presumidos iguais em todas as análises.

Também não é possível atribuir os resultados a um único produto ou modelo de linguagem. As categorias reúnem tecnologias que evoluem durante o período.

12.3 Tarefas registradas continuam sendo aproximações

A resolução de issues depende de práticas de gestão. Mudanças na disciplina de atualização podem alterar a relação entre registro e entrega. Epics oferecem uma aproximação adicional, mas continuam sendo unidades organizacionais heterogêneas.

Os autores procuram verificar mudanças de tamanho por duas abordagens: classificação textual iniciada com GPT-4o e previsão do tempo de ciclo a partir de dados anteriores à adoção. A primeira rotula uma amostra de 0,5% das tarefas, estratificada por empresa, e extrapola por aprendizado supervisionado; a segunda usa como referência issues resolvidas em 2022.

A validação do primeiro método compara o modelo supervisionado com os rótulos do GPT-4o. O erro quadrático médio de 0,4105, apresentado no Apêndice E, avalia essa reprodução, não a concordância com uma medição humana perfeita da dificuldade real.

O tempo de ciclo, por sua vez, inclui espera e coordenação. Predizê-lo pelo texto ajuda a construir uma aproximação consistente ao longo do tempo, mas não isola integralmente esforço técnico.

Assim, os testes enfraquecem a hipótese de uma mudança evidente na composição registrada das tarefas. Eles não eliminam toda mudança possível de escopo, complexidade ou valor.

Fontes: seção 2.3, p. 13; pp. 33–34; Figuras 7–8 do Apêndice D, pp. 78–79; Tabela 2 do Apêndice E, p. 98; Apêndice F.2, p. 102.

12.4 Qualidade e velocidade têm mensuração parcial

Os dados não oferecem uma avaliação abrangente de arquitetura, segurança, manutenibilidade, dívida técnica ou utilidade do produto. Comentários e bugs registrados captam dimensões específicas.

Tempos de abertura a merge são intervalos de calendário, e não horas trabalhadas. PRs ainda pendentes ou que nunca chegam ao merge não têm o mesmo desfecho observável dos integrados, o que limita a interpretação dos tempos médios.

Também não há uma medição completa do prazo entre a identificação de uma necessidade de negócio e o uso da solução pelo cliente. O aumento de 56,1% em abertura até merge não pode ser divulgado como aumento equivalente em todo o prazo de entrega de software.

12.5 Causalidade, poder estatístico e estrutura do modelo

Tendências anteriores semelhantes não comprovam a ausência de fatores simultâneos não observados. A proximidade de resultados entre estimadores ajuda a avaliação, mas tem escopo delimitado.

Estimativas imprecisas não estabelecem ausência de efeito. Tampouco a existência de muitos eventos assegura precisão em todos os resultados: a adoção ocorre na empresa, e a informação útil varia entre indicadores e horizontes.

As estimativas estruturais dependem de complementaridade perfeita, aproximação de problemas por comentários, alocação inicial e demais restrições. O termo residual preserva explicações não separadas. O ajuste do modelo não elimina essas escolhas.

As simulações adicionam hipóteses de demanda, evolução tecnológica e velocidade de ajuste do trabalho. Seus percentuais de emprego se referem às atividades de programação e revisão do modelo, não ao conjunto de todas as funções da empresa. Não devem ser usados para calcular uma quantidade inevitável de demissões em 2031.

13. O significado para a gestão de tecnologia

As implicações gerenciais formuladas pelos autores decorrem da diferença entre tarefas e processo produtivo. Avaliar o retorno da IA exige observar o fluxo completo: código produzido, capacidade de revisão e trabalho efetivamente concluído. Métricas intermediárias tomadas isoladamente podem superestimar a melhoria organizacional.

O estudo também sustenta a relevância de investimentos organizacionais complementares. Quando uma etapa acelera, a demanda por atividades adjacentes muda; a disponibilidade de profissionais com conhecimento da base de código condiciona o ajuste. Isso ajuda a explicar por que adquirir uma ferramenta e disseminar seu uso não esgota a adaptação da produção.

Os dados de gastos mostram outra dimensão dessa avaliação, sem resolver o retorno financeiro. Para a parcela de empresas e trabalhadores com faturamento observável via Cursor e Claude Code, em julho de 2026, o gasto mediano por trabalhador era de US$ 178 por mês, e a média, de US$ 808. O percentil 99 alcançava US$ 9.007.

A assimetria mostra que a média não representa o usuário típico. A cobertura é parcial, e esses valores não compõem uma contabilidade completa dos custos de adoção, revisão, treinamento ou mudanças organizacionais. O estudo não estima um retorno sobre investimento aplicável a cada empresa.

A constatação de um gargalo também não fornece uma política universal de reorganização. Os próprios resultados calibrados sugerem pouco ganho adicional de simples realocação interna naquele equilíbrio e preservam outros limites no termo residual.

Por fim, as evidências não sustentam abandonar a revisão, substituir critérios técnicos por volume de código ou definir cortes de pessoal a partir de percentuais simulados. A contribuição para a gestão é esclarecer onde a conversão entre capacidade técnica e resultado pode se perder, respeitando o que foi efetivamente medido.

Fontes: p. 17; seções 5–7, pp. 36–48; Figura 5E, p. 53.

14. Conclusão

Chen e Stratton documentam um aumento relevante na produção intermediária de código após a adoção de assistentes e agentes. Há também crescimento no código integrado, mas as estimativas para tarefas e projetos concluídos são menores e não atingem significância estatística a 5% nos últimos meses analisados.

A revisão ajuda a compreender essa diferença. Com agentes, aumenta a espera para chegar ao primeiro comentário humano, cresce o intervalo posterior até a integração e há mais comentários por submissão. A dependência de experiência e familiaridade com o código limita a velocidade com que a capacidade de revisão pode acompanhar a programação.

Ao mesmo tempo, não se detecta deterioração nos registros de bugs do software final nem mudança significativa no emprego agregado de engenharia durante o horizonte observado. Esses resultados impedem tanto a conclusão de que a IA não trouxe ganho algum quanto a de que o aumento de código já se converteu em melhoria proporcional de desempenho organizacional.

Os modelos ampliam a investigação para o longo prazo, mas acrescentam hipóteses que precisam acompanhar qualquer divulgação de seus números. A evolução da revisão, a demanda por software e a adaptação do trabalho produzem cenários diferentes, sem determinar um futuro inevitável.

A contribuição científica do estudo está em conectar etapas que costumam ser avaliadas separadamente. Acelerar a programação modifica as condições da produção de software; o resultado integral depende de como as atividades complementares conseguem responder.

15. Referência bibliográfica

CHEN, Fiona; STRATTON, James. Artificial Intelligence in the Firm: Bottlenecks in Software Production. Harvard University, Job Market Paper. Versão de 31 out. 2026. Primeira versão indicada: 7 jan. 2026. 120 p. Disponível no endereço corrente da autora: https://fion.ac/jellyfish.pdf. Consulta inicial da cópia fornecida: 31 out. 2026. Revisão desta síntese: 1 nov. 2026. Os números e as referências de páginas permanecem vinculados à cópia de 31 out., mesmo que o endereço corrente apresente uma versão posterior.