Capítulo 2 — Colaboradores estocásticos precisam de sistemas determinísticos de controle
O problema não é o agente variar
Section titled “O problema não é o agente variar”Um colaborador humano não executa uma tarefa complexa sempre pelo mesmo caminho. Ele interpreta, experimenta, corrige, muda de estratégia e às vezes erra. Ainda assim, equipes conseguem trabalhar com pessoas porque não dependem de previsibilidade absoluta de cada passo. Elas dependem de contratos, limites, revisão, testes, observabilidade e mecanismos de recuperação.
Com agentes de IA, a mesma ideia precisa ser tornada mais explícita.
O caminho de execução de um agente pode variar entre duas tentativas. A ordem em que ele lê arquivos, formula hipóteses, chama ferramentas ou propõe uma implementação não precisa ser idêntica para que o resultado seja aceitável. O que precisa ser controlado são as propriedades que importam.
É aqui que a Engenharia Agêntica muda a pergunta.
Em vez de perguntar “como faço o agente agir de forma determinística?”, perguntamos: quais propriedades precisam ser verdadeiras para que eu aceite o resultado, e quais evidências mostram que elas são verdadeiras?
Ahmed E. Hassan organiza essa ideia em torno de confiança construída por evidências verificáveis, não pela exigência de que cada passo de um colaborador estocástico seja previsível. 1
Esse deslocamento é o centro deste capítulo.
Confiança no resultado, não na narrativa
Section titled “Confiança no resultado, não na narrativa”Um agente pode terminar uma tarefa com uma explicação impecável:
- “implementei a feature”;
- “os testes passaram”;
- “não alterei nada fora do escopo”;
- “a mudança está pronta para produção”.
Essas frases não são evidência suficiente.
Elas são uma narrativa sobre o que teria acontecido.
Um sistema profissional precisa conseguir verificar a narrativa por fontes independentes: o diff real, os testes realmente executados, o resultado do build, os arquivos alterados, a política de acesso aplicada, o artefato promovido, o health check observado depois do deploy.
Esse princípio parece óbvio quando escrito dessa forma, mas ele é fácil de abandonar na prática porque agentes são muito bons em produzir explicações convincentes.
A regra operacional será:
o agente pode descrever o trabalho; o sistema de engenharia precisa provar o trabalho.
Isso não significa desconfiar de toda saída de IA por princípio. Significa separar duas funções: produzir uma proposta e decidir se a proposta satisfaz os critérios necessários.
Evidência determinística não exige execução determinística
Section titled “Evidência determinística não exige execução determinística”Há uma diferença importante entre tornar o processo inteiro determinístico e tornar os critérios de aceitação reproduzíveis.
Suponha que dois agentes resolvam a mesma tarefa de formas internas diferentes. Um cria primeiro o teste, outro começa pela implementação. Um consulta três arquivos, outro consulta cinco. Um faz uma tentativa extra.
Se ambos entregarem uma mudança que respeita os mesmos contratos, preserva invariantes, passa pelos mesmos gates e produz o comportamento esperado, a variação interna pode ser aceitável.
O que não pode variar silenciosamente são as propriedades que definem “pronto”.
No nosso método, essas propriedades serão distribuídas pelo fluxo:
Spec define o que deve ser verdadeiro.
Evidence demonstra propriedades observáveis.
Review trata decisões que ainda exigem julgamento.
Delivery garante que a revisão aprovada corresponde ao artefato promovido.
Operations verifica o comportamento real.
Learning registra o que precisa mudar depois do resultado.
É assim que a estocasticidade deixa de ser tratada como uma exceção incômoda e passa a ser uma característica de projeto.
O que máquinas devem decidir — e o que humanos ainda precisam decidir
Section titled “O que máquinas devem decidir — e o que humanos ainda precisam decidir”Nem toda verificação merece o mesmo mecanismo.
Algumas propriedades são adequadas para gates mecânicos:
- o código compila;
- uma suíte específica passa;
- uma API mantém determinado contrato;
- nenhum arquivo proibido foi alterado;
- uma política de lint foi respeitada;
- um artefato possui o checksum esperado;
- o health endpoint respondeu dentro do critério definido.
Quando uma propriedade pode ser expressa de forma reproduzível, automatizá-la reduz variação e evita que uma revisão humana gaste atenção com algo que uma máquina pode verificar melhor.
Jeremy McEntire diferencia esse tipo de gate mecânico de revisão consultiva: o primeiro avalia uma condição explícita de maneira reproduzível; o segundo depende de julgamento e pode variar entre avaliadores. 2
Mas essa distinção não significa substituir revisão humana por automação.
Há decisões que não cabem honestamente em uma expressão booleana:
- essa abstração é adequada para o domínio?
- esta mudança cria uma dependência arquitetural que vamos lamentar?
- este risco é aceitável para o negócio?
- a especificação está resolvendo o problema certo?
- estamos criando complexidade desnecessária?
- este sistema deveria sequer ter essa permissão?
O erro seria tentar transformar toda decisão humana em gate mecânico ou, no extremo oposto, tratar tudo como opinião de revisor.
A arquitetura de controle precisa usar cada mecanismo onde ele é forte.
Autonomia não é um botão liga/desliga
Section titled “Autonomia não é um botão liga/desliga”Discussões sobre agentes frequentemente tratam autonomia como se houvesse apenas duas opções:
manual ou autônomo.
Na prática, autonomia é um envelope.
Um agente pode receber liberdade para editar arquivos em uma branch, mas não para fazer merge. Pode executar testes locais, mas não acessar produção. Pode criar uma migration, mas não aplicá-la. Pode abrir um pull request, mas não aprová-lo.
O tamanho desse envelope deve acompanhar o risco.
Hassan relaciona delegação a blast radius e reversibilidade: uma mudança em código versionado, com testes e recuperação simples, pode suportar mais autonomia do que uma ação com efeito irreversível ou rollback incerto. 3
Essa ideia muda a pergunta de confiança.
Não precisamos decidir se “confiamos no agente” como uma propriedade absoluta. Precisamos decidir:
- qual dano máximo esta tarefa pode causar?
- quais permissões ela realmente exige?
- quais evidências serão produzidas?
- quanto tempo temos para detectar uma falha?
- a ação é reversível?
- existe um caminho de recuperação testado?
Quanto maior o blast radius e menor a reversibilidade, mais estreito deve ser o envelope de autonomia.
Reversibilidade é parte do design da delegação
Section titled “Reversibilidade é parte do design da delegação”Essa conclusão é especialmente importante para software porque grande parte do nosso ambiente pode ser tornada reversível.
Git permite voltar a uma revisão anterior. Containers podem ser reconstruídos. Infraestrutura declarativa pode ser reaplicada. Feature flags podem limitar exposição. Bancos podem ter estratégias de migration e restore. Releases podem usar canary ou rollout gradual.
Nenhum desses mecanismos elimina risco.
O que eles fazem é alterar o custo de um erro.
Uma tarefa que pode falhar de forma contida, detectável e recuperável é diferente de uma ação que pode apagar dados, publicar informação externa ou modificar produção sem rollback.
Por isso, rollback não aparece neste livro apenas no capítulo de incidentes. Ele começa aqui, na decisão sobre quanto podemos delegar.
A capacidade de recuperação é um componente da confiança.
Responsabilidade fecha o circuito
Section titled “Responsabilidade fecha o circuito”Delegação muda quem executa partes do trabalho, não quem precisa sustentar a decisão de aceitar a mudança. Tantithamthavorn mantém accountability no engenheiro que revisa, aceita e envia código gerado por IA. 4
Por isso, o fluxo precisa tornar visível quem aceitou o quê, com qual evidência e sob qual boundary. Essa cadeia será materializada mais adiante por commits, PRs, Evidence IDs, deploys e incidentes; aqui, basta fixar o princípio: autonomia sem responsabilidade observável vira transferência de risco.
Evidence Gate: transformar risco em requisitos observáveis
Section titled “Evidence Gate: transformar risco em requisitos observáveis”O Companion do livro inclui um primeiro laboratório chamado Evidence Gate.
A lógica é deliberadamente simples.
A entrada considera:
- tipo de mudança;
- autonomia concedida;
- impacto de produção;
- sensibilidade dos dados.
A saída aumenta as exigências de evidência conforme o risco cresce.
Uma mudança de documentação pode exigir apenas escopo claro e diff revisável. Uma alteração de infraestrutura com impacto alto pode exigir testes, integração, rollback, aprovação humana, least privilege, observabilidade e verificação pós-deploy.
A intenção não é transformar esse cálculo em uma fórmula universal.
É ensinar um padrão mental:
mais autonomia + mais impacto + menor reversibilidade = controles mais fortes.
O Evidence Gate é método deste livro, não uma escala padronizada da literatura. Ele sintetiza princípios de risk tiering, least privilege, evidência e recovery em uma ferramenta didática.
Um gate útil também precisa bloquear
Section titled “Um gate útil também precisa bloquear”Um sistema de controle que nunca impede progresso não é um gate; é uma decoração.
Nosso próprio projeto já produziu um exemplo útil.
Durante a preparação do backend de Change Episodes para produção, os testes do código haviam passado e a imagem Docker havia sido construída. Antes da promoção, porém, verificamos que o módulo necessário pelo servidor não estava incluído na imagem runtime. A promoção foi interrompida, o contrato da imagem foi corrigido, os testes de build foram ampliados, staging foi validado e apenas depois a revisão corrigida chegou a produção. 5
Esse episódio é pequeno, mas mostra o comportamento que buscamos.
O sucesso não foi “o deploy aconteceu rápido”.
O sucesso foi “o sistema impediu que uma revisão incompleta chegasse a produção e preservou evidência do motivo”.
Confiança é construída também pelas vezes em que o fluxo diz não.
O risco da verificação teatral
Section titled “O risco da verificação teatral”Existe ainda um anti-padrão mais sutil: executar checks sem garantir que eles realmente testam a propriedade importante.
Uma suíte pode passar porque não cobre o caso relevante. Um revisor pode aprovar porque o diff é grande demais para ser compreendido. Um agente pode produzir um teste que apenas confirma a própria implementação. Um health endpoint pode responder enquanto uma função crítica está quebrada.
Mechanical gate não significa gate correto.
A qualidade da verificação depende da qualidade da especificação, do contrato e da seleção das evidências.
Esse é o motivo de Evidence aparecer depois de Spec no nosso pipeline.
Antes de automatizar a pergunta “passou?”, precisamos saber o que “passar” significa.
Autonomia precisa de contexto de risco
Section titled “Autonomia precisa de contexto de risco”“Mais autonomia = mais verificação” aponta na direção correta, mas é insuficiente.
O controle necessário também depende de privilégio, reversibilidade, blast radius, observabilidade, maturidade dos testes, capacidade de rollback e consequência de um falso positivo no gate. Duas tarefas com o mesmo nível de autonomia podem exigir controles muito diferentes.
Por isso, autonomia nunca será tratada como pontuação isolada. Ela será analisada dentro de um sistema de evidência e recuperação. 3
Próximo passo: mudar a unidade de trabalho
Section titled “Próximo passo: mudar a unidade de trabalho”Até aqui estabelecemos duas coisas.
Primeiro, o gargalo se desloca quando geração fica barata.
Segundo, colaboradores estocásticos podem ser usados profissionalmente quando o sistema torna propriedades importantes verificáveis e limita o dano potencial.
Falta uma pergunta operacional:
qual deve ser o tamanho da mudança que entregamos a esse sistema?
Se uma tarefa for grande demais, o contexto cresce, o diff cresce, a verificação fica mais difícil e o blast radius aumenta.
O próximo capítulo responde com uma ideia antiga aplicada a uma realidade nova: trabalhar em pequenos lotes, usando mudanças limitadas — e não prompts — como unidade de engenharia.
Fronteira de confiança
Section titled “Fronteira de confiança”O agente pode propor, editar e executar dentro do envelope delegado. A fronteira de confiança está na passagem de output produzido para mudança aceita. Essa passagem exige evidência + revisão proporcionais ao risco.
Evidência exigida
Section titled “Evidência exigida”Uma mudança pode exigir, conforme o risco:
- Spec e acceptance criteria;
- testes/build/static checks;
- diff e revisão;
- least-privilege revisão;
- rollback plan;
- staging;
- health/observability;
- verificação pós-deploy.
Rollback e recuperação
Section titled “Rollback e recuperação”Reversibilidade não é plano de emergência anexado no fim. Ela altera o próprio envelope de autonomia. Mudanças com recuperação simples podem admitir delegação mais ampla; ações irreversíveis exigem limites mais estreitos. 3
Proveniência das fontes
Section titled “Proveniência das fontes”Rastreabilidade deste capítulo:
- CLM-012 — Hassan, deterministic evidência;
- CLM-017 — McEntire, mechanical gates vs judgment;
- CLM-018 — Hassan, risk/reversibility/autonomy;
- CLM-019 — Tantithamthavorn, accountability;
- CLM-010 — evidência do caso do nosso fluxo de produção.
Fontes de acesso limitado não foram usadas como autoridade factual neste capítulo.
Recursos complementares
Section titled “Recursos complementares”Recurso principal:
- Evidence Gate;
- Evidence Explorer do CE-2026-005;
- futura visualização de autonomia × risco × reversibilidade × evidência.
Footnotes
Section titled “Footnotes”-
Ahmed E. Hassan, Agentic Software Engineering (2026), front matter / scale flips the bottleneck, p. 13. Rastreabilidade interna: CLM-012. ↩
-
Jeremy McEntire, Beyond Code (2026), Chapter 6: Mechanical Gates Over Advisory Review, p. 57. Rastreabilidade interna: CLM-017. ↩
-
Ahmed E. Hassan, Agentic Software Engineering (2026), Core concept: the reversible world and delegation calibration, p. 292. Rastreabilidade interna: CLM-018. ↩ ↩2 ↩3
-
Kla Tantithamthavorn, Agentic Software Engineering (2026), Chapter 6: Agentic Software Engineering: A New Paradigm, p. 108. Rastreabilidade interna: CLM-019. ↩
-
Evidência do estudo longitudinal, CE-2026-005; evidências EVID-CE-2026-005-01, EVID-CE-2026-005-02, EVID-CE-2026-005-03, EVID-CE-2026-005-04, EVID-CE-2026-005-05. Rastreabilidade interna: CLM-010. ↩