Gates são uma função de perda. Estas são as quatro formas como eles falham.

Um gate é uma pessoa lendo. Tudo o que faz uma pessoa ler pior faz o gate piorar, e o AI-DLC produz muita coisa para ler.

O nono princípio do whitepaper do AI-DLC diz que as validações humanas “funcionam como uma forma de função de perda” (loss function), identificando e cortando trabalho desperdiçado mais adiante antes que ele aconteça. É a melhor frase do método. Ela explica por que o AI-DLC para depois de cada estágio e espera por você, e por que essa parada é engenharia, e não burocracia.

É também onde o método é mais fraco, e a documentação não diz isso. O gate é uma pessoa, e a IA produz artefatos muito mais rápido do que uma pessoa consegue ler com cuidado. No rollout que acompanhei dentro de uma grande organização de engenharia, os gates falharam de quatro formas, de novo e de novo, e nenhuma delas era bug de ferramenta.

Este artigo é sobre essas quatro falhas e os hábitos que resistem a elas.

O que uma função de perda faz num gate

Em machine learning, uma função de perda mede o quanto a saída de um modelo está errada, para o treinamento poder corrigi-la. O whitepaper pega emprestada a ideia. Em cada gate, uma pessoa mede o quanto o artefato está errado, para o workflow poder corrigi-lo antes de o próximo estágio construir em cima.

O motivo de isso importar é o efeito composto. No AI-DLC, todo estágio lê a saída do anterior como contexto. Um requisito vago não é contido pelo estágio de design. Ele é multiplicado: o design codifica a imprecisão como decisão, as Units codificam o design e o código codifica as Units. Uma ambiguidade que custava um comentário para corrigir no gate de requisitos custa um redesenho no gate de arquitetura e uma reescrita no code review.

A mesma decisão errada, pega em gates diferentes

O valor do gate não é pegar erros. É pegá-los na camada mais barata.

Onde é pega	Quanto custa corrigir
No gate de intent e requisitos	Um comentário e um documento gerado de novo. Minutos.
No gate de arquitetura	Um design novo e ADRs novos antes de existir qualquer código.
No code review	Reescrever uma Unit que já passa nos testes.
Em produção	Um incidente, e depois tudo o que está acima.

O que o AI-DLC 2 confere antes de te perguntar

Uma pessoa no gate é a última camada, não a única. O AI-DLC 2 empilha várias checagens para que, quando um artefato chega a você, os problemas mecânicos já tenham saído do caminho e a sua atenção possa ir para o julgamento.

Checagens que rodam antes e durante um gate no AI-DLC 2

1. 1

   Sensores

   Checagens determinísticas, como um linter ou um type check, que disparam sobre os arquivos que um estágio escreve. Algumas só avisam, outras bloqueiam até a correção.

   +
2. 2

   Agentes revisores

   Dois agentes que só revisam julgam requisitos, histórias e mockups, ou o design técnico, e escrevem um veredito READY ou NOT-READY com os achados. Eles nunca bloqueiam. Quem decide é a pessoa.

   +
3. 3

   Gates de verificação

   Checagens automáticas de rastreabilidade entre as fases: cada requisito vira uma história, nada ficou órfão, os artefatos concordam entre si.

   +
4. 4

   A sua aprovação

   No fim de todo estágio fora da Initialization: Approve ou Request Changes, com as suas palavras. Nada anda até você responder.

Repare no que os agentes revisores fazem. Num NOT-READY adversarial, o estágio roda de novo, até duas vezes por padrão, e o que continuar sem solução vai para o seu gate como achados. É um bom desenho: tira os problemas óbvios antes que eles custem a sua atenção. E tem um efeito colateral que vale nomear. Um gate que chega com uma revisão limpa anexada parece mais confiável do que é. Um veredito READY de um agente revisor é a opinião de um modelo sobre o trabalho de outro modelo. Útil, e não é a mesma coisa que uma pessoa que conhece o domínio dizer sim.

A Construction tem a sua variação. No AI-DLC 2 você aprova cada Unit num checkpoint verificado, e a verificação roda um comando que você autorizou uma vez. Depois disso dá para escolher “Continue automatically” nos checkpoints comuns. A aprovação do plano de cada Unit, a escolha do comando de verificação e toda falha continuam voltando para uma pessoa. O motor traça a linha entre o que pode ser delegado e o que não pode. A questão é se a pessoa do outro lado dessa linha ainda está lendo.

Falha um: o artefato parece completo e não diz nada

A primeira falha é a mais perigosa porque parece sucesso.

Uma liderança de produto com quem trabalhei durante o rollout explicou com uma analogia que eu passei a usar em todo lugar. Você recebe um e-mail do seu banco. Tem o logo, as cores certas, o tom formal. Como tudo parece familiar, você para de conferir o link. A familiaridade desliga o seu ceticismo, que é exatamente com o que um e-mail de phishing conta.

