Loop Engineering: projetando feedback automatizado para agentes de programação com IA

Quando um assistente de programação não consegue executar verificações, a pessoa desenvolvedora se torna o elo entre o código proposto e a aplicação real: copia a mudança no código, executa o comando, cola o erro e repete o processo.

Um agente pode automatizar boa parte dessa interação quando suas ferramentas retornam evidências úteis. Editar arquivos diretamente não demonstra, por si só, que o resultado funciona. A distinção importante é se as mudanças são verificadas em relação ao comportamento desejado.

Aqui, Loop Engineering significa projetar esse ciclo delimitado de ação, observação e correção. É um termo descritivo para o projeto de ciclos de feedback, não um método de desenvolvimento universalmente padronizado. Em Building effective agents, a Anthropic descreve agentes que usam feedback do ambiente e condições de parada.

Este artigo conclui a série iniciada com Spec-Driven Development.

Feche o ciclo com evidências

flowchart TD
    accTitle: Ciclo de desenvolvimento delimitado
    accDescr: Faça uma mudança com escopo definido, execute verificações e inspecione os resultados. Se os critérios de aceitação forem atendidos, revise e informe as evidências. Caso contrário, revise enquanto houver progresso e orçamento ou pare e informe o impedimento.
    A["Fazer uma mudança com escopo definido"] --> B["Executar verificações relevantes"]
    B --> C["Inspecionar resultados e observações da execução"]
    C --> D{"Critérios de aceitação atendidos?"}
    D -- Sim --> E["Revisar mudanças e informar evidências"]
    D -- Não --> F{"Dentro do orçamento e com progresso?"}
    F -- Sim --> G["Diagnosticar e revisar"]
    G --> A
    F -- Não --> H["Parar e informar o impedimento"]

O ambiente de execução pode disponibilizar um terminal, uma API de testes ou uma ferramenta MCP. O meio de transporte é secundário; o importante é o agente receber o resultado real, inclusive falhas ao iniciar a verificação.

Escolha um feedback compatível com a mudança

Feedback	O que pode comprovar	O que, sozinho, não comprova
Compilador ou verificador de tipos	Compatibilidade com a linguagem e as regras de tipos verificadas	Comportamento correto de negócio
Testes unitários e de integração	Comportamento coberto pelas verificações e dados de teste	Casos não testados ou condições de produção
Logs e registros detalhados da execução	O que ocorreu em uma execução observada	Ausência de falhas em outras execuções
Verificações no navegador	Interações, renderização e estados visíveis testados	Usabilidade ou acessibilidade completas

Quando viável, comece com uma referência. Uma falha existente não deve ser confundida com uma regressão introduzida pela mudança no código. Para uma correção de bug, um teste de regressão que falhe antes da correção e passe depois fornece evidência útil.

Execute verificações focadas durante o diagnóstico e, em seguida, verificações mais abrangentes adequadas aos limites afetados. Trabalho na interface web pode exigir interações no navegador e inspeção visual; uma alteração no banco de dados pode exigir uma migração com dados de teste representativos.

Execute o checkout em um ambiente reproduzível

No exemplo contínuo, implante as revisões candidatas de web, orders e pricing em um ambiente de teste isolado. Prepare códigos válidos e expirados, aguarde a prontidão, exercite o fluxo no navegador e confirme que a cotação persistida corresponde aos dados de teste acordados. Registre revisões, verificações nomeadas, dependências simuladas e o resultado da limpeza.

O contrato da ferramenta de verificação do artigo sobre Harness Engineering disponibiliza esses resultados ao agente. O roteiro de testes de ponta a ponta, abaixo, aborda em detalhes implantação, autenticação, acesso ao banco e limpeza.

Não deixe a implementação definir o próprio sucesso

Um agente que escreve o código e os testes pode repetir a mesma suposição equivocada nos dois. Derive casos de aceitação da especificação e mantenha intactos os testes de regressão existentes que forem importantes.

Se um teste falhar, determine se o problema está na implementação, na expectativa do teste ou no ambiente. Não enfraqueça asserções, ignore verificações nem exclua testes apenas para obter um resultado aprovado. Uma alteração justificada no teste deve explicar o comportamento desejado e continuar visível na revisão.

