Medindo IA no Desenvolvimento de Software: O Que os Dados Realmente Mostram

Eis um número que deveria fazer você parar: desenvolvedores usando ferramentas de IA acreditavam estar 20% mais rápidos. Na realidade, estavam 19% mais lentos.

Este achado vem de um estudo controlado randomizado conduzido pelo METR, envolvendo desenvolvedores experientes de código aberto trabalhando em bases de código maduras. Não é um outlier—é um sinal de que nossas intuições sobre produtividade com IA não são confiáveis.

Enquanto isso, a Jellyfish reporta que organizações com 80-100% de adoção de IA veem ganhos de 110%+ em throughput de pull requests. Ambos os achados podem ser verdadeiros. A diferença está no contexto, na medição e no entendimento do que você está realmente otimizando.

O ciclo de vida do desenvolvimento de software está sendo redefinido. Andrew Lau, CEO da Jellyfish, coloca um prazo: em três anos, o PDLC terá uma aparência completamente diferente. Esta é uma das maiores transformações desde a invenção da internet.

Mas transformação sem medição é apenas esperança com passos extras.

A Lacuna de Percepção

O estudo do METR revela algo desconfortável: desenvolvedores não sabem quão rápido estão trabalhando. Dezesseis desenvolvedores experientes completaram 246 tarefas em bases de código familiares—projetos aos quais contribuíram por mais de cinco anos. Com assistência de IA, reportaram sentir-se significativamente mais produtivos. O cronômetro discordou.

Por que a desconexão?

Ferramentas de IA são genuinamente úteis para certas tarefas: geração de boilerplate, consulta de sintaxe, exploração de APIs desconhecidas. Essa ajuda parece aceleração. Mas em bases de código maduras com padrões estabelecidos, o custo de troca de contexto ao interagir com IA—elaborar prompts, avaliar sugestões, corrigir alucinações—pode exceder o tempo economizado.

A lição não é que ferramentas de IA não funcionam. É que produtividade percebida e produtividade real são métricas diferentes, e confundi-las leva a decisões ruins.

A Lacuna de Confiança

Apenas 3% dos desenvolvedores “confiam plenamente” em código gerado por IA. 46% não confiam completamente. No entanto, 90% das equipes agora usam ferramentas de IA, contra 61% há um ano.

Isso cria uma dinâmica estranha: adoção quase universal combinada com ceticismo pervasivo. Desenvolvedores usam as ferramentas mas verificam tudo. Em alguns casos, esse overhead de verificação anula os ganhos de produtividade.

A lacuna de confiança não é irracional. Modelos de IA alucinam. Geram código de aparência plausível que falha em casos extremos. Otimizam para o contexto imediato enquanto perdem implicações arquiteturais. Ceticismo é apropriado.

Mas ceticismo sem medição deixa organizações adivinhando. O overhead de verificação vale a pena? Para quais tarefas? Em qual nível de adoção?

A Lacuna de Liderança

Eis outro número: 76% dos executivos acreditam que suas equipes abraçaram a IA. Apenas 52% dos engenheiros concordam.

Essa lacuna de percepção importa porque molda decisões de investimento. Líderes que acreditam que a adoção é alta podem subinvestir em treinamento e capacitação. Líderes que não veem os ganhos de produtividade que seus subordinados alegam podem cortar orçamentos de ferramentas prematuramente.

Apenas 20% das equipes de engenharia medem o impacto da IA com métricas de engenharia reais. O resto depende de pesquisas, anedotas ou nada.

O Que os Dados Realmente Mostram

A Jellyfish rastreou a adoção de IA em mais de 600 organizações ao longo de 2025. Os achados são nuançados.

A adoção está acelerando. O uso de assistentes de código cresceu de 49% para 69% entre janeiro e outubro. A adoção de agentes de revisão quase quadruplicou, de 14,8% para 51,4%. Isso não é hype—é gasto em infraestrutura e mudanças de fluxo de trabalho.