Um documento de requisitos gerado faz a mesma coisa. Tem as seções certas, os títulos certos, os critérios de aceite no formato certo. Você reconhece o formato de um documento bom e o seu cérebro marca como bom. Aí você lê de verdade, frase por frase, e não tem nada ali. Enchimento plausível no formato de uma spec.

A estrutura de um documento é fácil de ensinar para um modelo. O conteúdo do seu domínio não é. Então o modelo entrega com confiabilidade a parte que você confere de relance, e entrega sem confiabilidade a parte que você só confere lendo.

Falha dois: quem revisa está cansado

A segunda falha é aritmética. O agente gera um documento de requisitos, um conjunto de histórias, um design de domínio e uma lista de Units em minutos. Uma pessoa precisa de tempo de verdade para ler cada um com cuidado, e a atenção acaba muito antes dos documentos.

No rollout, o limite era de mais ou menos uma hora. Alguém da engenharia descreveu o momento com precisão depois de uma Inception longa: quando os últimos documentos chegaram, não tinha mais cabeça para revisá-los, e parou, porque senão começaria a aprovar qualquer coisa. Essa é a versão honesta. A maioria das pessoas não para. Continua clicando em Approve, e o gate continua registrando uma decisão que ninguém tomou.

Falha três: quem revisa não conhece o domínio

A terceira falha surpreendeu mais do que deveria. Os engenheiros e as pessoas de produto com o conhecimento mais fundo do domínio demoravam mais nos gates. Interrogavam cada afirmação, discordavam do agente e reescreviam os critérios de sucesso dele. As pessoas com menos conhecimento do domínio eram mais rápidas. Aceitavam a primeira saída.

É o contrário da história de sempre, de que a IA ajuda mais os juniores. Num gate, quanto menos você sabe, mais você confia, porque não tem com o que comparar a saída. Os pesquisadores chamam isso de viés de automação, e está documentado nos estudos de fatores humanos desde os anos 1990: as pessoas confiam demais em saídas automatizadas, ainda mais quando elas parecem autoritativas.

A consequência prática para o AI-DLC é sobre quem fica em qual gate. Um engenheiro júnior pode rodar um workflow. Um engenheiro júnior não deveria ser o único aprovador de um documento de requisitos num domínio em que entrou no mês passado. Dê tempo para as pessoas aprenderem o domínio antes de transformá-las em gate, e até lá junte quem opera com pouco domínio a alguém que revisa com muito domínio.

Falha quatro: a décima aprovação

A quarta falha é a confiança que se calibra pelo histórico. O agente acertou nove vezes hoje, então o décimo artefato ganha uma olhada. Nada no décimo é diferente. A sua atenção é.

Essa é difícil de ver por dentro, e é por isso que ela precisa de uma resposta mecânica, e não de boas intenções. Carimbar por cansaço não é defeito de caráter. É o que a atenção faz sob repetição, e a única defesa é um hábito que force uma leitura de verdade, não importa como foram as nove anteriores.

A regra da frase única

Este é o hábito. Antes de aprovar qualquer artefato, diga numa frase com o que ele te compromete e por que está certo. Em voz alta, no chat, ou para a pessoa do lado.

Se você consegue dizer, você leu. Se não consegue, não terminou, e a resposta é continuar lendo ou perguntar ao agente, não clicar em Approve. Parece trivial. É o controle mais barato que eu conheço para transformar um carimbo de volta numa decisão, porque não dá para resumir um documento que você só passou o olho sem perceber que só passou o olho.

Perguntas que tornam um gate real

1. 01

   Faça o artefato explicar os próprios compromissos.

   Um resumo nas palavras do agente mostra o que ele acha que construiu. Compare com o que você achou que pediu.

   Digite isto

   Before I approve: in one sentence, what does this document commit us to? Then list every assumption in it that did not come from my answers.

2. 02

   Questione os critérios de sucesso.

   Os agentes tendem a definir sucesso como a existência de um artefato. Sucesso é um resultado para o negócio. Se o critério é uma entrega, é o critério errado.

   Digite isto

   The success criterion you wrote is a deliverable. Rewrite it as an outcome we can measure after release.

3. 03

   Peça a segunda opinião num contexto limpo.

   Na mesma sessão, o agente defende as decisões que tomou. Só com o artefato na frente, ele as critica.

   Digite isto

   /clear, then load only the artifact and ask: Produce a critique of this as if you hadn't written it.

4. 04

   Pare quando perceber que está aprovando mais rápido.

   O arquivo de estado faz a pausa custar zero. Uma aprovação feita na segunda hora de uma sessão vale menos do que uma feita amanhã de manhã.

   Digite isto

   Stop here. Commit what is approved, and we continue this stage in the next session.

Ritmo é decisão de design, não soft skill

Todas as quatro falhas pioram com a velocidade. Por isso as contramedidas mais eficazes no rollout foram de ritmo, não de ferramenta.

