Pare de Engenharia de Prompts: Como um Harness Avaliativo Permitiu Enviar 25 Versões de Algoritmos de Forma Autônoma

tl;dr — Agentes são bons em pequenas correções e terríveis em "melhorar este algoritmo" porque cada mudança parece boa isoladamente e regrediu silenciosamente em outros lugares. Nós construímos um harness de IA — conjunto de testes imutável, rubrica multi-eixos, ferramenta de varredura, agente revisor independente, interface de avaliação visível para humanos, camada de persistência de conhecimento — que permite que um agente itere em um algoritmo real de forma autônoma enquanto um humano ainda contribui com intuição no nível certo. Vinte e cinco versões do nosso pipeline de quantização de cores foram enviadas em 13 dias (o log do git não mente); as seis mais recentes delas em cinco dias, logo após a atualização do próprio harness. O harness, não os prompts ou a automação completa, é o que tornou esse ritmo seguro.

Duas advertências importantes desde o início, porque elas mudam como o resto deste artigo é lido:

1. Este é um trabalho de tempo livre em um projeto paralelo — noites, finais de semana, a ocasional pausa para o almoço. Não é uma equipe em tempo integral, não é um sprint dedicado.
2. O autor é um gerente de produto que não consegue ler uma única linha de código. Cada linha do pipeline de quantização real foi escrita por agentes de IA. A contribuição do autor é o harness, as hipóteses e a revisão a olho humano.

A razão pela qual 25 versões são até possíveis nessa intensidade, a partir desse autor, é que o harness faz a supervisão. Uma vez que o ciclo está configurado, cada iteração é "abrir um terminal, propor uma hipótese em inglês simples, olhar para o painel, aprovar ou reverter." Se algo, essas duas advertências são o argumento mais forte para construir o harness: ele converte as pequenas janelas de tempo que um não engenheiro realmente tem em progresso de algoritmo enviado que normalmente exigiria um engenheiro de CV em tempo integral.

O que o projeto realmente é (um parágrafo de contexto)

O produto é BMBrick — uma ferramenta gratuita baseada em navegador que converte qualquer foto em um mosaico pixelado estilo LEGO construível. Você envia uma foto do seu cachorro ou da sua foto de casamento, e recebe uma prévia, um PDF imprimível com o plano e uma lista de peças com as cores exatas dos tijolos LEGO 1×1 em cada posição da grade para que você possa realmente comprar os tijolos e construí-lo.

O "algoritmo" que está sendo ajustado no restante deste artigo é o pipeline de quantização de cores que decide qual das ~42 cores físicas de placas 1×1 da LEGO colocar em cada pixel do mosaico final. A restrição é o que torna isso difícil: você tem 16 milhões de valores RGB de entrada possíveis para mapear para 42 cores físicas de tijolos, e a saída ainda precisa parecer com a foto original quando alguém a monta na vida real. Se o mapeamento estiver errado, tons de pele se tornam faixas de cor sólidas, olhos perdem reconhecimento, fundos se quebram em manchas — o resultado construível se torna irreconhecível como a pessoa na foto.

O padrão de harness abaixo é o que construímos em torno desse pipeline de quantização para continuar iterando sem quebrar o que já funcionava. O padrão se generaliza; o mosaico LEGO é apenas o exemplo trabalhado.

1. Por que "deixar o agente consertar" falha em algoritmos reais

Se você tem programado em par com um agente por alguns meses, o padrão geral provavelmente é familiar:

• Refatorações e trabalho de UI: o agente é uma estrela. Você descreve o resultado, ele edita os arquivos, você executa testes, envia.
• Documentação: problema resolvido. Agentes escrevem melhores READMEs do que a maioria dos humanos.
• Ajuste de algoritmo: um desastre.

O modo de desastre é específico e vale a pena descrever. Você pede ao agente para "tornar a saída mais limpa nesta imagem." O agente tenta algo — digamos, aumenta um parâmetro de suavização. A saída na imagem que você mostrou parece mais limpa. Ele comete. Você segue em frente.

