Resumo em 30 segundos. Quase todo time técnico já usa IA, e a sensação de produtividade subiu. Gerar código ficou barato. O que ficou caro foram as duas pontas: dizer com precisão o que precisa existir e provar que o resultado está certo. Soma-se a elas o ambiente em que o agente trabalha, o harness, que continua com a empresa depois que o modelo é trocado. O DORA, programa de pesquisa do Google, descreve a IA como amplificadora do que o time já tem. Na prática, onde há especificação clara e teste confiável, ela acelera; onde não há, produz mudança mais rápido do que o time consegue controlar. É nessas três frentes que o orçamento de IA de engenharia rende, e nenhuma delas vem na licença.
O fluxo que se instalou: pedir, colar, corrigir
A empresa comprou IA para tirar o trabalho mecânico do time técnico. Em muitos times, a IA ficou com a parte criativa e o desenvolvedor ficou com a mecânica.
O fluxo é fácil de reconhecer. O dev pede, a IA gera, o dev cola, testa, corrige e pede de novo. O código agora é gerado, e quem senta na cadeira continua produzindo código, só que num teclado que responde em linguagem natural.
A pesquisa de 2025 da Stack Overflow mostra o custo desse arranjo. 84% dos desenvolvedores usam ou pretendem usar IA no trabalho. A maior frustração, citada por 66%, é a resposta que está quase certa. E 45% dizem que depurar código gerado por IA toma mais tempo.
Quase certo é o pior tipo de errado: parece pronto, passa pelo olho cansado e volta em produção. Quem lidera costuma medir adoção por licença ativa e por sensação de velocidade, e as duas sobem. O painel não mostra quanto do dia do time virou conferência de texto gerado.
O que o DORA mediu quando a adoção subiu
No relatório de 2024, com cerca de 3 mil profissionais, cada aumento de 25% na adoção de IA veio associado a uma queda de 1,5% na vazão de entrega e de 7,2% na estabilidade. A produtividade percebida subia ao mesmo tempo. Cada pessoa se sentia mais rápida, e o sistema inteiro entregava pior.
Em 2025, com quase 5 mil respondentes, a vazão passou a subir junto com a adoção, e a instabilidade subiu também. 90% já usam IA no trabalho, mais de 80% relatam ganho de produtividade e 30% confiam pouco ou nada no código que ela gera.
A leitura do próprio DORA é a mais útil de todo o material: a IA amplifica o que já existe. Com teste automatizado, versionamento disciplinado e ciclo curto de feedback, o time ganha velocidade com segurança. Sem isso, a rede de proteção segue do mesmo tamanho enquanto entra mais mudança, e a conta chega como incidente e retrabalho.
Por isso aprovar licença de IA para engenharia, que parece decisão de ferramenta, é decisão de risco operacional.
O trabalho foi para as pontas
Em agosto escrevi aqui que o gargalo da engenharia mudou de lugar, da escrita para a revisão e a decisão. O passo seguinte é o dinheiro: se o gargalo mudou, o investimento tem de acompanhar, e o que eu vejo é a maior parte dele ainda indo para o ponto antigo.
Em 30 anos de carreira em tecnologia, vi isso acontecer algumas vezes. Desta vez o gargalo saiu da digitação. Escrever a função deixou de ser a parte cara. Saber qual função escrever, e como verificar que ela faz o que devia, virou a parte cara. Com a geração de código barata, o valor se concentra nas duas pontas do processo: especificar o que construir e provar que o resultado está certo.
Quem usa a ferramenta todo dia já percebeu. Na pesquisa da Stack Overflow, 46% dos desenvolvedores desconfiam da precisão do que a IA entrega, 33% confiam e só 3% confiam muito. Conferir exige saber exatamente o que se queria.
O código ficou barato. A certeza ficou cara.
Ponta de entrada: o defeito que nasce antes do código
Parte dos defeitos de qualidade escapa de qualquer teste, porque o código faz exatamente o que foi especificado. O problema nasceu antes, na definição do que construir.
Nos times que acompanhei este ano, os problemas de qualidade vinham de dois lugares. Um é o erro de implementação, que todo mundo procura. O outro raramente entra na investigação: o requisito vago, incompleto ou contraditório que chegou ao desenvolvimento com cara de pronto.
Antes da IA, esse segundo erro costumava ser pego no caminho. O dev estranhava o requisito, ia perguntar a quem respondia pelo produto, e a conversa corrigia o pedido. Com a IA no meio, a pergunta não chega a ser feita. O requisito vago vira código bem formatado em meio minuto, o código compila, e ninguém desconfia de algo com aparência de acabado. A máquina executa fielmente o pedido errado.
A especificação muda de papel por isso: o documento que ninguém relia vira a instrução que a máquina executa. Quem acompanha este site conhece essa tese desde Código vs. Comunicação: o valor do desenvolvedor está na clareza com que transforma necessidade em instrução. Com agentes escrevendo código, a ambiguidade que antes custava uma conversa custa cem linhas para refazer.
Ponta de saída: o imposto de verificação
Na outra ponta, o DORA analisou 1.110 respostas abertas de engenheiros do Google e chamou o efeito de imposto de verificação: o tempo que o time poupa escrevendo vai para a auditoria do que foi gerado. Um dos engenheiros contou que passa mais tempo de babá da IA, revisando o que ela está tentando fazer.
O imposto raramente aparece sozinho. O pull request cresce e a revisão vira fila. Cada dev pede à IA do seu jeito, e o código sai com tantos padrões quanto pessoas. O mesmo erro reaparece em projetos diferentes, porque a correção ficou na cabeça de quem a fez. Ninguém sabe dizer o que o agente pode tocar no repositório. O sênior passa o dia conferindo código gerado, e o júnior aceita sugestões que não saberia escrever.
São falhas de método, e atribuí-las às pessoas erra o alvo: o time recebeu a ferramenta sem receber a forma de trabalhar com ela.
O que reduz o imposto é teste com força de contrato, o teste que decide se uma mudança entra ou fica de fora. Garantia que depende de alguém olhar com atenção foi dimensionada para o volume de antes, e o volume subiu.
O que fica quando o modelo é trocado
O modelo que o seu time usa hoje vai sair de cena em poucos meses. A estrutura que o time monta em torno dele continua, e poucas das empresas que acompanho a tratam como investimento.
Essa estrutura se chama harness: o ambiente em que o agente trabalha. Reúne contexto persistente sobre o projeto e as regras da casa, especificações que a máquina consegue executar, testes que valem como contrato, as ferramentas que o agente pode usar com os limites do que ele não pode tocar, e um ciclo de feedback que converte cada erro corrigido em regra para a próxima vez.
Sem harness, cada dev explica o projeto à IA do zero em toda sessão, e o que foi corrigido se perde quando a conversa fecha. Com harness, o que o time aprendeu fica no ambiente e vale para a próxima sessão de qualquer pessoa.
O modelo de capacidades de IA do DORA, publicado com o relatório de 2025, chega a um desenho parecido pelo lado da pesquisa. Lista sete fatores que fazem a IA render em engenharia: posição clara da empresa sobre o uso de IA, ecossistema de dados saudável, dados internos acessíveis à IA, controle de versão forte, trabalho em lotes pequenos, foco no usuário e plataforma interna de qualidade. A escolha da melhor ferramenta não está entre eles.
Para quem aprova orçamento, a diferença é contábil. O que se paga em licença precisa ser pago de novo todo ano e, cancelado o contrato, não deixa nada. O que se investe em harness fica com a empresa e melhora a cada correção incorporada, qualquer que seja o modelo em uso. Nos orçamentos que vejo, quase todo o dinheiro vai para a licença.
Senioridade e capacitação: dois ajustes na casa
Duas estruturas que a empresa já tem ficaram defasadas em relação ao novo trabalho.
A primeira é a régua de senioridade. Por muito tempo, chegava a sênior quem resolvia, rápido e sem erro, o problema de código que travava os outros. Hoje boa parte dessa solução está ao alcance de qualquer pessoa que saiba descrever o problema à IA. O que continua com as pessoas é transformar o pedido vago de um cliente numa especificação sem brecha, desenhar o teste que prova o funcionamento, decidir o que o agente pode tocar e apontar, num bloco extenso de código gerado, a linha que vai falhar em produção. O DORA chama a atenção para um risco no sentido oposto, o paradoxo da expertise: a IA cobre rápido o que a pessoa não sabe e, com isso, pode poupá-la justamente do aprendizado difícil que forma um especialista. Plano de carreira que premia volume produzido remunera a parte do trabalho que a máquina já assumiu.
A segunda é a capacitação. Em maio de 2026, o DORA publicou um relatório sobre o retorno do investimento em IA no desenvolvimento de software. Segundo ele, os maiores retornos vêm do sistema organizacional em volta da ferramenta. O mesmo relatório recomenda não usar o ganho como motivo para cortar equipe e defende manter e capacitar quem conhece a operação.
Capacitar quem, e em quê? Numa empresa de software, o problema de qualidade nasce no código e na especificação, e cada lado precisa de coisa diferente. Quem escreve código aprende a montar e operar o ambiente do agente. Quem escreve requisito aprende a usar a IA para pôr o requisito à prova, achando a ambiguidade e a pergunta que ninguém fez ao cliente. Os dois precisam ainda de uma base de linguagem comum para conseguirem conversar. Um treinamento único, com o mesmo conteúdo para todos, erra a medida para os dois lados.
Como ler o orçamento de 2027
O planejamento do ano seguinte é o ponto em que essa mudança vira decisão ou fica como intenção. Dois exercícios mostram se o dinheiro está indo para o lugar certo.
Liste os retrabalhos mais recentes do time, dez bastam, e marque a origem de cada um: código ou especificação. A divisão entre os dois indica se o próximo real deve ir para ferramenta de código ou para a ponta de entrada.
Depois, separe o orçamento de IA de engenharia em duas linhas. Numa ficam licenças e assinaturas. Na outra, o trabalho de especificar, o de verificar e o ambiente do agente. Se a segunda linha está perto de zero, a empresa comprou velocidade para a etapa que já deixou de ser o gargalo. E se a única garantia contra uma mudança errada é atenção humana, ela vai ceder se o volume dobrar.
A IA escreve o código. Saber o que pedir e provar que o resultado serve continua sendo trabalho de gente, e ele não vem com a licença.
Perguntas frequentes
Onde o orçamento de IA em engenharia de software rende mais? Em três frentes que a licença não cobre: a especificação do que será construído, a verificação do que foi gerado e o ambiente em que o agente trabalha. Gerar código ficou barato; o valor foi para o que vem antes e depois da geração e para o ambiente onde ela acontece. O DORA, em 2025, descreve a IA como amplificadora: ela multiplica a qualidade que o time já tem, boa ou ruim.
O que é harness em engenharia de software com IA? É o ambiente em que o agente de IA trabalha: contexto persistente sobre o projeto, especificação que a máquina consegue executar, testes que funcionam como contrato, ferramentas e limites do que o agente pode tocar, e um ciclo de feedback que transforma cada correção em regra. Diferente da licença, ele continua com a empresa quando o modelo é trocado.
O que é o imposto de verificação? É o nome que o DORA deu, em março de 2026, ao tempo que o time poupa escrevendo código com IA e passa a gastar conferindo o resultado. Aparece como pull request maior, fila de revisão e sênior ocupado auditando código em vez de decidir o que construir.
Como saber se o problema de qualidade está no código ou na especificação? Classifique os últimos retrabalhos do time pela origem: implementação ou requisito. Defeito de requisito não é pego por teste, porque o código faz exatamente o que foi pedido. Se a maior parte vier da especificação, o investimento em ferramenta de código ataca o lado errado.
Treinamento de IA resolve o problema da entrega? Quando é desenhado por papel, ajuda. Quem escreve código e quem escreve requisito têm problemas diferentes, que nascem em lugares diferentes. O relatório de ROI do DORA, de maio de 2026, conclui que o retorno vem do sistema organizacional em volta da ferramenta. Um treinamento único, igual para todos, não mexe nesse sistema.
A régua de senioridade precisa mudar com a IA? Sim, quando mede volume produzido. A IA entrega boa parte do que antes distinguia o sênior, e o que sobra é especificar sem brecha, desenhar o teste e achar o defeito no código gerado. O DORA também alerta para o paradoxo da expertise: a IA pode pular o aprendizado que forma o próximo especialista.
Fontes: Stack Overflow, Developer Survey 2025, seção de IA; DORA/Google Cloud, Accelerate State of DevOps Report 2024 (cerca de 3 mil respondentes); DORA, State of AI-assisted Software Development (anúncio de 23/09/2025, quase 5 mil respondentes); DORA, AI Capabilities Model (2025); DORA, "Balancing AI tensions", Jessica Baolin e Nathen Harvey (10/03/2026), análise de 1.110 respostas abertas de engenheiros do Google; DORA, ROI of AI-assisted Software Development (11/05/2026).
Este texto consolida a tese de outubro de 2026. O diagnóstico anterior, sobre por que a entrega não acelera quando só a escrita fica mais rápida, está em O gargalo da sua engenharia mudou de lugar (e você ainda mede o antigo). A mesma mudança vista pelo lado do mercado, onde capacidade ficou barata e responsabilidade continua rara, está em Por que produto de IA não vira receita.
<!-- mkt-review: score=92 editor=mkt-quality-editor date=2026-10-14 -->