A Builder.io Viu Cada Salto Vir da Verificação: O Que Contém um Verificador Confiável

Um job de importação em que “88% dos pixels não batiam com o original” caiu para 2% em um fim de semana, usando um único modelo menor. A Builder.io relata isso como um único job, resultado próprio, e atribui o ganho ao verificador: “Todo salto entre rodadas veio de mudar a verificação, não o modelo.”

Essa frase é a parte útil. Quando um loop trava, escreve a Builder.io, “é tentador culpar o modelo e trocar por um maior. Isso teria sido inútil aqui. A verificação estava errada.” A IronBee, uma segunda equipe, descreve a mesma disciplina pelo outro lado: um juiz que só pode escolher entre opções oferecidas e precisa citar ids de evidência.

Os dois resultados vêm de uma equipe cada e são autorrelatados. Nenhum dos dois serve de prova para alegações de custo ou de acurácia. Lemos os dois como um roteiro: o que uma verificação precisa conter antes de você deixar um loop confiar nela.

Leituras relacionadas: três ingredientes de loops de agentes em produção, o harness decide a nota, autoaperfeiçoamento e o conjunto de avaliação, o modelo de decisão no caminho de controle. Este texto parte da construção do próprio verificador.

Como é uma verificação errada

A Builder.io relata quatro bugs na própria verificação que tornaram os resultados pouco confiáveis. Dois dos números que ela traz mostram o formato do problema.

Fontes que nunca carregaram fizeram uma exportação “parecer 17% diferente quando a diferença real era 0,19%”. A verificação media uma falha de renderização e a reportava como falha de design. No sentido oposto, uma página em branco pontuou de 3 a 5% na primeira versão da verificação e 57% ou mais depois da correção. Uma página em branco é um caso em que o veredito certo é conhecido, e a primeira versão da verificação errou.

Nenhuma das duas é falha do modelo. Na nossa leitura, um modelo mais forte apontado para essa verificação teria perseguido um erro de 17% inexistente, e capacidade gasta contra uma verificação errada mira o alvo errado.

Calibre a verificação com casos que você já conhece

A página em branco é o caso de calibração mais barato que existe. Você sabe a resposta certa antes de rodar qualquer coisa: ela deve pontuar como falha. O mesmo vale para uma saída sabidamente boa, que deve passar.

Lemos os dois números da Builder.io como argumento a favor de uma etapa permanente de calibração. Antes de a verificação julgar qualquer saída do agente, rode-a em um conjunto pequeno de casos em que uma pessoa já decidiu o veredito, com pelo menos um obviamente quebrado e um obviamente correto. Se a página em branco passa, a verificação não está pronta. Na nossa leitura, essa etapa teria exposto a nota de 3 a 5% da página em branco antes de ela influenciar uma rodada.

A fonte não diz que a Builder.io rodou casos de calibração com antecedência. A recomendação é nossa, tirada do que as falhas teriam mostrado.

Um conjunto retido deixa de ser retido quando você ajusta contra ele

A rodada 4 da Builder.io passou em 28 de 28 casos acompanhados e em apenas 3 de 5 casos retidos. A folha de estilo trazia 21 media queries, muitas cobrindo só 25 a 50 pixels. Lemos isso como uma saída ajustada aos casos que ela via: breakpoints estreitos são o que se escreve quando se está casando larguras de teste específicas em vez de construir um layout.

Na nossa leitura, os casos retidos cumpriram o papel: expuseram o ajuste que os casos acompanhados premiavam.

O resultado da IronBee mostra a rapidez com que essa proteção se corrói. O teste de 130 replays terminou como esperado em 110 de 130 execuções no início e em 130 de 130 depois das correções. As correções foram ajustadas no mesmo conjunto de teste, e a loja usada era uma demo em localhost que a IronBee controla. É resultado de fornecedor, e 130 de 130 em um conjunto contra o qual você ajustou diz pouco sobre a próxima execução no site de outra pessoa.

A regra prática é mecânica. Um conjunto retido só é retido enquanto ninguém olha as falhas dele. Quando você lê uma falha retida e ajusta o agente ou a verificação em resposta, aquele caso passou a integrar o conjunto acompanhado. Mantenha um segundo conjunto, não lido, para a próxima rodada, e renove-o.

Um juiz que escolhe e cita

