Daniel Epstein, Partner Tech Strategist na Microsoft, publicou um artigo em maio de 2026 defendendo que o desenvolvimento de agentes precisa de Agile. Não de prompt engineering. Não de modelos melhores. Agile. Issues com critérios de aceitação. Portões de revisão. Arquivos de instrução persistentes. Backlogs spec-first. A Microsoft chegou a publicar um repositório de template para operacionalizar a posição.
Lido ao lado do caso da PFF do mesmo mês, o argumento parece dar curto-circuito. A PFF deletou as dailies, o sprint planning, o refinamento, as retrospectivas e o papel de product manager. Dois engenheiros com agentes superaram um time de dez. Então qual é a resposta: o Agile sobrevive à era dos agentes ou não?
Os dois, porque Agile nunca foi uma coisa só.
Agile Sempre Foi Duas Coisas
Releia qualquer retrospectiva do Manifesto Ágil de 2001 e você encontra um rótulo único cobrindo duas máquinas muito diferentes ligadas no mesmo cabo.
A primeira é a pilha de coordenação. Dailies, sprint planning, refinamento, retrospectivas, demo days, gráficos de capacidade. Todo artefato dessa camada responde a uma pergunta sobre humanos: quando você está livre, o que está te bloqueando, quanto trabalho uma pessoa consegue segurar na cabeça por quatorze dias, como evitamos que o time queime. A pilha de coordenação é ergonomia. Otimiza a atenção humana escassa, lenta e opinativa para que um grupo pequeno de engenheiros consiga entregar software coerente sem se atropelar.
A segunda é a pilha de contrato. Issues com critérios de aceitação, definition of done, documentos de design, contratos de API, especificações de teste, checklists de revisão, arquivos de instrução persistentes. Todo artefato dessa camada responde a uma pergunta sobre o trabalho em si: o que essa mudança significa, como sabemos que está correta, o que não pode quebrar, o que precisa continuar verdadeiro depois do merge. A pilha de contrato é especificação. Codifica intenção com precisão suficiente para que outra pessoa, inclusive uma versão futura de você mesmo, execute sem ambiguidade.
Por vinte anos as duas pilhas pareceram uma só porque rodavam dentro da mesma cerimônia. A daily atualizava a coordenação e expunha lacunas no contrato ao mesmo tempo. A retro melhorava a coordenação e apertava contratos na mesma reunião. Separar as duas era desnecessário. Os agentes tornaram a separação necessária.
Por que os Agentes Derrubam a Pilha de Coordenação
Hora de engenheiro deixou de ser o recurso escasso.
Essa frase única é a história inteira. Cobrimos a evidência operacional em uma análise recente sobre a PFF e a inversão organizacional. Mike Spitz, CTO da Pro Football Focus, rodou um experimento de três meses no começo de 2026 em que dois engenheiros com agentes enfrentaram dez engenheiros sem eles. O time de dois entregou 25 vezes mais deploys, 10 vezes mais complexidade ponderada de tickets, e elevou o CSAT de uma linha de base de 7.5 para 8.6. No caminho, deletaram o papel de PM, o sprint planning, as dailies, o refinamento e as retrospectivas. A reunião curta de meia hora em dias alternados foi tudo que sobrou.
Isso é o que acontece quando o recurso que uma cerimônia protegia se torna abundante. A daily otimiza uma restrição, a velocidade de digitação humana coordenada entre agendas, que não vincula mais quando uma frota de agentes roda em paralelo. A pilha de coordenação não quebra de forma dramática. Ela simplesmente deixa de pagar o aluguel. As cerimônias viram teatro, e os líderes que continuam rodando por inércia estão pagando salário para manter rituais que protegiam uma restrição que se moveu.
Por que os Agentes Amplificam a Pilha de Contrato
O oposto é verdadeiro para a segunda pilha.
Epstein diz direto: “Isso não é um problema de modelo; é um problema de processo. Atualizar o modelo não resolve critérios de aceitação faltando.” O projeto Minthe que ele tocou expôs o modo de falha em um nível de detalhe que os entusiastas de prompt raramente encaram. Múltiplos agentes rodando em paralelo derivaram uns dos outros. O comportamento divergiu da spec. O código parecia correto isoladamente e incoerente no agregado. A única fonte estável de verdade que sobreviveu ao caos foi o tracker de issues do GitHub, onde os critérios de aceitação eram explícitos o bastante para ancorar cada agente de volta a uma definição única de pronto.
A razão é estrutural. Um engenheiro humano com um ticket vago faz uma pergunta, puxa o PM para o corredor, ou simplesmente toma uma decisão de bom senso baseada em anos de contexto sobre o produto. Um agente com um ticket vago inventa uma resposta. Ele não tem contexto compartilhado fora do artefato à frente dele. O artefato é o contrato. Se o contrato é frouxo, o agente preenche a folga com asneira plausível que compila, passa nos próprios testes e entrega regressão.
A outra frase de Epstein, a que vale imprimir e colar na parede: “Se você está pegando violações de arquitetura na revisão final em vez de durante a execução da história, sua governança chegou tarde.” Essa é a pilha de contrato dita como governança. Os critérios de aceitação, as restrições arquiteturais, os arquivos de instrução persistentes no repositório, os portões de revisão entre Plan, Issue, Implement, Review, Merge e Docs no template da Microsoft. Cada um desses artefatos move a intenção arquitetural de “revisão final” para “execução da história”, onde o agente pode de fato obedecer.
A pilha de contrato costumava ser um coadjuvante silencioso. Agora é a única coisa segurando o trabalho.
O Movimento: Promova a Camada de Contrato, Não Recoloque Cerimônias
O erro que a maior parte dos líderes está prestes a cometer é ler Epstein, entrar em pânico com os problemas de coerência que o Minthe expôs, e reparafusar a pilha de coordenação em cima de uma frota de agentes. Dailies com agentes. Sprint planning com agentes. Retros em que alguém apresenta métricas de agente. É movimento desperdiçado. A pilha de coordenação resolvia uma restrição que sumiu. Reinstalá-la não ajuda os agentes nem ajuda os humanos.
O movimento certo é o oposto. Promova a pilha de contrato a status operacional de primeira classe. Trate critério de aceitação com a seriedade que uma geração anterior reservou ao sprint planning. Faça dos arquivos de instrução persistentes artefatos versionados que circulam por pull request como código. Tire restrições arquiteturais do conhecimento tribal e coloque-as em regras legíveis por máquina que governam execução, não revisão. O diagrama de fases que a Microsoft entrega no template, Plan para Issue para Implement para Review para Merge para Docs, não é um fluxo que você adota porque parece arrumado. É um fluxo que você adota porque cada transição é um ponto onde a validação de contrato pode ser aplicada antes que a deriva acumule.
Dito de outra forma: o Agile não sobreviveu à era dos agentes. A metade contratual do Agile sobreviveu, e ela agora carrega a carga que a metade de coordenação dividia.
Isso Generaliza Para Além da Engenharia
A mesma decomposição aparece em todo lugar em que o modelo operacional começa a incluir agentes.
Times de marketing estão descobrindo que o briefing de campanha é o novo contrato. Onde uma analista júnior costumava preencher os espaços em branco com instinto de marca, um agente preenche com o que o briefing permite. Um briefing frouxo produz uma campanha tecnicamente dentro da spec e fora da marca. O briefing de marketing costumava ser o ponto de partida para uma conversa entre humanos. Está virando um artefato vinculante, o tipo que merece os mesmos portões de revisão que os engenheiros aplicam a decisões arquiteturais.
Times jurídicos estão rodando a mesma jogada. O formulário de intake de caso, o memo de deal, o documento de orientação para redlines. Costumavam ser contexto para uma associada humana. Estão virando o contrato que governa o que um agente pode minutar, marcar em vermelho ou escalar. Escritórios que investem em apertar artefatos de intake estão se distanciando dos demais. Escritórios que tratam intake como overhead administrativo estão vendo a saída do agente derivar para passivo.
Times de design são os próximos, e o artefato de contrato lá é o próprio design system. Um design system costumava ser um guia. Está virando a camada de regras que um agente operando no canvas precisa respeitar. Os times tratando seu design system como contrato versionado vão começar a parecer muito diferentes dos times que ainda o tratam como documentação.
A linha que atravessa os três é a mesma linha que traçamos na engenharia. O briefing é o contrato. O contrato é a superfície de governança. O agente é o executor. Promova a camada de contrato ou aceite a deriva.
Faça Isso Agora
Escolha uma frente de trabalho que já tem agentes operando. Engenharia serve. Campanhas de marketing, intake jurídico ou enforcement de design system funcionam igualmente bem.
No próximo sprint ou na próxima semana, faça exatamente uma coisa: pegue o artefato que o agente trata como fonte de verdade, seja um ticket, um briefing, um formulário de intake ou um arquivo de tokens do design system, e reescreva com critérios de aceitação completos. Não só “o que deveria acontecer”, mas “o que não pode acontecer”, “o que precisa continuar verdadeiro depois do trabalho concluído” e “o que conta como evidência”. Depois, faça todo agente rodar gate contra esse artefato antes de mergear, publicar ou protocolar.
Você vai descobrir em uma semana quais dos seus contratos estavam frouxos o suficiente para o agente estar preenchendo a folga com invenção. Essa descoberta vale mais do que mais um trimestre de debate sobre se o Agile está vivo. A pilha de contrato é o que você mantém. Tudo o resto está em renegociação.
Fontes
- Microsoft Developer Blog (Daniel Epstein). “Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts).” Maio de 2026.
- Microsoft / GitHub. “agentic-agile-template.” Maio de 2026.
A Victorino ajuda times de operação a promover a camada de contrato do trabalho com IA sem recriar cerimônias que não pagam mais o aluguel: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa