Engenharia de lastro: como tornar agentes autônomos verificáveis

Um agente autônomo pode planejar, editar arquivos, executar testes, analisar o resultado, tentar novamente e escalar um problema quando não consegue avançar. Com um loop bem montado, ele continua progredindo por horas sem intervenção humana.

Esse avanço resolve uma parte difícil da engenharia autônoma: como fazer o agente continuar trabalhando. Não resolve a parte mais perigosa: como saber se o que ele produziu é verdadeiro.

Um loop pode iterar com a mesma confiança sobre uma premissa correta e sobre uma premissa inventada. A velocidade não funciona como filtro de verdade. Testes passando também não provam que a explicação do agente sobre o sistema tem fundamento, nem que o item marcado como concluído foi realmente verificado por uma máquina.

Essa diferença apareceu de forma recorrente em mais de 130 sessões de engenharia autônoma envolvendo diagnóstico de código legado, redação de especificações e implementação dentro de um processo governado. As falhas críticas não eram, em geral, agentes travados. Eram agentes convincentes, produtivos e errados.

A resposta foi criar uma disciplina para classificar afirmações e bloquear mecanicamente aquelas que não têm sustentação suficiente. Chamamos essa disciplina de Engenharia de Lastro.

O problema que o loop não resolve

Imagine uma tarefa simples: descobrir onde uma integração externa é configurada e documentar seu comportamento.

O agente encontra um nome de cliente HTTP, observa uma URL em um arquivo de configuração e escreve que “o serviço usa timeout de 30 segundos e retry exponencial”. O primeiro trecho pode estar ancorado no repositório. O segundo talvez nunca tenha sido encontrado. Pode ser uma inferência baseada no padrão da biblioteca ou em um valor comum naquele tipo de integração.

Se o agente acrescentar essa conclusão à especificação e os testes existentes continuarem passando, o loop considera o trabalho bem-sucedido. A afirmação, porém, continua sem prova.

O mesmo acontece em tarefas maiores:

• uma arquitetura inferida a partir de nomes de diretórios é apresentada como arquitetura implantada;
• uma migration é tratada como reversível sem que exista evidência de rollback;
• a ausência de um segredo no código é descrita como prova de que ele está protegido;
• uma camada de testes é considerada suficiente porque importa o módulo, embora não exerça seus caminhos críticos;
• um componente é atribuído a um time sem que o histórico de autoria sustente essa conclusão.

O agente pode cumprir os critérios visíveis e ainda assim construir sua resposta sobre fatos que nunca observou. O problema não é apenas de qualidade da resposta. É de estado epistemológico: o sistema não distingue “vi isso”, “deduzi isso” e “não tenho como saber”.

O que é Engenharia de Lastro

Lastro é peso colocado na parte inferior de uma embarcação para manter sua estabilidade. Uma afirmação gerada por IA precisa de uma função equivalente: evidência graduada, citável e passível de contestação.

A disciplina usa três etiquetas simples, que podem ser localizadas por ferramentas comuns, inclusive um grep. A validação básica não depende de outro modelo interpretar a intenção do texto.

[A] Ancorada

A afirmação tem evidência direta e citável. Exemplos:

• arquivo:linha que mostra a configuração;
• teste executado com resultado registrado;
• definição de schema ou migration;
• hash de commit;
• declaração de infraestrutura ou configuração encontrada no repositório.

Uma afirmação [A] sem citação anexada é inválida por construção. Não é uma preferência editorial. Se o processo diz que a afirmação é ancorada, o artefato que a sustenta precisa estar presente.

[P] Pressuposta

A afirmação foi inferida a partir de padrões, nomes, convenções ou contexto incompleto. Ela pode ser útil, mas não pode se passar por fato.

Uma suposição [P] precisa gerar uma ação de validação posterior: uma pergunta ao responsável, um teste, uma busca adicional no repositório ou uma inspeção em ambiente autorizado. O rótulo impede que a inferência desapareça dentro de um parágrafo e volte a aparecer mais tarde como requisito confirmado.

[Q] Aberta

A evidência disponível não permite concluir. O agente deve declarar a lacuna e impedir o encerramento da tarefa quando aquela resposta for necessária para o contrato.

[Q] não significa que o sistema está quebrado. Significa que a conclusão não é medível com o material disponível. Em arquitetura, essa honestidade é mais útil do que uma resposta completa apenas na aparência.

Uma barra longa ao lado de [P] não transforma a suposição em fato. O comprimento pode representar a quantidade de material relacionado, mas a etiqueta continua indicando o tipo de evidência. Peso da evidência e confiança subjetiva são coisas diferentes.

Lastro precisa ser mecânico

Uma regra escrita em um manual não basta. Sob pressão, o processo tende a aceitar uma frase plausível, especialmente quando ela vem acompanhada de muitos arquivos alterados e testes verdes.

