La normalización de los fallos inexplicables
El software y los dispositivos conectados fallan cada vez más de formas que usuarios e incluso desarrolladores no pueden explicar, desde caídas opacas en la nube hasta errores crípticos en coches modernos, fomentando una cultura de “esta cosa estúpida da asco” en lugar de una responsabilidad clara y análisis de causa raíz. Quienes comentan vinculan este cambio a sistemas probabilísticos y herramientas impulsadas por IA, a la presión de la gestión por la velocidad frente al rigor y a una menor atención a las prácticas tradicionales de ingeniería, advirtiendo que normalizar estos fallos inexplicables erosiona la confianza y la fiabilidad en toda la pila. Otros sostienen que, con la evaluación, las pruebas y un uso restringido en dominios críticos para la seguridad, la IA puede seguir siendo una ayuda poderosa en lugar de una fuente de caos.
Alcance de los “fallos inexplicables”
- Quienes comentan ven fallos opacos e imposibles de depurar cada vez más comunes en:
- Servicios en la nube y APIs que muestran errores 5xx de forma intermitente con “solo reintenta” como norma.
- Dispositivos de consumo (especialmente coches) que muestran advertencias vagas y conectividad inestable sin un diagnóstico claro.
- El comportamiento cotidiano del software/OS, donde “apágalo y enciéndelo de nuevo” es la solución de facto.
- Algunos sostienen que esto siempre ha sido así; otros creen que “moverse rápido y romper cosas”, la implantación continua y la reducción del control de calidad lo han empeorado notablemente.
Determinismo, sistemas probabilísticos e IA
- Se elogian los sistemas deterministas por sus modos de fallo predecibles y contratos claros; los sistemas probabilísticos/basados en LLM se ven como potentes pero difíciles de razonar o garantizar.
- Preocupación: normalizar el comportamiento probabilístico en bibliotecas centrales, infraestructura y compiladores podría erosionar la fiabilidad de toda la pila.
- Contraargumento: incluso el código generado por IA sigue siendo determinista una vez escrito; el problema real es la mantenibilidad y la calidad del diseño, no la probabilidad en sí.
Cultura de ingeniería, calidad y responsabilidad
- Hay desacuerdo sobre si “los bugs son inevitables”:
- Un lado: los bugs son en gran medida una decisión de negocio; “cero bugs” es posible, pero demasiado caro para la mayoría.
- Otro lado: las pilas profundas y los sistemas distribuidos complejos hacen que algunos fallos sean efectivamente inevitables; hay que diseñar para la imperfección y la resiliencia (p. ej., pruebas de caos).
- Historias de:
- Debates de sobreingeniería frente a YAGNI, con casos extremos descartados hasta que aparecen.
- Empresas que parchean problemas sistémicos con reinicios cron programados y tolerancia a latencias de cola horribles.
- Varias personas vinculan la “inexplicabilidad” con la falta de responsabilidad: la culpa puede trasladarse a proveedores, nubes o ahora “la IA”.
Experiencia de usuario e informes de errores
- Se critican ampliamente los diálogos de error opacos (“algo salió mal”).
- Muchos preferirían mensajes detallados, incluso técnicos, y un buen registro antes que alertas vagas.
- El diseño minimalista de “simplemente funciona” se ve con un “gemelo malvado”: “simplemente no funciona, y no puedes ver por qué”.
Dominios de alto riesgo y diferentes tolerancias
- La banca tradicional y la aviación se citan como dominios que aún exigen bajas tasas de error y comportamiento trazable, aunque hay contraejemplos y fallos bancarios visibles para el consumidor.
- Se argumenta que la exposición a esos dominios elevaría el nivel de los desarrolladores; otros enfatizan que los incentivos de gestión (velocidad, coste) superan las preocupaciones por la calidad.
LLMs, desarrollo agente, Jev y evals
- Muchas personas usan LLMs intensivamente e informan de que:
- Aceleran el desarrollo, incluidas las pruebas.
- Pueden tanto introducir como corregir bugs rápidamente, si se combinan con una cultura sólida de pruebas y de determinismo/reproducibilidad.
- Preocupaciones:
- OSS y software empresarial “codificado por vibra”: más funciones, pero UX incoherente, problemas de rendimiento y comportamientos difíciles de depurar.
- Directivos usando IA para sacar más cosas, más rápido, normalizando tasas de fallo silenciosas del 10% como “suficientemente bueno”.
- Servicios de clasificación como Jev:
- Algunas personas informan haber validado sus puntuaciones de confianza y haber encontrado un rendimiento sólido y rentable.
- Otras subrayan que esa validación (evals, benchmarks, pruebas A/B) es precisamente lo que a menudo falta; confiar en la confianza del propio sistema sin evals independientes se señala como peligroso.
- Consenso amplio: unas buenas evals son difíciles, pero esenciales. Sin ellas, demostraciones de IA espectaculares pueden ocultar un rendimiento mediocre en el mundo real y profundizar la cultura de los fallos inexplicables.