O estado da IA no desenvolvimento de software: dados de mais de 400 organizações — Justin Reock, DX

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The State of AI in Software Development: Data from 400+ Orgs — Justin Reock, DX · Canal: AI Engineer · 18:47 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Justin Reock apresenta dados de relatórios da DX sobre o impacto da IA na experiência e na produtividade de desenvolvimento. A velocidade de entrega aumentou, mas os ganhos percebidos são modestos e a qualidade apresenta resultados voláteis; ao mesmo tempo, PRs maiores vêm acompanhados de menor confiança nas mudanças e menos entregas incrementais. A palestra propõe medir utilização, impacto e custo, relacionando o uso de IA a métricas fundamentais de produtividade e qualidade. Reock também argumenta que as organizações devem melhorar a infraestrutura e atacar gargalos do fluxo de trabalho, em vez de tratar a IA como uma forma de substituir pessoas.

Pontos-chave

A frequência de deploy aumentou, mas métricas de velocidade são indicadores indiretos e não representam, por si só, geração de valor.
O aumento percebido de velocidade foi de cerca de 4,5% ao longo de um ano, apesar dos investimentos em IA.
O impacto na taxa de falha de mudanças é muito variável entre empresas, e a IA ampliou a volatilidade observada.
O tamanho médio dos PRs subiu de cerca de 44 para 72 linhas, enquanto a confiança nas mudanças caiu 6%.
Engenheiros juniores usam IA com mais frequência e gastam mais tokens em tarefas semelhantes; engenheiros mais experientes economizam tempo em proporção parecida.
A avaliação da IA deve combinar métricas de utilização, impacto nos resultados e custo, comparando grupos de usuários com métricas fundamentais.
Documentação clara, código modular e testes confiáveis ajudam tanto desenvolvedores quanto agents.
Os ganhos de produtividade observados são modestos; organizações precisam identificar e resolver gargalos além da geração de código.
Exemplos da Morgan Stanley, Zapier e Spotify ilustram usos de agents para reduzir trabalho administrativo, apoiar revisões e agilizar a resposta a incidentes.

Capítulos

Início	Capítulo	Resumo
00:12	Apresentação e contexto dos dados	Justin Reock apresenta seu trabalho na DX e explica como a plataforma reúne dados sobre experiência de desenvolvimento e uso de IA.
01:13	Velocidade de entrega e percepção de produtividade	A frequência de deploy cresce, mas a percepção de velocidade aumenta pouco e varia entre regiões.
04:20	Qualidade, confiança e tamanho dos PRs	A qualidade apresenta resultados voláteis, enquanto os PRs ficam maiores e a confiança nas mudanças e na entrega incremental diminui.
08:26	Diferenças entre engenheiros e empresas	Engenheiros juniores usam mais IA, mas profissionais experientes economizam tempo de forma semelhante, e empresas menores tendem a ter mais ganhos.
10:32	Como medir o impacto da IA	A proposta é comparar grupos de usuários com métricas fundamentais e acompanhar utilização, impacto e custo.
13:08	Preparação da plataforma e eficácia do trabalho com IA	Documentação, código modular e testes confiáveis favorecem o uso de IA, e o feedback dos agents pode revelar problemas de colaboração.
14:41	Gargalos e exemplos de uso organizacional	Reock defende ampliar o foco além da geração de código e apresenta exemplos da Morgan Stanley, Zapier e Spotify.

Citações

Os agents e assistentes estão facilitando entender e modificar o código à minha frente, mas confio menos nos resultados. — 06:24

O que é bom para humanos também é bom para agents. — 13:39

Uma hora economizada em algo que não é o gargalo não vale nada. — 16:13

Isso não é uma história de substituição de pessoas; é uma história de capacidade de entrega e de inovação. — 17:15

Conceitos e entidades

Justin Reock (pessoa): Vice-CTO da DX que apresenta dados sobre IA, experiência de desenvolvimento e produtividade.
DX (empresa): Empresa que produz relatórios sobre experiência de desenvolvimento e impacto da IA com base em dados de sua plataforma.
DORA metrics (conceito): Conjunto de métricas de desempenho de entrega de software, incluindo frequência de deploy e taxa de falha de mudanças.
SPACE framework (conceito): Framework mencionado como uma das bases de pesquisa relacionadas à produtividade e à experiência de desenvolvedores.
developer experience (conceito): Experiência dos desenvolvedores ao realizar seu trabalho, considerada em relação à produtividade e aos resultados da organização.
PR (conceito): Unidade de revisão e integração de mudanças de código cujo tamanho e frequência são usados na análise apresentada.
Morgan Stanley (empresa): Empresa que criou um agent para interpretar código legado e gerar documentos de requisitos para engenheiros.
Zapier (empresa): Empresa que usa um ecossistema de agents para automatizar tarefas administrativas e apoiar revisões de código.
Spotify (empresa): Empresa que criou um agent para reunir instruções de runbooks e contexto de incidentes para equipes de resposta.
Theory of Constraints (conceito): Abordagem de gestão citada para defender que se deve identificar e resolver o gargalo do fluxo de trabalho.

Tradução completa (pt-BR)