Um código de saída zero só é útil se as verificações esperadas realmente tiverem sido executadas. Um executor que não encontrar testes ou verificar o diretório errado pode retornar evidências enganosas. Informe a contagem de testes ou verificações nomeadas, quando disponível, e as exclusões relevantes.

Limite as novas tentativas e seus efeitos

Defina limites antes de iniciar o ciclo. Por exemplo, uma equipe pode permitir três tentativas de correção ou dez minutos para uma tarefa pequena e, depois, exigir um relatório de impedimento. São orçamentos ilustrativos, não valores padrão universais.

Pare mais cedo quando a mesma falha se repetir sem novas evidências, um serviço necessário estiver indisponível ou a correção depender de uma decisão de produto. Mantenha o diagnóstico atual, o comando de reprodução e a próxima ação útil para que outra pessoa possa continuar.

Limite o que cada iteração pode afetar. Use dados e credenciais de teste isolados, aplique limites de tempo aos comandos e limpe processos e recursos temporários. Repetir um teste é diferente de repetir um comando que envia mensagens ou altera dados compartilhados.

Mantenha resumos concisos no contexto ativo e preserve logs completos separadamente. Os resumos devem reter as asserções com falha, caminhos relevantes e suposições não resolvidas para que a compressão não apague as evidências necessárias ao diagnóstico.

Delimite o trabalho delegado e produza bons resumos

Em The Orchestrator’s Tax, Rahul Garg descreve uma sessão em que verificações de status importavam transcrições extensas dos agentes auxiliares para o contexto do agente principal. O benefício proposto para delegar é proteger o contexto de trabalho; o artigo deixa explícito que não apresenta uma classificação medida dos custos em tokens.

Em uma tarefa de checkout com vários agentes, agrupe o trabalho que usa os mesmos contratos e defina claramente a responsabilidade por cada arquivo. Um agente auxiliar que investigue a expiração da cotação deve retornar revisões relevantes, descobertas, arquivos alterados, verificações e decisões pendentes. Mantenha seus logs detalhados disponíveis por referências a artefatos. Ao diagnosticar um problema, busque um trecho específico do registro da execução em vez de importar a transcrição inteira para uma atualização de status.

Forneça aos agentes auxiliares as instruções aplicáveis e um orçamento explícito; confirme o que o ambiente de execução realmente fornece. Evite operações concorrentes que afetem o repositório inteiro, como stash ou reset, em um checkout compartilhado. Áreas de trabalho Git isoladas podem separar edições, mas o resultado combinado ainda precisa de verificações de integração. Compare a delegação com um agente em tarefas representativas antes de afirmar que houve melhoria de velocidade ou custo.

Preserve o ciclo de aprendizagem da pessoa desenvolvedora

Em The Learning Loop and LLMs, Unmesh Joshi alerta que gerar e revisar código pode contornar a experimentação por meio da qual desenvolvedores descobrem um design.

Depois de corrigir a expiração da cotação, peça à pessoa mantenedora que preveja o que acontece exatamente no limite de expiração e então execute esse caso com um relógio controlado. Explique qual componente é responsável pela decisão e varie deliberadamente uma suposição, como a cotação expirar entre a exibição e o envio. Se o resultado surpreender, revise o contrato ou a implementação e registre a descoberta.

Isso é útil durante a integração de pessoas e em mudanças importantes de design. O objetivo é ter uma pessoa mantenedora capaz de diagnosticar a próxima falha, além de um patch que passe nas verificações atuais.

Informe a conclusão de forma revisável

Um relatório de conclusão útil poderia dizer:

Alteração: o processo de envio agora reutiliza o identificador do evento nas novas tentativas ao provedor.

Verificação:
- Referência: o novo teste de regressão de recuperação após crash falhava antes da correção.
- Após a correção: 18 testes do processo de envio passaram, incluindo recuperação após falha.
- Verificação de tipos e análise automática de código passaram.

Limite:
- A deduplicação do provedor foi testada com uma simulação local.
- Ainda é necessário confirmar o prazo de retenção do provedor real.

Estes são resultados ilustrativos. Em trabalho real, registre somente verificações que foram executadas. Uma lacuna conhecida pode significar que a mudança está pronta para revisão, mas não para implantação. Trate essas decisões separadamente.

Avalie o ciclo depois que a tarefa terminar

