np_auditor ← volver
27 de julio, 2026

El pedo real de las “alucinaciones” en producción

“Alucinación” ya está tan gastada que no diagnostica nada. Aquí hablamos de dos fallas concretas, medibles, que le pasan a cualquier agente que escribe código o toma acciones — y de por qué revisar “a ojo” no escala.

Falla 1: afirma algo que no pasó

Termina y te dice: “creé auth.py, importé bcrypt, y las pruebas pasan.” Tres cosas checables. Ninguna es verdad solo porque suena segura. La forma barata de enterarte es que truenen en prod tres días después. La forma correcta: medir cada afirmación en el momento — ¿existe el archivo? ¿se usa el import? ¿corrió el test? — y marcar verified o contradicted antes de que le creas.

Eso hace np_verify_response. No es una segunda IA opinando: es re-medición.

Falla 2: el código apunta a algo que nunca existió

Patrón típico: usa una función, clase o import que nunca definió. No es error de sintaxis (eso lo cacha el intérprete). Es una referencia fantasma que parece válida hasta que se ejecuta esa rama — a veces mucho después de que ya “revisaste” por encima. El análisis estático la encuentra con línea exacta, sin correr nada.

Por qué a mano no escala

Un developer puede cacharlo una o dos veces. No la vez 40, en un archivo que no escribió, un día que confía porque las otras 39 salieron bien. El vector real no es la falla suelta: es cuando dejas de revisar porque “normalmente jala”.

Cuando deja de ser molestia y se vuelve riesgo de lana

Si programas solo, un invento de código es un bug de review o CI. Si tu agente mete la cuchara en pagos — autoriza, concilia, SPEI, datos financieros — una frase no checada (“la cuenta destino ya validó”) que resulta falsa no es un bug: es dinero moviéndose sobre una premisa que nadie confirmó. En LATAM los agentes llegan a pagos más rápido que la vigilancia. Esa brecha es el pedo que resolvemos — no el meme de “la IA a veces se equivoca”.

Auditar esto en serio

No es un checklist de una vez al mes. Es la misma disciplina en tres momentos: antes del prompt, después de la respuesta, y sobre el código que queda. Cada uno cacha una falla distinta. Ninguno sustituye a los otros dos.