00:12 Eu sou Justin Rio. Sou vice-CTO na DX. Tenho a oportunidade de fazer boa parte das nossas pesquisas sobre experiência do desenvolvedor e sua relação com a produtividade do desenvolvedor. E, certamente, ao longo do último ano, boa parte dessas pesquisas se concentrou no impacto da IA sobre a experiência do desenvolvedor e aspectos básicos da produtividade dentro de uma organização. Produzimos esses relatórios trimestrais, nossos relatórios sobre o estado da IA e o impacto da IA, que analisam muitos dados brutos que conseguimos obter da nossa plataforma. Nossa plataforma

00:43 é uma plataforma de pesquisa criada pelas mesmas pessoas que trabalharam nas métricas Dora, no framework SPACE e no framework DevX. E, no fim das contas, é uma plataforma de coleta de dados capaz de analisar muitas tendências diferentes em uma organização: como estamos nos concentrando na experiência do desenvolvedor, estamos vendo resultados e melhorias nessa experiência e, certamente, estamos vendo resultados com a forma como usamos IA nos nossos workflows? Esta sessão vai ser um pouco diferente da sessão das 3h45, que acho que vai acontecer na sala de liderança mais tarde, e que apenas analisa os dados brutos do nosso relatório mais recente. Esta é uma espécie de prévia. Aqui, vamos analisar mais as tendências organizacionais e como nosso workflow está mudando, entre outras coisas, com base nos dados que estamos vendo.

01:13 Então, para começar, vamos dar uma olhada no que estamos vendo em termos do impacto na velocidade. Se alguém conhece as várias métricas de velocidade, como o fluxo de PRs e a frequência de deploy, espero que entenda a ressalva de que essas métricas não são perfeitas. Elas são métricas substitutas para entender como o trabalho flui por uma organização.

01:44 Elas não representam completamente a geração de valor. Também vamos analisar algumas métricas que se aproximam mais disso. Mas vamos tentar entender o que essa tecnologia está fazendo com as métricas brutas de velocidade na organização. Aqui está nossa métrica Dora de frequência de deploy. Quem conhece as métricas Dora? Certo, a maioria de vocês. Ótimo. Essa é uma das quatro métricas principais que tentam indicar a velocidade com que o trabalho é entregue em um ambiente. E estamos vendo um aumento constante. Está começando a perder força um pouco. Acho que há motivos para isso.

02:16 Parte do aumento que vimos no início se deveu às pessoas entregando PRs com mais frequência e coisas do tipo. Estamos vendo aumentos nessa métrica. Esta é uma pequena parte do SDLC e do PDLC, certo? É o processo desde a criação do PR até a tentativa de fazer o deploy em produção. Ela não nos diz nada sobre as taxas de reversão. Não nos diz nada sobre as proporções de defeitos. Não nos diz nada sobre a taxa de falha de mudanças. Só nos diz quanto estamos

02:46 colocando em produção agora. Mas os dados mostram que esse número está aumentando de forma constante. Certo. As tendências variam um pouco entre as regiões. Estamos vendo a América do Norte numa tendência de alta. Na Europa, na verdade, houve uma pequena queda no último trimestre. Acho que há vários motivos para isso. Obviamente, a forma como o trabalho é feito nessas regiões é diferente. A forma como podemos gastar dinheiro com essa tecnologia e pensar nos gastos com tokens é diferente; as regulamentações também são diferentes. Mas, se olharmos para

03:19 a tendência geral, ainda vemos melhorias nessa única métrica de frequência de deploy, mesmo entre diferentes regiões. Apenas vemos algumas variações entre elas. Aqui está uma métrica interessante: a percepção da velocidade de entrega. Quanto mais rápido os engenheiros sentem que estão entregando? Ela aumentou um pouco. Esse número indica um aumento de cerca de quatro e meio por cento. Mas

03:49 considerando que isso se refere a um ano inteiro e todo o investimento, os custos e os novos gastos com IA, é interessante que essa percepção da velocidade não tenha se mantido nem aumentado um pouco mais. Especialmente quando olhamos para estudos como o estudo do METR, obviamente famoso e falho, se vocês o conhecem. Em fevereiro, eles publicaram um acompanhamento desse estudo, dizendo que alguns dos sinais coletados eram imperfeitos e que precisavam repensar parte da análise. Mas o interessante é que, entre os 16 engenheiros que participaram desse estudo pequeno e falho, a

04:20 produtividade caiu cerca de 19%, mas a percepção aumentou cerca de 20%. Então houve uma diferença de aproximadamente 40% entre a percepção da produtividade e a produtividade real. Mas, quando analisamos isso de forma mais agregada, curiosamente, os números permanecem mais ou menos estáveis. Certo. E quanto ao impacto na qualidade e na entrega? Essas são apenas nossas métricas de velocidade. Mas o que isso está fazendo com a qualidade do nosso software? A primeira métrica que vamos analisar aqui é a métrica Dora da taxa de falha de mudanças. E vou

04:52 preparar vocês para isso. A maioria está sentada. O impacto que vimos na qualidade durante esse período é muito volátil. Cada linha deste gráfico representa uma empresa que fez parte desta parte específica do estudo. A linha mostra se a taxa de falha de mudanças aumentou ou diminuiu. O ideal é que ela diminua. Vocês querem ficar na parte de baixo deste gráfico. Mas o interessante é que, olhando para algumas das linhas mais altas, vemos aumentos de até 2%. Isso pode não parecer muito, até vocês perceberem que o

