A rotina de conferência que roda toda vez

A equipe pediu ao assistente uma tela de cadastro. Vinte minutos depois, a tela existia: campos, botão, validação. O desenvolvedor abriu no navegador e começou a lista mental de sempre. O botão de salvar não responde no celular. A mensagem de erro aparece atrás do rodapé. A máscara do CPF aceita letras. Ele voltou ao assistente com três correções, esperou, testou de novo, encontrou mais duas. Ao fim da tarde, a tela estava boa. O assistente trabalhou vinte minutos. A pessoa, quatro horas, fazendo o que ninguém tinha pedido ao assistente para fazer: conferir.

Esta peça mostra como transferir essa conferência para dentro do próprio fluxo, com uma rotina em que um assistente executa e outro confere a cada execução, sem depender de instruções digitadas na hora. O conceito está em Conferir antes de entregar. A forma mais simples de ver o ciclo funcionar, com duas sessões lado a lado, está em Quem faz e quem confere. Aqui o foco é a montagem permanente.

O que esta peça entrega

Uma rotina de conferência é um arranjo em que um assistente executa uma tarefa e outro assistente, com contexto separado, avalia o resultado contra critérios definidos antes de o trabalho começar. Se o resultado passa, entrega. Se não passa, quem executou recebe o parecer e refaz. O ciclo se repete até atingir os critérios ou o limite de rodadas.

O que sai daqui é um modelo reutilizável com seis componentes, um formato de critérios de aceitação e um mapa de onde aplicar. Nenhum dos componentes exige ferramenta específica. A documentação oficial da Claude descreve o padrão como avaliador e otimizador, e trata assistentes especializados como agentes que rodam em janelas de contexto próprias, com instruções e ferramentas restritas. As referências estão ao final.

Os seis componentes

1. Meta. O resultado desejado, em uma frase, com o padrão de comparação explícito. Não é "criar uma tela de cadastro". É "criar uma tela de cadastro que um usuário de celular conclui em menos de um minuto sem instrução". A referência concreta importa tanto quanto a tarefa: comparar com produtos comerciais do mesmo tipo é diferente de comparar com um protótipo interno.

2. Decomposição. A meta é quebrada em partes que podem ser conferidas isoladamente. Na tela de cadastro: a validação dos campos, o comportamento em tela pequena, a mensagem de erro, o fluxo de salvar. Cada parte recebe seu próprio par, o que executa e o que confere. Quanto mais fina a decomposição, mais precisa a conferência, e mais caro o conjunto.

3. Quem executa. O assistente que faz. Recebe a parte, a meta e os critérios. Não recebe a tarefa inteira, e isso é intencional: contexto reduzido produz foco. Pode rodar em um modelo econômico, porque sua tarefa é produzir versões.

4. Quem confere. O assistente que julga. Recebe apenas o resultado e os critérios. Não recebe o histórico de como o resultado foi construído, nem as razões das decisões de quem executou. Essa separação de contexto é o que a documentação chama de isolamento: o assistente trabalha em janela própria e devolve só o resumo. Uma regra prática útil é a do restaurante: quem cozinha a própria comida julga com condescendência. Quem só prova, julga o prato. Merece o modelo mais capaz disponível, porque um julgamento fraco desperdiça todas as rodadas seguintes. É a regra de modelo por tarefa, com o gasto concentrado onde a criticidade está ("Inteligência" [1]).

5. Critérios de aceitação. A lista do que precisa ser verdade para a parte ser aprovada. É o componente que mais influencia o resultado, e o que menos recebe atenção. Detalhado na seção seguinte.

6. Regra de parada. O que encerra o ciclo. Duas formas coexistem: uma nota mínima (quem confere pontua de zero a cem e só aprova acima de um limiar que você define) e um teto de rodadas (após oito ciclos, por exemplo, a rotina encerra e reporta o estado, aprovado ou não). Sem regra de parada, a rotina consome orçamento indefinidamente. Sem nota mínima, aprova cedo demais.

O modelo de critérios de aceitação

A documentação oficial da Claude recomenda que critérios de sucesso sejam específicos, mensuráveis e alcançáveis, e que rubricas de avaliação sejam detalhadas o suficiente para que um avaliador automatizado as aplique sem ambiguidade. O modelo abaixo segue essa orientação em três blocos.

Bloco objetivo. Condições binárias, verificáveis por código ou por inspeção direta. Todos os botões respondem ao clique. Nenhum elemento se sobrepõe em tela pequena. Os testes automáticos passam. O tempo de carregamento fica abaixo de dois segundos.

