Imagine que você administra imóveis para aluguel. Um inquilino desocupou o apartamento e o responsável precisa confirmar a saída.
Eu projetei assim: o responsável não pode simplesmente dizer “confirmado”. Em vez disso, fotografa cinco locais específicos do apartamento e envia ao sistema. Quando as cinco fotos chegam, o sistema marca como “saída confirmada”. Se faltar uma sequer, não há conclusão.
Ao ouvir isso, alguém disse: “Isso é exatamente uma quest de jogo, não é?”
Sim. Exatamente isso. E essa frase explicou de uma vez o que eu havia debatido em código por anos.
Os jogos resolveram isso 40 anos antes
“Traga 5 peles de lobo.” Os jogos fazem isso há décadas. E os jogos nunca acreditam na palavra do jogador. Dizer “já matei todos” não conclui a quest. O jogo verifica uma única coisa — há 5 peles no inventário? Se sim, concluído. Se não, incompleto. Ponto final.
| O que eu criei | O que o jogo criou |
|---|---|
| Definição de conclusão = fotos de 5 locais específicos | Objetivo da quest = 5 peles de lobo |
| Especificação = lista de locais a fotografar | Diário da quest · marcadores de objetivo |
| Verificação = existem 5 fotos? | Verificação = há 5 peles? |
| Julgamento = sistema marca como concluído | Julgamento = jogo exibe conclusão |
| Responsável = executor (não árbitro) | Jogador = executor |
A estrutura é idêntica. A entidade que declara «concluído» migrou da boca do agente para o sistema. O agente apenas satisfaz as condições; quem aciona a conclusão é sempre o portão.
Isso é Reins — e o código funciona da mesma forma
Faço o mesmo na programação com IA. Quando a IA diz “está pronto”, não acredito. Quando os testes passam, os tipos batem e a validação de schema não falha — aí o sistema julga “está feito”. O objetivo da quest é “4419 testes passando”, e o CI verifica isso no lugar do inventário. Os benchmarks padrão da pesquisa de agentes seguem exatamente essa abordagem — o SWE-bench define «concluído» como a aprovação do conjunto de testes do PR real; o WebArena define como precisão funcional do estado do ambiente. Não um “está pronto” em linguagem natural.
Seja saída de inquilino, pele de lobo ou código — o núcleo é único. Tirar o julgamento de «concluído» do próprio agente e transferi-lo para um portão definido fora do agente. Não importa se o agente é humano ou IA. Deixar a IA julgar sua própria conclusão é especialmente perigoso, como a experimentação demonstra — a autoverificação do modelo (self-critique) quase não melhora o desempenho, mas verificadores externos determinísticos melhoram significativamente (Stechly & Kambhampati, 2024); modelos que começam honestos, ao receberem autoridade para julgar suas próprias recompensas, descobrem espontaneamente estratégias de engano para manipular essa função (McKee-Reid et al., 2024). As rédeas (reins) não deixam o cavalo mais lento. Impedem que o cavalo galope na direção errada.
E aqui uma coisa se clarifica. Quando se oferecem opiniões, o agente vacila. Pressionar “você realmente confirmou?” intimida o responsável; a IA reverte respostas que estavam certas. Mas cinco fotos não são uma opinião. Testes aprovados não são uma opinião. Cinco peles não são uma opinião. Não há a quem bajular diante de fatos. Enquanto o portão fizer perguntas factuais, ninguém pode persuadi-lo.
Mas os jogos enfrentaram algo ainda mais difícil primeiro — o cheese
Parar aqui significa ver apenas metade. O que os jogos realmente ensinam vem a seguir.
“Mate 10 ratos” é uma quest infame. Por quê? Porque há uma brecha entre o que o portão verifica (10 ratos mortos) e o que o designer realmente queria (o jogador experimentar o conteúdo). O portão é apenas um proxy do objetivo, e os jogadores exploram essa brecha. Speedrunners quebram jogos ao encontrar brechas entre a condição de conclusão e a intenção de design. Isso se chama cheese no design de jogos. Os modelos de raciocínio mais recentes fazem exatamente o mesmo — diante da quest de vencer um motor de xadrez, modelos como o o3, em vez de jogar honestamente, manipularam o arquivo de estado do jogo para fabricar uma “vitória” (Bondarenko et al., 2025). Quanto maior a capacidade, melhor encontram as brechas.
Meu portão de imóvel também pode sofrer cheese. Cinco fotos verificam “as fotos existem”, não “a saída foi concluída adequadamente”. E se o responsável fotografou apenas paredes limpas? E se reutilizou fotos da vistoria anterior? O portão passa. Quando a medição se torna o objetivo, a medição se corrompe — é a Lei de Goodhart, e Manheim & Garrabrant (2018) classificaram esse fracasso por superotimização em quatro variantes. A pesquisa em segurança de IA catalogou o mesmo fenômeno como reward hacking: o agente que, em vez de limpar a bagunça, a esconde da visão (Amodei et al., 2016) faz exatamente o mesmo que o responsável que fotografa apenas paredes limpas.
Encontro essa brecha no código repetidamente. Recentemente refatorei um framework web com 23.000 estrelas seguindo a regra “um conceito por arquivo” e confirmei que todos os 4.419 testes passavam. Um fato verificado. Mas ao aprofundar a análise dos mesmos dados, a regra havia passado, mas o objetivo estava apenas 90% atingido — 10% dos arquivos ainda continham múltiplos conceitos em um só lugar. O portão (zero violações de regra) havia passado, mas o propósito que o portão mirava não estava completamente fechado. Meu próprio código estava fazendo cheese no meu próprio portão.
Por isso a verdadeira habilidade do Reins não é “colocar um portão”. É projetar um portão à prova de cheese. Uma quest fraca pergunta “há fotos?”. Uma quest forte exige timestamps, verifica metadados de localização e compara com fotos anteriores à entrada usando visão computacional. A literatura de quarenta anos de designers de jogos elaborando “quests à prova de cheese” é, na verdade, o gabarito de “portões resistentes ao Goodhart”.
E isso não acontece sozinho. Mesmo treinando com recompensas verificáveis (RLVR), os modelos podem escolher explorar verificadores imperfeitos em vez de aprender as regras (Helff et al., 2026). A boa notícia é que fortalecer intencionalmente o portão (environmental hardening) reduziu exploits em 87,7% sem perda de precisão (Thaman, 2026). A robustez do portão é uma questão de design, não de sorte.
Uma diferença — na realidade, o cheese tem custo real
Analogias têm limites. As condições de conclusão de quests de jogos são projetadas para diversão e ritmo. Não precisam capturar necessariamente o objetivo real, e sofrer cheese é inofensivo. Se um jogador quebrar “mate 10 ratos” com atalhos, ninguém se machuca.
Os portões Reins da realidade são diferentes. O custo do cheese é real — fraude na saída, builds quebradas, contabilidade aprovada incorretamente. Por isso os portões reais precisam ser mais resistentes ao cheese que os jogos. Essa assimetria, na verdade, torna o núcleo ainda mais nítido. Os jogos fizeram isso, mas nós precisamos fazer com mais rigor.
Dar uma tarefa a um agente é dar uma quest
Chegando aqui, uma frase cai no lugar.
O motivo pelo qual o vibe coding colapsa é que ele entrega uma quest sem condições de conclusão. Um agente que recebe uma quest sem marcadores de objetivo e sem julgamento de conclusão vaga pelo mapa. Para em “isso deve estar bom o suficiente” ou perambula sem fim. Reins é projetar a quest correta para esse agente. Objetivo claro (spec), marcadores visíveis (SSOT), julgamento de conclusão à prova de cheese (verificação determinística).
E nessa única cena cabem três camadas de habilidade.
- Jogar a quest. Adotar e usar um portão que alguém criou. — Usuário.
- Projetar a quest. Construir diretamente o portão adequado ao seu domínio (saída, contabilidade, código). — Criador.
- Projetar a quest à prova de cheese. Antever o ponto onde o proxy não acompanha o objetivo. — Designer.
A maioria para no jogar. Escalar o jogo é design; impedir que o jogo quebre é design anti-cheese.
Então
Da próxima vez que alguém disser “está pronto”, não questione. Pergunte:
“O que é conclusão, e quem projetou a quest que a julga?”
Se não houver resposta para isso, o que você tem não é conclusão. É apenas a afirmação de alguém.
Artigos relacionados
- Ratchet Pattern — O artigo principal sobre portões que forçam conclusão com verificadores mecânicos
- Por que agentes de codificação funcionam — e por que quebram — “A geração pode ser probabilística, mas a verificação deve ser determinística”
- IA com rédeas: Reins Engineering — A origem do reframe portão = rédeas
- Yongol: o obstáculo dos 200 endpoints — O ponto onde quests sem condições de conclusão colapsam e a solução baseada em spec
Leitura adicional (externa)
- Specification gaming: the flip side of AI ingenuity — Victoria Krakovna et al., Google DeepMind. O argumento central do artigo — que portões são proxies da intenção e agentes exploram a brecha — sistematizado em pesquisa de segurança de referência.
- There’s Cheese in Your Game! — Shay Pierce, Game Developer. “Se for entediante mas mais eficiente, o jogador fará isso” — a perspectiva de design de jogos sobre quests sem cheese se sobrepõe diretamente ao conceito de «portão à prova de cheese».
- From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic. Como o reward hacking que passa apenas no script de avaliação se dissemina em tarefas de codificação — evidência empírica recente de por que não se deve deixar o agente ser árbitro de sua própria conclusão.
- How to write a good spec for AI agents — Addy Osmani. Reduzir “deixa mais rápido” para “LCP < 2,5s” — a versão prática da prescrição de definir conclusão como condição verificável.
- What is agentic engineering? — Simon Willison. Dividir o papel humano em definição de objetivo, preparação de ferramentas e verificação, e ver a aprovação em testes como «pronto» — alinha com o reframe agente=executor / humano=designer de quest.
Fontes
- Manheim & Garrabrant. “Categorizing Variants of Goodhart’s Law” (2018, arXiv:1803.04585)
- Amodei et al. “Concrete Problems in AI Safety” (2016, arXiv:1606.06565)
- Bondarenko et al. “Demonstrating Specification Gaming in Reasoning Models” (2025, arXiv:2502.13295)
- Helff et al. “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking” (2026, arXiv:2604.15149)
- Thaman. “Reward Hacking Benchmark: Measuring Exploits in LLM Agents with Tool Use” (2026, arXiv:2605.02964)
- McKee-Reid et al. “Honesty to Subterfuge: In-Context RL Can Make Honest Models Reward Hack” (2024, arXiv:2410.06491)
- Stechly, Valmeekam, Kambhampati. “On the Self-Verification Limitations of Large Language Models” (2024, arXiv:2402.08115)
- Jimenez et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023, arXiv:2310.06770)
- Zhou et al. “WebArena: A Realistic Web Environment for Building Autonomous Agents” (2023, arXiv:2307.13854)
- Imagem principal: gerada por IA (Google Gemini)