05:22 benchmark do setor é de cerca de 4%. Isso significa que talvez estejamos entregando 50% mais defeitos do que antes. Então, é importante entender em que lado desse gráfico vocês estão. Vocês precisam começar a medir isso, certo? Esse padrão existe mesmo sem IA, aliás. Isso tem muito a ver com outros fatores; não é algo causado exclusivamente pela IA. Boa parte disso tem a ver com o pipeline de release, os testes automatizados e tudo o que envolve a forma como vocês lançam o código. O padrão continua o mesmo. A amplitude mudou como resultado da IA. Sempre vemos esse tipo de

05:52 variação na volatilidade, mas geralmente não nesses extremos. Esse é o efeito da IA que estamos vendo. Aqui está algo muito interessante. Estas são duas métricas qualitativas de qualidade que normalmente estão mais ou menos em sintonia uma com a outra. A capacidade de manutenção do código: o quanto os desenvolvedores consideram que o código pode ser mantido ao fazer alterações nele. Segundo nossos dados, esse número aumentou quase 4%. A propósito, estamos analisando cerca de 200 mil engenheiros neste estudo para coletar esses dados. Já a confiança nas mudanças,

06:24 que tradicionalmente vemos muito associada à capacidade de manutenção do código — “Este código pode ser mantido. É modular. É fácil de modificar. Sinto confiança nas mudanças que estou colocando em produção” —, essa não. Nosso índice de confiança nas mudanças caiu 6%. Essa tensão é realmente interessante porque significa algo como: “Certo, agents e assistentes estão facilitando para mim entender e modificar o código que tenho diante de mim, mas confio menos nos resultados. Agora tenho mais medo de quebrar coisas do que tinha há um ano.” Então, é um efeito psicológico interessante que vemos aqui. E boa parte disso se deve ao aumento mensurável do tamanho dos PRs. Esta vai ser uma das métricas mais importantes que vamos analisar este ano. Ainda não dobrou, mas vejam essa trajetória, certo? Isso abrange o mesmo período do estudo, cerca de um ano, e vimos os PRs passarem de cerca de 44 linhas, em média, por PR, para 72. Há vários motivos para isso. Não é apenas a probabilidade de que a forma como esses modelos funcionam seja resultado do treinamento para gerar

06:54 efeito psicológico que vemos aqui. E muito disso se deve ao fato de que o tamanho dos PRs está aumentando de forma mensurável. Essa será uma das métricas mais importantes que vamos analisar este ano. Ainda não chegou a dobrar, mas vejam essa trajetória, certo? Isso é ao longo do mesmo período de estudo, de cerca de um ano, e vimos os PRs passarem de cerca de 44 linhas, em média, por PR, para 72. Há vários motivos para isso. Não é só, sabe, a probabilidade de que a forma como esses modelos funcionam seja que eles estejam sendo treinados para produzir

07:25 código relativamente medíocre. Escrevo código profissionalmente desde o fim dos anos 90. Lembro que era um grande mérito para um desenvolvedor conseguir implementar o mesmo caso de uso com o mínimo de código possível. Agora é como: bom, não, vamos colocar isso para funcionar. E, sabe, o código gerado vai ser essencialmente medíocre, porque é a lei das médias. Mas, além disso, pense no seguinte: se você tem um pipeline de build que leva 45 minutos ou uma hora para terminar e agora tenho a IA gerando funções para mim instantaneamente, vou abrir quatro PRs diferentes, com quatro funções diferentes, e esperar 45 minutos ou uma hora

07:55 ou seja lá quanto tempo cada build levar, ou vou simplesmente enfiar todo aquele código em um único PR? Certo? Há vários motivos para isso, mas vale muito a pena mencionar que cada linha de código extra é um possível bug, uma possível vulnerabilidade. É mais coisa para revisar. Torna o código menos portátil. Então, também precisamos prestar atenção a essa métrica, porque estamos vendo isso associado à percepção de entrega incremental. Posso trabalhar em pequenas mudanças incrementais. E essa é, na verdade, uma das dimensões de experiência do desenvolvedor com menor impacto qualitativo que vimos no último ano. Esse número e esse sentimento caíram

08:26 10%. E a entrega incremental é péssima, é… Como também aprendemos, ela é muito importante para a forma como tentamos entregar de um jeito que seja fácil reverter e em que possamos entender e revisar as mudanças que estão sendo feitas. [fungada] Certo. E quanto às diferenças demográficas? O que muda nos impactos da IA entre desenvolvedores juniores e outros? Engenheiros juniores são os que mais usam IA. Isso realmente não deveria surpreender ninguém. Sempre que temos uma nova evolução, de novo, escrever

08:58 código profissionalmente desde o fim dos anos 90 — sou meio veterano — também estou nessa jornada, mas há menos coisas para desaprender quando você está entrando no setor. Em muitos casos, você já vem trabalhando com esse tipo de coisa desde que saiu da faculdade e, por isso, tem mais chances de implementar isso quando começa a trabalhar. Também vimos outras tendências. Temos formas interessantes de analisar a eficiência por caso de uso, e vou falar disso na segunda palestra, mais tarde hoje. Uma delas é analisar a experiência dos agents

09:28 — literalmente, estamos perguntando aos agents sobre a experiência deles trabalhando com pessoas. Estamos tentando descobrir em quais casos de uso eles estão trabalhando e quantos tokens gastaram. E, sem dúvida, também vemos uma tendência: para o mesmo caso de uso, desenvolvedores mais juniores gastam mais tokens do que desenvolvedores mais experientes. E isso é só uma curva de aprendizado, certo? De novo, isso não deveria surpreender ninguém. Mas, em termos de quem mais usa, vemos que são os juniores. Porém, apesar desse uso adicional, vemos que engenheiros de staff ou mais experientes economizam praticamente o mesmo tempo,