Bloco de experiência. Condições que exigem uso, não leitura. Um usuário sem instrução conclui o fluxo principal. A mensagem de erro explica o que corrigir. O estado de carregamento é visível. Este bloco só funciona se quem confere conseguir operar a interface, o que exige integração com automação de navegador ou, no mínimo, captura de tela avaliada como imagem. Sem isso, quem confere lê código e presume comportamento, e a conferência perde a maior parte do valor.

Bloco de padrão. A comparação com a referência declarada na meta. Está no nível de uma solução comercial da mesma categoria? Um profissional da área aprovaria sem ressalvas? Aqui entra um critério subjetivo que vem ganhando espaço em relatos recentes de quem trabalha com assistentes: quem confere precisa ficar impressionado, não apenas satisfeito. É subjetivo, e funciona, porque força quem executa a ir além do funcional. A documentação sugere pedir ao avaliador que raciocine antes de pontuar e que use escalas fechadas (correto ou incorreto, ou de um a cinco), o que reduz a variabilidade do julgamento.

Para quem vem de um diagnóstico, os três blocos já têm origem: o bloco objetivo sai do impacto esperado da ficha da iniciativa, o bloco de experiência sai do problema de negócio, e o bloco de padrão sai da referência de comparação registrada no mapa de prioridades ("Canvas" [2]). O artigo estruturante da série mostra esse mapeamento em detalhe.

Um esqueleto textual que serve de partida:

META: [resultado desejado] comparável a [referência concreta].

PARTES: [lista de partes conferíveis isoladamente].

PARA CADA PARTE:
  QUEM EXECUTA recebe: parte, meta, critérios.
  QUEM CONFERE recebe: resultado e critérios, sem histórico.
  CRITÉRIOS:
    Objetivos: [condições binárias]
    Experiência: [condições testadas em uso]
    Padrão: [comparação com a referência]
  QUEM CONFERE pontua de 0 a 100 com justificativa.
  APROVA se nota >= [limiar]. Senão, devolve parecer a quem executa.

REGRA DE PARADA: máximo de [N] rodadas por parte.
RELATÓRIO FINAL: partes aprovadas, partes pendentes, nota de cada uma.

De instrução a estrutura

O esqueleto acima funciona digitado como pedido. Mas o ganho real aparece quando ele deixa de ser digitado e passa a viver na estrutura do projeto: um arquivo de definição para quem executa, outro para quem confere, com integrações restritas e modelo definido, e um comando que dispara a rotina inteira com o mínimo de entrada. É a diferença entre uma rotina que depende de quem lembra de pedir e uma rotina que roda toda vez. A peça de abertura da série, A estrutura vale mais do que a ferramenta, explica por que essa migração é o que separa resultado eventual de resultado previsível, e Do diagnóstico ao sistema que a equipe mantém mostra como ela se organiza em escala de equipe.

Onde aplicar, e o que muda em cada caso

Desenvolvimento de funcionalidades. O caso de origem. Um assistente implementa, o outro testa como usuário e compara com o padrão. O ganho é a eliminação das rodadas manuais de correção. A documentação da Claude traz exemplos de revisores com acesso somente leitura, o que impede quem confere de corrigir por conta própria e preserva a separação de papéis.

Testes automatizados. Inverte-se o par: um assistente escreve os testes, o outro roda a bateria e avalia cobertura, casos de borda e legibilidade. Um critério útil: cada teste falha quando a funcionalidade é quebrada de propósito. Teste que nunca falha não é teste.

Conferência diária de aplicações em produção. Uma rotina de manutenção que vem sendo adotada por equipes que operam vários aplicativos: um assistente entra na aplicação, percorre as funcionalidades principais como um usuário e reporta ou corrige o que encontra, conforme a gravidade. É o ciclo aplicado a operação, não a construção. Combina com a disciplina de registro consultável e política de retentativa que qualquer automação séria carrega ("Automação" [3]).

Revisão de documentação e conteúdo. Um assistente escreve, o outro lê como o público-alvo e avalia clareza, aderência ao tom e ausência de erro factual. Critérios de padrão funcionam bem aqui: um leitor sem contexto entende o primeiro parágrafo? Este próprio artigo pode ser conferido assim.

Tratamento de dados. Um assistente monta a transformação, o outro valida contra amostras conhecidas, checa distribuições e procura registros que violam regras de negócio. O bloco objetivo domina, e a conferência por código é mais confiável do que por modelo. A origem da verdade de cada entidade precisa estar nomeada antes, ou quem confere não tem contra o que comparar ("Fontes de dados" [4]).

