Projetando Restrições para Confiabilidade de Agentes de IA em Produção

De Prompts Frágeis a Protocolos de Execução

Um usuário do Reddit compartilhou uma metodologia detalhada para ir além do prompting único com o Claude e criar sistemas confiáveis de nível de produção. A abordagem se concentra em projetar restrições em vez de escrever instruções, demonstrada pela remoção segura de aproximadamente 140 arquivos de uma base de código ativa com zero builds quebrados e verificação completa.

Componentes-Chave do Design de Restrições

O sistema consiste em várias partes críticas que transformam prompts em protocolos de execução:

Definição Precisa de Papel

• Definir comportamento, limites e o que está explicitamente fora do escopo
• Evitar declarações vagas como "seja um especialista"
• Sem isso, o modelo preencherá lacunas e improvisará

Enumeração de Modos de Falha

• Perguntar: "Como você falhará nesta tarefa?"
• Identificar riscos incluindo: exclusões incorretas, cadeias de dependência quebradas, etapas ignoradas, falhas silenciosas e expansão de escopo
• Se os riscos não forem explícitos, não serão mitigados

Mitigações para Cada Modo de Falha

• Anexar regras explícitas, não sugestões
• Exemplos incluem: "sem julgamentos subjetivos" (agir apenas em listas explícitas), "verificar após cada etapa" (testes, verificações ou equivalentes), "parar em caso de falha" (sem continuidade), "imprimir saídas para cada comando"
• Se um modo de falha não tiver um controle, ele acontecerá

Execução em Fases com Pontos de Verificação

• Pré-voo (estado de referência)
• Execução em blocos com verificação
• Etapas de alto risco isoladas
• Validação final (testes, build, varreduras)
• Tarefas longas exigem validação de estado ou o modelo se desvia

Regras Anti-Atalhos

• Sem refatoração
• Sem "melhorias"
• Sem tocar em arquivos não especificados
• Sem pular etapas de verificação
• Sem continuar após falha

Causas Raiz de Falha

A postagem identifica padrões comuns de falha no uso de agentes de IA:

• Comportamento implícito excessivo
• Nenhuma consciência explícita de falha
• Nenhuma validação forçada
• Nenhum limite rígido

Diretrizes Práticas

O autor fornece uma regra geral para tarefas com consequências reais:

• Sem definição de papel → desvio
• Sem modos de falha → pontos cegos
• Sem salvaguardas → alucinação
• Sem pontos de verificação → perda de estado

Esta abordagem distingue entre sistemas que "funcionam na maioria das vezes" e aqueles que são "confiáveis o suficiente para confiar em um sistema real". O autor enfatiza que o prompting único para tarefas complexas deixa a maior parte da capacidade não utilizada.