3 fallas silenciosas que casi nos cuestan caro usando IA (y cómo las cazamos antes)

¿Por qué un agente de IA puede fallar sin mostrar ningún error?

Un agente de IA puede declarar “listo” con total confianza y estar completamente equivocado — sin un solo error en pantalla. No es que el modelo “no sepa”: las fallas de agentes de IA suelen ser silenciosas — el código corre, se ve limpio, y falla exactamente donde nadie miró.

Construyendo un kit portátil con varios agentes de IA como comandos (Claude Code, GLM, Qwen Code y Codex) nos topamos con dos fallas que ilustran esto de forma muy concreta. Ninguna se detectó “porque el código se veía bien” — se detectaron re-verificando en vivo, no confiando en el reporte. Este método de re-verificación en vivo es el mismo que aplicamos en Varela Insights antes de poner cualquier agente de IA en producción de un cliente en México — es la diferencia entre automatizar y automatizar a ciegas.

¿Cómo detectamos un script que “se abre y se cierra” sin ningún error?

El síntoma: un script de arranque en Windows se abría y se cerraba al instante. Sin mensaje de error, sin pista. La explicación fácil (“algo está mal configurado”) no llevaba a nada.

La causa raíz apareció al exigir evidencia cruda (el output real del intérprete de comandos, no un resumen) en vez de conformarse con “debería funcionar”: el archivo combinaba finales de línea de Unix con caracteres especiales (símbolos, acentos) — una combinación que el intérprete de Windows no logra procesar, y que rompía silenciosamente cada línea del script.

El detalle técnico importa menos que lo que pasó después: al aplicar el mismo arreglo al resto de un kit completo, un barrido exhaustivo sobre los 13 scripts del proyecto encontró que 12 de ellos tenían el mismo bug — no solo el que originalmente se reportó roto. La lista “recordada” de la sesión anterior solo tenía 7 anotados. Casi el doble se había escapado.

¿Qué tan a fondo hay que verificar antes de decir “ya está limpio”?

Más de lo que uno cree. Antes de tratar un repositorio como seguro para compartir, no basta con mirar el árbol de archivos actual — hace falta revisar el historial completo. En este caso, se escaneó el 100% del historial de git (7 commits, ~565 KB) con una herramienta real de detección de secretos, no solo con un vistazo: el resultado fue 0 hallazgos reales, y 1 sola coincidencia que resultó ser un texto de ejemplo (sk-XXXX...), no una credencial real. Confirmar esto tomó menos de 10 segundos de escaneo — y sin correrlo, la afirmación “está limpio” habría sido una suposición, no un hecho.

¿Qué pasa cuando dos sesiones de IA resuelven el mismo problema sin coordinarse?

A mitad de una sesión de trabajo, al revisar el estado de un repositorio antes de una acción externa, apareció algo inesperado: otra sesión, con otro modelo, había resuelto un problema parecido horas antes — con un enfoque completamente distinto — sin que ninguna de las dos supiera de la otra.

Esto no es un defecto de una herramienta específica. Es lo que pasa con cualquier trabajo en paralelo sin comunicación explícita, humano o con IA: dos sesiones atacan el mismo problema, cada una convencida de que es la única trabajando en él.

Lo que cambia con IA es la velocidad a la que esto puede pasar sin que nadie se dé cuenta — y por eso el mecanismo que lo detectó importa más que el hallazgo en sí: antes de tomar la acción externa, se verificó el estado real (no el que la memoria de la conversación asumía) contra el sistema remoto directamente. Ahí apareció la divergencia — en menos de un minuto de verificación, antes de que la acción externa se ejecutara sobre una premisa equivocada.

¿Cuál es el patrón detrás de las 3 fallas?

Ninguna de las dos se cazó por “el código se ve bien” o “el agente dijo que ya funciona”. Se cazaron aplicando la misma disciplina, dos veces:

1. Exigir evidencia cruda antes de aceptar “listo”. No el resumen de un reporte — el output real, corrido de nuevo, en el momento.
2. Barrer, no confiar en la lista recordada. Un bug encontrado una vez casi siempre tiene más instancias de las que la memoria recuerda — en este caso, el doble.
3. Verificar el estado externo antes de actuar sobre él, en vez de operar sobre lo que la memoria de la sesión asume que es cierto.

Nada de esto es exclusivo de trabajar con IA — es disciplina de ingeniería de toda la vida. Lo que cambia es que un agente de IA puede generar volumen y confianza aparente mucho más rápido de lo que un humano puede verificar por instinto. La verificación deliberada deja de ser opcional.

¿Qué se lleva alguien que no usó este kit específico?

Si tu equipo (humano o con agentes de IA) está construyendo rápido, la pregunta que vale la pena hacerse antes de declarar algo “listo” no es “¿se ve bien?” — es “¿qué evidencia cruda tengo de que esto realmente pasó, corrida ahora mismo, no hace un rato?”. Las 3 disciplinas de arriba cuestan minutos aplicarlas. Cuestan mucho más no aplicarlas después de que algo ya se publicó, se compartió, o se rompió en producción.