Daniel Epstein, Partner Tech Strategist na Microsoft, escreveu algo em maio de 2026 que a maioria dos times correndo atrás de modelos melhores vai ler rápido demais. As falhas que eles continuam encontrando quando agentes constroem software em escala não vêm do modelo. Vêm de um processo que está faltando. A frase dele é direta: “Isso não é um problema de modelo; é um problema de processo. Atualizar o modelo não resolve critérios de aceitação faltando.” Depois vem a parte que deveria fazer o leitor parar: “Um agente mais capaz trabalhando contra uma spec ambígua produz uma deriva mais sofisticada, não menos.”
Essa segunda oração inverte o instinto sobre o qual a maioria dos líderes está operando. O plano de todo mundo é esperar o próximo modelo, plugar e ver os problemas de qualidade se dissolverem. Epstein está dizendo que o oposto acontece. Quanto mais inteligente o executor, mais convincentes ficam suas respostas erradas. A governança precisa morar em algum lugar onde a atualização do modelo não consiga contornar. Ele a coloca no backlog.
Um Modelo Melhor Piora uma Spec Frouxa
Pense no que um agente mais capaz de fato faz com a ambiguidade. Ele não pausa para perguntar. Ele preenche o espaço, e preenche com mais competência do que o modelo anterior tinha. Um agente mais fraco, recebendo uma história vaga, produzia lixo óbvio, do tipo que um revisor pegava em trinta segundos porque parecia errado. Um agente mais forte, recebendo a mesma história vaga, produz algo que parece certo, compila limpo, passa nos testes que ele mesmo escreveu e viola em silêncio uma invariante que ninguém anotou.
É por isso que “esperar o próximo modelo” não é estratégia de qualidade. A capacidade eleva o teto da saída e o teto da deriva plausível ao mesmo tempo. O que mantém os dois separados é a especificação. Epstein é preciso nisso: “Agentes operam contra especificações, não contra prompts abertos. Cada história define entradas, saídas e invariantes.” Um agente não é um colega que compartilha o seu contexto. É um executor cujo mundo inteiro é o artefato à frente dele. Se esse artefato diz o que deveria acontecer mas não o que nunca pode acontecer, o agente trata o silêncio como permissão.
Então a restrição não é o raciocínio do agente. É a precisão do item de trabalho contra o qual o agente raciocina. E precisão não é uma propriedade do modelo. É uma propriedade do processo. Você a escreve, você a versiona, você a aplica.
A Governança É uma Propriedade do Backlog
Aqui está o movimento que Epstein faz e que o reenquadramento companheiro do Agile para agentes não faz. Ele não diz apenas para manter seus contratos. Ele diz onde esses contratos têm que morar: dentro da própria história, como critérios de aceitação, antes de qualquer agente tocar no trabalho.
A maioria dos times trata governança como ponto de checagem. Construa a coisa, depois passe por um revisor que verifica violações de arquitetura, exposição de segurança e invariantes quebradas. A frase de Epstein mirada exatamente nesse hábito merece ser impressa e colada acima do quadro: “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.”
Leia isso como uma ordem de realocação. Uma restrição de segurança que vive na cabeça de um revisor, ou num wiki, ou num checklist de revisão final, é uma restrição que o agente nunca viu enquanto trabalhava. O agente já derivou. A revisão só conta o quanto. Mova essa mesma restrição para os critérios de aceitação da história, escrita como uma invariante que o agente precisa satisfazer para chamar o trabalho de pronto, e ela vira algo contra o qual o agente executa, em vez de algo que um humano descobre depois do fato. A história deixa de ser um pedido. Vira a superfície de governança.
Isso é concreto, não filosófico. Cada card no quadro carrega seu próprio portão. “Não pode escrever na tabela legada.” “Precisa preservar o contrato de API existente para os chamadores da v1.” “Precisa rejeitar entrada que falha na validação de schema em vez de forçá-la.” Esses não são comentários de revisão. São entradas na história, presentes antes da primeira linha de código, visíveis ao executor o tempo todo.
CI É a História Um, os Portões de Revisão Ficam Entre as Ondas
Epstein sustenta o princípio com uma falha que ele viveu, e essa é a parte mais útil do artigo porque é um erro, não uma teoria. No projeto Minthe dele, o pipeline de CI não foi a primeira história construída. Veio depois. Quando o portão automatizado passou a existir, problemas de qualidade já tinham se acumulado por várias ondas de trabalho, e funcionalidades tiveram que ser reabertas e reconstruídas contra o padrão que o pipeline finalmente passou a impor. A lição que ele tira é inequívoca: a infraestrutura de validação, CI/CD, linting, testes automatizados, deveria ser a primeira história que você implementa, não a última.
O raciocínio decorre direto do argumento da deriva. Se a governança só funciona quando fica à frente do agente, então a maquinaria que impõe governança precisa existir antes de o agente produzir qualquer coisa que valha a pena governar. Construa o portão, depois construa através dele. Um time que entrega seis ondas de funcionalidades e só então adiciona CI tem seis ondas de saída desprotegida para reauditar. Um time que entrega o CI como onda zero tem um padrão contra o qual toda onda posterior é medida na chegada.
A mesma lógica explica por que os portões de revisão ficam entre as ondas de entrega em vez de no finalzinho. O fluxo de Epstein roda Plan, Issue, Implement, Review, Merge, Docs, com o contexto persistente do agente guardado em arquivos do repositório como .github/copilot-instructions.md, CLAUDE.md e STYLE.md, e um ponto de revisão depois de cada onda em vez de uma inspeção final única. A deriva acumula. Pegá-la depois da onda dois custa uma onda de retrabalho. Pegá-la depois da onda seis custa cinco. Um portão entre cada onda mantém o raio de explosão em um único incremento, e mantém os arquivos de contexto persistente honestos, porque cada revisão é uma chance de apertar as regras que a próxima onda herda.
O Que Isso Significa para Qualquer Time Adotando Agentes
O formato do conselho é geral, mesmo que a evidência de Epstein seja o projeto de um engenheiro. Ele é franco em dizer que isto é uma peça de metodologia, não um estudo. Não há benchmarks aqui, nem percentuais, nem comparação controlada. É o primeiro de uma série planejada, ancorado no trabalho dele no Minthe e na prática de colegas. Trate como uma hipótese bem argumentada de dentro da Microsoft, não como prova medida.
O que sobrevive a essa ressalva é a estrutura, e a estrutura viaja. Qualquer time colocando agentes em trabalho real herda a mesma física. A ambiguidade é preenchida pelo executor. Um executor mais capaz a preenche de forma mais convincente. Restrições descobertas na revisão são restrições descobertas tarde demais. O remédio não depende de qual modelo você roda nem de qual fornecedor você compra. Depende de se seus itens de trabalho carregam suas próprias invariantes e de se seu portão existe antes da sua saída.
Isso generaliza para além do código também. Um briefing de marketing, um formulário de intake jurídico, uma spec de pipeline de dados: cada um é um item de backlog contra o qual um agente executa, e cada um pode carregar seus critérios de aceitação na frente ou expor suas violações na revisão. A disciplina é idêntica, e é a mesma que traçamos na deriva de governança da automação e na inversão organizacional dos times que deletaram suas dailies. A única pergunta é se você escreve a restrição no card ou paga para descobri-la depois.
Faça Isso Agora
Abra seu backlog de agentes e escolha a próxima história que você planeja atribuir. Antes de ela sair, acrescente três linhas: uma invariante que o trabalho precisa preservar, uma coisa que ele nunca pode fazer, e uma evidência concreta que prove as duas. Depois cheque um fato sobre o seu setup, se o seu portão de CI roda antes de essa história mergear ou depois. Se o portão roda depois, você acabou de encontrar a sua verdadeira primeira história, e não é a funcionalidade que você ia construir. É o pipeline que deveria ter sido entregue antes de todas elas.
Para o reenquadramento mais amplo de quais práticas Ágeis sobrevivem à era dos agentes, leia a peça companheira: Agentic-Agile: Contratos, Não Cerimônias.
Fontes
- Daniel Epstein (Microsoft). “Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts).” Maio de 2026.
A Victorino ajuda equipes a mover a governança para cima, para dentro de como o trabalho de IA é especificado e revisado: 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