Do Lado de Quem Constrói — Uma Coluna do Maycon Santos
Enquanto a IA torna a produção quase gratuita, a palavra pronto silenciosamente começa a significar duas coisas diferentes — e a que ela deixa de significar é a que entrega trabalho digno de confiança.
“Há um momento em que a maioria dos times de entrega chega sem perceber acontecer: a definição de pronto deixa de ser aplicada, porque o trabalho corre mais rápido do que qualquer pessoa volta a revisá-la.”
Marcamos uma tarefa como pronta numa terça-feira. Os testes passaram, a demo funcionou, o revisor aprovou, e movemos o card para a direita. Na terça seguinte, dois de nós estávamos reconstruindo boa parte dela, porque aquilo que chamamos de pronto dava conta do caminho feliz e de quase nada mais. Ninguém cortou caminho de propósito. A gente simplesmente nunca combinou o que pronto era pra significar antes de declarar. Foi a última vez que deixamos essa pergunta sem resposta.
Pronto É Duas Palavras Vestindo Um Único Rótulo
É tentador ler isso como um problema de teste, ou de code review, e corrigir com uma barreira mais rígida no pull request. É o diagnóstico errado. O que aconteceu de fato foi que a palavra pronto carregava dois significados diferentes, e a gente havia parado de perceber a diferença. Há pronto no sentido de produzido: o código existe, roda, se parece com a coisa. E há pronto no sentido de verificado: o trabalho foi checado contra uma definição do que precisava fazer, e ele se sustenta. Não são o mesmo estado. Durante boa parte da história do software, ficaram próximos o suficiente pra serem tratados como um só, porque produzir código era lento o bastante pra produção e verificação andarem no mesmo ritmo.
Essa é a suposição que a IA quietamente quebrou. Quando um engenheiro trabalhando com IA produz numa tarde o que antes levava três dias, a produção acelera e a verificação não. A definição de pronto, que antes acompanhava o trabalho porque o trabalho era lento, agora fica pra trás dele. E uma definição que fica pra trás não interrompe o trabalho. Só deixa de ser aplicada. Pronto derrapa, sprint após sprint, de verificado contra o que combinamos para parece pronto, porque parece pronto é a parte que a IA barateou, e verificado é a parte que ela não barateou.
Isso não é um efeito pequeno, e agora aparece no jeito como a indústria se mede. No relatório de 2025 sobre desenvolvimento de software assistido por IA, o DORA constatou que a adoção de IA começou a elevar a throughput de entrega, os times realmente estão entregando mais, enquanto continua a correlacionar com maior instabilidade: mais falhas de mudança, mais retrabalho, tempo maior pra recuperar quando algo quebra[1]. A mudança foi consequente o bastante para o DORA adicionar uma nova métrica central, Rework Rate, a parcela de deploys que existem só pra consertar o que um deploy anterior errou. Leia com clareza. A indústria acabou de tornar retrabalho um número de primeira classe, porque o trabalho crescentemente parece pronto e depois precisa ser feito de novo. Lido descuidadamente, isso parece um argumento contra a IA. Não é. É um argumento sobre o que acontece com uma definição de pronto quando o trabalho para de esperar por ela.
A Lacuna É Algo Que os Times Já Sentem
Já vi isso acontecer em times que eram, por qualquer medida visível, disciplinados. Escreviam tickets. Revisavam pull requests. Tinham uma definição de pronto escrita numa página de wiki em algum lugar. A página não era o problema. O problema era que a definição vivia num documento, e o trabalho corria mais rápido do que qualquer pessoa voltava ao documento, então pronto virou uma decisão de julgamento tomada no momento por quem estava fechando o ticket.
As pessoas que fazem o trabalho sentem a lacuna mesmo quando não sabem nomeá-la. Na pesquisa de desenvolvedores do Stack Overflow de 2025, uma das maiores do tipo com mais de quarenta mil respondentes, a adoção de ferramentas de IA subiu para 84%, enquanto a parcela de desenvolvedores que confia na acurácia do que essas ferramentas produzem caiu para 33%, e mais desenvolvedores agora ativamente desconfiam dessa produção, 46%, do que confiam nela[2]. A mesma pesquisa constatou que a razão mais comum pela qual desenvolvedores ainda recorreriam a outro ser humano, apontada por 75% deles, é justamente quando não confiam na resposta da IA[2]. Fica com isso. Um time pode adotar uma ferramenta quase universalmente, se recusar a confiar na maioria do que ela produz, e ainda assim mover o card para pronto, porque pronto passou a significar o código está aqui e roda, não o código foi checado contra o que devia entregar e se sustenta. A lacuna de confiança é a lacuna de definição, aparecendo como sentimento.
A Lentidão Era um Portão Acidental
Aqui está a distinção que a maior parte da cobertura perde, porque está ocupada discutindo se a IA escreve código bom ou ruim. A qualidade do código gerado não é o mecanismo. O mecanismo é que a produção lenta funcionava como um portão acidental. Quando construir levava três dias, você tinha três dias pra lembrar o que a coisa deveria fazer, pra notar o caso de borda, pra sentir o desconforto que significa ainda não. Aquele portão nunca foi projetado. Era um efeito colateral de as coisas serem lentas, e discretamente aplicava uma definição de pronto que ninguém precisava escrever. A IA removeu a lentidão, e com ela o portão acidental, e expôs que a definição por baixo nunca foi de fato estrutural sozinha.
Então este é um diagnóstico de estrutura ausente, não da IA, e a diferença é o argumento inteiro. Quando a definição de pronto é explícita e checável antes de o trabalho começar, quando pronto nomeia condições específicas que o trabalho precisa satisfazer e alguma coisa diferente do julgamento humano cansado pode confirmar essas condições, então a produção barata vira exatamente o que você quer. Cada unidade quase gratuita de trabalho aterrissa contra uma barra que não se move, é checada contra ela, e ou passa ou volta. A velocidade se compõe em trabalho concluído em vez de acumular retrabalho. IA estruturada não é a opção lenta e cautelosa. É IA mirada numa definição de pronto que foi decidida antes de o gatilho ser puxado.
Decida o Que Pronto Significa Antes de o Trabalho Começar
Então se você lidera entrega, a pergunta que precisa parar de fazer é se o time está entregando mais rápido. Quase certamente está, a velocidade é real, e não é a coisa com que se preocupar. A pergunta que precisa começar a fazer é onde a sua definição de pronto realmente mora, e quando ela é aplicada. Se a resposta honesta é que pronto é decidido no momento, por quem está fechando o ticket, contra um padrão reconstruído da memória depois de o trabalho já existir, então você não tem uma definição de pronto. Você tem um rótulo que gruda no trabalho depois que ele parece concluído. A correção não é mais uma etapa de revisão parafusada no fim. É decidir, por escrito e em termos checáveis, o que pronto significa antes de o trabalho começar, para que a velocidade tenha algo fixo em que aterrissar. Depois que movemos a definição pra frente, a velocidade parou de trabalhar contra nós e começou a se compor.
O risco nunca foi a IA escrever o código errado. É chamar algo de pronto antes de decidir o que pronto tem que significar. Resolva isso primeiro, e velocidade vira conclusão em vez de movimento.
Fontes
- DORA (Google Cloud). State of AI-assisted Software Development 2025. 2025. https://dora.dev/dora-report-2025/
- Stack Overflow. 2025 Developer Survey, AI section. 2025. https://survey.stackoverflow.co/2025/ai
Data de verificação: 11/06/2026. Cada número foi confirmado, presente e correto, na fonte citada nessa data. As duas fontes foram publicadas nos doze meses anteriores, conforme a seção 12.3 do MKT_Article_Standard.