10:00 certo? E gastam menos tokens. Quero deixar isso bem claro também. Então, em termos de economia bruta de tempo no resultado agregado, os números são bem parecidos entre engenheiros juniores, que usam mais a tecnologia, e engenheiros de staff, que conseguem identificar alucinações com mais facilidade, entender a arquitetura das mudanças que estão fazendo e coisas assim. Empresas menores lideram em economia de tempo. Claro, os pipelines de release serão menos complicados. Sabe, há menos complexidade geral na organização. Isso vai gerar mais economia de tempo para uma empresa

10:32 que já tem menos atrito e um pouco mais de agilidade do que uma empresa maior. E quanto à mensuração? Como devemos pensar em medir essas coisas? Vale mencionar que medir a produtividade e a experiência dos desenvolvedores já era um desafio antes da IA, e nunca concluímos essa discussão antes de colocar mais combustível nessa fogueira. Certo? Então, isso ainda é difícil, e eu diria que agora é ainda mais difícil, porque há vários aspectos da IA que confundem a análise, mas nós

11:04 todos vamos ter que responder a essa pergunta este ano, certo? Gastamos 10 milhões — ou muito mais, se vocês vierem à minha palestra sobre tokens, mais tarde hoje. Onde está a produtividade 10x? Ao pensar nessas coisas, é importante ter em mente que não devemos descartar o que já estamos medindo, certo? Nossas métricas fundamentais de experiência e produtividade dos desenvolvedores continuam sendo as mais importantes. Queremos entender como a IA está afetando essas métricas confiáveis que já acompanhamos. Por exemplo, talvez queiramos analisar grupos de usuários.

11:35 Talvez queiramos pegar dados da telemetria da API e informações fornecidas pelas ferramentas e usá-los para entender quem está usando o quê e onde. Mas só queremos usar esses grupos e analisá-los comparativamente com base nas nossas métricas fundamentais. Que efeito isso está tendo, de fato, na qualidade? E na velocidade? Que impacto está tendo na organização e na geração de valor? É daí que vem nossa estrutura de mensuração de IA. Não vou me alongar muito sobre isso. Temos um white paper extenso disponível. Meu colega Anton, que está no fundo da sala, de camisa branca, poderá

12:07 distribuir cópias impressas dos relatórios que temos depois da palestra. Eles explicam como desenvolvemos essa metodologia e como usá-la e pensar sobre ela. Ela se concentra em três dimensões principais de mensuração. A primeira é a utilização: usuários ativos diários, usuários ativos semanais e coisas do tipo. A segunda é o impacto: quais métricas devemos acompanhar para ver se há progresso, com base na utilização? À medida que a utilização aumenta, que impacto esperamos ver nos negócios? E, por fim, o custo. É uma piada justa dizer que estamos 15 anos depois do último grande ciclo de hype

12:37 e ainda estamos tentando entender o custo de cloud, mas essas coisas estão ficando bem caras. Vamos ter que medi-las. Então, também dá para pensar nisso como uma curva de maturidade. A maioria das pessoas começa pela utilização, à esquerda. Primeiro, tenta entender o que está acontecendo na organização com a tecnologia, quem está usando, o que está usando, com que frequência e para quais casos de uso. Depois, como relacionamos isso às métricas de impacto, à geração de valor — ao que realmente queremos entender para saber se esses investimentos estão funcionando, que é o que queremos descobrir. Este é apenas um exemplo de como poderíamos correlacionar isso. Então, vocês poderiam

13:08 analisar dois grupos de usuários diferentes e compará-los usando métricas como tempo de ciclo do PR, tamanho do PR ou retorno e revisão, certo? Então, a ideia é pensar nisso assim: por enquanto, separar os grupos e depois observar como eles se saem nessas métricas fundamentais de produtividade que aprendemos a considerar confiáveis. Também precisamos conseguir entender se nossa plataforma está pronta. Gosto de dizer que, em 2024, demos a todos um assistente de programação. Em 2025, começamos a criar agents. Agora estamos percebendo que nossa infraestrutura não estava pronta para nada disso.

13:39 Muitos dos fornecedores que estão aqui vendem soluções que ajudam com esse problema. Acho que, se vocês conseguirem medir o preparo da plataforma para IA, terão uma ideia muito melhor de quão eficientemente vão gastar tokens e fornecer contexto a esses agents. Isso inclui documentação clara, precisa e bem estruturada; estruturas de dados com relações simples; código modular e fácil de gerenciar; CI local confiável; e suítes de testes que não falham de forma intermitente. Aliás, se alguma dessas coisas soa familiar, é porque antes simplesmente chamávamos isso de boa experiência do desenvolvedor, certo? Mas acontece que

14:10 O que é bom para os humanos também é bom para os agents. Então, talvez, paradoxalmente, finalmente estejamos fazendo os investimentos que deveríamos ter feito nas últimas duas décadas. Também queremos entender a eficácia da forma como trabalhamos com IA. E esta é uma maneira de fazer isso. O que vocês estão vendo aqui é feedback qualitativo vindo dos agents, que nos dizem onde tiveram problemas para se orientar junto com o humano, com o contexto que lhes foi fornecido e com os ciclos de feedback pelos quais tiveram que passar. Então, estamos obtendo esses dados dos agents para tentar descobrir a eficácia das nossas equipes ao

