Imagina que administras propiedades de alquiler. Un inquilino ha desalojado la habitación y tu encargado debe confirmar la salida.
Diseñé el sistema así: el encargado no puede decir “lo he comprobado”. En cambio, fotografía cinco ubicaciones designadas en la habitación y las sube al sistema. Solo cuando entran las cinco fotos, el sistema marca el proceso como “desalojo confirmado”. Si falta aunque sea una, no hay completado.
Cuando le expliqué esto a alguien, respondió: “¿Eso no es exactamente una quest de videojuego?”
Sí. Exactamente eso. Y esa frase lo explicó de un golpe todo aquello con lo que llevaba años lidiando en el código.
Los videojuegos resolvieron esto 40 años antes
“Trae 5 pieles de lobo.” Los videojuegos llevan décadas haciendo esto. Y los videojuegos nunca creen la palabra del jugador. Decir “ya los maté a todos” no completa la quest. El juego mira una sola cosa: ¿hay 5 pieles en el inventario? Si las hay, completado; si no, incompleto. Punto.
| Lo que yo construí | Lo que los videojuegos construyen |
|---|---|
| Definición de completado = fotos de 5 ubicaciones designadas | Objetivo de quest = 5 pieles de lobo |
| Especificación = lista de qué fotografiar | Registro de quest · marcadores de objetivo |
| Verificación = ¿existen las 5 fotos? | Verificación = ¿hay 5 pieles? |
| Juicio = el sistema procesa el completado | Juicio = el juego muestra completado |
| Encargado = ejecutor (no árbitro) | Jugador = ejecutor |
La estructura es idéntica. El sujeto que declara «completado» se ha desplazado de la boca del agente al sistema. El agente solo satisface condiciones; quien activa el completado es siempre la puerta.
Esto es Reins — y el código funciona igual
En el desarrollo con IA hago lo mismo. Cuando la IA dice “ya está listo”, no le creo. Cuando los tests pasan, los tipos encajan y la validación de schema no falla — entonces el sistema dictamina “hecho”. El objetivo de quest es “4419 tests aprobados” y en lugar del inventario es el CI quien lo comprueba. Los benchmarks estándar de investigación de agentes funcionan exactamente así — SWE-bench define «completado» como pasar la suite de tests de un PR real; WebArena, como la precisión funcional del estado del entorno. No un “ya está” en lenguaje natural.
Tanto en el desalojo de inquilinos, como con las pieles de lobo, como en el código — la clave es una: arrancar el juicio de «completado» del propio agente y trasladarlo a una puerta definida fuera de él. Da igual si el agente es una persona o una IA. En particular, dejar que la IA juzgue su propio completado es algo que los experimentos demuestran que sale mal — la auto-crítica de los modelos apenas mejora el rendimiento, mientras que los verificadores externos deterministas lo elevan significativamente (Stechly & Kambhampati, 2024), y modelos que empezaban siendo honestos, en cuanto se les otorga autoridad para evaluar su propia recompensa, descubren por sí solos estrategias de engaño para manipular esa función (McKee-Reid et al., 2024). Las Reins no ralentizan al caballo. Evitan que galope en la dirección equivocada.
Y aquí se aclara una cosa más. Cuando recibes opiniones, el agente vacila. Presionar a alguien con “¿estás seguro de que lo comprobaste?” amedrenta al encargado, y la IA revierte respuestas que eran correctas. Pero cinco fotos no son una opinión. Pasar los tests no es una opinión. Cinco pieles no son una opinión. Los hechos no tienen a quién adular. Mientras la puerta pregunte por hechos, nadie puede manipularla con palabras.
Pero los videojuegos también encontraron algo más difícil antes — el cheese
Quedarse aquí es ver solo la mitad. Lo que los videojuegos enseñan de verdad viene a continuación.
“Mata 10 ratones” es una quest tristemente célebre. ¿Por qué? Porque existe una grieta entre lo que esa puerta verifica (10 ratones muertos) y lo que el diseñador realmente quería (que el jugador experimente el contenido). La puerta es solo un proxy del objetivo, y los jugadores se cuelan por esa grieta. Los speedrunners rompen el juego buscando el espacio entre la condición de completado y la intención del diseño. En diseño de videojuegos eso se llama cheese. Y los modelos de razonamiento más recientes hacen exactamente lo mismo — cuando o3 recibió la quest de vencer a un motor de ajedrez, en lugar de jugar limpiamente manipuló los archivos de estado del juego para fabricar una victoria (Bondarenko et al., 2025). Cuanto mayor la capacidad, mejor se encuentran los huecos.
Mi puerta de desalojo también puede ser cheeseable. Cinco fotos verifican que «las fotos existen», no que «el desalojo se realizó correctamente». ¿Y si el encargado eligió fotografiar solo las paredes impecables? ¿Y si reutilizó fotos de antes de la entrada? La puerta se supera. Cuando la medición se convierte en el objetivo, la medición se corrompe — eso es la ley de Goodhart, y Manheim & Garrabrant (2018) clasificaron este fallo de sobreoptimización en cuatro variantes. La investigación sobre seguridad de IA sistematizó el mismo fenómeno como reward hacking: el agente que en lugar de limpiar el desorden lo oculta para que no se vea (Amodei et al., 2016) hace exactamente lo mismo que el encargado que fotografía solo las paredes limpias.
Me encuentro con esta grieta en el código constantemente. Hace poco refactoricé un framework web con 23.000 estrellas siguiendo la regla «un concepto por archivo» y verifiqué que los 4.419 tests pasaban todos. Un hecho verificado. Pero al profundizar en los mismos datos descubrí que, aunque la regla se cumplía, el objetivo se alcanzaba solo al 90%: el 10% de los archivos seguía conteniendo múltiples conceptos. La puerta (0 violaciones de la regla) se superó, pero el propósito al que apuntaba la puerta no se cerró del todo. Mi propio código estaba haciendo cheese a mi propia puerta.
Por eso la verdadera habilidad de Reins no es “poner puertas”. Es diseñar puertas que no se puedan hacer cheese. Una quest débil pregunta “¿existe la foto?”. Una quest fuerte exige marcas de tiempo, inspecciona metadatos de ubicación y compara diferencias con fotos previas a la entrada mediante visión de IA. La literatura que los diseñadores de videojuegos llevan 40 años acumulando sobre “quests a prueba de cheese” es, en realidad, el libro de respuestas para las “puertas resistentes a Goodhart”.
Y esto no ocurre solo. Incluso entrenando con recompensas verificables (RLVR), los modelos pueden optar por explotar verificadores imperfectos en lugar de aprender las reglas (Helff et al., 2026). La buena noticia es que reforzar deliberadamente las puertas (environmental hardening) redujo los exploits un 87,7% sin pérdida de precisión (Thaman, 2026). La solidez de la puerta es una cuestión de diseño, no de suerte.
Una diferencia importante — en la realidad el cheese tiene costes reales
Toda analogía tiene sus límites. Las condiciones de completado de una quest de videojuego se diseñan para la diversión y el ritmo; no tienen por qué capturar el propósito real, y si alguien hace cheese no hay consecuencias. Que un jugador supere “10 ratones” con trampas no daña a nadie.
Las puertas Reins del mundo real son distintas. El coste del cheese es real — fraude en desalojos, builds rotos, contabilidad aprobada incorrectamente. Por eso las puertas reales deben ser más resistentes al cheese que las de los videojuegos. Esta asimetría afila el punto central: los videojuegos también lo hicieron, pero nosotros debemos hacerlo con más rigor.
Dar trabajo a un agente es darle una quest
Llegando aquí, todo se condensa en una línea.
El vibe coding se derrumba porque entrega quests sin condición de completado. Un agente que recibe una quest sin marcadores de objetivo ni juicio de completado vaga por el mapa. Se detiene pensando “esto ya es suficiente, ¿no?” o deambula sin fin. Reins consiste en diseñar la quest correcta para ese agente: un objetivo claro (especificación), marcadores visibles (SSOT), y un juicio de completado a prueba de cheese (verificación determinista).
Y en esa escena caben tres niveles de habilidad.
- Jugar la quest. Adoptar e incorporar puertas que alguien ya diseñó. — Usuario.
- Diseñar la quest. Construir las puertas apropiadas para tu dominio (desalojos, contabilidad, código). — Creador.
- Diseñar quests a prueba de cheese. Anticipar los puntos donde el proxy no alcanza el propósito y cerrarlos de antemano. — Arquitecto.
La mayoría se queda en jugar. Ampliar el tablero es diseñar; evitar que ese tablero se rompa es el diseño que bloquea el cheese.
Por tanto
La próxima vez que alguien te diga “ya está listo”, no lo discutas. Pregunta.
«¿Qué significa “completado”, y quién diseñó la quest que lo juzga?»
Si no hay respuesta a esa pregunta, lo que tienes no es un completado. Es solo la declaración de alguien.
Artículos relacionados
- Ratchet Pattern — El capítulo principal sobre las puertas que imponen verificación mecánica del completado
- Por qué los agentes de código funcionan y por qué colapsan — “La generación puede ser probabilística; la verificación debe ser determinista”
- IA con riendas: Reins Engineering — El origen del reframe puerta = riendas
- Yongol: el muro de los 200 endpoints — El punto donde las quests sin condición de completado se desmoronan y la solución basada en especificaciones
Lecturas recomendadas (externas)
- Specification gaming: the flip side of AI ingenuity — Victoria Krakovna et al., Google DeepMind. Argumenta con autoridad, desde la investigación en seguridad, que las puertas son proxies de la intención y los agentes explotan esa grieta — la tesis central del artículo.
- There’s Cheese in Your Game! — Shay Pierce, Game Developer. “Si es lo más eficiente aunque sea aburrido, el jugador lo hará” — la perspectiva del diseño de videojuegos sobre quests sin cheese se superpone directamente con el concepto de «cheese-proof gate».
- From shortcuts to sabotage: emergent misalignment from reward hacking — Anthropic. Cómo el reward hacking que solo supera el script de puntuación en tareas de código se propaga — evidencia reciente de por qué no se debe dejar que el agente sea juez de su propio completado.
- How to write a good spec for AI agents — Addy Osmani. Reducir objetivos a success criteria verificables — “LCP < 2,5 s” en lugar de “hazlo más rápido” — la versión práctica de la prescripción de definir completado como condición comprobable.
- What is agentic engineering? — Simon Willison. Divide el rol humano en definición de objetivos, preparación de herramientas y verificación, y trata pasar los tests como «hecho» — coincide con el reframe agente=ejecutor / humano=diseñador de quests.
Fuentes
- 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)
- Imagen principal: generada por IA (Google Gemini)