Ganhos de throughput são reais, mas condicionais. Organizações que passaram de 0% para 100% de adoção de IA viram 113% mais pull requests por desenvolvedor—de 1,36 para 2,9 semanais. Mas essa correlação inclui efeitos de seleção. Equipes que adotam IA completamente tendem a já ser de alto desempenho.

Melhorias de tempo de ciclo são consistentes. O tempo de ciclo mediano caiu 24%. Isso é mais difícil de explicar com viés de seleção. Loops de feedback mais rápidos beneficiam todos.

Taxas de bugs contam uma história complexa. PRs de correção de bugs aumentaram de 7,5% para 9,5% do total de PRs. É porque IA introduz mais bugs? Ou porque iteração mais rápida expõe bugs mais cedo? Ou porque IA facilita o envio de correções? O número sozinho não responde à pergunta.

Retenção de ferramentas revela algo. Após 20 semanas, Copilot e Cursor retêm 89% dos usuários. Claude Code retém 81%. Alta retenção sugere utilidade genuína, não apenas novidade.

As Três Barreiras de Adoção

Lau identifica três barreiras que separam organizações com ganhos marginais de IA daquelas vendo melhorias de 100%+:

Barreira 1: Capacitação e Treinamento. Muitas organizações implantam ferramentas de IA sem ensinar desenvolvedores a usá-las efetivamente. Engenharia de prompts é uma habilidade. Assim como saber quando não usar IA—quando o custo de troca de contexto excede o benefício.

Barreira 2: Ferramentas e Modelos Certos. Nem todos os assistentes de codificação IA são equivalentes. O modelo importa. A integração importa. A janela de contexto importa. Organizações que tratam ferramentas de IA como commodities intercambiáveis perdem oportunidades de otimização.

Barreira 3: Redefinição de Papéis e Processos. Esta é a barreira mais difícil. Quando desenvolvedores gastam mais tempo escrevendo prompts do que código, estão fazendo trabalho de especificação—tradicionalmente o domínio de product managers e arquitetos. Fronteiras de papéis se borram. Proporções de equipe mudam. Estruturas de incentivo precisam de atualização.

Organizações que superam as três barreiras veem os ganhos de 110%+. Organizações que esbarram em qualquer barreira veem as desacelerações paradoxais que o estudo do METR documentou.

Um Framework de Medição que Funciona

Lau propõe um framework de três camadas que vai além de métricas de vaidade:

Camada 1: Adoção. Rastreie tanto uso quantitativo (frequência, quais ferramentas, quais modelos) quanto engajamento qualitativo (desenvolvedores estão usando prompts efetivamente? estão usando IA para tarefas apropriadas?). Adoção sem uso efetivo é ruído.

Camada 2: Throughput. Meça taxa de PRs, tempo de ciclo, latência de revisão—mas no nível do sistema, não individual. Métricas de desenvolvedores individuais criam incentivos perversos. Métricas de sistemas revelam fluxo.

Camada 3: Resultados. Conecte atividade de desenvolvimento a resultados de negócio: progresso do roadmap, taxas de defeitos, impacto no cliente. Uma equipe enviando o dobro de PRs que não movem o produto não melhorou.

A maioria das organizações mede a Camada 1 mal e ignora as Camadas 2 e 3 completamente. É por isso que 80% das equipes não conseguem responder perguntas básicas sobre ROI de IA.

O Imperativo do Pensamento Sistêmico

Eis um insight que se perde no discurso de produtividade: o PDLC é um fluxo, não uma coleção de tarefas isoladas.

Acelerar geração de código sem acelerar revisão de código cria um gargalo de revisão. Revisão mais rápida sem aprovação de compliance mais rápida cria um gargalo de compliance. Toda otimização local que ignora dinâmicas de sistema arrisca criar desacelerações globais.