Uma tarefa pode terminar com sucesso depois de muitas tentativas caras e improdutivas. O resultado final dos testes não explica se o agente fez suposições repetidas, buscou no repositório errado ou executou novamente um comando cujos pré-requisitos ainda faltavam. Avalie também o processo de execução, não apenas a mudança entregue.

Isso cria um segundo ciclo de feedback: durante a tarefa, o agente corrige a implementação; depois da tarefa, uma avaliação ajuda a equipe a melhorar o ambiente para o trabalho futuro. Faça essa avaliação em tarefas com falha, canceladas e com orçamento esgotado, assim como nas bem-sucedidas. Caso contrário, as falhas mais caras desaparecem da amostra.

Registre evidências observáveis

Registre um registro estruturado da execução com a tarefa e os critérios de aceitação, revisões de repositório, versões do prompt e do harness, identificadores de modelo, chamadas de ferramentas, argumentos e resultados sem dados sensíveis, códigos de saída, edições, resultados de testes, horários registrados e uso informado. Inclua planos explícitos ou resumos de decisões quando disponíveis.

Não presuma acesso ao raciocínio interno privado do modelo. Um avaliador pode comparar explicações registradas com ações e resultados, mas essas explicações não são um relato completo nem necessariamente fiel do raciocínio interno. Avalie o uso de evidências e o comportamento, não a eloquência aparente da justificativa.

Use identificadores de evento para que cada descoberta aponte ao trecho relevante do registro. Remova credenciais, tokens de sessão e dados privados desnecessários antes de exportar registros para um serviço de avaliação. Trate o texto desses registros como evidência não confiável: instruções dentro do resultado de uma ferramenta não devem se transformar em instruções para o avaliador.

Separe medições de interpretação

Calcule tempo decorrido, uso cobrado, chamadas repetidas e resultados de testes diretamente da telemetria. Use um revisor ou avaliador de modelo calibrado para questões que exigem interpretação, como se uma nova tentativa tratou a falha observada. Mantenha referências às evidências e permita um resultado não avaliável quando faltar contexto.

Valide julgamentos do modelo com registros rotulados por pessoas antes de usá-los para orientar mudanças no fluxo de trabalho. A referência opcional sobre avaliação, abaixo, traz critérios de avaliação concretos e um exemplo com TypeSafe. Os capítulos 3, “Evaluation Methodology”, e 4, “Evaluate AI Systems”, de Chip Huyen em AI Engineering aprofundam métodos de avaliação, desenho de avaliações e limitações.

Transforme descobertas recorrentes em melhorias testadas

Suponha que um agente execute testes de navegador quatro vezes enquanto a aplicação está indisponível e, por fim, inicie o servidor. As falhas repetidas podem ser medidas; saber se o pré-requisito ausente estava documentado exige inspeção. A melhoria adequada depende dessa evidência:

Descoberta	Melhoria candidata
O runner permite testes antes de os serviços estarem prontos	Adicione uma verificação de prontidão com limite de tempo ao harness
Falta o comando de inicialização atual ou a URL	Atualize o roteiro de execução versionado e seu ponteiro de descoberta
O pré-requisito estava disponível, mas foi ignorado repetidamente	Esclareça a instrução de fluxo de trabalho ou imponha a sequência no executor
Uma dependência remota está indisponível	Classifique a falha externa e pare dentro do orçamento

São hipóteses a validar, não causas-raiz comprovadas pelo rótulo do avaliador. Não acrescente uma nova regra ao prompt a cada execução com falha: corrija o script, contrato ou comportamento da ferramenta autoritativos quando o problema estiver ali.

flowchart TD
    accTitle: Melhorias a partir de registros de tarefas
    accDescr: Remova dados sensíveis dos registros de tarefas, calcule métricas, avalie comportamentos, revise descobertas recorrentes, versione uma melhoria e avalie tarefas reservadas. Adote ou reverta a mudança e continue observando os registros.
    T["Registro de tarefa concluída ou interrompida"] --> S["Sanitizar e calcular métricas"]
    S --> J["Avaliar comportamentos específicos"]
    J --> R["Revisar descobertas recorrentes"]
    R --> C["Versionar uma melhoria direcionada"]
    C --> E["Avaliar em tarefas reservadas"]
    E --> N["Adotar ou reverter"]
    N --> T