O lastro funciona quando o sistema bloqueia a passagem de uma afirmação sem classificação, de uma afirmação [A] sem citação ou de uma conclusão baseada em [P] e [Q] onde o contrato exige comprovação.

Isso muda a unidade de revisão. Em vez de perguntar apenas “o agente terminou?”, o time pergunta:

• quais afirmações foram feitas;
• que evidência sustenta cada uma;
• quais pontos continuam inferidos;
• quais perguntas seguem abertas;
• o que impede o agente de encerrar prematuramente.

O objetivo não é transformar todos os documentos em relatórios burocráticos. É preservar a diferença entre observação, inferência e desconhecimento quando o trabalho passa por várias etapas e pessoas.

Três mecanismos que completam o lastro

Classificar afirmações individuais não adianta se o processo permite que o agente ignore a classificação na hora de declarar sucesso. Três mecanismos fecham essa brecha.

Sensores são os únicos juízes

O estado de concluído deve ser definido por uma lista de verificações executáveis antes do início do trabalho. Apenas os códigos de saída desses sensores podem aprovar a entrega.

Uma explicação convincente não é um sensor. Uma captura de tela que parece correta não é um sensor. A confiança do agente também não é.

Dependendo da tarefa, os sensores podem verificar a presença de contratos, a execução de testes, a consistência entre especificação e implementação, a ausência de ciclos arquiteturais ou a existência de evidências obrigatórias. O ponto central é que “pronto” precisa corresponder a condições observáveis, não ao relato do executor.

O contrato separa produzir de verificar

Antes do trabalho começar, executor e verificador assinam um contrato de escopo. O executor declara o que entregará. O verificador declara o que examinará em relação a essas entregas.

O verificador não deve avaliar o raciocínio interno do executor. Ele recebe o contrato e as saídas dos sensores. Essa separação reduz uma falha comum em loops autossupervisionados: o mesmo processo cria o artefato, escolhe os critérios e decide que o artefato é bom.

O contrato também limita a avaliação. Um verificador não deve reprovar ou aprovar com base em exigências que não foram definidas. Isso torna a decisão auditável e evita que o agente esconda uma mudança de escopo dentro de uma narrativa de conclusão.

A ferramenta deve sobreviver à própria inspeção

Quando o produto construído é uma ferramenta de inspeção, existe uma verificação especialmente forte: submeter a própria ferramenta à análise que ela oferece.

O resultado dessa inspeção pode se tornar um critério de não regressão para cada lançamento. A verificação deixa de depender da memória de alguém ou de uma revisão eventual. Se a ferramenta começa a produzir um diagnóstico incoerente, perde evidência ou deixa de detectar uma condição que deveria detectar, o próprio processo registra a regressão.

Esse princípio não prova que uma ferramenta é perfeita. Ele cria uma pressão concreta contra a deterioração silenciosa e expõe contradições entre o que ela promete avaliar e o que consegue sustentar sobre si mesma.

Como aplicar na próxima sessão

Comece pequeno. Não tente instrumentar todo o fluxo de engenharia de uma vez.

1. Liste as afirmações que o agente precisará fazer para concluir a tarefa.
2. Defina o que conta como evidência direta para cada uma.
3. Exija [A], [P] ou [Q] em todas as afirmações relevantes.
4. Faça cada [A] apontar para uma fonte citável.
5. Converta cada [P] em pergunta ou verificação futura.
6. Marque como bloqueadora qualquer [Q] que afete uma decisão do contrato.
7. Escreva sensores executáveis antes de iniciar a implementação.
8. Faça um verificador independente consumir apenas o contrato e as saídas dos sensores.

Depois, revise os casos de escape: texto sem etiqueta, citações inexistentes, testes que não exercitam o comportamento declarado e tarefas encerradas apesar de perguntas abertas.

O resultado esperado não é um agente que nunca erra. Isso não é uma condição realista. O resultado é um agente que deixa visível onde observou, onde inferiu e onde não conseguiu concluir.

Da confiança para a rastreabilidade

Loops dão aos agentes persistência. Lastro dá limites ao que eles podem afirmar. Juntos, eles formam uma base mais segura para a engenharia autônoma: o agente pode continuar tentando, mas não pode converter tentativa em evidência; pode propor uma hipótese, mas não pode promovê-la silenciosamente a fato; pode concluir uma tarefa, mas somente quando os sensores previstos aprovarem o contrato.

Essa é a mudança de foco necessária. A pergunta não é apenas se o agente produziu código ou documentação. É se cada decisão importante continua ligada a uma evidência que outra pessoa ou máquina consegue verificar.

Na prática, essa é a função de um diagnóstico com lastro: transformar a análise em afirmações rastreáveis, explicitar a incerteza e bloquear conclusões que o repositório não sustenta. O agente continua sendo executor. A verdade precisa estar no processo.