Do Agile ao Agentic Operating Model · Capítulo 10 de 19 · 21 min
O contrato que define sucesso antes de o agente escrever código
Quem escreve o critério de aceite mantém o controle da entrega.
Este capítulo faz parte do curso gratuito Do Agile ao Agentic Operating Model.
Delegar uma tarefa a um agente sem dizer por escrito o que conta como pronto entrega duas coisas de uma vez: a execução e o critério de aprovação. A execução você quer delegar mesmo. O critério é o que paga a conta quando o resultado sai errado e ninguém consegue apontar onde. O que está em jogo é dinheiro que vaza por comportamento incorreto aprovado numa revisão apressada, e prazo que estoura no retrabalho. A decisão que cabe a você é uma só: quem assina o critério de aceite antes de o trabalho começar. Escrever esse critério pode ser delegado a qualquer pessoa competente, ou até ao próprio agente; aprová-lo continua sendo seu.
Glossário rápido
TDD (Test-Driven Development)
Desenvolvimento guiado por teste. A regra é escrever o teste do comportamento desejado antes do código que realiza esse comportamento.
Teste vermelho
O teste que falha porque o comportamento ainda não existe. Ele descreve o alvo antes de alguém mirar.
CI (continuous integration, integração contínua)
O servidor que roda a bateria de verificações a cada mudança enviada e devolve aprovado ou reprovado, sem depender de alguém lembrar de rodar.
PR (pull request)
O pacote de mudança que alguém propõe ao código principal. Passa por revisão antes de ser incorporado.
Commit
Um registro de alteração salvo no histórico do sistema, com autor, data e a lista do que mudou. É a unidade de trabalho que o histórico guarda, e vários commits formam um PR.
Diff
A diferença entre o antes e o depois de uma alteração, mostrada linha a linha, com o que saiu marcado de um jeito e o que entrou de outro. Revisar por diff é ler apenas o que mudou, sem reler o sistema inteiro.
Prompt
O texto de instrução entregue ao agente: o que ele deve fazer, o que não pode fazer e em que formato responder. Prompt de sistema é a camada fixa dessas instruções, que vale para todas as tarefas daquele agente.
Produção
O sistema no ar, atendendo clientes reais. Quando o curso diz "em produção", leia "na frente do cliente", onde o erro custa cliente e não apenas uma correção.
Spec (especificação)
O documento que descreve a intenção, as restrições e o que fica deliberadamente de fora do escopo.
Raio de dano (blast radius)
O alcance do estrago quando a mudança falha: quantos clientes, quanta receita, qual dado e por quanto tempo. É a régua que gradua quanta prova cada entrega precisa carregar.
Regressão
Comportamento que funcionava e parou de funcionar depois de uma mudança. É o custo escondido de toda entrega rápida.
A aula sobre o que exigir antes de aprovar fixou a prova da entrega; falta decidir quem define o sucesso antes de ela começar.
Por duas décadas o debate sobre escrever teste (um roteiro que confere o combinado, como a vistoria da obra) antes do código, o método que a sigla TDD nomeia, foi resolvido pela economia: teste primeiro consome tempo de gente cara. O agente (programa que executa a tarefa sozinho, como um estagiário com procuração) inverteu o sinal dessa conta.
Escrever a implementação passou a custar minutos. Aceitar a implementação errada ficou caro, porque saída de modelo probabilístico compila, roda e faz a coisa errada com aparência de acerto. Sobra um ponto de controle: o critério escrito antes, que vale independentemente de quem executou a tarefa.
O critério de aceite da obra
Ninguém contrata uma reforma pedindo que a cozinha fique melhor. O contrato lista medidas, materiais, prazos e o que caracteriza entrega recusada. O pedreiro escolhe como assentar; o que conta como pronto foi escrito antes, por quem paga. O teste vermelho ocupa esse mesmo lugar no trabalho com agentes: descreve o resultado aceitável antes de qualquer produção começar.
Onde a analogia para de valer: obra tem inspeção presencial e ritmo humano. Um agente produz mudança rápido demais para inspeção item a item, então o critério de aceite precisa ser executável por máquina, além de legível por gente.
Quando você dirige milhares de linhas de geração de código, precisa de uma forcing function que obrigue você a entender o que está sendo construído.
A mesma tarefa delegada, com e sem contrato escrito antes
Sem critério escrito antes
Evitar
- O sucesso é definido depois, olhando o que o agente entregou
- A revisão vira leitura de diff, e diff limpo costuma passar
- Quem aprova precisa reconstruir a intenção de memória
- Comportamento incorreto aparece na fatura ou no cliente
Com critério escrito antes
Recomendado
- O sucesso está escrito antes de o agente começar
- A primeira camada de revisão roda por máquina, em segundos
- Quem aprova compara entrega contra contrato
- Comportamento incorreto é recusado antes de entrar no código principal
Tech lead de um squad de checkout
Varejo online
Dor
Regra nova de cupom de desconto, prazo curto e ninguém disponível para ler 240 linhas de código linha a linha.
Solução
Antes de abrir o agente, escreveu em 12 minutos três testes que falhavam: cupom expirado recusado com código próprio, total zerado sem cobrança emitida e total nunca negativo.
Resultado
O agente entregou em 9 minutos e dois dos três testes falharam. Cupom expirado devolvia sucesso com desconto zero, e cupom de valor fixo acima do carrinho produzia total negativo. O diff estava limpo, tipado e comentado: passaria numa revisão humana comum.
Custo apurado: 12 minutos de contrato contra um erro de cobrança em produção.
Cenário construído para fins didáticos. Números não correspondem a cliente específico.
Os três testes do caso acima, em linguagem de negócio
| O que o teste exige | Por que ele existe | O que passa despercebido sem ele |
|---|---|---|
| Cupom vencido é recusado, e a recusa informa que o motivo foi o vencimento | A tela mostra mensagens diferentes para cupom vencido e para cupom sem desconto aplicável | O desconto some sem explicação, o cliente não entende o que houve e a conversa vira chamado no atendimento |
| Carrinho que fecha em zero não gera cobrança nenhuma | Cobrança de R$ 0,00 é uma transação como qualquer outra para a operadora de pagamento | A empresa paga taxa por transação em cobranças de valor zero, e isso só aparece na fatura do mês seguinte |
| O total nunca fica negativo, qualquer que seja o cupom | Cupom de valor fixo maior que o carrinho subtrai abaixo de zero se ninguém escrever o piso | O sistema devolve dinheiro que ninguém pagou |
Os três cabem numa conversa de doze minutos e nenhum deles exige ler uma linha de código. Escrever a coluna da esquerda é o trabalho que não se delega; traduzi-la para teste automatizado é execução, e pode ir para o próprio agente.
// Os três foram escritos ANTES de qualquer implementação, e os três
// falham agora: é isso que define o alvo.
// Leia expect(X).toBe(Y) como "exijo que X seja exatamente Y".
it("recusa cupom vencido informando o motivo", () => {
const r = aplicarCupom(carrinho(200), cupom("PROMO10", {
expiraEm: "2026-06-30",
}), new Date("2026-07-01"));
expect(r.ok).toBe(false);
expect(r.erro).toBe("CUPOM_EXPIRADO"); // recusar sem motivo não basta
});
it("não emite cobrança quando o total fecha em zero", () => {
const r = aplicarCupom(carrinho(50), cupomFixo(50));
expect(r.total).toBe(0);
expect(r.cobrancas).toHaveLength(0);
});
it("nunca produz total negativo", () => {
expect(aplicarCupom(carrinho(50), cupomFixo(80)).total)
.toBeGreaterThanOrEqual(0);
});No caso do cupom, o responsável técnico do squad gastou 12 minutos escrevendo três testes e pegou dois defeitos que o diff limpo esconderia numa revisão comum. Numa empresa, a pergunta que decide isso é de propriedade, antes de ser de metodologia: quem é dono de cada etapa quando um agente ocupa o meio do ciclo. São sete etapas, e o humano fica nas pontas.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
Quem é dono de cada etapa do ciclo
| Etapa | O que acontece | Dono |
|---|---|---|
| Intenção | Problema, restrições e o que fica fora do escopo | Produto ou fundador |
| Critérios de sucesso | O que é verificável e mensurável | Produto com a liderança técnica |
| Teste vermelho | O contrato, escrito antes do código | Pessoa desenvolvedora, ou agente sob supervisão |
| Implementação | Código gerado até o teste passar | Agente executor |
| Refatoração | Limpeza estrutural com a bateria de testes verde | Agente com revisão humana |
| Verificação | Evidências coletadas e criticadas | CI, agente revisor e humano conforme o raio de dano |
| Aceite | Decisão de que a entrega vale | Dono do produto |
O agente executor nunca é dono da etapa que define o sucesso nem da que decide se a entrega vale. Essa separação é o mecanismo de controle; o restante é ferramenta. A etapa que costuma ficar órfã é a validação adversarial, em que um segundo agente critica a implementação contra a especificação antes de qualquer humano gastar atenção.
Na fila da semana está uma regra de comissionamento que só a área comercial entende de verdade. Ninguém em engenharia sabe escrever o critério de aceite dessa regra, e o agente está livre.
Como você libera essa tarefa?
Há um efeito econômico direto ao lado disso. Parte do tempo que a IA economiza na escrita volta como tempo de auditar, revisar e validar o que ela produziu. Este curso chama esse saldo de imposto de verificação (verification tax), e o nome é convenção didática nossa, sem origem em relatório de mercado. O contrato reduz esse imposto porque automatiza a primeira camada da auditoria: a bateria de testes responde se o comportamento contratado existe, antes de qualquer pessoa entrar na fila de revisão.
Existe também um argumento de eficácia, mais forte que o de custo, e ele vem com uma condição que quase todo mundo ignora.
Se a figura ultrapassar a área visível, deslize para os lados. Pelo teclado, foque a figura e use as setas.
A pesquisa TDAD mediu regressão em SWE-bench Verified, um conjunto público de problemas reais de software usado para avaliar agentes. A taxa de regressão é a fatia das tarefas em que alguma coisa que já funcionava parou de funcionar depois da entrega, então aqui número menor é resultado melhor. Foram três estados:
- Linha de base, sem nenhuma instrução extra: 6,08% das tarefas quebraram algo que funcionava.
- TDD instruído sem contexto de teste: 9,94%. Instruir piorou o resultado.
- TDD com mapa de dependência entre código e testes: 1,82%, queda de cerca de 70% em relação à linha de base. Na direção oposta, e aqui maior é melhor, a fatia de problemas efetivamente resolvidos subiu de 24% para 32%.
O estado do meio é o achado que muda a implantação de segunda-feira. Acrescentar "siga TDD" ao prompt (o texto de instrução do agente, como um bilhete ao funcionário), sem entregar ao agente o mapa de qual teste cobre qual trecho de código, piorou a regressão. A explicação é direta: instruído a manter a bateria verde e sem enxergar o que sua mudança afeta, o agente otimiza para o verde local e quebra o que está fora do campo de visão.
Sem o mapa, a prescrição de método sozinha custa caro; o ganho vem dele. Registre também o tamanho da base, porque ela é pequena: dois modelos de código aberto, rodando em máquina comum e não em servidor de laboratório, submetidos a 125 tarefas no total. Serve como indicação de direção, sem autorizar precisão de decimal.
Antipadrão para evitar nesta semana: acrescentar "siga TDD" ao prompt de sistema e considerar a prática adotada. Segundo a TDAD, é o estado que piorou o resultado. A correção é operacional: antes de instruir TDD, garanta que o agente receba no contexto quais testes cobrem os arquivos que ele vai tocar. Enquanto o seu ferramental não produzir esse mapa, instruir TDD é a pior das três opções disponíveis.
Verificação rápida
Por que instruir o agente a fazer TDD, sem entregar o mapa entre código e testes, piorou a regressão em vez de apenas não melhorar?
Feche a página e responda de memória. (1) Quais das sete etapas do ciclo não podem ter o agente executor como dono, e por quê? (2) Por que o argumento econômico contra escrever teste antes inverteu de sinal quando agentes entraram no ciclo? (3) O que um critério de aceite precisa ter além do caminho feliz para funcionar como contrato, e a sua última tarefa delegada tinha isso?
A pergunta para a próxima reunião de liderança é esta: nas tarefas que delegamos a agentes no último mês, quem escreveu o critério de aceite e quando ele foi escrito? O critério para responder tem duas partes. Se o critério nasceu depois da entrega, você não tem controle, tem opinião sobre o resultado. Se nasceu antes, mas está apenas na cabeça de alguém, ele não sobrevive à ausência dessa pessoa nem serve de defesa numa auditoria. Escrito antes e executável por máquina é o único formato que resiste às duas situações.
Duas tarefas para esta semana, antes da próxima delegação a um agente.
1. Donos do ciclo. Preencha a tabela de donos das sete etapas para o seu time real, com nomes de pessoas e de agentes. Identifique a etapa órfã e proponha um dono com nome e rito.
2. Contrato antes do código. Escolha uma tarefa da fila e escreva os critérios de aceite antes de delegar, usando como referência de forma a tabela dos três testes desta aula: um de comportamento de negócio, um de caso limite e um que precisa valer em qualquer cenário. Escreva em português; a tradução para teste automatizado é execução e pode ir para o agente. Compare o resultado entregue com o que você teria aceito sem o contrato.
Confira o resultado por quatro sinais: (a) toda etapa tem dono nomeado, e a etapa órfã foi nomeada explicitamente em vez de cair por default na liderança técnica; (b) os critérios incluem pelo menos um caso limite, daqueles que ficam na fronteira da regra, e um de erro; (c) você aponta pelo menos uma diferença entre o que foi entregue e o que teria aceito sem o contrato, porque nenhuma diferença indica contrato frouxo; (d) você sabe dizer se o seu ferramental entrega hoje ao agente o mapa entre código e testes, ou se você está no estado do meio da TDAD.
Perguntas frequentes deste capítulo
Contrato escrito antes vale para tudo, inclusive protótipo descartável?
Quem escreve o teste quando o agente é mais rápido que o humano nisso?
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. Nos vídeos e áudios, use Anotar este momento. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Conexões deste capítulo
Veja o que estudar antes e para onde seguir depois, explore os conceitos e compare abordagens em outros cursos. Sugestões marcadas como “sugerido pelo grafo” vêm dos assuntos em comum, não do índice do curso.
Estude antes
- CursoAgentes de IA Autônomos: Do Conceito à Produção
- CursoVídeo com IA: Claude Code, Codex e ElevenLabssugerido pelo grafo5 capítulos de “Do Agile ao Agentic Operating Model” usam conceitos apresentados em “Vídeo com IA: Claude Code, Codex e ElevenLabs”.
- CursoMCP para quem decidesugerido pelo grafo4 capítulos de “Do Agile ao Agentic Operating Model” usam conceitos apresentados em “MCP para quem decide”.
Conceitos deste capítulo
O mesmo assunto em outros cursos
- Agentes de código para executivosVetar proposta que não nomeia o verificadorExaminar conexões de Vetar proposta que não nomeia o verificador
- Software e IA para executivosRevisar a entrega pela lista do que mudou linha a linhaExaminar conexões de Revisar a entrega pela lista do que mudou linha a linha
- CRO: Otimização de Conversão e ExperimentaçãoAgentic commerce: converter para quem não tem olhosExaminar conexões de Agentic commerce: converter para quem não tem olhos
- Engenharia de Software para ExecutivosLer o que mudou em cada alteração antes de aprovarExaminar conexões de Ler o que mudou em cada alteração antes de aprovar
Leve uma ideia para a prática
Escolha uma atividade no painel e volte a este curso quando quiser.
Atividades e evolução ficam reunidas no painel da sua conta.