14:41 trabalhar com IA. E também podemos dividir isso por casos de uso, o que é muito importante. Queremos entender quais casos de uso nos dão o melhor aproveitamento dos tokens. E, mais uma vez, queremos gerar impacto na criação de valor e na produtividade dentro da empresa. Por fim, a quinta tendência: integração ao longo do SDLC e do PDLC. Por que faríamos isso? Porque a geração de código nunca foi o gargalo, para começar, certo? Mesmo que os engenheiros estivessem recebendo dos modelos código instantâneo com 100% de precisão — e não estão —, ainda assim vocês só estariam atuando em

15:11 algo entre 14% e 16% do fluxo de valor total. Então, precisamos pensar além disso. Especialmente porque, neste momento, os ganhos de produtividade que estamos realmente observando são mais modestos do que o esperado. Apesar dos aumentos no volume de PRs, o estudo que fizemos de novembro de 2024 a fevereiro deste ano encontrou um aumento mediano de apenas cerca de 7,7% nessa métrica de velocidade e uma média de 13%; até mesmo nossos melhores resultados ficaram na faixa dos 70%. Ninguém chegou a 2x,

15:42 ninguém chegou a 5x, ninguém chegou a 10x. E isso acontece porque a economia de tempo proporcionada pela IA ainda é superada por outros fatores não relacionados à IA na nossa organização, certo? Certo? Talvez estejamos economizando muito tempo com IA, e isso é ótimo. Mas, se ainda estamos anulando essa economia de tempo com dias cheios de reuniões, alternância de contexto e outras fontes de interrupção, além dos efeitos cumulativos do ambiente de desenvolvimento e dos atritos na forma como criamos software para além do código, então não estamos atacando o gargalo. E, como nos diria Eli Goldratt, da teoria das restrições e de A Meta, que também inspirou

16:13 O Projeto Fênix: um hora economizada em algo que não é o gargalo não vale nada. Então, precisamos encontrar o gargalo e resolvê-lo. E é isso que muitas organizações estão fazendo. O Morgan Stanley tem falado bastante publicamente sobre a criação do agent de IA DevGen, que interpreta código legado, como Natural e COBOL de mainframe. E tenho vergonha de admitir que escrevi muito em Perl na minha carreira, mas agora é legado. O agent cria PRDs para entregar aos engenheiros e eliminar essa etapa de engenharia reversa. E isso está economizando para o Morgan

16:44 Stanley cerca de 300 mil horas por ano, neste momento. A Zapier é uma das minhas histórias favoritas de IA atualmente. Eles têm todo um ecossistema de agents que usam para lidar com muitas tarefas administrativas e com a sobrecarga, como reuniões diárias de standup e coisas do tipo. Reduziram as reuniões de standup usando resumos de agents e outros recursos desse ecossistema que criaram: agora são duas vezes por semana, em vez de cinco. Estão conseguindo integrar engenheiros novos em cerca de duas semanas, o que é muito rápido. Em geral, o benchmark do nosso setor para isso é de mais de um mês. Mas a minha parte favorita dessa

17:15 história é que estão observando cerca de 15% a mais de criação de valor por engenheiro. Então, estão contratando mais do que em qualquer outro momento da história da empresa inteira, porque perceberam a verdade: estão obtendo mais capacidade de cada engenheiro. Estão tendo um retorno sobre o investimento melhor por engenheiro, e contratar mais engenheiros vai melhorar sua vantagem competitiva. Essa é a atitude certa. Essa é uma história sobre throughput. É uma história sobre aumento da capacidade de inovar. Não é uma história sobre substituição de funcionários. Muito bem. Eles estão automatizando cerca de 3.000 revisões de código por semana, acionadas por um pull request,

17:45 e analisam aspectos superficiais. Ainda precisam de humanos no processo, mas a revisão inicial e superficial feita pelo agent faz parte do sistema de registro. Ela fica nos comentários do PR, então o próximo engenheiro a fazer a revisão já terá uma ideia do que os agents analisaram. Isso pode economizar tempo. Por fim, o Spotify: se alguém se lembra do modelo Spotify de DevOps, eles eram uma espécie de referência em DevOps. Criaram um agent para SREs que reúne etapas de mitigação dos runbooks, informações e contexto sobre o incidente e coloca tudo isso nos canais de comunicação de SRE. Assim, quando ocorre um incidente, os SREs têm contexto imediato e não precisam passar vários minutos investigando para descobrir como resolver o problema.

18:16 Então, se quiserem se aprofundar nesses dados, nosso relatório do Q2 será publicado em apenas algumas semanas. Mas o relatório do Q1 ainda contém muitos detalhes desta sessão. Se assinarem nossa newsletter ou voltarem ao site, teremos nosso relatório do Q2 pronto por volta de meados ou do fim de julho. E, se quiserem ver uma prévia

18:47 desse relatório, essa é a palestra que vou apresentar mais tarde, nesta tarde. Obrigado a todos pelo tempo. Agradeço. >> [música] [música]

Transcrição original

