Acelerar a produção de código sem alterar o restante do processo não acelera a entrega; acelera a chegada de problemas em produção. A velocidade de uma equipe de desenvolvimento não é medida pela rapidez com que escrevem código, mas pela rapidez com que conseguem fazer alterações com segurança, e esses dois aspectos têm se dissociado cada vez mais nos últimos dois anos.
É um fenômeno comprovado, não uma mera suspeita.
O relatório DORA 2024 do Google Cloud, que entrevistou cerca de 39.000 profissionais, descobriu que um aumento de 251% na adoção de IA estava correlacionado com uma queda em 1,5% em capacidade de entrega e de 7.2% em estabilidade. A explicação oferecida pelos próprios autores não é que o código seja pior, mas sim que o tamanho dos lotes de alterações está aumentando: mais alterações são enviadas de uma só vez, são revisadas com menos rigor e são implementadas com mais riscos.
O estudo METR de julho de 2025 adicionou uma camada extra de complexidade. Em um teste controlado com 16 desenvolvedores experientes em 246 tarefas do mundo real, os participantes levaram 191 TP3Ts a mais usando assistência de IA, embora esperassem ser 241 TP3Ts mais rápidos e, após o teste, ainda acreditassem ter sido 201 TP3Ts mais rápidos. Vale ressaltar que o próprio METR revisou esse desenho do estudo em 2026 para verificar um possível viés de seleção, e uma coorte maior mostrou uma diferença muito menor: o resultado exato ainda está em debate.
O que não está em discussão é a descoberta secundária, e esta é a mais importante para qualquer direção a ser tomada: A percepção da velocidade e a velocidade real são coisas distintas.. Uma equipe pode ter a sensação de estar avançando muito mais rápido, mesmo que o sistema demore mais para chegar à produção.
A dimensão da alteração é a variável oculta por trás da maioria dos problemas de implementação. Uma pequena alteração é minuciosamente revisada, totalmente testada, implementada rapidamente e, se falhar, a causa pode ser identificada em minutos. Uma grande alteração não permite nada disso.
Variável | Troco | Grande mudança |
|---|---|---|
Qualidade da avaliação | Está perfeitamente compreendido. | «"Parece razoável"» |
Cobertura de testes | Verificável | Parcial na prática |
Tempo de diagnóstico em caso de falha | Minutos | Horas ou dias |
Custo da reversão | Baixo | Pare: Isso está arrastando outras coisas junto. |
Risco de implantação | Limitado | Acumulado |
Até recentemente, o esforço de escrever código funcionava como um limite natural para o tamanho dos lotes de alterações. Com a remoção desse limite, o tamanho dos lotes aumenta, a menos que alguém decida explicitamente restringi-lo. Essa decisão — limitar o tamanho das alterações — é provavelmente a intervenção mais eficaz em termos de custo disponível para uma equipe de desenvolvimento atualmente.
Medir linhas de código, tarefas concluídas ou "produtividade por desenvolvedor" piora ativamente a situação, pois recompensa justamente o comportamento que causa o problema. As quatro métricas DORA continuam sendo o padrão razoável:
Frequência de implantação. Com que frequência um produto é colocado em produção? Alta frequência implica em lotes pequenos.
Prazo de entrega da alteração. Desde o momento em que é escrito até entrar em produção. Mede todo o processo, não apenas a escrita em si.
Alterar a taxa de falhas. Qual a porcentagem de implantações que resultam em incidentes? Este é o contraponto à velocidade.
Tempo de restabelecimento do serviço. Quanto tempo leva para se recuperar? Isso mede a capacidade real de operação.
Os dois primeiros indicadores medem a velocidade, os dois últimos a estabilidade, e devem ser considerados em conjunto. Uma equipe que melhora os dois primeiros, mas piora os dois últimos, não melhorou: simplesmente transferiu o trabalho para o futuro e para a equipe de suporte.
Limitar a magnitude das alterações. A medida mais simples e eficaz. Ela força a divisão do trabalho em unidades compreensíveis e restaura a qualidade da revisão.
Invista em testes antes de priorizar a velocidade. À medida que mais código é gerado, a rede de segurança se torna ainda mais importante. Sem testes confiáveis, o controle de desempenho é uma aposta recorrente.
Automatize a implantação e o rollback. Se a implementação for cara, a equipe acumulará alterações até que valha a pena, e o lote grande será devolvido.
Meça a estabilidade com a mesma visibilidade que a velocidade. Se o painel de controle do comitê mostrar apenas as entregas, a equipe otimizará as entregas.
Não recompense a velocidade isolada. Os incentivos geram comportamento. Se o que é enviado for celebrado em vez do que é suportado, mais será enviado e menos será suportado.
Existe, em muitos comitês, a expectativa de que o auxílio da IA se traduza em entregar o dobro no mesmo prazo. Essa expectativa é o que gera a pressão que mina a estabilidade.
A conversa franca tem duas partes. Primeiro: a geração de código realmente acelerou de forma real e mensurável. Segundo: a entrega é um processo mais amplo — que envolve compreensão, revisão, teste, integração, implantação e operação — e só acelera quando todo o pacote é considerado.
Traduzido para uma frase que funcione em um conselho: Reduzimos o custo de uma parte do processo, não do processo inteiro.. Aproveitar essa melhoria exige investir no restante, e não exigir o dobro.
Essa é a mesma conclusão alcançada da perspectiva arquitetônica, e é por isso que o debate voltou ao projeto em vez da execução, como discutimos em O gargalo é, mais uma vez, a arquitetura.
Isso acelera a geração de código, mas não necessariamente a entrega. O relatório DORA de 2024 constatou que um aumento de 25% na adoção de IA correlacionou-se com uma queda de 1,5% na produtividade e uma queda de 7,2% na estabilidade, atribuídas ao aumento no tamanho dos lotes de alterações.
Porque determina a qualidade da revisão, a abrangência real dos testes, o tempo necessário para diagnosticar uma falha e o custo de reversão. O esforço de escrever o código atuava como um limite natural de tamanho; sem esse limite, ele precisa ser explicitamente restringido.
As quatro métricas DORA são: frequência de implantação, tempo de entrega de alterações, taxa de falha de alterações e tempo de restauração do serviço. As duas primeiras medem a velocidade e as duas últimas medem a estabilidade; elas devem ser analisadas em conjunto.
Um estudo METR de 2025 mediu um atraso de 19% em desenvolvedores experientes que esperavam acelerar o processo até 24%. Posteriormente, a própria METR revisou o desenho do estudo em busca de possíveis vieses, e uma coorte maior mostrou uma diferença menor. A conclusão consistente é que a velocidade percebida e a velocidade real divergem.
Testes automatizados confiáveis, implantação e reversão automatizadas e um limite explícito para o tamanho das alterações. À medida que o volume de alterações aumenta, a rede de segurança e a capacidade de reversão tornam-se mais importantes, e não menos.
Porque recompensam o comportamento que causa o problema: produzir mais volume sem garantir que ele chegue à produção de forma confiável. O incentivo determina o comportamento, e medir a produção em vez dos resultados transfere o custo para o suporte e as necessidades futuras.
Sua equipe entrega mais rápido ou apenas produz mais? Analisamos todo o processo de entrega — revisão, testes, implementação e operação — e indicamos onde está o verdadeiro gargalo. Vamos conversar →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