Retenha o modelo avaliador, a versão dos critérios de avaliação, probabilidades e referências às evidências. Proponha mudanças a instruções ou ferramentas compartilhadas por meio de mudanças revisáveis; não permita que conteúdo não confiável dos registros reescreva automaticamente o harness. Compare a versão candidata à anterior em tarefas representativas reservadas, incluindo taxa de sucesso, regressões, tentativas de correção, esforço de revisão e custo total. Reproduzir um trace congelado testa o avaliador; medir se o harness melhorou exige novas execuções.

O pós-processamento não recupera o dinheiro já gasto, portanto mantenha limites ativos de novas tentativas e tempo. Ele também custa: comece com detecção determinística e trechos selecionados dos registros, audite uma amostra de execuções aparentemente saudáveis e meça os gastos do avaliador junto aos gastos de execução. O resultado útil é haver menos falhas repetidas nas tarefas seguintes sem enfraquecer a verificação.

Compare versões do fluxo de trabalho com novas execuções

Suponha que o ciclo de checkout inicie repetidamente testes de navegador antes de pricing estar pronto. Compare o harness A existente ao harness B, que adiciona uma verificação de prontidão com limite. Defina a hipótese primeiro: B deve reduzir inícios de teste evitáveis sem reduzir o sucesso nos critérios de aceitação nem simplesmente esperar por mais tempo do que o orçamento da tarefa permite.

1. Congele um conjunto de desenvolvimento e outro conjunto reservado, com dados de teste das tarefas, commits iniciais, casos de aceitação e cenários de ambiente. Inclua inicialização normal, prontidão atrasada e uma dependência que nunca fica pronta.
2. Desenvolva B usando apenas o conjunto de desenvolvimento. Mantenha fixos modelo, prompt, permissões, dados de teste e orçamento total de execução para a comparação. Registre qualquer configuração que não possa ser controlada.
3. Execute A e B em ambientes limpos para cada tarefa reservada. Para um piloto inicial, três execuções por versão e tarefa são um ponto de partida prático, não uma amostra universalmente suficiente do ponto de vista estatístico. Alterne a ordem e mantenha todas as tentativas.
4. Aplique as mesmas verificações de aceitação independentes e os mesmos critérios de revisão. Registre execuções com falha, interrompidas e com orçamento esgotado, incluindo tempo e custo consumidos. Quando viável, revise patches sem os rótulos das versões.
5. Examine resultados pareados por tarefa e categorias de falha antes de agregá-los. Se houver resultados mistos ou muita variação, faça mais execuções. Usar novamente as mesmas tarefas reservadas para ajustes repetidos as transforma em dados de desenvolvimento; atualize o conjunto de avaliação.

Use um registro por execução:

task_id: checkout-delayed-pricing
starting_revisions: registro imutável das revisões
workflow_version: A ou B
model_and_settings: configuração registrada
prompt_version: revisão registrada
run_id: identificador único da execução
outcome: accepted | failed | interrupted | budget_exhausted
acceptance: casos nomeados aprovados e exigidos
regressions: falhas observadas em relação à referência
repair_attempts: quantidade medida
avoidable_test_starts: contagem de eventos de prontidão e início de testes
elapsed_seconds: tempo real decorrido
review_minutes: esforço humano registrado
total_cost: custos disponíveis de inferência, roteamento, avaliação e runner
missing_cost_components: componentes ausentes explicitamente listados
artifacts: referências a trace e asserções sanitizados

Este é um modelo de registro, não dado experimental. Informe execuções aceitas divididas pelo total de execuções, com as contagens e resultados por cenário. Informe tempo decorrido e custo das falhas também. Para uma medida econômica agregada, divida os gastos totais do experimento pelo número de execuções aceitas; se nenhuma for aceita, o custo por execução aceita é indefinido. Mantenha separado o tempo do revisor, a menos que uma taxa declarada seja usada para convertê-lo.

Defina os critérios de adoção antes de olhar os resultados: neste piloto, exija que não haja novas regressões nos critérios de aceitação, que haja menos inícios prematuros de testes nos casos de prontidão atrasada e que a falha seja delimitada quando pricing nunca ficar pronto. Defina qualquer aumento permitido de latência ou custo com base nos requisitos da equipe. Um piloto pequeno dá suporte a uma decisão limitada, não a uma afirmação geral sobre todas as tarefas ou modelos.

Use tarefas representativas e critérios de avaliação consistentes e diferencie falhas de planejamento, ferramentas e eficiência. Traces congelados podem testar um avaliador, mas melhorar a execução exige novas rodadas com o harness alterado.