[00:12] Uh I’m Justin Rio. I’m the deputy CTO at DX. I get to do a lot of our research around uh developer experience and its relation to developer productivity. And certainly over the last year, a lot of that research has focused on AI’s impact on the developer experience and basic aspects of productivity uh within an organization. Uh so we produce these quarterly reports, our our state of AI and AI impact reports which looks at really a lot of raw data that we’re able to get from our platform. Our platform

[00:43] is a researchback platform uh built from the same folks who worked on Dora metrics and the space framework and the DevX framework. Uh and really at the end of the day it’s a data gathering platform that can look at a lot of different trends across an organization with you know how are we focusing on developer experience are we seeing outcomes and improvements with developer experience and certainly are we seeing outcomes with the way that we’re using AI in our workflows. This session is going to be a little bit different than the 345 session I think that’s up in the

[01:13] leadership room later today which just looks at the raw data from our newest report. It’s a little bit of a preview. This is looking at more like organizational trends and how our workflow is changing and and things like that based on the data that we’re seeing. Uh so first things first, let’s kind of look at what we’re seeing in terms of the velocity impact. Now if anybody’s familiar with looking at various velocity metrics like PR throughput and deployment frequency like hopefully you understand the caveat that these metrics are not perfect. They are proxy metrics for understanding the way that work flows through an organization.

[01:44] They’re not fully representative of the value generation. We’re going to look at some metrics that are closer to that as well. But let’s just try to understand what this technology is doing in terms of just the raw velocity metrics in the organization. So here’s our Dora metric for deployment frequency. Who’s familiar with Dora metrics? All right, most of you. Great. Um, so this is one of the, you know, four key metrics that tries to understand directionally, you know, the speed of shipping work within an environment. And we’re seeing it steadily increase. um it’s tapering off

[02:16] a little bit. I think there’s reasons for that. Uh some of the surge that we saw early on was due to people shipping, you know, PRs more frequently and and things like that. Um so we’re seeing increases in this. This is one small part of the SDLC PDLC, right? This is like the creation uh of the PR to actually trying to deploy this into production. It doesn’t tell us about revert rates. It doesn’t tell us about defect ratios. It doesn’t tell us about change failure rate. It just tells us about how much stuff are we now kind of

[02:46] pushing out into production. But you know the data is showing us that this number is steadily increasing. Okay. Um the trends vary a little bit across regions. Um we are seeing North America just sort of like trending up. We’ve seen Europe actually pull back a little bit just in the last quarter. Um I think you know there’s there’s a number of reasons for that. I mean obviously the way work is done in these regions are differently. the way that we can spend money on this technology and think about token spend is different, the regulation is different. Um, but if we just look at

[03:19] the through line in general, you know, we still see improvements uh in in this one metric of deploy frequency even across various regions. We do just see some variance in those regions. [clears throat] Here’s one that’s kind of interesting though. Uh, the perceived rate of delivery. How much faster do engineers feel in terms of what they’re delivering? It’s gone up a little bit. This number shows an increase of about four and a halfish percent. Um, but

[03:49] given that that’s a full year and given all the investment and cost and new spend on AI, it’s interesting that this perceived rate has not stayed has not kind of crept up a little bit more. especially when you look at some studies like obviously infamous flawed MER study if you’re familiar with that study uh back in February they actually released a follow-up to that study saying that some of the signals they gathered were sort of imperfect and they needed to rethink some of that but what was interesting was that in these 16 engineers that were part of that study small study flawed study uh the

[04:20] productivity went down by about 19% but the perception went up by about 20% so there was like a 40% spread in perception of productivity versus actual ual productivity. But here when we look at this on more of an aggregate things interestingly stay uh sort of flat. All right. What about impact on quality and and delivery? Right? So those are just kind of our speed our velocity metrics. But what is this actually doing to our software quality? Um the first metric we’ll look at here is the Dora change failure rate metric. And uh let

[04:52] me prepare you. Most of you are sitting down. It’s very volatile the impact that we’ve seen on quality over this period of time. Each line on this graph represents a single company that was part of this particular part of this study. And that line shows whether you’ve moved up in terms of your change failure rate or moved down in terms of your change failure rate. You want to go down. You want to be on the bottom side of this graph. Uh but what’s interesting is if you look at some of these top lines, you see people increasing as much as 2%. Which doesn’t sound like much until you realize that the industry

[05:22] benchmark is about 4%. So that means shipping potentially 50% more defects than we were shipping before. So you really just want to understand what side of this graph you’re on. You want to start measuring this stuff, right? Um this pattern exists without AI, by the way. This has a lot to do, it’s not purely causal with AI. A lot of this has to do with like your release pipeline, your automated testing, everything that’s surrounding the way that you’re releasing the code. The pattern remains the same. The amplitude has changed as a result of AI. We always see this type of

[05:52] shift in volatility, but not usually to these extremes. And that’s the AI effect that we’re seeing right there. Here’s a really interesting one. These are two qualitative quant uh uh quality metrics uh that normally are sort of in sync with one another. Code maintainability, how how maintainable dovel developers perceive the code to be in terms of making changes to it. That number has gone up almost 4% according to our data. By the way, we’re looking at about 200,000 engineers in this study to gather this data. The uh co the change

[06:24] confidence though, which traditionally we’ve seen closely associated with code maintainability. Hey, this code is maintainable. It’s modular. It’s easy to modify. I feel good about the changes that I’m pushing into production. Nope. Our change confidence number has gone down 6%. This is really an interesting tension because it means like, okay, agents and assistants are making it easier for me to understand and modify the code that’s in front of me, but I trust the outputs less. I’m more afraid now of breaking things than I was a year ago. So, it’s an interesting

