Eu me considero “agilista” desde os tempos do RUP. Sim, aquele RUP: iterativo no papel, mas tão cerimonioso que precisava de um documento para explicar os outros documentos. Foi a minha porta de entrada para a ideia de que software se constrói em ciclos, e de lá para cá acompanhei o Manifesto Ágil virar Scrum, Scrum virar “Scrum, mas…”, e Kanban virar a coisa que a gente faz quando cansa de Scrum.
Agora tem um agente de IA sentado na minha mesa escrevendo código mais rápido do que eu consigo ler. E a pergunta que não sai da minha cabeça é: os rituais que eu defendi durante vinte e tantos anos ainda fazem sentido?
Para responder isso eu precisei de um modelo mental e de uma volta no tempo. Tenha paciência comigo.
Quatro pontas de um diamante
O Harold Leavitt, lá em 1964, descreveu uma organização como um diamante com quatro pontas: estrutura, tarefas, pessoas e tecnologia. O detalhe importante do modelo não são as pontas, são as setas entre elas. Está tudo interligado: mexeu numa, as outras se mexem junto, querendo ou não.
Em desenvolvimento de software a gente costuma simplificar isso para um triângulo de pessoas, processos e tecnologia. É nesse triângulo que a nossa conversa acontece. A IA mexeu, e muito, na ponta da tecnologia. Não dá para fingir que as outras duas vão ficar paradas no lugar. E como as pessoas continuam sendo as mesmas (por enquanto), a ponta que mais vai sentir o tranco é a dos processos.
E processo, em software, sempre foi uma história sobre uma coisa só.
Sempre foi sobre feedback
Em 1959 a gente (a gente = programador e não eu, que nem era nascido 😛) programava em COBOL no estilo code and fix, sem método nenhum. Deu tão certo (#sqn) que em 1968 a OTAN precisou convocar uma conferência para inventar o termo “engenharia de software” e tentar colocar ordem na bagunça. Veio o Waterfall em 1970, o Modelo Espiral do Boehm em 1988, o RUP em 1999 e, em 2001, o Manifesto Ágil como reação a tudo isso.
Se você olhar essa linha do tempo de longe, percebe que ela conta uma história só: a briga contra o feedback tardio. O Waterfall congelava requisitos no início e só descobria que estava tudo errado na homologação, quando mudar ou corrigir alguma coisa custava uma fortuna. O Boehm desenhou uma curva mostrando que o custo de mudar cresce exponencialmente conforme o projeto avança: uma correção barata na fase de requisitos vira um pesadelo em produção. O Ágil foi, essencialmente, a decisão de encurtar os ciclos para pegar os erros enquanto ainda estavam na parte baixa dessa curva.
Guardem essa curva. Ela vai voltar.
O gargalo mudou de lugar
Durante toda a história que eu contei acima, escrever código era a parte lenta. Revisar era rápido, testar era relativamente rápido, discutir em reunião era… bom, reunião é reunião. Mas o trabalho pesado ficava na digitação. Estimativas, sprints de duas semanas, story points, tudo isso foi calibrado para um mundo em que o esforço de produzir era o esforço dominante.
O Armin Ronacher chamou o que aconteceu de “The Final Bottleneck”: a IA inverteu a relação e agora escrever é mais rápido do que revisar. O Avery Pennarun (apenwarr) foi mais longe e argumentou que cada camada de aprovação multiplica o tempo por 10, porque a IA acelera a produção mas não acelera a revisão. E não é só impressão: o relatório da Faros AI sobre o “paradoxo da produtividade” mostra quase o dobro de PRs abertas e o tempo de revisão crescendo na mesma proporção. Produzimos mais e entendemos na mesma velocidade de antes.
Aí vem a provocação: se um agente implementa uma feature em duas horas e a revisão leva cinco, o que exatamente estamos estimando no planning? A pergunta “quanto tempo para implementar?” perdeu relevância. A pergunta que importa virou “quanto tempo para garantir que isso está correto?”. Tem gente na AWS defendendo que o sprint planning deveria evoluir para algo como intent design: em vez de estimar tarefas, o time define intenção, guardrails e critérios de sucesso, e deixa a implementação para quem agora é rápido nela. Eu não sei se o nome vai pegar, mas a ideia de que o planning deixa de ser sobre esforço e passa a ser sobre intenção me parece certa.
Vale lembrar:
“Computadores são inúteis, eles só sabem dar respostas”. — Pablo Picasso
Se a IA dá respostas muito rápido o trabalho de fazer as perguntas certas e conferir se a resposta faz sentido continua sendo nosso, e ele não ficou nada mais rápido.
A curva de custo, de novo
Voltemos à curva do Boehm. Eu sempre gostei do argumento de que pair programming é a forma mais barata de revisão que existe, porque a validação acontece no exato momento em que o código nasce, lá na parte baixa da curva. O code review tradicional acontece bem mais à direita, quando a mudança já está pronta e o autor já foi fazer outra coisa.
Com IA, o “par” passou a ser humano mais agente, e o custo desse pareamento é praticamente zero. A dinâmica inverteu: o humano vira o navigator permanente (revisa, direciona, decide) e o agente vira o driver (digita, implementa). O Kent Beck chama isso de augmented coding: você escreve o teste, a IA gera a implementação, você valida. A validação é reposicionada no ponto mais barato da curva. Para mim esse é o ponto de virada de toda a discussão.
O problema é o que acontece do lado direito da curva. Se o volume de código gerado é impossível de revisar no ritmo em que chega, o revisor cai no dilema que chamam de cognitive debt: ou mantém o rigor de antes e vira o gargalo do time, ou aprova no ritmo que o código aparece e torce para os testes pegarem o que a revisão deixou passar. Nenhuma das opções é boa.
E aqui tem uma coisa que a gente costuma esquecer: code review nunca foi só sobre achar defeito. Era o jeito de distribuir conhecimento sobre o codebase, alinhar decisões de arquitetura, fazer sêniors ensinarem júniors e vice-versa. Era o jeito de manter um modelo mental (aka contexto) compartilhado de como o sistema funciona. Se a máquina escreve o código e a máquina também revisa, quem é responsável? E, mais importante, como o time aprende? Aquela ideia de collective code ownership do XP não se sustenta se ninguém do time leu o código.
E o “como o time aprende” não é preocupação de um programador velho rabugento gritando para a nuvem. Um estudo da Anthropic sobre formação de habilidades com IA mostrou que quem delega passivamente (pede o código, cola, segue em frente) sai com menos de 40% de compreensão do que foi feito, enquanto quem usa a IA para investigar conceitos passa dos 65%. A mesma ferramenta produz um profissional que aprende ou um que só delega, dependendo de como o processo em volta dela é desenhado. Mais um cenário onde o processo pode se tornar um problema.
Isso muda até a definição de pronto. “Done” deixou de ser “funciona e passou nos testes” e passou a ser “funciona, eu entendo por que funciona e sei o que monitorar”. O Casey West, no Agentic Manifesto, descreve como a passagem de verificação (fez o que eu disse?) para validação (fez o que eu queria?). E o pessoal da Mozilla AI aponta que a nossa cultura sempre ligou ownership a autoria; a IA quebra esse vínculo, e agora você precisa ser dono de algo não porque você escreveu aquilo mas porque você entende aquilo.
Pelo mesmo raciocínio, o WIP limit do Kanban precisa mudar de dimensão. Não adianta limitar quantas tarefas estão “em andamento” se um agente consegue mover dez delas para essa coluna ao mesmo tempo. O limite relevante virou “quantas mudanças o time consegue entender simultaneamente”. O projeto OpenClaw, com suas 2.500 PRs abertas, é o que acontece quando a entrada cresce mais rápido que a capacidade de processar: uma falha acumulativa.
O que levar desses questionamentos?
A IA não torna os processos obsoletos. Ela torna os processos errados mais perigosos, porque agora o erro é produzido em escala industrial.
O gargalo se deslocou de escrever para compreender e validar, e os rituais precisam acompanhar esse deslocamento. A daily deixa de ser “o que eu fiz” e passa a ser “o que eu entendi sobre o que foi feito”. A retrospectiva, que sempre foi o ritual mais negligenciado, virou na minha opinião o mais importante de todos: é o único momento formal em que o time para e pergunta “qual código gerado a gente não entende? que decisões técnicas o agente tomou sem a gente validar?”.
Também vale um alerta. Tem gente dizendo que documentação e specs agora importam mais que o código, porque viraram o insumo do agente. Pode ser. Mas se a resposta para tudo for “escreva uma spec bem detalhada antes de começar”, cuidado: isso tem nome, e o nome é Waterfall. Mais spec na frente não é sinônimo de mais controle. O que separa uma spec útil de um documento de requisitos de 1970 não é o tamanho dela, é o tamanho do ciclo até o primeiro feedback: se a spec alimenta um agente que devolve algo testável em uma hora, ótimo, isso é Ágil com outra ferramenta; se ela precisa estar “completa e aprovada” antes de qualquer código existir, é a curva do Boehm de novo, só que com um capítulo novo. Vinte anos para matar o Waterfall e seis meses para a IA trazê-lo de volta seria um final meio irônico para essa história.
O Ágil precisa evoluir, não ser abandonado. E o jeito mais barato de começar é o mesmo de sempre: revisando as suas práticas, uma por uma, e perguntando se elas ainda estão otimizando o gargalo certo.
Deixei de fora várias práticas que também merecem essa revisão (TDD, CI/CD, prototipação, demos, refactoring) desse texto porque ele já entrega o ferramental para refatorar os seus processos. Uma lista mais extensa pode ser encontrada nos slides da minha apresentação na Codecon 2026.
