O site que você está lendo foi desenhado, construído, revisado e publicado em um único dia. Um plano de doze tarefas, dezesseis commits, uma identidade visual completa, e tráfego em produção antes do jantar. A maior parte do trabalho foi feita por agentes de IA.
Essa frase é barata em 2026. Todo mundo tem uma demo. A parte que não é barata é esta: eu assinaria embaixo de cada linha que foi ao ar, e não li quase nenhuma delas.
A parte interessante não é a velocidade. É o que foi preciso para confiar no resultado.
01 / A regra
Um modelo conquista confiança pelo seu harness, não pelos seus pesos.
Você não compra qualidade trocando para um modelo maior ou escrevendo um prompt melhor. Você compra com a forma do loop ao redor do modelo. O loop tem três partes, e as três sustentam a estrutura:
- Um espaço de ação pequeno e tipado. O modelo recebe decisões de um conjunto fechado, não julgamento livre. Uma tarefa, um briefing, valores exatos para usar.
- Um verificador que o modelo não controla. A saída dele não vale nada até que algo com quem ele não pode discutir diga o contrário: um teste, um build, um revisor que nunca viu suas desculpas.
- Em caso de falha, tentar de novo com o erro do verificador em mãos. Não do zero, nem com um discurso motivacional. Com o erro exato, colado no contexto.
Decompor uma pergunta difícil em três verificáveis vence perguntá-la de uma vez, bem, todas as vezes.
02 / A forma do loop
Ao construir este site, o loop funcionou assim. Um plano dividiu o trabalho em doze tarefas, cada uma pequena o suficiente para que um modelo barato a executasse por transcrição. Cada tarefa recebeu um implementador novo, sem memória das outras: só seu briefing, as interfaces que toca, e as regras globais.
Depois vem a parte que a maioria pula. Cada tarefa também recebeu um revisor. As instruções do revisor incluem uma linha que faz quase todo o trabalho:
Trate o relatório do implementador como afirmações não verificadas sobre o código.
O relatório diz que os testes passam. Ótimo. Me mostra o diff. O relatório diz que o arquivo bate com o spec byte a byte. O revisor faz o diff de novo, ele mesmo. Os achados voltam ao implementador com a evidência anexada, as rodadas de correção têm um limite, e um controlador decide todo conflito entre o que o plano diz e o que o código precisa, registrando cada decisão. Nada é resolvido em silêncio.
Parece burocrático. Roda em minutos, em paralelo, e é o motivo inteiro pelo qual o resultado é confiável.
03 / O que o harness pegou
Teoria é bonito. Aqui está o que o loop de fato pegou em um dia, nada do qual eu teria pegado lendo o código sozinho.
Um design que falhava com gente que eu nunca vou conhecer. O vermelho de destaque deste site, sobre o fundo papel, mede um contraste de 3,85:1. Fica ótimo. Não cumpre os padrões de acessibilidade para texto pequeno. Um revisor calculou a razão, sinalizou, e a correção introduziu um vermelho mais escuro usado só onde o texto é pequeno. Você está olhando para ele nas tags do catálogo.
Um instrumento mentiroso. A etapa de verificação tirou capturas de tela mobile com Chrome headless e reportou o layout quebrado em 375px. Não estava. Abaixo de aproximadamente 500px, aquele build do Chrome monta o layout da página em 500 silenciosamente e recorta a imagem para a largura pedida. As capturas eram ficção. O agente que detectou isso não discutiu: construiu um teste de calibração, uma fileira de blocos de largura fixa que quebram linha em um ponto conhecido, e fixou o viewport real em 500px. Depois pilotou o navegador pelo protocolo DevTools em vez disso, encontrou um overflow real em 320px, e corrigiu. Verifique o instrumento antes de confiar no veredito dele.
O próprio chefe estando errado. Em certo momento, eu determinei, com confiança, que uma dependência precisava ser rebaixada para bater com o que estava instalado. O implementador, em vez de obedecer, checou: lockfile, instalação em modo dry-run, build, testes. Tudo verde na versão mais nova. Minha premissa vinha de dados desatualizados. A decisão foi revogada e o código foi publicado na versão que eu tinha proibido. Um harness onde o worker não pode ter razão contra o chefe é só burocracia com passos extras.
04 / O que não funciona
Os modos de falha são todos versões do mesmo erro: deixar a plausibilidade substituir a verificação.
Pular a revisão porque o resultado parece certo. Deixar o modelo corrigir o próprio trabalho, que é a mesma coisa fantasiada. Fazer uma pergunta grande para um modelo grande e torcer, em vez de decompor em respostas pequenas que dá para checar. Confiar no relatório em vez do diff. Confiar na captura de tela em vez do instrumento que a tirou.
Nenhum desses falha fazendo barulho. É isso que os torna caros. Uma falha barulhenta custa minutos. Uma resposta plausível e errada custa cada decisão construída em cima dela.
05 / O ponto
A frota não construiu este site porque os modelos ficaram inteligentes o suficiente. Os modelos já são inteligentes o suficiente há um tempo. Ela construiu o site porque cada unidade de trabalho passou por um portão que não conseguiu convencer com conversa.
O harness é o produto. O modelo é só a parte que você aluga.