É por isso que ferramentas de IA estão se expandindo além da codificação. Agentes de revisão cresceram de 14,8% para 51,4% de adoção em 2025. Testes são o próximo passo. Lau identifica como fronteira: precisamos de novas formas de formalizar “verdade” e intenção para que IA possa verificar, não apenas gerar.

As organizações que vencerão não são aquelas com os geradores de código mais rápidos. São aquelas com o fluxo de desenvolvimento ponta a ponta mais coerente.

O Insight Real

Lau articula algo que estava à espreita no fundo de toda discussão sobre IA em codificação:

“Por décadas, pensamos que codificar era a parte difícil. Acontece que descrever o que construir é mais difícil.”

Quando um desenvolvedor escreve um prompt, está escrevendo uma especificação. Está fazendo trabalho de design, não de implementação. O labor cognitivo não desapareceu—deslocou-se para cima.

Isso tem implicações profundas para contratação, treinamento e desenvolvimento de carreira. As habilidades que importam estão mudando. Organizações que reconhecerem isso cedo encontrarão a transição de talentos mais suave. Aquelas que não, terão desenvolvedores excelentes em algo que IA agora faz e subtreinados para o que IA precisa deles.

Aceleração de Riscos

Mais um dado que merece atenção: IA aumenta necessidades de compliance, não as reduz.

Código se move mais rápido. Ciclos de revisão se comprimem. A janela entre “merged” e “deployed” encolhe. Todo controle que operava em cadência semanal agora precisa operar diariamente ou continuamente.

Organizações que veem IA como razão para relaxar controles de governança têm a lógica invertida. IA é razão para incorporar controles mais cedo, automatizar verificações de compliance e construir auditabilidade no pipeline desde o início.

As organizações que se movem mais rápido com IA são também aquelas com os frameworks de governança mais robustos. Isso não é coincidência. Governança habilita velocidade ao reduzir retrabalho, evitar incidentes e construir a confiança organizacional necessária para autonomia expandida de IA.

O Que Fazer Com Isso

Se você é um líder de engenharia tentando entender o impacto da IA, aqui está um caminho prático:

Pare de confiar no sentimento dos desenvolvedores. O estudo do METR prova que percepção não rastreia realidade. Instrumente seus sistemas. Meça tempos de ciclo reais, throughput de PRs e frequência de deploy. Compare períodos com e sem assistência de IA para tipos de tarefas equivalentes.

Meça no nível do sistema. Métricas de desenvolvedores individuais criam gaming e ressentimento. Métricas de sistema—tempo de ciclo ponta a ponta, eficiência de fluxo, identificação de gargalos—revelam onde IA ajuda e onde cria novas restrições.

Invista em treinamento, não só em ferramentas. A barreira de adoção que mais importa é a lacuna de habilidades. Desenvolvedores precisam aprender quando usar IA, como elaborar prompts efetivamente e como verificar outputs eficientemente. Faça orçamento para isso.

Redefina papéis proativamente. Se seus desenvolvedores estão gastando tempo significativo em trabalho de especificação, reconheça isso. Atualize descrições de cargo, critérios de contratação e planos de carreira. A transição está acontecendo quer você a gerencie ou não.

Conecte a resultados. Ganhos de throughput que não se traduzem em valor para o cliente são métricas de vaidade. Construa a infraestrutura de medição que conecta atividade de desenvolvimento a resultados de negócio.

Os ganhos de produtividade da IA no desenvolvimento de software são reais. Assim como as lacunas de percepção, os problemas de confiança e as falhas de medição que impedem organizações de capturá-los.

As organizações que mais se beneficiarão não são aquelas com maior adoção de IA. São aquelas com o entendimento mais claro do que IA muda, do que não muda e de como medir a diferença.

---

Fontes: Entrevista McKinsey Technology com CEO da Jellyfish Andrew Lau, Estudo RCT do METR, Jellyfish 2025 AI Metrics in Review