Levantamentos e avaliações. Um assistente coleta evidências sobre um processo, uma área ou um sistema. O outro compara cada afirmação com a fonte e marca o que foi declarado sem evidência. É o arranjo que transforma um questionário respondido de memória em um retrato com base, e é o mesmo cuidado que uma boa medida de capacidade exige de cada nota: evidência citável, não impressão ("Prontidão" [5]).

Materiais práticos de execução. Instruções calibradas, capacidades empacotadas e roteiros que um diagnóstico entrega à equipe ganham critérios de aceitação embutidos ("aceleradores" [6]). Um material que declara o que "pronto" significa é um material que a equipe confere sem depender de quem o escreveu.

Erros comuns na montagem

Dar a quem confere o mesmo contexto de quem executa. O julgamento fica condescendente, porque quem confere conhece as razões das escolhas.

Conferir apenas por leitura de código quando o critério é de experiência. Quem confere aprova o que parece correto, não o que funciona.

Definir critérios depois de ver o resultado. Critério escrito após o fato tende a descrever o que foi entregue, não o que deveria ter sido.

Deixar a rotina sem teto de rodadas ou sem orçamento. O custo fica invisível até a fatura.

Decompor de menos. Uma parte grande demais produz uma conferência vaga demais, e quem executa não sabe o que corrigir.

O entregável

O que esta peça deixa pronto para uso: o modelo de seis componentes, o esqueleto de critérios em três blocos e o mapa de aplicação por atividade. Preenchido para uma tarefa concreta, o conjunto vira um material reutilizável, no sentido que a metodologia dá ao termo: contextualizado, reutilizável e executável sem tradução.

Na série

Esta é a peça 4 da série Da decisão à entrega, em sete peças. O artigo estruturante, Do diagnóstico à entrega, é a porta de entrada. As peças anteriores são A estrutura vale mais do que a ferramenta, Conferir antes de entregar e Quem faz e quem confere, e a sequência segue com Muitas entregas ao mesmo tempo, O critério de sucesso vale mais do que o pedido e Do diagnóstico ao sistema que a equipe mantém.

Termos citados neste artigo

[1] "Inteligência": camada técnica do Impulso Framework que escolhe o modelo certo para cada tarefa, com estratégia híbrida de custo. Detalhada em Inteligência: o modelo certo para cada tarefa.

[2] "Canvas": ficha em sete blocos que detalha cada iniciativa priorizada no diagnóstico (problema, dados, tipo de solução, solução proposta, impacto esperado, riscos e implementação). Detalhado em Iniciativas: o Radar e o Canvas.

[3] "Automação": camada técnica da execução em escala, com política de retentativa e registro consultável de execuções. Detalhada em Automação: onde a IA para de ser assistente e vira sistema.

[4] "Fontes de dados": camada técnica que nomeia a origem da verdade de cada entidade e dá dono e rotina à confiabilidade do dado. Detalhada em Fontes de dados: a IA multiplica o que recebe.

[5] "Prontidão": etapa do diagnóstico que mede a capacidade real de executar em oito dimensões, com evidência por nota. Detalhada em Prontidão: o filtro que separa ambição de fracasso anunciado.

[6] "Aceleradores": materiais práticos de execução (instruções calibradas, atalhos, capacidades empacotadas e roteiros), contextualizados, reutilizáveis e executáveis sem tradução. Detalhados em Plano de Ação: aceleradores que dispensam tradução.

Referências

Documentação oficial da Claude (Anthropic), consultada em setembro de 2026:

Building effective agents, padrões de orquestrador e trabalhadores, paralelização e avaliador e otimizador. https://www.anthropic.com/research/building-effective-agents

Create custom subagents, contexto isolado, restrição de ferramentas, escolha de modelo por assistente e conferência em navegador. https://code.claude.com/docs/en/sub-agents

Define your success criteria. https://platform.claude.com/docs/en/test-and-evaluate/define-success

Develop test cases, métodos de avaliação por código, por modelo e por pessoa, e rubricas. https://platform.claude.com/docs/en/test-and-evaluate/develop-tests

Escreva o critério antes do resultado. É o critério que trabalha enquanto você não está olhando.

Tool | Frente: Consulting | Série Da decisão à entrega, peça 4 de 7 | Proposições ancoradas: IA como amplificador, diagnóstico que produz ação | 1.590 palavras | Leitura: 8 minutos