Três semanas depois, você descobre que a mudança de suavização regrediu sete outras imagens que você não estava olhando. Seis das "melhorias" do agente fizeram o mesmo. A base de código agora está cheia de ajustes enviados com confiança que você precisa bisectar um por um.

Isso não é uma falha do agente. É uma falha do harness. Especificamente: o agente não tinha uma maneira de saber que havia regredido algo mais. Pedir a ele de forma mais gentil não teria consertado isso. Engenharia de prompt mais cara não teria consertado isso. O problema é estrutural.

O que conserta isso: um harness de avaliação que o agente deve satisfazer antes que qualquer mudança seja enviada. Esse harness é sobre o que este artigo trata.

2. O que queremos dizer com "harness de IA"

Existem três pontos no espectro de autonomia do agente:

1. Engenharia de prompt — você elabora o prompt perfeito, o agente faz uma tentativa, você verifica a saída, você itera o prompt. Ótimo para geração única; terrível para trabalho contínuo porque nada se acumula.
2. Autonomia total do agente — soltar o agente em um repositório e esperar. Funciona para protótipos em campo; colapsa em código de produção porque o agente não tem como detectar quando está piorando as coisas.
3. Autonomia mediada por harness — você constrói um ponto de verificação automatizado entre "o agente propõe uma mudança" e "a mudança é enviada." O harness é o ponto de verificação. O agente pode iterar tão rápido quanto quiser, mas apenas mudanças que passam pelo harness sobrevivem. Criticamente, o harness tem dois revisores — um revisor de IA para throughput, um revisor humano para intuição — e as saídas de avaliação são projetadas para que ambos possam usá-las.

Temos executado nosso pipeline de quantização de cores LEGO através da opção 3 por 13 dias. Vinte e cinco versões enviadas; mais de onze experimentos rejeitados documentados. O intervalo mais impressionante: v18 → v19 saiu no mesmo dia, depois v22 / v23 / v24 / v25 nos quatro dias seguintes — seis versões em cinco dias, logo após a atualização do próprio harness. O mesmo harness pegou regressões que humanos perderam na revisão de código, mudanças de parâmetros que funcionaram em uma imagem e quebraram seis outras, e pelo menos duas tentativas de "IA me ajudou a reescrever isso de forma mais limpa" que introduziram efeitos colaterais em camadas que ninguém viu individualmente.

O resto deste artigo é a receita.

3. As cinco peças

Você pode construir um harness funcional com esses cinco componentes. Eles são individualmente óbvios; a combinação é o que faz o ciclo funcionar.

3.1 Um conjunto de testes imutável

Escolha um conjunto de entradas representativas e nunca as mude durante uma iteração de ajuste.

Para nosso pipeline, o conjunto de testes é 13 fotos: 4 retratos (humanos + animais de estimação), 2 retratos multi-sujeitos, 2 cenas de casamento, 2 paisagens, 1 objeto em close, 1 entrada deliberadamente borrada (controle negativo), 1 referência em preto e branco. Cada uma foi escolhida porque estressa um modo de falha específico (bandas de gradiente, pressão de paleta de tons de pele, manchas de fundo, etc).

Duas regras sobre o conjunto de testes:

1. Adicione novos casos apenas entre versões principais, nunca no meio da iteração. Mudar o conjunto de testes durante a iteração permite que o agente (e você) escolha vitórias.
2. Cada caso deve estressar algo específico. Não adicione "mais entradas" em massa; escolha entradas que exponham modos de falha distintos. Nossos 13 são aproximadamente ortogonais no que quebram.

O menor conjunto de testes útil é talvez 5 casos. Passando de 20, você está otimizando para o conjunto de testes em vez da distribuição real.

3.2 Uma rubrica de pontuação multi-eixos (não um escalar)

Se você reduzir a avaliação a um número, o agente otimizará para esse número e a lei de Goodhart se aplicará imediatamente. Use múltiplos eixos.

A nossa: