IA assinou o atestado de óbito do Agile

O Agile sempre prometeu uma coisa: entregar código mais rápido. Ciclos curtos, feedback constante, iteração contínua. E funcionou, por um tempo, para um contexto. Mas sempre teve um efeito colateral que a comunidade tratou como custo aceitável: o código produzido sob pressão de sprints de duas semanas frequentemente envelhece mal. A sustentabilidade de longo prazo era sacrificada em prol da velocidade de entrega.

Agora a IA gera código mais rápido que qualquer sprint. E ironicamente, cria exatamente os mesmos problemas que o Agile criava, só que numa escala absurdamente maior.

O gargalo nunca foi escrever código

Essa é a parte que ninguém gosta de ouvir e porque o Agile já era fonte de tanta crítica.

O Agile inteiro foi construído em cima de uma premissa que podia até fazer sentido: que o gargalo da entrega de software é a produção de código. Sprints, story points, velocity: tudo gira em torno de otimizar o throughput de código escrito por humanos.

Mas em 2026 esta óbvio para geral que este não é o verdadeiro gargalo. Qualquer equipe com acesso a um agente de IA produz código numa velocidade que torna sprints de duas semanas quase cômicos.

O que o Agile e a IA têm em comum

Ambos otimizam a produção e negligenciam a compreensão.

O Agile te fazia entregar rápido, mas a pressão dos sprints frequentemente significava menos tempo para documentação, menos tempo para refactoring, menos tempo para entender de verdade o que estava sendo construído. O resultado? Sistemas que funcionavam no curto prazo mas que eram verdadeiras esculturas de gelo.

A IA faz a mesma coisa, só que pior. Um agente produz código que parece perfeito, compila, passa nos testes, até segue boas práticas do projetp. PRs estão crescendo em tamanho e complexidade. O tempo que seniores gastam em code review explodiu. Mas a confiança dos desenvolvedores no output de IA continua baixa. Como vários estudos recentes apontam, código gerado por IA acumula dívida técnica numa velocidade que desenvolvedores humanos simplesmente não conseguem igualar.

O Problema da IA

A base de código cresce, a compreensão não acompanha, e em algum momento você está mantendo um sistema que ninguém na equipe realmente entende. Não é um cenário hipotético. Está acontecendo agora. Dois experimentos mentais para tornar isso concreto. E nos vamos ser generosos com a IA.

Suponha que pré-IA, escrever código tenha representado 50% de todo o esforço necessário para entregar uma feature. Entender o problema, discutir requisitos, projetar a solução, escrever o código, testar, revisar, deployar, monitorar. Metade disso era implementar o código. Agora imagine que os agentes reduzam esse pedaço para zero. O trabalho total cai no máximo pela metade. No máximo. A outra metade do trabalho continua intacta. E aqui está o ponto: o Agile foi projetado para otimizar a metade que está desaparecendo. Ninguém tem um framework para a outra metade. A metade que sobrou.

Agora o segundo, mais perverso. Vamos ser extremamente generosos e assumir que a IA é realmente nível PhD. Que ela produz código com uma densidade de bugs dez vezes menor que a sua equipe. Espetacular, certo? Só que ela também produz código cem vezes mais rápido. Faz a conta. O resultado líquido? Dez vezes mais bugs no sistema.

A velocidade aumentou. A compreensão piorou.

Então como as equipes estão resolvendo isso na prática?

Essa é a pergunta que me interessa de verdade. Não as teorias, não os produtos. O que as equipes estão fazendo para criar confiança no código que está sendo gerado em velocidade industrial?

Porque é isso que está acontecendo: times inteiros estão tendo que reinventar seus processos de trabalho em tempo real. O playbook antigo: escrever código, abrir PR, fazer review, mergear, não foi projetado para o volume e a velocidade do código agêntico.

Algumas coisas que estão surgindo:

O review virou o trabalho principal, não o complementar. Antes, code review era o que você fazia entre tasks. Agora é a task. As equipes que estão funcionando bem tratam revisão como atividade primária.

IA revisando IA, com humano no topo. Ferramentas de IA estão criando uma camada intermediária: a IA faz um primeiro review mecânico e o humano foca no que importa: lógica de negócio, decisões de arquitetura, sustentabilidade. Não é perfeito, mas libera bandwidth humano para o que só humanos conseguem avaliar.

Novas abordagens para PRs: Na prática, a maioria dos times tem experimentando com dois modelos opostos.

