Err@r rápido na era da GenAI: o gargalo mudou de lugar
Com IA, tarefas por dev subiram 34% e a mediana do tempo em revisão de PR, 441,5%. O gargalo mudou de lugar — agora o que precisa correr é a detecção do erro.
Falhe rápido. Você já ouviu essa frase mil vezes. Eu já disse essa frase mil vezes. E continuo achando que ela está certa. Só que ela deixou de apontar para o mesmo lugar.
O que precisa ser rápido mudou. E quem não percebeu isso não está errando rápido. Está errando em escala.
Deixa eu voltar no tempo: entender onde essa ideia nasceu explica tudo o que veio depois. O falhe rápido nasceu numa economia em que produzir era caro e errar era barato. Escrever código levava semanas, e a única forma de não queimar dinheiro era descobrir o erro cedo.
Em janeiro de 2001, Barry Boehm e Victor Basili publicaram na IEEE Computer o número que virou lei: encontrar e corrigir um problema depois da entrega custa, com frequência, 100 vezes mais do que corrigir nas fases de requisitos e de design. E o mesmo texto faz a ressalva que quase ninguém repete: em sistemas pequenos e não críticos, o fator cai para 5 para 1. Os dois também estimaram que de 40% a 50% do esforço de um projeto é retrabalho evitável. Esse número vem de projetos dos anos 1970 e 1980. É dado antigo, e eu uso porque ele explica de onde veio a nossa crença.
Presta atenção no 5 para 1: é a licença para experimentar. Em 1999, Kent Beck abriu o Extreme Programming Explained com a hipótese que sustentava tudo aquilo: “sob certas circunstâncias, a curva exponencial do custo de mudança ao longo do tempo pode ser achatada”. Em 2011, Eric Ries deu nome de produto à ideia no The Lean Startup: não é falhe rápido, é falhe barato. E o loop dele tem três etapas: construir, medir, aprender. A frase dele é literal: todo processo de startup que funciona é aquele que acelera esse ciclo de feedback.
Guarda essa frase. Ela é o centro deste texto.
A GenAI mexeu em uma variável só: barateou o construir. Gerar código, protótipo, proposta, análise ficou quase de graça, e rápido. Medir e aprender continuaram no ritmo humano. É isso que desanda o loop.
Pensa numa fábrica: multiplica por dez a velocidade da linha e mantém a mesma esteira de inspeção. O que sai do outro lado não é dez vezes mais produto. É uma fila de coisa não conferida.
É o que os dados de 2026 mostram. A Faros AI analisou dois anos de telemetria de 22 mil desenvolvedores em 4 mil times, comparando times de baixa e de alta adoção de IA. A conclusão de tarefas por desenvolvedor subiu 34%. Os bugs por desenvolvedor, 54%. E o portão de entrada do código? A mediana do tempo em revisão de pull request subiu 441,5%. A espera até a primeira revisão cresceu 156,6%. O tempo entre o commit e a produção, 480,4%. E 31,3% mais pull requests passaram a ser mergeados sem nenhuma revisão.
Produzir acelerou. Conferir, não. E quando o portão entope, o time faz a única coisa que pode: abre o portão. Não é descuido de quem programa. É fila.
Eu já trouxe esses indicadores aqui no canal, no segundo texto da série. Em 2025, a mesma empresa tinha medido 91% de alta no tempo de review e 9% de alta nos bugs por desenvolvedor, num estudo de julho de 2025. Um ano depois, os mesmos indicadores estão em 441,5% e 54%. Isso não é um pico. É uma direção: o gargalo mudou de lugar e continua se movendo.
Aqui está o dado que me fez escrever este artigo. A Veracode testou mais de 100 modelos de linguagem em 80 tarefas de geração de código, em quatro linguagens. Em 45% das tarefas, o modelo introduziu uma vulnerabilidade que está no OWASP Top 10. Em Java, a taxa de aprovação em segurança foi de cerca de 28,5%: mais de 70% de falha. E o relatório, publicado em julho de 2025 (modelos de 2023 a meados de 2025), registra que isso não melhorou conforme os modelos ficaram mais novos.
Lê esse último ponto de novo. O erro não desaparece quando o modelo melhora. Ele fica mais bem escrito. Então esperar o próximo modelo não é plano. É fé. O plano é detectar.
Só que detectar ficou mais difícil, porque o erro mudou de cara: ele já não chega com cara de erro. Chega com cara de certeza.
Um trabalho apresentado na EMNLP em 2025 mediu isso em experimento controlado: entre 16% e 43% das alucinações que acontecem mesmo quando o modelo sabe a resposta vêm acompanhadas de alta certeza. Com prompt adversarial, o número vai de 18% a 46%. São uma fração pequena do total de alucinações, de 0,3% a 2,1%, e é justamente por isso que são perigosas: poucas, confiantes e sem cara de erro. Em setembro de 2025, pesquisadores da OpenAI propuseram uma explicação: a alucinação persistiria porque treino e avaliação premiam o chute em vez de premiar a admissão de incerteza. É hipótese. Mas o efeito prático é o mesmo: parte da confiança que você lê na tela é o próprio erro.
A Stack Overflow ouviu 49 mil desenvolvedores em 177 países na edição de 2025 do seu survey. A maior frustração, citada por 45% deles, é lidar com “soluções de IA que estão quase certas, mas não exatamente”. E 66% estão gastando mais tempo justamente consertando código de IA quase certo. A confiança na acurácia dessas ferramentas caiu de 40% para 29%. A adoção subiu para 80%. A gente usa mais e confia menos.
Porque o erro quase certo é o mais caro que existe: erro evidente você rejeita em cinco segundos; erro plausível entra, passa pela revisão, vai para o cliente e aparece três semanas depois, quando já tem gente em cima.
E quem paga essa conta é gente. Na pesquisa da Sonar com 1.149 desenvolvedores (campo em outubro de 2025), 96% disseram não confiar plenamente que o código gerado por IA seja funcionalmente correto. Apenas 48% revisam sempre o código assistido por IA antes do commit. 95% gastam algum esforço revisando, testando ou corrigindo saída de IA. E 38% dizem que revisar código de IA dá mais trabalho do que revisar código de um colega humano, contra 27% que dizem o contrário. A percepção do problema ainda varia com a estrada de quem lê: 66% dos desenvolvedores com até 10 anos de carreira já viram código de IA que parecia correto e não era confiável, contra 48% entre os com 20 anos ou mais.
Repara no que isso significa para quem lidera: o ganho de produção entrou no relatório, o custo da revisão não. Ele ficou no colo do time, e no seu.
Tem uma coisa que quase ninguém quer olhar de frente: sem medição, o time não sabe se está acelerando. Um ensaio randomizado da METR acompanhou 16 desenvolvedores experientes em 246 tarefas reais, de janeiro a junho de 2025. Com IA liberada, as tarefas levaram 19% mais tempo. Os mesmos desenvolvedores tinham previsto ganho de 24%; depois de viver o estudo, continuaram estimando ganho de 20%. Erro de percepção de quase 40 pontos percentuais. Em fevereiro de 2026, a METR voltou com números melhores (18% de ganho, com intervalo de confiança de 38% de ganho a 9% de perda), e os próprios autores avisam que aquele dado é evidência fraca, por viés de seleção. Trago os dois porque o ponto não é quem está certo sobre a IA. É que sensação e medição não são a mesma coisa.
O DORA, que mede entrega de software há anos, fecha o raciocínio na edição de 2025, com cerca de 5 mil profissionais ouvidos. 90% usam IA no trabalho e mais de 80% dizem que ela aumentou a produtividade. Mas 30% relatam pouca ou nenhuma confiança no código gerado. E, diferente de 2024, a adoção de IA passou a ter relação positiva com o volume entregue, mantendo relação negativa com a estabilidade da entrega. O aviso está escrito no próprio relatório: sem sistemas de controle robustos, como teste automatizado, versionamento maduro e ciclos de feedback rápidos, aumento de volume vira instabilidade.
Antes de fechar, o dado que joga contra o que eu escrevi. Um estudo com 300 engenheiros, ao longo de um ano (setembro de 2024 a agosto de 2025), registrou queda de 31,8% no tempo de ciclo de revisão de pull requests depois da adoção de uma plataforma interna de IA. Existe caso em que a revisão ficou mais rápida, não mais lenta. Eu não vou esconder isso. Mas vou ler o caso inteiro: o estudo descreve geração de código e revisão automatizada implantadas juntas, dentro de uma plataforma única, com o mesmo time medindo tudo ao longo de um ano. Isso não fecha a minha tese sozinho. Reforça o ponto central, que não é sobre a IA. É sobre o instrumento de detecção. Onde ele existe, o ciclo encurta. Onde falta, o ciclo vira fila.
Então voltemos ao começo. O falhe rápido não foi revogado. Ele mudou de lugar. Quando produzir era caro, errar rápido significava testar barato e mudar de rumo antes de gastar. Agora produzir é barato e o erro também, só que o erro vem em volume, vem com cara de acerto e chega mais rápido do que a sua capacidade de conferir. O que ficou caro foi descobrir. O que ficou lento foi aprender com o que foi descoberto.
Por isso eu digo que o falhe rápido de hoje tem outro alvo: detecção e retorno. Detecção é o teste que roda sozinho, é o dado que mede a entrega, é a definição de pronto que ninguém negocia na véspera. Retorno é a cadência de olhar o que voltou e mudar o plano. Sem os dois, o seu ciclo não está rápido. Está só cheio.
E aí eu te devolvo a pergunta: no seu time, quanto tempo leva entre um erro entrar no código e alguém descobrir que ele entrou? Se a resposta for “não sei”, você acabou de encontrar o seu gargalo novo. Me conta nos comentários. Eu leio e respondo.
Este é o quarto texto da série Agilidade com Dados. Se você chegou agora, comece pelo primeiro: A fábrica invisível.