Mantenha as sessões de aprovação em torno de uma hora. Divida uma Inception longa em duas sessões, em dias diferentes, em vez de uma maratona de três horas. Nunca emende Inception e Construction na mesma sessão para ganhar tempo: decisões aprovadas por um time cansado na Inception viram retrabalho na Construction, e o retrabalho custa mais do que uma segunda sessão teria custado. E coloque o manager nos primeiros mobs com a tarefa explícita de pedir a pausa, porque um time pressionado a parecer produtivo não vai pedir sozinho.

Nada disso deixa o método mais lento de um jeito que importe. O AI-DLC guarda o estado em arquivos, então um workflow pausado continua exatamente de onde parou. A única coisa que você perde pausando é a ilusão de que aprovar mais rápido era andar mais rápido.

Human in the loop, human on the loop

Por baixo de tudo isso há uma pergunta maior: quanto uma pessoa deveria aprovar, afinal?

Kief Morris traçou a distinção com clareza em Humans and Agents in Software Engineering Loops. Uma pessoa in the loop aprova cada passo. Uma pessoa out of the loop está fazendo vibe coding. Uma pessoa on the loop desenha e melhora o sistema dentro do qual os agentes rodam, o harness, e supervisiona os resultados em vez de cada ação. O guia de AIDLC da Augment Code trata isso como a decisão central de operação: in the loop para decisões de alto risco, on the loop para trabalho validado e bem delimitado.

Human in the loop

1. 01Aprova cada estágio e cada artefato
2. 02Certo para trabalho de alto risco, ambíguo ou regulado
3. 03Desmorona quando o volume de artefatos passa a atenção disponível

Human on the loop

1. 01Desenha os gates, as regras e as checagens dentro dos quais os agentes rodam
2. 02Supervisiona os resultados e intervém nas falhas
3. 03Só é seguro quando as checagens conseguem carregar a confiança que você tirou

O AI-DLC 2 já deixa você fazer essa passagem num lugar estreito: escolher “Continue automatically” nos checkpoints comuns da Construction é passar de in the loop para on the loop naquela parte do trabalho. É o movimento certo quando a Unit tem um comando de verificação de verdade, testes que significam alguma coisa e sensores que pegam os problemas mecânicos. É o movimento errado quando a única coisa entre o agente e a sua branch principal é uma pessoa cansada que parou de ler uma hora atrás.

Essa é a regra geral, e é a mesma por trás de harness engineering: você conquista o direito de aprovar menos fazendo o sistema checar mais. Entusiasmo não conta como verificação.

Perguntas frequentes

O que significa human on the loop?+

Uma pessoa on the loop supervisiona os resultados de um processo automatizado e desenha as regras e as checagens dentro das quais ele roda, em vez de aprovar cada passo. Uma pessoa in the loop aprova cada passo.

Em termos de AI-DLC, aprovar cada estágio é in the loop. Deixar os checkpoints verificados da Construction seguirem automaticamente enquanto você cuida dos planos e das falhas é on the loop.

Qual a diferença entre um gate de aprovação e um gate de verificação no AI-DLC?+

Um gate de aprovação fecha todo estágio fora da Initialization e espera uma pessoa responder Approve ou Request Changes. Um gate de verificação roda entre as fases e é automático: confere se os artefatos são rastreáveis e consistentes, por exemplo se cada requisito vira uma história. Um checa julgamento, o outro checa ligações.

Dá para desligar os gates de aprovação no AI-DLC 2?+

Em parte. Na Construction você pode deixar os checkpoints comuns de Unit rodarem automaticamente. A aprovação do plano de cada Unit, a escolha do comando de verificação e toda falha continuam exigindo uma pessoa, e a guarda de presença humana não pode ser baixada para um único workflow. O escopo que você escolhe também decide quais estágios rodam, e um estágio que não roda não tem gate.

Os agentes revisores substituem o review humano?+

Não. O AI-DLC 2 tem dois agentes que só revisam e escrevem um veredito READY ou NOT-READY com os achados, e num NOT-READY adversarial o estágio roda de novo até duas vezes por padrão. Eles nunca bloqueiam, e quem decide é a pessoa. São bons em pegar problemas óbvios, e os vereditos limpos deles podem fazer um artefato fraco parecer mais confiável do que é.

Quanto deveria durar uma sessão de aprovação?+

Mais ou menos uma hora. No rollout que acompanhei, as aprovações depois da primeira hora lendo documentos gerados viraram carimbo. Divida as Inceptions longas em várias sessões. O arquivo de estado faz a pausa custar zero.

Quem deveria aprovar um gate de AI-DLC?+

Alguém que conheça o domínio o bastante para discordar do agente. Quem revisa com pouco domínio aceita a primeira saída; quem revisa com muito domínio interroga. Até a pessoa conhecer o domínio, junte-a com alguém que conheça.

Para onde ir agora

O whitepaper está certo: um gate é uma função de perda, e é o lugar mais barato para pegar uma decisão errada. Mas uma função de perda que parou de medir é só um atraso. Mantenha as sessões curtas, faça o agente declarar as suposições, use a regra da frase única, e só passe um gate de in the loop para on the loop quando houver verificação de verdade por trás.