La normalización de los fallos inexplicables: cuando la IA hace que 'la cosa apesta' sea la respuesta aceptada

The Normalization of Inexplicable Failures

El artículo critica cómo los modelos de IA como Jev, de TypeSafe AI, devuelven valores con puntuaciones de confianza que nadie sabe calibrar ni usar bien. Los desarrolladores los adoptan por velocidad y bajo costo, sin evaluar fallos ni asumir responsabilidad. El autor teme que 'a veces simplemente apesta' se convierta en la conclusión habitual ante errores, en lugar de investigar causas concretas. Señala que el desarrollo acelerado por LLM podría mejorar el QA, pero se usa para evitar la rendición de cuentas.

La tragedia de la ingeniería de software actual es que estamos diseñando activamente sistemas en los que ni el usuario ni el constructor parecen tener interés en comprobar si hay un cuerpo detrás de la puerta. Nos encogemos de hombros y concluimos: la cosa apesta.
  1. pmarreck

    Me tomo muy en serio la reproducibilidad (aficionado a nix) y el determinismo (marcar fallos en tests es una situación de alerta roja, todos manos a la obra en mi mundo) y la corrección.

    También me tomo muy en serio el testing (de las cosas correctas). Y los nueve nueves (fan de Elixir).

    Y... también me tomo muy en serio el desarrollo asistido por agentes. Lo cual requiere prácticamente todas las comprobaciones habidas y por haber para mantenerse productivo. Y eso me parece bien. He visto bugs que yo no habría cometido. Y también he visto corregidos mis propios bugs. Todos se han corregido en poco tiempo. No veo por qué esto es un problema.

    Sube tus estándares personales.

    La cuestión es que la situación del software poco fiable ya era insostenible antes de que los agentes (en malas manos) la empeoraran.

  2. adamddev1

    Excelente artículo. La gente siempre defiende el desarrollo agéntico/basado en LLM diciendo: "Bueno, es suficientemente bueno", o "Funciona la mayor parte del tiempo".

    Eso puede ser tolerable para alguna app de cara al usuario. Pero ¿y si empezamos a normalizar los fallos en las librerías, la infraestructura y los compiladores? Todo degenera en un desastre de falta de fiabilidad, y eso ralentiza TODO y a TODOS.

  3. theamk

    > Cuando un botón se rompe en un sitio web, tengo un modelo de lo que debería haber pasado. En algún lugar se rompió un contrato. [...] Puede que no tenga acceso para depurar solo un estado HTTP 500, pero espero que haya alguien cuyo trabajo sea entender por qué el endpoint está devolviendo 500. La propiedad está bien definida aunque sea opaca³.

    > Sin embargo, para muchos usuarios, la experiencia real es más o menos solo "esta mierda apesta". El software ya se siente caprichoso; más fallos solo cambian la tasa de frustración.

    Apuesto a que el autor no usa mucho los servicios en la nube. No son solo "usuarios", también son desarrolladores. ¿Github devuelve 5xx? ¿Un servicio de AWS no funciona? ¿Tu correo no se entregó? No hay nada que nosotros (los desarrolladores) podamos hacer, "esta mierda apesta".

  4. layer8

    > Esto lleva a una normalización de lo inexplicable.

    También está estrechamente relacionado con una normalización de la falta de responsabilidad.

    > Esto no es "obtener una cuenta FTP, montarla localmente con curlftpfs y luego usar SVN o CVS en el sistema de archivos montado" -- todavía tienes que hacer la parte difícil.

    Probablemente a estas alturas esté perdiendo a la parte más joven de la audiencia. ;)

  5. WorldMaker

    Las "puntuaciones de confianza" siempre han implicado un significado antropocéntrico que no existe. Un algoritmo no tiene "confianza" de la forma en que una persona tiene confianza, pero en cuanto pones algo con ese nombre delante de un empresario, asume que el número siempre es una "curva de calificaciones con letras" significativa o un "porcentaje universal". Sigo creyendo firmemente que la vieja cita de "hay mentiras, malditas mentiras y luego estadísticas" sigue siendo clave para entender por qué el ML está llevando a resultados tontos en lugar de hype. La gente no entiende las estadísticas, así que las máquinas que no producen más que estadísticas confunden especialmente a la gente. (Creo que esto también se aplica a los LLM).

  6. teraflop

    La "normalización de lo inexplicable" es ciertamente indignante. Siempre ha sido mala en lo que respecta al software informático, y cada vez se está colando más en otros productos de consumo que dependen de software embebido.

    Compré un coche eléctrico nuevo hace poco. En general, he estado bastante contento con él. Poco después de comprarlo, empezó a aparecer un mensaje de advertencia que decía "revisar sistema EV" cada vez que lo arrancaba. Para cuando lo llevé al concesionario, la advertencia había desaparecido, y el técnico me dijo algo así como "eh, supongo que a veces hace eso, avísanos si vuelve a pasar". ¿Fallo de hardware? ¿Bug de software? ¿Quién sabe?

    Como la mayoría de los coches modernos, tiene conectividad y Google Maps integrados en el sistema de infoentretenimiento. La gran mayoría del tiempo, funciona bien. A veces dice que no tiene conectividad (lo que significa que no hay datos de tráfico y las rutas son subóptimas) durante todo un trayecto, incluso en zonas con buena señal celular donde normalmente funciona bien. A veces el coche dice que tiene conectividad, pero Google Maps sigue pensando que está offline. A veces Maps carga y muestra una ruta, pero el botón "iniciar navegación" se queda girando para siempre como si siguiera esperando algo. ¿Están relacionados estos problemas? ¿Hay una causa común que podría solucionarse? ¿Quién sabe?

    (Convenientemente, la garantía específicamente no cubre ningún fallo de software o firmware en funcionar correctamente).

  7. benjaminsky2

    He validado la puntuación de confianza de Jev. La precisión escala linealmente con la confianza para los 3 casos de uso que probé. >.9 coincidía con un etiquetador humano. Descubrí inmediatamente un comportamiento de usuario que no esperaba por ~$3. Ahora puedo mitigarlo en tiempo real gracias al bajo coste y la latencia. Esto puede tener un gran impacto financiero positivo para todos nuestros clientes.

    No sé por qué alguien sentiría la necesidad de criticar esto sin mostrar un ejemplo real de fallo.

  8. hyperhello

    Si pasas más tiempo con un producto, es más probable que elijas volver a hacerlo, aunque sea por un fallo o una molestia. Lo justificarías de alguna manera (ahora tengo ventaja o algo así). Esto también se aplica a mirar cosas; una caja de colores vivos en la estantería del supermercado simplemente tiene más probabilidades de ser elegida porque la miras primero y durante más tiempo.

    Hacerte perder tu tiempo y tus recursos es un signo de poder, pero conseguir que desperdicies tu propio tiempo y tus propios recursos es hegemonía.

Más de este día

2026-09-27