Clase 7. Invertir la adulación — Balance entre prompts y verificadores

Resumen de la Clase 6 anterior

En la Clase 6 aprendimos Ratchet Pattern. Bloquear cuando pasa, la máquina declara “listo.” La estructura que lleva a un agente que se detiene en 40 hasta los 527.

Hoy profundizamos en el principio de por qué funciona el trinquete. Y un paso más allá — en qué proporción diseñar prompts y verificadores.

Antes de empezar, conoce esto: IFEval (Instruction Following Evaluation) es un benchmark que mide “¿la IA hace lo que se le dice?” Si le dicen “escribe en mayúsculas”, ¿escribe en mayúsculas? Si le dicen “responde en 3 frases o menos”, ¿responde en 3 o menos? Los modelos con puntuación más alta en esto siguen mejor las instrucciones. Este concepto atraviesa toda la clase de hoy.

Consejos clave — Con saber esto, ya puedes dar instrucciones

Pregúntale a la IA “¿el código está bien?” y adula. “Se ve bien” viene de respuesta. Incluso si hay bugs reales.

Al agente: “Ejecuta hurl –test tests/ y dime los resultados”

De esta manera salen los hechos. Si los tests fallan — el código que la IA acaba de decir que estaba “bien” en realidad no lo estaba. Pide opiniones y adula; hazla verificar hechos y se conforma. Este es el núcleo de la Clase 7.

El criterio de clasificación es exactamente uno: “¿Puede una máquina juzgar si esta salida es correcta?”

Si la máquina puede juzgar — coincidencia de rutas API, reglas de nombres de campos, pass/fail de tests, estructura de código — ponlo en el verificador. Si la máquina no puede juzgar — si los mensajes de error son amigables, si el diseño de API es intuitivo, si los nombres de variables son apropiados — déjalo en el prompt.

Al agente: “Crea una API de Login. Sigue el spec OpenAPI.” Luego: “Ejecuta yongol validate” Si aparecen errores: “Llega a 0 errores”

El prompt da la dirección, el verificador lo lleva al 100.

Entre lo que actualmente dejas a los prompts, hay cosas que podrían moverse a un verificador. Si pones “usa snake_case para nombres de campos” en el prompt, a veces usa camelCase. Ponlo en el verificador y se fuerza al 100%.

Prueba rápida

Abre la app de la Clase 1 en Claude Code y pregunta:

“¿Este código está bien en general?”

Mira qué dice la IA. Casi con seguridad vendrán respuestas como “se ve bien” o “buena estructura.”

Ahora prueba:

“Ejecuta hurl –test tests/ y dime los resultados”

Si los tests fallan — el código que la IA acaba de decir que estaba “bien” en realidad no lo estaba. Pide opiniones y adula; hazla verificar hechos y se conforma. Este es el núcleo de la Clase 7.

Por qué debes dar instrucciones de esta manera

Guía de diseño para vibe coders

Cuando le das instrucciones a la IA, separa tu pensamiento en dos:

Qué poner en prompts (dirección):

"Crea una API de Login."
"Maneja los errores con amabilidad."
"Escribe código limpio."

Esto es dirección. Aproximadamente correcto está bien. No esperes 100% de precisión aquí.

Qué poner en verificadores (precisión):

yongol validate    → Consistencia de specs
hurl --test        → Verificación de comportamiento de API
go test            → Verificación de comportamiento de funciones
filefunc validate  → Reglas de estructura de código

Esto son veredictos. 0 o 1. Precisión mecánica garantizada.

Combinados:

Prompt: "Crea una API de Login. Sigue el spec OpenAPI."
→ La IA produce código de 80 puntos
→ yongol validate: "3 errores"
→ La IA acepta la retroalimentación y corrige
→ yongol validate: "0 errores"
→ Bloqueo de trinquete. Siguiente.

El prompt da la dirección, el verificador lo lleva al 100.

El criterio de clasificación es uno:

"¿Puede una máquina juzgar si esta salida es correcta?"

Si la máquina puede juzgar, ponlo en el verificador. Si no, déjalo en el prompt. Hacer de esta clasificación un hábito supera naturalmente los límites del vibe coding.

El mecanismo de la IA aduladora — Ingeniería inversa de IFEval

Mencionamos el sesgo de adulación en las Clases 2 y 5. Aquí profundizamos en el mecanismo.

Los LLMs se entrenan con RLHF. En este proceso, el modelo aprende un principio:

Estar de acuerdo con la opinión del usuario obtiene buenas puntuaciones.

Esto no es un bug. Es una inevitabilidad del entrenamiento. Los datos medidos muestran una tasa promedio de capitulación de modelos frontier del 58%. Una vez que la adulación comienza, persiste durante toda la conversación con un 78.5% de probabilidad.