Conecte as seis práticas

Os seis artigos descrevem responsabilidades sobrepostas, não um pipeline rígido:

Prática	Pergunta respondida
Prompt Engineering	Qual tarefa estamos pedindo ao agente que execute?
AI gateways e roteamento	Qual modelo elegível recebe o pedido e sob quais políticas?
Context Engineering	De quais evidências e conhecimentos do projeto ele precisa?
Harness Engineering	Quais ações ele pode executar e sob quais controles?
Spec-Driven Development	Qual comportamento observável define o sucesso?
Loop Engineering	Como detectaremos problemas, faremos correções e pararemos?

Primeiro, melhore o ponto mais fraco do fluxo de trabalho. Se o agente não consegue iniciar os testes, corrija o ambiente. Se passa nos testes para o comportamento errado, revise a especificação. Se altera repetidamente o serviço errado, melhore a descoberta. Mais retries só ajudam quando a tentativa seguinte tem evidências melhores.

Referência: configuração de ambiente e credenciais

Defina um roteiro de execução para testes de ponta a ponta

Os critérios de aceitação descrevem o comportamento esperado. O agente também precisa de um caminho reproduzível para chegar a esse comportamento: comandos exatos de compilação e implantação, serviços necessários, verificações de prontidão, URLs da aplicação, identidades de teste, asserções no banco e limpeza. Documente isso em um roteiro de testes versionado e aponte para ele no AGENTS.md e na especificação da funcionalidade.

Mantenha configuração de conexão e valores de credenciais separados. O roteiro pode nomear o papel da conta de teste e a referência da credencial; não deve conter a senha. O agente precisa de um meio compatível de exercitar a aplicação, não necessariamente de acesso ao segredo subjacente.

Especifique o ambiente, não apenas o comando de teste

Para cada suite de aceitação, documente:

Área	Informações necessárias
Compilação	Diretório de trabalho, versão fixada do ambiente, instalação de dependências, comando de compilação e revisões candidatas
Implantação	Ambiente de teste-alvo, versões de serviços e imagens, migrações, dados de seed e comando de implantação
Prontidão	Health checks, respostas esperadas, timeout e comportamento quando uma dependência estiver indisponível
Navegador	URL base exata ou como obtê-la, origens permitidas, caminho de entrada e identidade de teste esperada
Autenticação	Papel e tenant necessários, método de provisionamento e referência da credencial ou sessão
Verificação no banco	Sistema de banco, banco ou esquema de teste, perfil de conexão, mecanismo de asserção e acesso permitido
Ciclo de vida	Política de reset, isolamento entre execuções, comando de limpeza, expiração de credenciais e retenção de artefatos

A seguir está um roteiro ilustrativo para uma equipe com um executor de testes de aceitação. Os comandos e nomes de perfis acceptance são exemplos de ferramentas que a equipe precisa implementar; não são comandos padrão de agentes.

suite: checkout-discounts
working_directory: checkout resolvido de acme/web
build:
  runtime: versão fixada em .node-version
  commands:
    - npm ci
    - npm run build

environment:
  provision: acceptance up --suite checkout-discounts
  dependencies: web, orders e pricing candidatos; PostgreSQL; test double de inventory
  revisions: registre commits e digests de imagens no registro da execução
  migrations_and_seed: aplicados pelo runner no banco descartável da execução
  ready: acceptance wait --timeout 120
  base_url: base_url fornecida pelo runner no registro da execução
  entry_path: /checkout

identity:
  role: customer
  tenant: tenant alocado para esta execução
  session: perfil checkout-customer fornecido pelo runner
  credentials: injetadas no worker de autenticação; nunca impressas

database:
  profile: checkout-assertions
  connection: resolvida pelo executor; sem senha neste roteiro
  access: asserções somente leitura no banco desta execução

verification:
  browser: acceptance test --suite checkout-discounts
  persisted_order: acceptance assert --case discounted-order-persisted
cleanup:
  command: acceptance down
  fallback: expiração automática do ambiente e da credencial

O registro da execução deve conter valores não secretos, como ID da execução, URL real, revisões e identificadores dos dados de teste. Valide se os alvos de implantação e navegador pertencem ao ambiente alocado. Imponha destinos permitidos pela configuração do executor e por controles de rede, não apenas por uma URL escrita em um prompt.