A restrição de projeto da IronBee cabe em cinco palavras: “Jev picks. It never writes.” O juiz escolhe entre opções que recebe. Um veredito do zero fica fora do alcance dele. Cada veredito cita ids de evidência (a IronBee mostra [r3], [l12] e [s5] como exemplos), de modo que uma pessoa pode abrir o item citado e conferir se ele sustenta a decisão. Um LLM entra apenas como alternativa para execuções travadas.

Duas propriedades importam para uma implantação governada, na nossa leitura. Um juiz limitado a opções oferecidas não consegue inventar uma condição de aprovação que você não listou. E um veredito que aponta para um id de evidência pode ser auditado depois por alguém que não estava lá.

A IronBee também relata onde o juiz dela falhou, o que é mais útil que o número de destaque. Em um caso, julgou uma tarefa da Airbnb concluída com p=0,99 sem que a busca tivesse sido refeita. Em outro, um pedido da Kindle passou com p=0,51 enquanto o estado real era PAYMENT_FAILED. Uma probabilidade alta ligada a um veredito errado e uma aprovação ligada a um pagamento que falhou são o mesmo defeito visto de dois ângulos: a nota não estava amarrada ao estado do mundo. Por isso o id de evidência pesa mais que a probabilidade. A probabilidade é a confiança do juiz em si mesmo. O id de evidência é algo que você pode ir olhar.

A IronBee é um estudo de caso de fornecedor que promove o Jev, construído pela TypeSafe. Usamos como segundo ponto de dados para o padrão de construção, não como benchmark.

Concordância não é independência

Um segundo revisor adicionado a uma verificação fraca pode parecer garantia. Philipp Dubach, em um texto conceitual sobre gestão de conhecimento corporativo, afirma o limite diretamente: “Automated review can support this process, but agreement is not independent verification. Two agents may reach the same conclusion because they relied on the same mistaken decision note.” Em tradução livre: a revisão automatizada pode apoiar o processo, mas concordância não é verificação independente, porque dois agentes podem chegar à mesma conclusão ao confiar na mesma nota de decisão equivocada.

Tome o bug das fontes como ilustração (nossa, sem origem na Builder.io): dois juízes pontuando o mesmo render quebrado reportariam o mesmo número errado. Independência vem de uma entrada diferente, de uma medição diferente ou de uma pessoa, e um segundo modelo lendo o mesmo artefato não fornece nenhuma das três.

Uma condição que acrescentaríamos

Nenhuma das fontes descreve o próximo item, então trate-o como proposta de projeto nossa. Uma verificação que o agente pode editar não é verificação. Se o loop deixa o agente afrouxar um limite, pular um caso ou reescrever o script de pontuação para obter aprovação, o verificador passa a fazer parte do que está sendo verificado.

Tornaríamos a verificação inacessível ao agente, com uma saída explícita. Quando o agente conclui que a verificação está errada (e às vezes estará, como mostram os quatro bugs da Builder.io), ele para e escreve o motivo, em vez de alterar a verificação. Uma pessoa decide então quem está errado, a verificação ou o agente. A saída importa porque, sem ela, um agente diante de uma verificação quebrada tem duas opções, e uma delas é burlá-la.

Faça isto agora

Escolha um loop que você roda hoje e audite a verificação dele com esta lista:

Rode-a em uma saída em branco ou obviamente quebrada. Ela reprova?
Rode-a em uma saída que você sabe estar correta. Ela aprova?
Localize o conjunto retido. Alguém leu as falhas dele e agiu sobre elas? Se sim, monte outro.
Olhe um veredito. Ele cita algo que você pode abrir, ou só uma nota?
Veja quem pode editar a verificação. Se o agente pode, remova esse acesso e adicione um caminho de parar e explicar.

Se o loop travou, faça essa auditoria antes de trocar o modelo.

Fontes

Builder.io. “Build an agent loop a small model can finish.” Outubro de 2026.
IronBee. “How We Built the Fastest, Cheapest Browser Agent with Jev.” Outubro de 2026.
Philipp D. Dubach (blog pessoal). “Enterprise Knowledge Management: Connecting AI to Action.” Outubro de 2026.

A Victorino ajuda equipes de engenharia a auditar as verificações por trás dos loops de agentes antes que elas decidam o que vai para produção: contato@victorino.com.br | www.victorino.com.br