[06:54] psychological effect that we see here. And a lot of this is because PR size is measurably increasing. This is going to be one of the most important metrics that we look at this year. Hasn’t quite doubled, but look at that trajectory, right? This is over the same period of study about a year and we’ve seen PRs go from uh around 44 lines on average per PR up to 72. Now there’s there’s a number of reasons for this. It’s not just, you know, the likelihood that the way that these models work is that they’re be being trained to output

[07:25] relatively mediocre code. I’ve been writing code professionally since the late 90s. I remember when it was a great mark of a developer to be able to implement the same use case with as little code as possible. Now, it’s like, well, no, let’s get the thing out. And, you know, the code that’s being generated is going to be essentially mediocre because it’s law of averages. But on top of that, too, think about if you’ve got a build pipeline that takes 45 minutes or an hour to complete and now I’ve got AI generating functions for me instantly. Am I going to push four different PRs with four different functions and wait 45 minutes or an hour

[07:55] or whatever that is per build or I’m just going to cram all that code into a single PR? Right? So there’s multiple reasons for this, but it really bears mentioning that like every extra line of code is a potential bug, a potential vulnerability. It’s more to review. It makes the code less portable. So we need to pay attention to this metric as well because we’re also seeing this associated with perception of incremental delivery. I get to work on small incremental changes and this is actually one of the lowest qualitative developer experience drivers that we’ve seen impacted over the last year. This number and this sentiment has gone down

[08:26] 10%. And incremental delivery is awful is is as we’ve learned also very important for uh for the way that we try to deliver in a way that’s easy to roll back uh and where we can understand and review the changes that are being pushed through. [snorts] Okay. Uh what about demographic differences? Uh what is different about AI impacts across like you know junior devs and stuff like that? Junior engineers are using AI the most. This really should surprise nobody. anytime we have sort of a new leap again writing

[08:58] code professionally since the late 90s I’m a bit of an OG I’m on this journey too but there’s less to unlearn when you’re coming into the industry right in many many cases you’ve already been working with this kind of stuff like right out of school and so you’re more likely to implement it uh when you actually start working now we’ve seen some other trends there too uh we have interesting ways of looking per use case at efficiency uh which I’ll get into in the second talk later today and one of those is looking at agent experience

[09:28] like literally we’re we’re asking agents about their experience working with humans. We’re trying to figure out what use cases uh are they working on and how many tokens did they spend. And definitely we also see a trend where the more junior developers for the same use case will spend more tokens than a more senior developer on the same use case. And that’s just a learning curve, right? Again, that should surprise nobody. But in terms of who’s using it the most, we do see juniors using it the most. However, despite that additional use, we see staff plus or more senior engineers saving about the same amount of time,

[10:00] right? And and burning less tokens. I want to make sure that that’s kind of clear too. So in terms of like raw time savings in the aggregate output of this, it’s pretty flat between junior engineers who are using the tech more and staff engineers who have an easier time spotting hallucinations, understanding the architecture around the changes they’re making and things like that. Smaller companies lead in time savings. Sure, you know, the release pipelines are going to be less complicated. You know, there’s less overall complexity in the organization. uh that’s going to uh lead to more time savings for a company

[10:32] that already has less friction and has a little bit more agility to it than a larger company. What about measurement? How should we be even be thinking about measuring this stuff? I mean, it bears mentioning that that measuring developer productivity and measuring developer experience was a challenge before AI and we we never completed that conversation before kind of throwing accelerant on this. Right? So, this is still a difficult thing and I’d argue even more difficult to do now because it’s confounded by several different aspects of of AI, but we’re

[11:04] all going to have to answer this question this year, right? Spent 10 million or way more if you come to my talk later today on tokens. Uh where’s our 10x productivity? When we’re thinking about this stuff, it’s important to bear in mind that we don’t throw away what we’re measuring, right? our foundational developer experience and developer productivity metrics are still what matter the most, right? We want to understand how a AI is impacting these trusted metrics that we’ve already been looking at. Like we want to maybe look at cohorts of users.

[11:35] We maybe want to take data from the API telemetry and things that come out of the tools and use that to understand who’s using what and where. But we would only want to use those cohorts and look at them comparatively across our foundational metrics. What is this actually doing to quality? What is this actually doing to speed? What is this doing to impact to the organization and value generation? And so this is where our AI measurement framework comes from. I won’t spend too much time on this. We have a big white paper available. Uh my colleague Anton who’s standing in the back of the room in the the white shirt will be able to

[12:07] hand out some hard copies of reports that we have after the talk that go into the way that we derive this methodology and how to use it and think about it. Um it focuses on three key dimensions of measurement. So looking at utilization, our daily active users, weekly active users, that sort of thing. Uh it looks at impact. So which metric should we be, you know, looking for moving the needle based on utilization? Uh as our utilization goes up, what do we hope to see in terms of impact to the business? And then cost. It’s a fair joke that we’re 15 years after the last major hype

[12:37] cycle and we’re still trying to figure out cloud cost, but the stuff is getting pretty expensive. We’re going to have to measure it. Um so you can think about this as a bit of a maturity curve as well. Most people start with utilization on the left. Just figuring out what’s happening in the organization with the tech, who’s using it, what are they using, how often, and for what use cases. And then how do we then cross reference those to the impact metrics, the value generation, what we really want to understand to know whether these investments are actually working, which is what we really want to figure out. This is just an example of how we might correlate such a thing. So you could

