IA no desenvolvimento: o que os dados realmente mostram

Quase todo time de desenvolvimento já adotou alguma ferramenta de IA. A pergunta que quase ninguém responde com dados é mais incômoda: isso está de fato entregando software mais rápido? Existem estudos controlados sobre o assunto, e as conclusões deles não batem entre si. Entender por que elas divergem é mais útil do que escolher o número que agrada.

Dois estudos, dois resultados opostos

Em 2023, um experimento controlado com 95 desenvolvedores freelancers pediu que implementassem um servidor HTTP em JavaScript. O grupo com acesso ao GitHub Copilot terminou a tarefa 55,8% mais rápido que o grupo de controle. É um dos números mais citados do setor, e ele é real.

Em 2025, a METR rodou outro experimento controlado, com 16 desenvolvedores open source experientes, em 246 tarefas reais dentro dos repositórios que eles próprios mantêm. Resultado: com acesso às ferramentas de IA de early-2025, eles ficaram cerca de 19% mais lentos.

Os dois estudos são metodologicamente sérios. Eles não se contradizem: eles mediram coisas diferentes.

O que explica a diferença

A variável decisiva não é a ferramenta, é o contexto da tarefa.

O estudo de 2023 usou uma tarefa greenfield, autocontida e bem especificada, resolvida por pessoas sem familiaridade prévia com aquele código. É o cenário em que um modelo brilha: o padrão é comum, o contexto necessário cabe na janela, e não existe histórico para respeitar.

O estudo da METR foi o extremo oposto: base de código grande, madura, com convenções implícitas, e desenvolvedores que já conheciam cada canto dela. Aqui o modelo precisa de contexto que ele não tem, e a pessoa gasta tempo revisando, corrigindo e descartando sugestões. O custo de verificar passa a competir com o ganho de gerar.

A leitura prática: ganho de IA é alto em código novo e periférico, e cai (podendo ficar negativo) em código central, antigo e muito conhecido por quem mexe nele.

A percepção engana, inclusive a sua

O detalhe mais desconfortável do estudo da METR não é o 19%. É que os participantes achavam que tinham ficado cerca de 20% mais rápidos, mesmo tendo ficado mais lentos. Antes de começar, previam ganho de 24%.

Ou seja: a sensação de velocidade sobreviveu intacta à evidência do contrário. Isso importa porque a maioria das decisões de adoção de IA em empresas é tomada exatamente com base nessa sensação, coletada em pesquisa interna de satisfação. Percepção é um dado legítimo, mas não é medida de throughput.

A leitura da DORA: IA é amplificador, não atalho

O relatório da DORA de 2025 sobre desenvolvimento assistido por IA chega num enquadramento que reconcilia bem os dois experimentos: a IA amplifica as características que o seu sistema de entrega já tem. Onde existe base sólida, lotes pequenos, testes confiáveis e feedback rápido, a IA acelera. Onde existem gargalos, ela aumenta a pressão sobre eles e expõe o problema mais rápido.

É por isso que a mesma ferramenta produz resultados opostos em dois times da mesma empresa. A variável não é o modelo, é a plataforma em volta dele.

Como medir sem se enganar

O erro mais comum é medir atividade: linhas aceitas, sugestões usadas, commits por dia. São métricas que a IA inflaciona por construção, e que não dizem nada sobre valor entregue.

O framework SPACE existe justamente para isso. Ele propõe cinco dimensões (satisfação e bem-estar, performance, atividade, comunicação e colaboração, eficiência e fluxo) e defende que produtividade não se reduz a uma métrica só. Combinado com as métricas de entrega da DORA (lead time, frequência de deploy, taxa de falha em mudanças, tempo de restauração), você consegue enxergar se a IA está encurtando o caminho até produção ou só gerando mais código para revisar.

Um teste honesto e barato: pegue duas equipes comparáveis, mude a adoção de IA em uma delas e olhe lead time e taxa de falha em mudanças por um trimestre. Se nada mudou nessas duas, o ganho que você está celebrando é percepção.

O que isso significa para o seu time

Três conclusões que sustentam decisão:

1. Não espere ganho uniforme. Direcione IA primeiro para código novo, scaffolding, testes, migrações repetitivas e exploração de código desconhecido. Tenha expectativa baixa em código central e maduro.
2. Não meça por sensação. Instrumente lead time e estabilidade antes de escalar a adoção, senão você não vai saber diferenciar ganho real de entusiasmo.
3. Trate como investimento em plataforma. Se os testes são lentos e frágeis e o review é gargalo, IA piora a fila. Resolver isso vem antes, e é o que decide se a IA vai pagar.

A pergunta útil não é "a IA funciona?". É "onde, no nosso fluxo, ela paga, e como vamos saber?".