O primeiro: nenhum review no PR. Zero. Em vez disso, validação brutal no pipeline testes de regressão exaustivos, análise estática pesada, tudo automatizado. Se passa, mergeou. O review humano acontece depois, no delta entre releases: quando chega a hora de lançar, o time para e revisa a diferença acumulada entre a última versão e a nova. O custo é encontrar problemas tarde demais.

O segundo: mini PRs encadeados. Nenhum diff acima de 100 linhas. Em vez de abrir um PR com uma feature inteira, você (ou seu agente, claro) fatia em mudanças minúsculas e encadeadas. Cada uma é trivial de revisar, tanto por humanos quanto por IA. O custo é mais overhead de processo.

As duas abordagens funcionam melhor que o modelo anterior. As duas têm problemas. Ainda não sei qual escala melhor. Mas o fato de estarmos experimentando com modelos tão diferentes diz algo sobre o momento: o processo antigo quebrou e ninguém tem certeza do que vai substituí-lo.

Documentação antes do código. Essa é a que dá o golpe final no Agile.

Lembra do segundo valor do Manifesto Ágil? "Working software over comprehensive documentation." Software funcionando vale mais que documentação abrangente. Por trinta anos, isso virou justificativa para não documentar quase nada. "O código é a documentação." "Se precisa de comentário, o código não está claro." A gente repetiu isso como mantra.

Em equipes que trabalham com agentes, a documentação de design e intenção está se tornando mais importante que o código em si. O "source of truth" não é mais o código, é o documento que descreve o que o código deveria fazer e por quê. Quando você pode jogar fora a implementação e regenerar a qualquer momento o que tem valor durável é a especificação: os requisitos, a arquitetura, as decisões de design, os trade-offs, os porquês, os testes de aceitação.

Pensa nisso por um segundo. O Manifesto Ágil dizia que software funcionando era o artefato primário. Agora software funcionando é o que qualquer agente produz em minutos. O artefato o que exige inteligência humana é justamente o que o Agile nos mandou desvalorizar: a documentação.

Métricas de compreensão, não de volume: "commits por dia" e "linhas de código" já eram métricas horríveis antes da IA. Todo mundo sabia. Todo mundo media assim mesmo. Mas agora não são apenas métricas ruins, são lixo puro. E lixo perigoso. Qualquer bagre com acesso a um agente gera dez mil linhas de código por dia.

As métricas que importam agora são todas sobre confiança e sustentabilidade do sistema: taxa de falha em deploy, tempo médio de resolução de incidentes, change failure rate e coisas desse tipo.

O processo inteiro está mudando.

Enquanto escrevia isso, a Linear concorrente do Jira, acabou de declarar que issue tracking está morto. O timing é quase poético.

O argumento é direto: issue tracking foi construído para um modelo de handoff. PM define o escopo, engenheiro pega depois, e o sistema enche de priorização, negociação e workflows para cobrir o gap entre os dois.

Se o Jira e o Kanban definiram o processo de desenvolvimento de software para uma geração inteira, me pergunto o que vem depois. E não me refiro a uma ferramenta me refiro ao processo em si. A forma como equipes decidem o que construir, como validam o que foi construído, como criam confiança no sistema.

Porque o modelo de handoff não sobrevive quando o agente pode ir da issue ao PR em minutos. Não faz sentido um PM escrever uma issue detalhada, um engenheiro ler essa issue dois dias depois e aí pedir pro agente planejar a implementação e executar. O ciclo inteiro precisa comprimir. A pergunta é: comprimir para o quê?

Linear aposta que o próximo sistema é construído em torno de contexto e agentes, não de handoffs. Que o que importa é capturar intenção, feedback, decisões e deixar agentes transformarem isso em execução. Talvez estejam certos. Talvez estejam vendendo a ferramenta deles com narrativa bonita. Provavelmente os dois ao mesmo tempo.

Mas a provocação é válida: se issue tracking, Kanban boards e sprint planning foram os artefatos de processo de uma era onde produzir código era caro e lento, quais são os artefatos de processo de uma era onde produzir código é barato e instantâneo? Ninguém sabe. E quem diz que sabe deveria mesmo estar lançando produto.

O que vem depois

O Agile nasceu de uma frustração legítima com processos pesados que não entregavam código. Morreu porque a IA entregou código na velocidade que ele sempre prometeu. E mostrou que entregar código nunca foi o problema de verdade.

O problema sempre foi entender o que estamos construindo e por quê. Nenhum sprint resolveu isso. Nenhum agente vai resolver. Isso continua sendo trabalho nosso.