[13:08] look at two separate cohorts of users and you could compare them across metrics like PR cycle time or PR size or push back and review. Right? So lots of uh the way to think about this again is to right now separate cohorts and then look at how that plays out across these foundational productivity metrics that we’ve learned to trust. We also need to able be able to understand our platform’s readiness. I like to say that in 2024 we gave everybody a coding assistant. In 2025 we started building agents. Now, we’re realizing that our infrastructure wasn’t ready for any of

[13:39] this. A lot of the vendors that are here are are are selling solutions that help you with this problem. Um, I think if you can measure your platform’s AI readiness, you’re going to have a much better handle on how efficient you’re going to be spending tokens and providing context to these agents. So, these are things like clear and accurate, well structured documentation, data structures with straightforward relations, manageable modular code, reliable local CI and non-flaky test suites. If by the way any of this sounds familiar to you, it’s because we used to just call this good developer experience, right? But it turns out that

[14:10] what’s good for humans is also good for agents. So we may finally paradoxically be making those investments that we should have been making over the last couple of decades. We also want to understand the effectiveness of the way that we work with AI. And this is one way of doing that. What you’re actually seeing here is feedback, qualitative feedback coming back from agents telling us where they ran into issues with steering with the human. the the context that was provided for them, the the feedback cycles that they had to go through. So, we’re actually getting that data from the agents to try to figure out how effective our teams are at

[14:41] working with AI. And we can break this down into use cases, which is very important, too. We want to understand which use cases are giving us the most efficient token spend. And again, moving the needle for value creation and productivity within the business. Finally, the fifth trend, integrating across the SDLC and PDLC. Why would we want to do this? Because code generation was never the bottleneck in the first place, right? Even if engineers are getting like 100% accurate instant code coming from the models, which they are not, you would still only be attacking

[15:11] anywhere from maybe 14 to 16% of the overall value stream. So we need to think beyond that. Uh especially because right now the productivity gains that we are actually seeing are more modest than expected. Despite additional PR throughput uh increases, our median increase in the study that we did from November to to 2024 to February this year only found about a median 7.7% increase in this velocity metric, a 13% average, but even our top performers were in the 70% range. Nobody hit 2x,

[15:42] nobody hit 5x, nobody hit 10x. And that’s because our time savings that come out of AI are still being outweighed by other nonAI factors within our organization, right? Right? We might be saving a lot of time with AI and that’s great. But if we’re still eclipsing those time savings because of meeting heavy days and context switching and other sources of interruption, the cumulative effects of the dev environment and friction in the way that we create software around the code, then we’re not attacking the bottleneck. And as Ellie Goldroat from the theory of constraints and the goal and uh inspire

[16:13] inspiration for the Phoenix project would tell us that an hour saved on something that isn’t the bottleneck is worthless. And so we need to find the bottleneck and fix the bottleneck. And that’s what a lot of organizations are doing. Morgan Stanley has been really public about their creation of the DevGen AI agent, which is an agent for interpreting legacy code like uh mainframe natural and cobalt. And I hate to admit Pearl. I’ve written a lot of Pearl in my career, but it’s legacy now. The agent actually creates PRDS to hand to engineers to get rid of that reverse engineering step. And it’s saving Morgan

[16:44] Stanley about 300,000 hours a year right now. Zapier is one of my favorite stories in AI right now. They have a whole agent ecosystem that they’re using to deal with a lot of administrative tasks and overhead like daily standups and things like that. They’ve reduced their standups by using a agent summaries and things like that in this ecosystem that they’ve built to two times a week as opposed to five times a week. They’re successfully onboarding engineers within about a twoe period which is really fast. Our industry benchmark for that is over a month usually. But my favorite part about this

[17:15] story is that they’re seeing about a 15% additional value creation per engineer. So they are hiring more than they have in the history of their entire company because they realize the truth here that they’re getting more capacity per single engineer. They’re getting a better return on investment per single engineer and hiring more engineers will improve their competitive edge. This is the right attitude. This is a throughput story. This is an increased innovative capacity story. This is not a headcount replacement story. Fair. uh they’re automating about 3,000 of their code

[17:45] reviews a week triggered off of a pull request and um they look at superficial stuff. They still need humans in the loop, but the initial superficial uh uh review that comes from the agent is all part of the system of record. It stays in the PR comments and so the next engineer to actually perform the review will have an idea of what the agents already looked at. So it can save some time. Finally, Spotify, if anybody remembers the Spotify model from DevOps, they were sort of the northstar for DevOps. uh they built an agent for S SRRES that will gather remediation steps

[18:16] from runbooks and information and context about the incident and put all that together into SR communication channels so that when an incident occurs the S sur has uh immediate context and doesn’t have to go through multiple minutes of discovery uh to figure out how to solve the issue. So, if you want to dive deeper into this data, our Q2 report is coming out in just a few weeks. Uh, but the Q1 report still has a lot of tidbits from this session in it. And if you subscribe to our newsletter or you come back to the website, by midish end of July, we’ll have our Q2 report. And if you want to see a preview

[18:47] of that report, that’s the talk that I’m giving later this afternoon. Thanks everybody for your time. I appreciate it. >> [music] [music]