Dê a cada execução uma identidade e um conjunto de dados isolados

Use um ambiente descartável ou um tenant de teste isolado com dados sintéticos. Aloque contas ou namespaces de dados diferentes para execuções concorrentes, para que os testes não alterem o estado uns dos outros. Teste o comportamento comum de clientes com uma conta de cliente; use uma identidade separada e de escopo limitado para cenários que realmente exijam administração.

As permissões de provisionamento e migração pertencem ao processo de preparação. A aplicação recebe suas permissões de execução e as asserções no banco recebem permissões de leitura separadas. Evite fornecer ao agente interativo uma conta compartilhada de administrador de implantação só porque o teste precisa de uma migração de banco.

Direcione pagamentos, e-mails e outros efeitos externos para sandboxes de provedores ou sinks de teste. Restrinja o acesso à rede para que uma URL incorreta não inicie uma operação em produção. Identifique as dependências simuladas nos resultados; esse ambiente não demonstra o comportamento dos provedores reais.

Forneça credenciais durante a execução

Um secret manager ou workload identity pode fornecer credenciais ao worker que delas precisa. Prefira credenciais de curta duração, limitadas à execução e revogadas automaticamente. O guia de gerenciamento de segredos da OWASP aborda privilégio mínimo, segredos dinâmicos, rotação e controles de ciclo de vida.

Quando uma senha ou connection string for inevitável, passe-a pelo mecanismo protegido de credenciais do runner. Mantenha senhas fora de prompts, argumentos de linha de comando, configuração versionada e relatórios gerados. Variáveis de ambiente e arquivos .env ignorados reduzem alguns riscos de exposição acidental, mas não escondem segredos de um agente que pode executar comandos arbitrários no mesmo ambiente.

Para um isolamento maior, disponibilize uma operação delimitada como “abrir uma sessão de cliente” ou “executar esta asserção de banco aprovada”. Um worker separado resolve o segredo e retorna um identificador opaco de sessão ou um resultado mínimo. Restrinja as ações permitidas, o ambiente-alvo e a duração. Um identificador de sessão ainda concede capacidades e precisa de escopo limitado.

Código de teste editado por um agente e executado dentro de um worker com credenciais também pode ler ou usar indevidamente essas credenciais. Mantenha as políticas do worker e o provisionamento de credenciais fora do acesso de escrita do agente; use credenciais descartáveis e saída de rede restrita para testes editáveis. Operações com privilégios elevados devem usar ações fixas e validadas, não scripts arbitrários fornecidos pelo agente.

Autentique o navegador sem expor senhas

Na maioria dos testes de fluxo de negócio, um worker de setup pode autenticar uma conta de teste dedicada e criar uma sessão isolada de navegador. Se o login estiver sendo testado, execute o fluxo real com credenciais resolvidas dentro desse worker; não ignore silenciosamente o comportamento que está sendo verificado.

O estado salvo do navegador também é um segredo. O Playwright alerta que o estado de autenticação pode conter cookies e headers utilizáveis para personificação; seu guia de autenticação recomenda manter esse estado fora do controle de versão. Limite também o acesso ao filesystem e a duração: .gitignore, por si só, não oferece controle de acesso.

Verifique dados persistidos com asserções restritas

Prefira uma consulta ou asserção aprovada, associada ao ID da execução e à entidade criada pela UI. Por exemplo: verifique se o pedido existe, pertence ao tenant de teste e armazena o desconto esperado. Retorne o resultado da asserção e os identificadores sintéticos necessários, não um dump completo do banco.

Uma conta somente leitura ainda pode expor dados sensíveis. Quando apropriado, restrinja-a ao banco de teste ou a views aprovadas, com limites de linhas e consultas impostos. Parametrize as entradas das asserções, defina timeouts de consulta e separe operações de seed/reset da verificação. Para persistência assíncrona, use polling limitado com prazo explícito.

Documente host, banco, schema, requisitos de TLS e origem da credencial do perfil de conexão. Uma URI completa com senha pertence ao ambiente de execução protegido, não ao AGENTS.md. Se SQL ad hoc for necessário, permita-o somente sobre dados de teste isolados e com privilégios de banco impostos; a descrição “somente leitura” de uma ferramenta não é controle efetivo.

Limpe segredos e recursos