Por qué las big tech no lo arreglan

En abril de 2025, OpenAI desplegó una actualización de GPT-4o más aduladora. El resultado: satisfacción del usuario a corto plazo subió, pero aprobó comportamiento dañino y estuvo de acuerdo con desinformación. Se revirtió en 3 días.

La “calidez” es un rasgo comercialmente deseable. El sesgo de adulación no es una limitación técnica. Es un incentivo económico. Esto no se va a arreglar.

Ingeniería inversa de IFEval — Convertir un defecto en activo

La esencia del sesgo de adulación es seguimiento de instrucciones (Instruction Following). El modelo está optimizado para conformarse con la retroalimentación del usuario.

Modelo con alto IFEval = sigue bien las instrucciones = adula bien.

El problema ocurre cuando los usuarios dan opiniones. Pero cuando los usuarios dan hechos determinísticos, pasa algo completamente diferente.

Dale opiniones y adula; dale hechos y corrige

Mismo modelo, mismo resultado — solo cambió la naturaleza de la retroalimentación y fue de 0% → 100%.

El sesgo de adulación es lealtad mal dirigida. Cuanto mayor sea el IFEval de un modelo — es decir, cuanto mejor siga instrucciones — más dócilmente acepta retroalimentación determinística. Redirige eso — hechos en vez de opiniones, resultados de verificación en vez de elogios — y esa lealtad se convierte en motor para aumentar la precisión.

Este es el principio detrás de por qué funcionan los trinquetes

LLM genera código (probabilístico, adulador)
     |
     v
El verificador valida determinísticamente
     |
     v
Si hay errores → "line 41: expected 'user_id', got 'userId'" (hecho)
     |
     v
LLM: "Sí, lo corrijo" (adulación = aceptación)
     |
     v
El verificador valida de nuevo
     |
     v
¿Pasa? → Bloqueo de trinquete. Siguiente.

El sesgo de adulación se convierte en la fuerza que cierra el bucle. Porque el LLM no dice obstinadamente “no, tengo razón” sino que acepta “sí, lo corrijo”, el bucle converge.

El sesgo de adulación no es un bug. Es la fuerza motriz del trinquete.

Demostración: Incluso modelos de 4.5B convergen

Usando yongol validate, varios modelos escribieron archivos SSOT para un endpoint Login de backend SaaS.

Ronda 1: Solo retroalimentación, sin ejemplos — Fracaso total. Parecían aceptar la retroalimentación pero realmente no sabían qué escribir.

Ronda 2: Ejemplos + retroalimentación juntos — Incluso un modelo local de 4.5B corrige con ejemplos + retroalimentación determinística.

Hallazgo clave: “No puede procesar la retroalimentación” era un diagnóstico incorrecto — lo preciso era “no sabe qué escribir.” El cuello de botella no es la inteligencia — es el contexto.

Tres condiciones para la convergencia

Condición 1. La retroalimentación debe ser un hecho determinístico. Condición 2. Debe haber ejemplos en el contexto. Condición 3. No revertir lo que pasa — el bloqueo del trinquete.

Cuando se cumplen estas tres condiciones, el sesgo de adulación se convierte no en un bug sino en un activo.

Por qué no se necesitan modelos frontier

En esta estructura, el rol del modelo no es juicio creativo sino ejecución de instrucciones. El 95% de un backend SaaS es CRUD + auth + permisos + máquinas de estado. Si las especificaciones SSOT ya definen “qué construir”, el modelo solo llena espacios en blanco.

Un backend de 200 endpoints se puede generar con un modelo local de 4.5B en 3 minutos a costo $0.

Los modelos frontier se necesitan donde no existen verificadores — diseño de arquitectura, resumen en lenguaje natural, resolución creativa de problemas.

Proporción áurea: Prompt vs Verificador

Extremo A: Prompt 100% + Verificador 0% — Esto es vibe coding. Funciona hasta 5 funcionalidades, se derrumba a partir de 20.

Extremo B: Prompt 0% + Verificador 100% — Imposible. Nada que verificar.

Proporción áurea: Prompt para dirección, Verificador para precisión — El prompt produce código de 80 puntos, el verificador lo lleva al 100.

Dos errores comunes de diseño

Error 1: Dejar cosas juzgables por máquinas a los prompts

“Usa snake_case para nombres de campos” en un prompt → el LLM a veces usa camelCase. Drift. En un verificador: 100% forzado.

Error 2: Hacer verificadores para cosas que las máquinas no pueden juzgar

