Human in the loop: alucinaciones y la falsa confianza
El problema de los modelos no es que se equivoquen. Los compiladores también se equivocan, los humanos nos equivocamos todo el tiempo. El problema es que se equivocan con el mismo tono con el que aciertan.
La confianza es estilo, no evidencia
Un modelo genera texto plausible. La seguridad de la redacción es una propiedad del estilo, no una medida de certeza. “El método Array.prototype.findLast no existe en Node 16” y “el método Array.prototype.findLastIndexOf acepta un segundo parámetro” se ven exactamente igual de convincentes; una es cierta y la otra es una invención de la casa.
Nosotros venimos entrenados socialmente al revés: asociamos seguridad con competencia. Por eso la falsa confianza del modelo pega tan bien en la parte del cerebro que también le cree al consultor que habla fuerte.
Dónde se cuela el error en la práctica
Las alucinaciones baratas —una función que no existe, un import inventado— se mueren solas: el compilador o el test las mata en segundos. Nadie llega a producción con import { magia } from 'nowhere'.
Las caras son otras. Un WHERE que parece correcto pero ignora los registros con deleted_at. Un manejo de zona horaria que funciona en Santiago y falla en el cambio de hora. Un retry sin idempotencia que cobra dos veces. Todas compilan, todas pasan los tests que también escribió el modelo, y todas son plausibles a la lectura rápida.
El patrón es claro: el riesgo no está donde la máquina es obviamente ignorante, sino donde es sutilmente confiada.
El humano no va “en el loop”, va en la frontera
“Human in the loop” se suele implementar como “que alguien mire antes de mergear”, lo que en la práctica significa que alguien apruebe 800 líneas a las 18:40 de un viernes. Eso no es supervisión, es un trámite con nombre en inglés.
Ubica al humano donde el error es irreversible o caro:
- Dinero y facturación. Siempre.
- Migraciones y borrados. Todo lo que no tiene
undo. - Datos personales y permisos. Un
WHEREde más aquí es un incidente legal. - Cambios de contrato público. APIs y eventos que otros consumen.
Y sácalo de donde la máquina verifica mejor: formato, refactors mecánicos, cobertura de tests, actualizaciones de dependencias con suite verde.
Verificar en vez de creer
La pregunta útil frente a cualquier salida no es “¿esto suena bien?” sino “¿cómo lo compruebo sin leerlo entero?”. Tipos, tests, ejecución real, comparación contra un baseline, consulta a la fuente. Un agente que puede correr lo que escribió y mostrarte la salida es cualitativamente distinto a uno que solo te la describe.
Regla práctica en mi equipo: ninguna afirmación sin evidencia adjunta. Si el reporte dice “los tests pasan”, el reporte trae la salida. Suena a burocracia hasta la primera vez que descubres que no habían corrido.
La parte incómoda
Los humanos también tenemos falsa confianza, y llevamos más tiempo practicándola. La diferencia es que a un colega lo calibras con el tiempo: sabes que Pedro es optimista con las estimaciones y que Ana nunca dice “listo” sin haberlo probado.
Con un modelo no hay calibración por reputación. Cada respuesta empieza de cero, con la misma seguridad. Por eso el sistema tiene que aportar la desconfianza que el modelo no aporta: no como pesimismo, como diseño.