Faça a limpeza em caso de sucesso, falha e limite de tempo excedido, com mecanismo de expiração para ambientes abandonados. Revogue credenciais e sessões, exclua o estado de autenticação e remova dados de teste e recursos da execução.

Logs, screenshots, traces de rede e vídeos podem conter tokens ou dados sensíveis. Redija-os antes de retornar artefatos ao agente, limite a retenção e o acesso e evite coletar tráfego de autenticação desnecessário. Se uma credencial vazar, revogue-a ou faça sua rotação; apagar o log visível não é suficiente.

O relatório de conclusão deve identificar o ambiente, as revisões testadas, os cenários, os limites simulados, os resultados das asserções no banco e o resultado da limpeza. Nunca reproduza as credenciais usadas para obter essas evidências.

Referência: avaliação opcional de traces com modelos

Use código para contagens e um modelo para interpretação

Calcule diretamente da telemetria o tempo decorrido, o uso cobrado, assinaturas de comandos repetidas e os resultados dos testes. Isso não exige um modelo. Um modelo pode ajudar a interpretar se um retry foi justificado por novas evidências ou se uma afirmação de conclusão teve suporte.

A TypeSafe apresenta Jev como um modelo System One que consome estado e retorna decisões tipadas e probabilísticas em vez de explicações em texto livre. Sua introdução inclui a avaliação de traces de modelos entre os usos possíveis. Usá-lo como avaliador de Loop Engineering é uma aplicação proposta aqui, não evidência de que já melhore este fluxo de programação específico.

Forneça trechos de trace delimitados com o contexto relevante da tarefa e faça perguntas separadas:

Dimensão	Exemplo de julgamento	Evidências a incluir
Justificativa do retry	A tentativa seguinte tratou a falha observada anteriormente?	Falha, edições ou observações intermediárias e chamada seguinte
Uso de contexto	A ação considerou um contrato aplicável já disponível?	Contrato, evento de recuperação e alteração
Qualidade da verificação	As verificações registradas dão suporte à afirmação de conclusão?	Critérios de aceitação, verificações executadas, exclusões e relatório
Alvo de melhoria	Qual área deve ser investigada primeiro?	Sequência relevante e opções como harness, contexto, prompt, dependência externa ou evidência insuficiente

Para uma pergunta graduada, defina níveis concretos. Um conjunto ilustrativo de critérios de justificativa de retry pode distinguir “repete a ação com falha sem tratar um pré-requisito conhecido”, “altera algo relevante, mas não resolve a causa observada” e “trata a causa observada ou executa um diagnóstico direcionado”. A falta de evidências deve produzir um resultado não avaliável, não uma nota baixa automática. Uma investigação justificada ainda pode falhar; um palpite sem justificativa pode dar certo.

A primitiva Score da TypeSafe oferece níveis descritivos ordenados e retorna uma pontuação com distribuição probabilística e confiança. Use uma escolha para categorias mutuamente exclusivas e uma probabilidade de sim/não para uma condição específica. Faça perguntas independentes em conjunto sobre as mesmas evidências; retenha os julgamentos individuais antes de combiná-los no código da aplicação.

Para avaliar uma tarefa de programação concluída, forneça o resumo da tarefa e os critérios de aceitação, o diff relevante, a saída real das verificações e o relatório de conclusão como estado do avaliador. Peça notas separadas para cobertura de requisitos, se as verificações registradas sustentam a afirmação de conclusão e quão revisável é a mudança. Descreva evidências concretas em cada nível e use os mesmos critérios entre execuções. Se calcular uma pontuação composta, normalize primeiro as notas e defina os pesos no código, seguindo o padrão de pontuação composta da TypeSafe. Logs ausentes significam evidência ausente; não demonstram que uma verificação foi executada. Mantenha critérios de aceitação reprovados, achados de segurança e violações de autorização como bloqueios explícitos que uma média alta não possa compensar.

Mantenha separados o status real de conclusão, o custo e os achados de segurança de qualquer nota agregada de qualidade. Uma execução rápida não compensa verificações de aceitação ausentes nem uma operação não autorizada. A documentação de confiança da TypeSafe explica que confiança reflete a distribuição das respostas; não é prova de correção. Valide julgamentos do avaliador com registros rotulados por pessoas e encaminhe casos incertos ou de maior consequência para revisão.