- Em meio à ampla adoção de ferramentas de codificação com IA e ao aumento dos custos, empresas de tecnologia conhecidas estão organizando, em métricas em várias camadas, como quantificam na prática a utilidade da IA
- O ponto central é uma abordagem híbrida que acompanha ao mesmo tempo métricas básicas de engenharia já existentes (ex.: throughput de PR, taxa de falha em mudanças) e métricas específicas de IA (ex.: taxa de uso da IA, tempo economizado, CSAT)
- Destaca-se uma mentalidade experimental que extrai tendências e correlações por meio de segmentação por nível de uso de IA por equipe/indivíduo/coorte e de comparações antes e depois
- É necessário um desenho equilibrado que monitore continuamente qualidade, manutenibilidade e experiência do desenvolvedor junto com métricas de velocidade, para evitar o aumento da dívida técnica e os efeitos colaterais de benefícios de curto prazo
- No longo prazo, prevê-se a expansão da medição para telemetria remota de agentes e até áreas de trabalho não relacionadas à programação; no fim, a pergunta se resume a: “a IA está tornando melhor aquilo que já é importante (qualidade, velocidade de lançamento no mercado e experiência do desenvolvedor)?”
O debate sobre o impacto da IA e a lacuna de medição
- Como se vê com frequência no LinkedIn e em outros lugares, há uma enxurrada de afirmações de que a IA está mudando a forma como as empresas desenvolvem software
- A mídia simplifica o impacto da IA para “quanto código foi escrito”, mas, como resultado, o setor passa a enfrentar o risco de acumular a maior dívida técnica da história
- Embora houvesse consenso de que LOC (linhas de código) não é uma métrica adequada de produtividade, ela voltou a ganhar espaço por causa da facilidade de medição, encobrindo valores essenciais como qualidade, inovação, velocidade de lançamento e confiabilidade
- Atualmente, muitos líderes de engenharia estão tomando decisões importantes sobre ferramentas de IA sem saber claramente o que funciona e o que não funciona
- Segundo o LeadDev 2025 AI Impact Report, 60% dos líderes apontam a “falta de métricas claras” como o maior desafio
- Os líderes no campo demonstram insatisfação entre a pressão por resultados e executivos obcecados por LOC, e a lacuna entre a informação necessária e a medição real continua se ampliando
- O autor pesquisa ferramentas para desenvolvedores há mais de 10 anos e, desde 2021, atua em consultoria de ganho de produtividade e medição do impacto da IA
- Depois de entrar como CTO da DX, passou a colaborar com centenas de empresas e liderar análises de DevEx, eficiência e impacto da IA
- No início de 2025, com base em dados de mais de 400 empresas, ele foi coautor do AI Measurement Framework
- Trata-se de um conjunto recomendado de métricas necessárias para adoção de IA e medição de impacto, construído com base em pesquisa de campo e análise de dados
- Neste texto, ele analisa como 18 empresas de tecnologia medem de fato o impacto da IA e compartilha:
- exemplos reais de métricas de Google, GitHub, Microsoft e outras
- formas de uso para identificar o que funciona
- metodologia de medição do impacto da IA
- definições e guia de métricas de impacto da IA
1. Métricas reais de 18 empresas
- Casos de 18 empresas como Google, GitHub, Microsoft, Dropbox, Monzo, Atlassian, Adyen, Booking.com e Grammarly são compartilhados em imagem
- Embora as empresas adotem abordagens diferentes, em comum elas se concentram em alguns grupos centrais de métricas
-
1. Métricas de uso (Adoption & Usage)
- DAU/WAU/MAU: quase todas as empresas acompanham usuários ativos diários, semanais e mensais das ferramentas de IA
- Intensidade de uso/eventos de uso: Google, eBay e outras detalham desde escrita de código e respostas em chat até agentic actions
- CSAT da ferramenta de IA: várias empresas, como Dropbox, Webflow e Grammarly, também fazem pesquisas de satisfação
-
2. Métricas de produtividade (Throughput & Time Savings)
- Throughput de PR (PR throughput): várias empresas, como GitHub, Dropbox, Webflow e CircleCI, acompanham essa métrica em comum
- Tempo economizado (Time savings): medição do tempo semanal economizado por engenheiro (Dropbox, Monzo, Toast, Xero e outras)
- Tempo de ciclo de PR: usado por Microsoft, CircleCI, Xero, Grammarly e outras
-
3. Métricas de qualidade/estabilidade (Quality & Reliability)
- Change Failure Rate: a métrica de qualidade mais comum em empresas como GitHub, Dropbox, Adyen, Booking.com e Webflow
- Manutenibilidade do código/percepção de qualidade: GitHub, Adyen e CircleCI avaliam isso em conexão com DevEx
- Bugs/taxa de reversão: Glassdoor (número de bugs), Toast (PR revert rate)
-
4. Métricas de experiência do desenvolvedor (Developer Experience)
- Satisfação do desenvolvedor/pesquisas (DevEx, DXI): usadas por Atlassian, Webflow, CarGurus, Vanguard e outras
- Bad Developer Days (BDD): a Microsoft mede atrito de forma original com o conceito de “dias ruins do desenvolvedor”
- Carga cognitiva e friction do desenvolvedor: Google, eBay e outras
-
5. Métricas de custo e investimento (Spend & ROI)
- Gasto com IA (total & per developer): algumas empresas acompanham custos, como nos casos de Dropbox, Grammarly e Shopify
- Capacity worked (taxa de utilização): a Glassdoor mede quanto a ferramenta foi usada em relação ao seu potencial máximo
-
6. Métricas de inovação/experimentação (Innovation & Experimentation)
- Innovation ratio / velocity: GitHub, Microsoft e Webflow transformam a velocidade de inovação em métrica
- Número de testes A/B: a Glassdoor usa a quantidade mensal de testes A/B como métrica principal
- Métricas de resultado, como tempo economizado, throughput de PR, taxa de falha em mudanças, usuários engajados e taxa de inovação, são acompanhadas em paralelo com métricas de comportamento de uso
- A composição das métricas varia de acordo com as prioridades e o contexto do produto de cada organização, e não existe uma única métrica universal
2. Base sólida: o núcleo da medição de impacto da IA
- Escrever código com IA não muda os critérios de um bom software. Qualidade, manutenibilidade e velocidade continuam sendo essenciais
- Por isso, métricas existentes como Change Failure Rate, throughput de PR, tempo de ciclo de PR e experiência do desenvolvedor (DevEx) continuam sendo importantes
- Métricas totalmente novas são desnecessárias
- A pergunta importante é: “A IA está melhorando aquilo que já era importante?”
- Se você ficar em métricas superficiais como LOC ou taxa de aceitação, não conseguirá entender corretamente o impacto da IA
- São necessárias novas métricas-alvo para entender exatamente o que está acontecendo no uso de IA
- É possível identificar onde, quanto e de que forma a IA está sendo usada e aplicar isso em decisões sobre orçamento, rollout de ferramentas, segurança e compliance
- As métricas de IA mostram coisas como:
- Quantos e quais tipos de desenvolvedores estão adotando ferramentas de IA?
- Quanto trabalho, e que tipos de trabalho, a IA está impactando?
- Qual é o custo?
- As principais métricas de engenharia mostram coisas como:
- Se a equipe está fazendo ship mais rápido
- Se a qualidade e a confiabilidade estão melhorando ou piorando
- Se a manutenibilidade do código está caindo
- Se as ferramentas de IA estão reduzindo atritos no fluxo de trabalho dos desenvolvedores
-
No caso da Dropbox
- Métricas de IA
- DAU/WAU (usuários ativos diários e semanais)
- CSAT da ferramenta de IA (satisfação)
- Tempo economizado por engenheiro
- Gastos com IA
- Métricas centrais (usando o Core 4 Framework)
- Change Failure Rate
- throughput de PR
- Resultados
- Usuários regulares semanais de IA = 90% de todos os engenheiros (acima da média do setor, de 50%)
- Usuários regulares de IA tiveram aumento de 20% em PRs mesclados + redução na Change Failure Rate
- Mais importante do que a taxa de adoção em si é verificar se há contribuição real para o desempenho da organização, da equipe e do indivíduo
3. Desdobrando métricas por nível de uso de IA
- São feitas várias análises comparativas para entender que mudanças a IA traz para a forma de trabalho dos desenvolvedores
- Comparação entre usuários e não usuários de IA
- Comparação das principais métricas de engenharia antes e depois da adoção de ferramentas de IA
- Acompanhamento do mesmo grupo de usuários (cohort analysis) para observar mudanças após a adoção de IA
- Segmentar os dados (slicing & dicing) para identificar padrões
- Análise por atributos como função, tempo de casa, região e linguagem principal
- Exemplo: juniores passam a abrir mais PRs, enquanto seniores ficam mais lentos por terem maior peso em revisões
- Isso permite identificar grupos que precisam de treinamento e suporte adicionais e grupos em que o uso de IA gera mais efeito
- Caso da Webflow
- No grupo de desenvolvedores com 3 anos ou mais de empresa, o ganho de tempo com uso de IA foi o maior
- Com ferramentas como Cursor e Augment Code, houve aumento de 20% no throughput de PR (comparando usuários de IA vs. não usuários)
- Necessidade de uma baseline sólida
- Organizações sem uma base de métricas de produtividade de desenvolvedores têm dificuldade para medir o impacto da IA
- Com o Core 4 Framework (usado por Dropbox, Adyen, Booking.com etc.), é possível estabelecer rapidamente uma linha de base
- Use em conjunto dados do sistema, dados de amostragem de experiência e pesquisas regulares para fazer comparações mais confiáveis
- Acompanhamento contínuo e mentalidade experimental são essenciais
- Medição pontual não tem muito significado; é preciso acompanhar séries temporais para identificar tendências e padrões
- O ponto em comum entre empresas bem-sucedidas: definem objetivos concretos e validam hipóteses com dados
- Sem depender cegamente dos dados, mantêm uma mentalidade experimental orientada por objetivos
4. Cautela com manutenibilidade, qualidade e experiência do desenvolvedor
- O desenvolvimento assistido por IA ainda é uma área nova
- Faltam dados que comprovem o impacto na qualidade e na manutenibilidade do código no longo prazo
- O principal desafio é equilibrar o ganho de velocidade no curto prazo com o risco de dívida técnica no longo prazo
- É preciso acompanhar conjuntamente métricas que se contrabalançam
- A maioria das empresas acompanha ao mesmo tempo Change Failure Rate e throughput de PR
- Quando a velocidade sobe, mas a qualidade cai, isso funciona como um sinal imediato de problema
- Métricas adicionais para monitorar qualidade e manutenibilidade
- Change confidence: grau de confiança do desenvolvedor na estabilidade do código durante o deploy
- Code maintainability: facilidade para entender e modificar o código
- Perception of quality: percepção dos desenvolvedores sobre a qualidade do código e as práticas da equipe
- É necessário combinar métricas de sistema e métricas autorrelatadas
- Dados de sistema: throughput de PR, frequência de deploy etc.
- Dados autorrelatados: confiança na mudança, manutenibilidade etc. → sinais fundamentais para evitar impactos negativos de longo prazo
- Recomenda-se fazer pesquisas regulares de experiência do desenvolvedor (DevEx)
- Com o exemplo de pesquisa, é possível acompanhar a correlação entre qualidade, manutenibilidade e uso de IA
- Feedback não estruturado também é útil para identificar problemas existentes e discutir soluções
- O significado real de experiência do desenvolvedor (DevEx)
- Não é um conceito de benefícios como “pingue-pongue e cerveja”, e sim a remoção de atritos em todo o processo de desenvolvimento
- O objetivo é garantir eficiência em todo o processo de planejamento → desenvolvimento → testes → deploy → operação
- Ferramentas de IA podem reduzir atritos na escrita de código e nos testes, mas também correm o risco de adicionar novos atritos em revisão, resposta a incidentes e manutenção
- Insight de campo (Shelly Stuart, da CircleCI)
- Métricas de output (throughput de PR) mostram o que está acontecendo, mas a satisfação do desenvolvedor mostra a sustentabilidade
- A adoção de IA pode causar desconforto inicial, por isso acompanhar a satisfação é uma ferramenta essencial para distinguir atrito de curto prazo vs. valor de longo prazo
- 75% das empresas também acompanham CSAT/satisfação das ferramentas de IA → foco em construir uma cultura de desenvolvimento sustentável, mais do que apenas velocidade
5. Métricas únicas e tendências interessantes
- Microsoft: Bad Developer Day (BDD)
- Conceito para medir em tempo real a fricção e o nível de fadiga no trabalho cotidiano
- Resposta a incidentes e conformidade, custo de alternância entre reuniões e e-mails, e tempo gasto em sistemas de gestão de trabalho são fatores que tornam o dia ruim
- Em equilíbrio com a atividade de PRs (indicador substituto do tempo de programação), o dia é avaliado como bom se houver um tempo mínimo garantido para programar, mesmo com algumas tarefas de baixo valor
- Objetivo: verificar se as ferramentas de IA estão reduzindo a frequência e a gravidade dos BDDs
- Glassdoor: medição de experimentos e taxa de uso de ferramentas
- Acompanha, pelo número mensal de testes A/B, se a IA está aumentando a velocidade de inovação e experimentação
- Em paralelo, adota uma estratégia de formar power users como evangelistas internos de IA
- Capacity worked (taxa de utilização): mede o uso real em relação ao uso potencial da ferramenta para identificar o ponto de saturação da adoção e decidir sobre realocação de orçamento
- Queda da Acceptance Rate
- Antes era uma métrica central de IA, mas tem escopo limitado por observar apenas o momento em que a sugestão é aceita
- Não reflete manutenibilidade, ocorrência de bugs, reversão de código nem a percepção de produtividade do desenvolvedor
- Hoje já não é muito usada como métrica principal, mas há exceções:
- GitHub: usa para melhorar o Copilot e apoiar decisões de produto
- T-Mobile: estima em que medida o código gerado por IA é efetivamente incorporado à produção
- Atlassian: usa como métrica auxiliar de satisfação do desenvolvedor e qualidade das sugestões
- Análise de custos e investimentos
- A maioria das empresas não acompanha ativamente o custo de uso para evitar desmotivar os desenvolvedores
- A Shopify adota a abordagem de celebrar os desenvolvedores com maior consumo de tokens por meio do AI Leaderboard
- ICONIQ 2025 State of AI Report: previsão de que o orçamento corporativo para produtividade com IA em 2025 dobre em relação a 2024
- Algumas empresas estão migrando para um modelo de reduzir o orçamento de contratação e realocá-lo para ferramentas de IA
- Ausência de telemetria de agentes
- Atualmente quase não há medição, mas a possibilidade de adoção nos próximos 12 meses é alta
- Com a expansão de workflows de agentes autônomos, cresce a necessidade de medir comportamento, precisão e taxa de regressão
- Falta de medição de atividades não relacionadas à codificação
- Hoje a medição está limitada ao suporte à escrita de código; sessões de planejamento no ChatGPT ou tratamento de issues no Jira raramente entram na conta
- Em 2026, com a expansão do uso de IA para todas as etapas do SDLC, a medição também precisará evoluir
- Atividades concretas, como code review e varredura de vulnerabilidades, são mais fáceis de medir; tarefas abstratas são mais difíceis
- Espera-se uma ampliação do escopo das medições autorrelatadas (“Quanto tempo você economizou com IA esta semana?”)
6. Como o impacto da IA deve ser medido?
- AI Measurement Framework
- Desenvolvido com Abi Noda, coautor do DevEx Framework
- Elaborado com base em dados de campo de cerca de 400 empresas e em pesquisas sobre produtividade de desenvolvedores ao longo dos últimos 10 anos
- Combina métricas de IA com métricas centrais para avaliar conjuntamente velocidade, qualidade, manutenibilidade e experiência do desenvolvedor (DevEx)
- Uma métrica isolada (por exemplo, proporção de código gerado por IA) funciona bem como headline, mas não é um meio suficiente de medir resultados
- É necessário combinar dados qualitativos e quantitativos
- Só é possível obter uma compreensão multidimensional ao coletar tanto métricas de sistema (volume de PRs, DAU/WAU, frequência de deploy etc.) quanto métricas autorrelatadas (CSAT, economia de tempo, percepção de manutenibilidade etc.)
- Muitas empresas usam DX para coleta e visualização de dados, embora também seja possível construir sistemas customizados
- Métodos de coleta de dados
- Dados de sistema (quantitativos): API de administração das ferramentas de IA (uso, gasto, tokens, taxa de aceitação) + métricas de SCM, JIRA, CI/CD, build e gestão de incidentes
- Pesquisas regulares (qualitativas): pesquisas trimestrais ou semestrais para identificar tendências de longo prazo, como DevEx, satisfação, confiança em mudanças e manutenibilidade, que são difíceis de captar por métricas de sistema
- Amostragem de experiência (qualitativa): inserção de perguntas curtas durante o workflow (ex.: logo após enviar um PR, “Você usou IA?”, “Este código foi fácil de entender?”)
- Prioridades de execução
- Pesquisas regulares são o ponto de partida mais rápido: é possível obter dados iniciais em 1 a 2 semanas
- Assim como o nível de precisão necessário para instalar uma cortina é diferente do necessário para lançar um foguete, decisões de engenharia também podem ser valiosas com um grau de precisão suficiente para indicar a direção
- Depois, a confiabilidade aumenta ao combinar outros métodos de coleta para validação cruzada
- Recursos adicionais
- Pontos a considerar na aplicação interna
- Em vez de perseguir taxa de adoção ou uma métrica isolada, é preciso verificar se está melhorando a capacidade de entregar software de alta qualidade rapidamente aos clientes
- Pergunta central:
> “A IA está melhorando o que já é importante — qualidade, velocidade de lançamento e experiência do desenvolvedor?”
- Perguntas a tratar em reuniões de liderança:
- O que define desempenho de engenharia na nossa organização?
- Temos dados de desempenho de antes da adoção de ferramentas de IA? Se não, como vamos estabelecer rapidamente uma baseline?
- Não estamos confundindo atividade de IA com impacto da IA?
- Estamos equilibrando velocidade, qualidade e manutenibilidade?
- Já é possível ver o impacto na experiência do desenvolvedor?
- Estamos operando um modelo de medição em múltiplas camadas que inclua tanto dados de sistema quanto dados autorrelatados?
7. Como a Monzo mede o impacto da IA
- Introdução inicial
- A primeira ferramenta foi o GitHub Copilot. Incluído na licença do GitHub e integrado naturalmente ao VS Code, passou a ser usado por todos os engenheiros
- Depois, testaram em paralelo várias ferramentas como Cursor, Windsurf e Claude Code, enquanto continuavam investindo com foco no Copilot
- Filosofia de avaliação de ferramentas de IA
- Em um ecossistema de ferramentas que muda rapidamente, a experiência direta é indispensável
- Só dá para entender o desempenho quando os membros da equipe aplicam IA diariamente em código real e até criam e usam eles mesmos os arquivos de configuração dos agentes
- A avaliação combina métricas objetivas (uso, desempenho) e pesquisas subjetivas (satisfação com DX)
- Efeitos e valor percebido
- Os engenheiros sentem que, com a IA, ficou mais fácil fazer busca e resumo de documentação e entendimento de código, além de reduzir a carga cognitiva
- Em um mercado competitivo por talentos, não oferecer as melhores ferramentas aumenta o risco de perda de desenvolvedores → disponibilizar ferramentas em si já é uma estratégia de retenção de talentos
- Dificuldades de medição
- Os números fornecidos pelos vendors se limitam a métricas restritas, como taxa de aceitação, e é difícil entender o impacto real no negócio
- Também é praticamente impossível validar isso com precisão por meio de testes A/B
- É difícil consolidar dados de uso de várias ferramentas (GitHub, Gemini, Slack, Notion etc.) → limitações de telemetria e vendor lock-in são os principais obstáculos
- Como resultado, por enquanto a percepção dos desenvolvedores é o principal sinal
- Áreas em que funciona bem
- Grande resultado em migração: percepção de redução de 40% a 60% no trabalho de alteração de código
- Em tarefas repetitivas e manuais, como comentários de modelos de dados, o LLM faz o rascunho inicial e o engenheiro revisa → grande economia de trabalho em escala
- Lições inesperadas
- Falta de noção sobre custos de LLM: ao ver a fatura baseada no uso real de tokens, a necessidade de otimização ficaria muito mais evidente
- Exemplo: a revisão automática de código do Copilot consome muitos tokens e entrega pouco resultado, então vem desativada por padrão e foi alterada para um modelo opt-in quando necessário
- Áreas em que a IA não é usada
- Dados de clientes: é proibido aplicar IA tanto a dados brutos quanto a dados desidentificados
- Em áreas com dados sensíveis, a prioridade máxima é evitar o risco de vazamento de dados
- Filosofia da equipe de plataforma
- Fornecer guardrails: preparar um ambiente de uso seguro, incluindo proteção de dados
- Compartilhar casos: divulgar com transparência casos de sucesso e fracasso, além de experiências no uso de prompts
- Enfatizar a dualidade: compartilhar tanto os aspectos positivos quanto os negativos para manter uma visão equilibrada
- Relembrar os limites dos LLMs: destacar que a IA tem limitações como os humanos, para evitar confiança excessiva
Conclusão e implicações
- Medir o impacto da IA ainda é uma área muito nova
- Não existe uma “melhor metodologia” no setor
- Até empresas de porte e mercado semelhantes, como Microsoft e Google, usam métricas diferentes
- Cada empresa tem sua abordagem própria e seu próprio “flavor”
- É comum medir métricas conflitantes ao mesmo tempo
- Exemplo representativo: acompanhar juntos a taxa de falha de mudanças (confiabilidade) e a frequência de PRs (velocidade)
- Como implantar rápido só faz sentido se não prejudicar a confiabilidade, é preciso medir os dois eixos com equilíbrio
- Medir o impacto de ferramentas de IA é um desafio semelhante ao de medir a produtividade de desenvolvedores
- Medir produtividade é um problema com o qual o setor vem lidando há mais de 10 anos
- Não dá para explicar a produtividade de uma equipe com uma única métrica, e otimizar uma métrica específica não necessariamente aumenta a produtividade real
- Em 2023, a McKinsey anunciou que havia “resolvido” a forma de medir produtividade, mas Kent Beck e o autor adotaram uma posição cética em relação a isso → artigo de contestação
- Ainda não há uma solução clara, mas é preciso experimentar
- Até que a medição de produtividade seja totalmente resolvida, também será difícil resolver completamente a medição do impacto das ferramentas de IA
- Mesmo assim, é preciso continuar experimentando e tentando novas abordagens para responder à pergunta: “Como as ferramentas de coding com IA mudam a eficiência diária e mensal de indivíduos, equipes e empresas?”
Ainda não há comentários.