Escrever código deixou de ser o gargalo do software corporativo

Um estudo assinado por Leon Musolff, da Wharton, com Mert Demirer e Liyuan Yang, do MIT, publicado em 9 de setembro, rastreou mais de 100 mil desenvolvedores no GitHub entre 2022 e 2026, cruzando o histórico com dados de adoção de ferramentas da Microsoft. Sistemas de autocompletar aumentaram a atividade de codificação em 40%. Agentes que editam código junto com o desenvolvedor levaram o ganho acumulado a 140%. Agentes que trabalham sozinhos, sem supervisão linha a linha, levaram a 180%.

Esse mesmo salto de 180% correspondeu a um aumento de apenas 50% em projetos de software concluídos, e 30% em lançamentos efetivos. Nas quatro maiores lojas de aplicativo (Apple App Store, Google Play, Chrome Web Store e SourceForge), os lançamentos mensais na loja da Apple subiram de cerca de 30 mil para 100 mil entre o início de 2025 e abril de 2026. O uso total do que foi lançado ficou estável ou caiu.

A leitura óbvia é que a ferramenta ainda está imatura. Copilotos escrevem rápido, mas a revisão automatizada erra, a integração trava contra sistema legado, e é questão de tempo até os mesmos modelos que geram código aprenderem também a revisar, testar e publicar sozinhos. O gargalo seria técnico, e estaria prestes a se fechar conforme os modelos melhoram.

Onde os 180% de código viram 30% de entrega

Musolff resume o achado central numa frase: a restrição está migrando de escrever código para revisar, integrar e, por fim, distribuir o que foi escrito. Não é a mesma tarefa em maior volume — é uma tarefa diferente, que sempre dependeu de julgamento humano e continua dependendo.

A tentativa mais óbvia de fechar essa distância é usar a própria IA para revisar o que a IA escreveu. Musolff testou essa hipótese, e ela falha: quando o mesmo modelo que escreveu o código também o revisa, a revisão não tem a mesma qualidade. O limite não está na velocidade de gerar, está na independência de julgar, e isso não se resolve com mais um agente do mesmo tipo trabalhando em cima do primeiro.

A restrição não está mais em escrever código. Está em revisar, integrar e distribuir o que já foi escrito.

O que a leitura óbvia erra, em três números

A leitura óbvia	O que os números mostram
Falta a IA aprender a revisar o próprio código	Revisão pela mesma IA que escreveu “não resolve o problema” — a qualidade cai
É questão de tempo até lançamentos alcançarem a curva de código	Código cresceu 180%, lançamentos 30%: a distância é estrutural, não temporal
Mais aplicativos disponíveis deveria significar mais uso	Uso ficou estável ou caiu nas quatro lojas, apesar da enchente de lançamentos

O preço de lançar mais e ninguém encontrar

A produção não trava só na distribuição. Mesmo o que chega a ser publicado enfrenta uma barreira seguinte: ser encontrado. Musolff levanta a possibilidade de que a descoberta tenha ficado mais difícil justamente pela enchente: quando o número de aplicativos novos triplica, cada um fica mais difícil de achar em meio aos outros.

E há ainda uma etapa depois da descoberta.

Iterar com quem usa, ajustar o que não funciona na prática, sustentar a adoção ao longo do tempo: nenhuma dessas etapas escreve uma linha de código, e nenhuma delas encolheu na mesma proporção em que a produção cresceu.

A métrica que parou de significar o que significava

Para quem dirige uma empresa que comprou licença de copiloto esperando fila de funcionalidades mais curta, a métrica que valia até aqui parou de significar o que significava. Contar commits, pull requests abertos ou até projetos iniciados mede exatamente a parte do processo que deixou de ser escassa. A pergunta que sobra é quantas pessoas na operação têm autoridade e tempo para revisar, aprovar e publicar no mesmo ritmo em que o código passou a ser gerado, e se esse número cresceu na mesma proporção do investimento em ferramenta de geração.

Contratar mais desenvolvedor júnior para alimentar a esteira ataca o lado errado do funil, porque aumenta quem produz para uma fila que já está cheia mais adiante. O retorno maior vem de reforçar quem revisa e decide: sênior com autoridade para julgar o que entra em produção, processo de integração que não emperra a cada entrega, e alguém responsável por olhar se o que foi lançado está sendo usado, já que a pesquisa mostra que essa métrica recebe bem menos atenção do que a velocidade de geração.

A mesma lógica não fica restrita a desenvolvimento de software. Qualquer função em que a IA multiplica o que sai, seja proposta, relatório, peça de campanha ou análise interna, esbarra na mesma parede se a capacidade de revisar, decidir e publicar não crescer no mesmo ritmo. O gargalo migrou. A maioria das operações ainda mede o lado de trás dele.

Quantas etapas depois de gerar a sua operação consegue revisar, aprovar e publicar no mesmo ritmo em que passou a gerar?