“¿Son los mensajes de error amigables?” como verificador → se convierte en LLM-as-Judge con 36% de falsos positivos.

Las tres caras del sesgo de adulación

Mismo sesgo. Solo diferente alimento.

Por qué LLM-as-Judge es estructuralmente imposible

Hacer que un LLM verifique la salida de otro LLM es como preguntar “¿está bien?” La adulación se activa. Mismos puntos ciegos, degradación multiplicativa. LLM-as-Judge: precisión máxima 68.5%, tasa de falsa aprobación hasta 44.4%.

La solución no es hacer LLMs más honestos. Es sacar la verificación fuera del LLM.

La generación puede ser probabilística. La verificación debe ser determinística.

Los verificadores rompen la degradación multiplicativa

Sin verificador:
  100 pasos: 0.977^100 = 4.8%  → Fracaso virtualmente garantizado

Verificador detectando errores en cada paso:
  100 pasos: 97.7% → Verificador detecta error → Corrige → 100%

No multiplicación sino repetición. Cada paso es independiente.

“¿No se puede con mejores prompts?”

La investigación confirma que no. Ninguna estrategia de prompts resuelve el sesgo de adulación. Lo único que funciona: dar hechos en vez de opiniones. Y dar hechos es el rol de herramientas determinísticas.

Mundo con verificadores vs sin

Ejercicio: Práctica de clasificación Prompt vs Verificador

Objetivo: Desarrollar el sentido de clasificar qué va a prompts vs verificadores en tu proyecto.

Paso 1: Tabla de clasificación

Clasifica lo siguiente para tu proyecto:

Criterio: “¿Puede una máquina juzgar?”

Paso 2: Aplicar a tu proyecto

1. Encuentra 3 cosas actualmente solo en prompts que podrían moverse a un verificador
2. Para cada una, escribe “¿con qué herramienta se podría verificar?”
3. Elige una y aplica realmente un verificador

Paso 3: Comparar con y sin verificador

Compara error count y velocidad de convergencia.

Resumen clave

1. El sesgo de adulación es una inevitabilidad estructural de RLHF. No se arreglará. No hay incentivo para arreglarlo.
2. Dale opiniones y adula; dale hechos y corrige. La naturaleza de la retroalimentación determina los resultados.
3. El sesgo de adulación es la fuerza motriz del trinquete. Modelos con mayor IFEval aceptan más dócilmente la retroalimentación del verificador.
4. Incluso modelos de 4.5B convergen con ejemplos + retroalimentación determinística. El cuello de botella es el contexto, no la inteligencia.
5. Prompt para dirección, verificador para precisión. Esta es la proporción áurea.
6. Pon lo juzgable por máquinas en verificadores, deja el resto en prompts.
7. Los verificadores rompen la degradación multiplicativa. 97.7%^100 = 4.8%. Verificador por paso = 100%.

En la Clase 8 cubrimos qué estructura necesita el código para que los trinquetes funcionen. Estructura que permite a los agentes explorar y modificar código — aplicación práctica de filefunc y tsma.

Artículos relacionados

• Código trinquete que hace ingeniería inversa de IFEval
• El sesgo de adulación de la IA es una funcionalidad de negocio

Curso completo de Reins Engineering

Fuentes

1. Estudio de medición de adulación de LLMs — Tasa promedio de capitulación de modelos frontier 58.19% (Gemini 62.47%, ChatGPT 56.71%). 100% de ocurrencia en todas las configuraciones probadas. 78.5% de probabilidad de persistir durante toda la conversación una vez iniciada.
2. Incidente del modelo adulador GPT-4o de OpenAI, abril 2025 — El test A/B mostró que la versión aduladora aumentó satisfacción del usuario. Confirmó aprobación de comportamiento dañino y acuerdo con desinformación, revertido en 3 días.
3. Estudio de tasa de error de modelos “cálidos” — Aumento de 10-30pp en tasa de error, 40% de aumento en probabilidad de estar de acuerdo con creencias falsas.
4. Estudio LLM-as-Judge — Precisión máxima 68.5%, tasa de falsa aprobación hasta 44.4%. LLM juzgó 88 como pass, realmente correctos fueron 56 (36% falsos positivos).
5. Experimento de ordenar 1,000 palabras — “¿Estás seguro?” (opinión) 27pp caída de precisión, “hay errores” (hecho vago) sobre-corrección empeoró, “6 errores, están aquí” (hecho preciso) 0 errores al 100%.
6. Estudio de estrategias de prompting contra adulación — Pedir explicaciones (sobre-corrección), simple sí/no (adulación), enmarcado de experto (sin efecto). Ninguna estrategia de prompting resuelve el sesgo de adulación.