O loop de feedback que mudou como eu uso IA

Eu usei o OpenCode "cru" por uns dias e quase abandonei.

Abria o terminal, selecionava um modelo que eu não conhecia bem, mandava um prompt, esperava a resposta, lia, copiava, colava, ajustava, mandava de novo. Era a mesma dança que eu fazia com o GPT, só que pelo terminal. O que estava errado? Nada, tecnicamente. O que estava faltando? Tudo.

O GitHub tinha acabado de cortar meu Copilot, eu migrei pra OpenCode achando que ia ser "outro Copilot". Mas o OpenCode tem uma diferença brutal: ele não é só um chat com IA. É uma CLI, com sistema de agentes, com orquestração, com agent swarm. O leque de coisas que dá pra fazer com ele é absurdo — e eu estava usando como se fosse um bloco de notas glorificado.

Eu sabia que, se ficasse nesse "prompt, espera, vê, prompta de novo", eu não ia extrair nem 10% do que a ferramenta entrega. Aí eu decidi parar e estudar. Modelos, pontos fortes, casos de uso. Orquestração. Filosofia por trás. Estudando os modelos e a documentação do OpenCode, eu encontrei a primeira coisa que mudou de verdade como eu uso IA: o loop de feedback.

O que é (de verdade) um loop de feedback

A coisa mais simples do mundo, quando a gente para pra olhar.

Você pede uma coisa. O agente faz. Você olha o que ele fez. Se não bateu o que você queria, você aponta o erro e pede de novo. O agente corrige. Você olha de novo. Quando bateu, acabou.

O detalhe que parece óbvio — mas que não é — é que o "olha" e o "aponta o erro" são uma segunda ação. Não é o mesmo passo do "pede". É um passo separado, que precisa de critério. Sem critério, o loop vira loop infinito. O caso clássico: você pede um botão, o agente te devolve três. Você fala que só queria um. Ele te devolve dois, e ainda inventa uma lógica que você não pediu. Você tira a lógica, ele põe o botão de volta. Duas horas depois, o botão tá certo — mas só porque você desistiu de pedir mais nada.

É exatamente isso que a Anthropic chama de "evaluator-optimizer" (avaliador-otimizador): um LLM (ou humano) gera a resposta, outro (ou o mesmo, com outro papel) avalia, e a avaliação vira input pra próxima iteração. O nome é pomposo, o conceito não.

Onde o conceito fica mais interessante é na segunda parte do trabalho deles, sobre "harness design" — a estrutura que envolve o agente em tarefas longas, com planner, generator e evaluator. O ponto central: separar quem produz de quem julga. Não é vaidade de framework. É porque o mesmo modelo, avaliando o próprio trabalho, tende a se aprovar. Você pede "está bom?", o agente responde "está bom", e a conversa acaba sem ter entregado nada útil.

Enquanto eu estudava, encontrei uma implementação concreta do conceito: o oh-my-opencode-slim, o mesmo plugin que eu detalhei no post Por que eu saí do Copilot. Ele monta um time de sete agentes em cima do OpenCode, cada um com um modelo diferente — um orquestra, outro explora o código, um busca documentação, um revisa arquitetura, um cuida de UI, um executa, e um roda múltiplos modelos em paralelo pra dar veredito. Eles não competem entre si; o orquestrador reconcilia. É o harness design em sete agentes, com o modelo certo pra cada papel.

Aí o loop vira de verdade um loop: o gerador faz, o avaliador julga, o gerador corrige. Os dois podem ser o mesmo modelo, com prompts diferentes. A separação tá no papel, não na tecnologia.

Por que difere de um prompt

Um prompt é uma pergunta. Um loop é um processo.

A diferença apareceu pra mim no menu do site. Pedi "faz o menu funcionar", o agente me devolveu três opções que eu não pedi. Pedi uma só, ele tirou duas e adicionou uma animação que também não pedi. Pedi pra tirar a animação, ele tirou — e quebrou no mobile. Cinco iterações depois, o menu funcionava. Mas a primeira resposta, sozinha, não tinha chance.

Aí fica claro: um prompt te dá uma resposta; um loop te dá um resultado.

O prompt funciona bem quando a tarefa cabe inteira na cabeça do modelo. "Me explica o que é closure." "Escreve uma função que soma dois números." "Traduz essa frase." Resposta única, critério único, acabou. É o cenário onde o GPT brilha e onde o Copilot original entregava valor — completions curtas, autocompletes, explicações pontuais.

O prompt começa a sabotar quando o critério não cabe na cabeça do modelo, ou quando o critério é grande demais pra caber num único olhar. "Refatora esse módulo." "Implementa esse fluxo de checkout." "Faz esse site funcionar em mobile e desktop." São tarefas com N decisões, cada uma com N ramificações. O modelo não erra por preguiça — erra porque a soma das pequenas decisões rende um resultado que não é o que você queria.

Aí o loop aparece não como feature, mas como necessidade. O critério vira explícito: "tem que renderizar, tem que passar lint, tem que ser acessível". Cada iteração é uma checagem contra esse critério. A primeira resposta raramente bate. A terceira, às vezes. A quinta, geralmente. Mas a primeira sozinha — sem o loop — não tinha chance.

