O ponto-chave é que o harness não é uma única ferramenta.

Ele é o sistema de controles ao longo de todo o ciclo de vida.

Os dois pilares de um Harness

1. Feedforward (antes da execução)

Feedforward é a orientação fornecida antes do modelo rodar:

• Instruções claras
• Contexto estruturado
• Exemplos (few-shot)
• Expectativas de formato de saída

Objetivo: reduzir ambiguidade antes da geração.

2. Feedback automatizado (depois da execução)

O feedback não deve depender de humanos encontrando cada erro manualmente.

Um modelo mais robusto usa sensores automatizados:

• Testes unitários e de integração
• Validação de schema e contratos
• Regras de negócio e heurísticas
• Uso seletivo de LLM como juiz para revisão semântica

Se uma verificação falhar:

• Reexecutar quando o erro for transitório
• Corrigir quando a correção for determinística
• Escalar quando a confiança for baixa ou o impacto for alto

É assim que o sistema se autocorrige.

Entre feedforward e feedback, o harness também gerencia a camada de execução:

• Orquestração de ferramentas e funções
• Estratégias de retry e fallback
• Observabilidade com logs, traces e métricas

Juntas, essas camadas tornam a IA operável: controlável, testável e evoluível.

O risco real: adoção sem disciplina

As equipes vão usar IA de qualquer forma, com ou sem harness. Sem ele, surgem rapidamente anti-patterns conhecidos:

• Prompts tratados como se fossem especificações
• Validação mínima
• Confiança excessiva no primeiro resultado
• Sistemas que parecem bons até falharem em produção

E conforme a IA acelera a geração de código, o problema cresce:

• A velocidade de entrega aumenta, mas a confiança não
• Revisores viram gargalos
• Desvios ocultos se acumulam mais rápido
• A dívida de qualidade aparece depois, com custos maiores

Uma preocupação comum de líderes é que nem toda equipe está pronta para isso. O problema principal não é senioridade, e sim o modelo operacional.

Essa abordagem exige que equipes pensem diferente:

• Definir o que é correto antes da execução
• Construir loops de feedback, não apenas prompts
• Projetar para lidar com falhas, não apenas caminhos ideais

Essas são habilidades aprendíveis, mas exigem estrutura e orientação.

Harness engineering é como equipes guiadas por especificações evitam esse gap de disciplina. Ele externaliza o conhecimento do time em controles explícitos, evitando depender de um único engenheiro experiente para garantir qualidade.

Um harness mínimo para começar (times Java com specs-driven)

Você não precisa de um framework gigante para começar.

Comece com uma topologia simples, como um serviço CRUD em Spring Boot, e construa um template reutilizável de harness.

Passo 1: Definir o pacote de especificações (Spec Pack)

• Descrição do problema
• O que não será feito (non-goals)
• Exemplos de aceitação
• Exemplos de contratos de API ou eventos
• Restrições operacionais (latência, logs, segurança)

Por exemplo, um spec pack para um endpoint POST /customers poderia ser assim:

# spec-pack/create-customer.yml
problem: Create a new customer record with validated contact info
non_goals:
  - Deduplication logic (handled by a separate service)
acceptance_examples:
  - input: { name: "John Doe", email: "john@example.com" }
    expected_status: 201
    expected_body_contains: ["id", "createdAt"]
  - input: { name: "", email: "invalid" }
    expected_status: 400
    expected_errors: ["name is required", "email format is invalid"]
contract: openapi/customers.yml#CreateCustomer
constraints:
  max_latency_ms: 200
  logging: structured_json
  auth: bearer_token

Este único arquivo dá ao agente limites claros, à suíte de testes objetivos claros e ao revisor um checklist claro.

Passo 2: Definir guias de Feedforward

• Convenções de código
• Limites arquiteturais
• Fluxo de “como implementar”
• Fluxo de “como testar”

Passo 3: Definir sensores de Feedback

• Build e checagens de tipo
• Testes rápidos
• Regras estruturais
• Verificação de contratos
• Uma etapa de revisão semântica para mudanças de alto risco

Passo 4: Fechar o ciclo de controle

Quando um problema se repete, não corrija apenas o código.

Melhore o harness:

• Adicione uma regra
• Adicione um sensor
• Melhore uma habilidade
• Melhore um exemplo de especificação

É aqui que harness engineering deixa de ser uma configuração pontual e passa a ser uma prática contínua de engenharia.

Depois que o harness existe, a próxima pergunta é como expandi-lo para outros times.

Como ajudar os times a terem sucesso

Torne o jeito certo o mais fácil

Não dependa apenas de documentos de boas práticas.

Codifique os padrões diretamente:

• Templates reutilizáveis
• Validações de schema embutidas
• Gates de validação em CI
• Comportamentos padrão de retry e escalonamento

Se o harness for opcional, ele será ignorado.

Conecte com padrões já conhecidos de engenharia

Reduza a carga cognitiva conectando conceitos de IA com conceitos familiares:

• Contrato de prompt → contrato de entrada de função
• Validação de saída → assertions de teste
• Política de retry → estratégia de tratamento de erro
• Conjunto de avaliação → mentalidade de fixtures de teste

Evolua as perguntas de revisão

Em vez de perguntar “esse prompt está bom?”, pergunte:

• O que define que isso está correto?
• Qual sensor valida isso?
• Qual é o caminho de falha?
• Quando devemos escalar?

Isso transforma o trabalho com IA em trabalho de engenharia.

O que parar de fazer

Se você está migrando para desenvolvimento de IA guiado por especificações, esses hábitos custam caro:

• Tratar um único prompt como se fosse uma “spec”
• Assumir que testes passando significam comportamento correto
• Deixar regras arquiteturais apenas no conhecimento informal do time
• Rodar checagens caras em todo lugar sem estratégia de custo
• Corrigir falhas recorrentes sem atualizar o harness

Esses padrões mantêm os times em modo reativo.

Um modelo mental melhor

Um resumo útil:

• Specs definem o estado desejado
• Harness define o sistema de controle
• Agentes executam mudanças dentro desse sistema
• Humanos direcionam e melhoram o sistema ao longo do tempo

É assim que equipes reduzem a necessidade de supervisão sem perder qualidade.

Não confiando mais no modelo.

Mas construindo um harness melhor.

Pensamento final

Prompts são o ponto de entrada. Não são o modelo operacional.

O verdadeiro ganho vem de construir sistemas onde o comportamento da IA é guiado, validado e continuamente melhorado.

Essa é a mudança:

De estagiário para sistema.