SoftwareA inteligência artificial pode acelerar tarefas de programação, mas isso não elimina o trabalho de revisão — e, em equipes grandes, pode até aumentá-lo. A pesquisa da Linux Foundation Research, divulgada em 20 de outubro de 2026, ouviu 234 pessoas que contribuem ou mantêm projetos de código aberto; entre os achados, participantes estimaram que cerca de 25% dos pull requests recebidos eram contribuições de baixa qualidade geradas com IA. A proporção estimada subiu para 31% em projetos com mais de 50 contribuidores.
Esses números são avaliações dos participantes da pesquisa, não uma contagem independente de todos os pull requests publicados na indústria. Ainda assim, ajudam a explicar por que “gerar mais código” não é a mesma coisa que entregar software melhor.
Onde a IA economiza tempo — e onde ele volta como revisão
No relatório completo da Linux Foundation Research, os participantes estimaram reduções de tempo entre 19% e 52%, dependendo da tarefa. A economia tende a ser maior em atividades bem delimitadas, como escrever código. Em tarefas complexas, porém, 21% disseram que levaram mais tempo com IA, por precisarem investigar erros sutis ou premissas equivocadas.
O efeito também varia conforme o tamanho do projeto. Entre responsáveis por projetos com mais de 50 contribuidores, 64% relataram ciclos de revisão mais longos para contribuições feitas com apoio de IA. Isso não significa que a IA produza código ruim por definição; significa que o aumento de volume e a falta de contexto podem transferir parte do esforço da escrita para a verificação.
O que as equipes podem fazer
A pesquisa aponta uma lacuna de governança: só 35% dos projetos consultados tinham uma política formal permitindo contribuições assistidas por IA, enquanto 32% não tinham política nem planos para criar uma. A divulgação do estudo pela Linux Foundation também destaca que as equipes relatam ganhos de produtividade, mas precisam combinar esse uso com revisão e testes.
Para uma equipe de produto, a leitura prática é tratar a IA como parte do fluxo de desenvolvimento, com critérios claros: quais ferramentas podem acessar o código, que testes devem acompanhar cada mudança, quem responde pela validação e quando o uso precisa ser informado. Revisores podem concentrar a atenção em arquitetura, segurança, regras de negócio e casos de borda, enquanto automações cuidam de verificações repetitivas.
Também vale medir o resultado além da quantidade de código produzido. Tempo até concluir uma tarefa, retrabalho, defeitos encontrados depois da entrega e horas gastas em revisão ajudam a mostrar se a ferramenta realmente melhorou o processo. Essa recomendação é uma aplicação dos achados a equipes de produto; o levantamento em si estudou comunidades de código aberto.
A conclusão não é evitar IA nem aceitar qualquer sugestão. É usar a velocidade para liberar tempo para testes, manutenção e decisões de engenharia — e garantir que cada mudança continue tendo uma pessoa responsável por entendê-la.