O que muda, na prática, é que o prompt é uma relação de mão única: você fala, o modelo responde, acabou. O loop é mão dupla: você fala, o modelo responde, o critério julga, o modelo corrige. O segundo tem chance de convergir. O primeiro só converge por acaso.

No projeto real

O lugar onde o loop virou concreto foi aqui: na construção deste site.

Stack é Next.js 16, Tailwind v4, shadcn/ui, com VitePlus (vp) como toolchain. Sem framework de teste. Verificação padrão do projeto: vp run build (production build) e vp run lint (ESLint via Oxlint). Mais o type-check, que precisa ser rodado à mão porque o next.config.mjs está com typescript: { ignoreBuildErrors: true } — ou seja, erros de tipo não quebram o build. O tsc --noEmit é uma verificação à parte.

O loop que eu montei em cima disso virou quatro critérios explícitos: build, lint, type-check, e render visual. Os agentes verificavam contra esses critérios antes de me entregar. Se algum falhasse, a falha virava input pra próxima iteração. Quando os quatro passavam, a mudança chegava pronta.

Foi aí que o loop começou a mostrar o que ele faz de diferente.

O caso mais claro foi a camada de primitivos do design system. Pedi ao agente pra criar Article, Header, Cover, SectionHeading, Badge, MetaItem — seis primitivos que iam virar a base visual do site. O primeiro veio com assinaturas inconsistentes, padronizou, e na hora de remover uma prop que ninguém usava, quebrou uma chamada que esperava ela. Build/lint/tsc passaram, render quebrou. Foi o loop que pegou.

O mesmo padrão se repetiu na decomposição de componentes. O BlogPostView virou quatro subcomponentes: post-back-link, post-header, post-cover, author-card. Cada iteração pequena, cada verificação rodada, cada commit só quando os quatro passavam. O loop virou o ritmo do trabalho: cada commit era um round do loop, cada merge era o critério passando.

E, na prática, isso já rodava orquestrado. O omo-slim gerenciava o time: um agente propunha a mudança, outro agente rodava os gates de qualidade (build, lint, type-check, grep no output dos JS e HTML gerados pra garantir que tudo estava lá), e o orquestrador reconciliava. Quando os critérios eram aceitos, ele me entregava com a flag verde. Eu só precisava fazer a checagem visual antes de commitar. O loop virou de mão dupla entre agentes — um fazia, outro julgava, o orquestrador reconciliava — e o humano virou o último gate, não o primeiro.

A coisa que mais me chamou atenção: as iterações raramente precisavam de mais de cinco rounds. A primeira resposta cobria 60–70% do critério. As duas ou três seguintes cobriam o resto. Sem o loop, eu teria olhado a primeira resposta, achado "tá ok", e seguido — e o erro de tipo ou de render teria ido pra produção.

O que isso muda em mim

Três coisas concretas.

A primeira é atenção. Antes do loop, eu gastava uma fração grande do meu tempo fazendo o que a máquina faz melhor: rodar build, conferir lint, caçar erro de tipo. Era trabalho de qualidade, mas era trabalho mecânico. Hoje, esse trabalho roda entre agentes, e o que sobra pra mim é a parte que máquina não faz: o julgamento de intenção, a checagem visual, a decisão de quando o critério é o critério certo. Eu troquei horas de conferência por minutos de decisão.

A segunda é postura. Quando o loop roda entre agentes, eu deixei de ser o "prompter" que escreve prompt e fica torcendo. Virei o "diretor" que define o critério, deixa o time rodar, e entra quando o critério não fecha. É uma diferença sutil na superfície, mas muda o tipo de erro que eu pego. Antes eu pegava erro de output. Agora eu pego erro de critério.

A terceira é o que sobra pro humano. Quando o agente verifica o próprio trabalho, quando outro agente valida contra o output, quando o orquestrador reconcilia — o humano vira o último gate, não o primeiro. O ganho de tempo é real, mas o ganho mais interessante é de atenção: o que me exigia 80% de foco mecânico, agora exige 20% — e os outros 80% viraram tempo de pensar o que vale a pena construir, em vez de conferir o que já foi construído.

Eu não aprendi a usar IA. Aprendi a verificar.

Por onde ir

• OpenCode (opencode.ai) — o cliente onde o loop roda.
• oh-my-opencode-slim (github.com/alvinunreal/oh-my-opencode-slim) — o plugin que transforma o OpenCode num time de 7 agentes especializados (Orchestrator, Explorer, Oracle, Council, Librarian, Designer, Fixer), com modelo certo por papel.
• Anthropic: Building Effective Agents — onde o conceito de "evaluator-optimizer" é formalizado.
• Anthropic: Building verification loops in Claude Code — a aplicação prática do loop como skill reutilizável.
• Anthropic: Harness design for long-running apps — sobre a estrutura que envolve o agente em tarefas longas, com planner/generator/evaluator.