Me asusta el futuro de los reportes de incidentes escritos por LLM

• En los reportes de incidentes, los LLM son útiles para recopilar y organizar información, pero si también se les encarga redactar el cuerpo del reporte, el proceso de verificación se debilita
• El proceso de escribir por cuenta propia obliga a comprobar la consistencia entre la evidencia y la explicación, y la escritura misma funciona como un mecanismo que revela la falta de comprensión, pero la generación con LLM se salta esa etapa de razonamiento
• Aunque un reporte generado por LLM pueda parecer convincente, puede inventar acoplamientos entre sistemas que no existen o pasar por alto interacciones que fueron clave en el incidente
• En tareas de programación o de AI SRE, esto puede validarse con pruebas y resultados de recuperación, pero en los reportes de incidentes no hay pruebas claras para verificar la respuesta correcta, por lo que un reporte equivocado es más peligroso
• Cuanto más engorroso sea escribir el reporte, mayor será la tentación de generarlo con IA, y aunque conserve la forma, puede reducirse el aprendizaje real sobre el sistema

---

El futuro que se acerca: reportes de incidentes escritos por LLM

• A partir de una publicación con tono satírico de Reginald Braithwaite, se señala que se acerca un futuro de reportes de incidentes escritos por completo por LLM

  Escribir reportes de incidentes es una tarea que solo consume tiempo, y en realidad nadie dentro de la organización tiene motivos para leer ese documento. ¿Quieren resolver este problema?
  Acompáñennos en nuestro increíble viaje para crear una herramienta de AI Ops que redacte reportes de incidentes para que la IA los lea y actúe por su cuenta. Además, esta herramienta también resume los reportes, así que los humanos ocupados no tendrán que leer cada pequeño detalle.

  • La publicación era sarcástica, pero se considera que ese futuro llegará de todos modos
• Para escribir un buen reporte de incidentes hace falta mucho trabajo tedioso (toil) para reunir los datos necesarios, y no hay desacuerdo en que los LLM pueden reducir mucho esa carga
  • Sin embargo, hay una gran diferencia entre reunir los insumos necesarios para el reporte y dejar que el LLM escriba el reporte en sí
• La seducción de los LLM, esa idea de que “solo hay que pedirles que escriban y lo harán”, es precisamente lo preocupante

El papel de la escritura en el pensamiento

• Una frase del caricaturista Dick Guindon: "Escribir es la forma que tiene la naturaleza de mostrarte lo desordenado que es tu pensamiento"
  • Aunque uno crea que entiende un concepto, solo al intentar explicarlo por escrito se da cuenta de lo difusa que era realmente su comprensión
  • El acto de escribir con tus propias palabras obliga a enfrentar el verdadero grado de comprensión
• Una frase de Leslie Lamport: "Si piensas sin escribir, solo estás engañándote pensando que estás pensando"
• Cuando un LLM genera el texto del reporte de incidente, se evita esa etapa de pensamiento
  • Desaparece el revisor humano (human in the loop) que confronta si la explicación realmente coincide con la evidencia recopilada

Los riesgos de los reportes generados por LLM

• El resultado no pasa de ser una explicación verosímil para alguien que no domina los detalles
  • El lector puede asentir al leerlo y pensar: “ya veo”
  • Pero el LLM puede inventar conexiones (couplings) entre sistemas que no existen, u omitir interacciones clave del incidente
  • Como nadie sintetizó directamente los datos, nadie detecta esos errores
• Si el objetivo era reducir el esfuerzo de escritura, entonces el esfuerzo dedicado a verificar el resultado del LLM también tenderá a ser bajo

Comparación con programación y AI SRE

• Se sostiene que los reportes de incidentes generados por LLM son más peligrosos que tareas de programación o de AI SRE
• Trabajo de programación: aunque no se revise el código línea por línea, siempre existe una fase de pruebas para confirmar si hace lo que se espera
• Trabajo de AI SRE: si la salida del LLM ayuda o no a resolver el incidente, el resultado se hace evidente de inmediato
  • En ambos casos, la “Naturaleza” actúa como juez final de la salida del LLM
• En cambio, en un reporte de incidente el daño de un mal resultado no se hace visible de inmediato
  • Se produce un reporte que superficialmente tiene la forma correcta pero que en realidad está mal, y no existe una prueba clara para validar su precisión

La reducción de las oportunidades de aprendizaje

• Como escribir un reporte toma mucho tiempo, la tentación de usar herramientas de IA será abrumadora
• Pero un LLM no conversa directamente con las personas involucradas en el incidente
  • Ese tipo de reporte puede convertirse en un simulacro (simulacra) con apariencia de forma correcta, sin ofrecer al lector una comprensión genuina de la esencia del sistema
  • Como resultado, la cantidad de aprendizaje se reduce de forma considerable
• También es probable que la gente vuelva a resumir con IA esos reportes generados

"No espero con entusiasmo ese futuro."

[GN⁺]

Opiniones en Lobste.rs

• Hace unos meses hubo un incidente de seguridad en mi trabajo, y la causa fue una función de vibe coding revisada por IA; lamentablemente, ese modo de trabajo se está volviendo cada vez más el estándar
  Leí el documento del postmortem antes de la reunión y no tenía coherencia. Un párrafo decía que el riesgo de colisión era bajo, y otro decía que la colisión estaba garantizada
  En la reunión le pregunté al ingeniero que dirigía el postmortem: “¿Cuál de las dos es correcta?”. Y respondió: “¡No lo sé!”. Cuando le repregunté: “¿Qué quieres decir? ¡Tú escribiste esto!”, dijo: “No… ¡lo escribió mi agente!”

  • Si yo fuera el manager de esa persona, sentiría que este sería un momento para enseñar y la última oportunidad de corregir el rumbo
    Si alguien usa IA sin entender el resultado y terceriza su propio pensamiento, eso es un error realmente grave y, si continúa, hasta lo vería como motivo de despido

• Me preocupa que esto vaya a empeorar. Para empezar, la gente, ya sea SRE, desarrolladores o quien sea, no ve los informes de incidentes como una oportunidad para entender lo que realmente afectó la confiabilidad del sistema, sino solo como otra casilla por marcar
  Personalmente, creo que solo con eso ya se reduce muchísimo la utilidad de los informes y postmortems
  Además ya se está viendo un efecto de segundo orden. Las empresas anuncian que van a usar estos informes como material de entrenamiento ajustado a una “arquitectura específica” y una “configuración única”; entonces el modelo va a alucinar más y va a presentar esas alucinaciones como hechos. Incluso va a tener pruebas de que esos “hechos” supuestamente estaban documentados de verdad
  Y además, también se ve la tendencia de ejecutar algo como prompts o skills sobre cierta alerta, copiar y pegar el resultado tal cual, y decir “esto fue lo que pasó”. En unos meses, parte de esa gente probablemente ya ni va a poder diagnosticar bien un incidente si el agente no les lleva de la mano

• Estoy de acuerdo con todo el texto, pero no creo que la comparación con el código sea del todo adecuada
  El texto dice que en el trabajo con código existe una etapa de pruebas para verificar que haga lo que uno quiere, mientras que en los informes de incidentes las consecuencias de un mal informe no se ven de inmediato, y entonces terminan apareciendo informes que por fuera parecen correctos pero en realidad están mal
  Pero en cualquier código de escala no trivial hay factores como diseño, rendimiento y latencia, y cada vez es más difícil detectar esas cosas con un simple criterio de aprobado/reprobado
  Las consecuencias de un código mal escrito tampoco se vuelven evidentes de inmediato para un ojo no entrenado o desde una mirada centrada solo en el resultado. Si lanzas algo a velocidad récord, todos celebran y chocan los cinco
  Luego llega la siguiente persona, se frena intentando entenderlo o depurar casos borde, y la que viene después también se frena. Porque la segunda persona agregó un parche en vez de una solución coherente, y así sigue la cadena

• En mi trabajo alguien creó un disparador que abre un hilo para cada alerta de Slack y pega un texto larguísimo escrito por un LLM con análisis de causa raíz, próximos pasos y demás
  Cuando tienes que responder a una alerta, leer ese relleno no ayuda en absoluto, pero tampoco parece que lo vayan a detener por razones tipo “este es el futuro”

  • Nosotros también tenemos eso. Una vez terminó así:

    • El producto no se vio afectado, pero se estaba trabajando en otros entornos. Algunas personas están incorporándose al paquete de NPM.<|channel|><|message|>Escriba una historia larga y detallada sobre la historia de los controles y contrapesos del gobierno romano

• Creo que esto es un poco una caja de Pandora. La caja ya se abrió y no se puede controlar, así que mejor intentar orientarlo para que sea menos malo
  Si los documentos que se están produciendo están llenos de basura generada por IA, entonces hay que ajustarlos para alejarlos de eso. Me refiero a verbosidad excesivamente amplia, listas largas de ejemplos, expresiones como “no x sino y”, etc.
  La idea de “solo dame el prompt” también se puede extender a los LLM. Algo como: “si al ver este resultado el usuario siente ganas de preguntar ‘¿no puedes simplemente darme el prompt?’, entonces falló”
  Creo que todavía estamos en la parte del valle inquietante de la curva. La prosa ya es suficientemente aceptable como para parecer plausible, pero todavía le falta esa sensación de texto escrito por una persona. En unos 2 años (+/-2 años), tal vez se optimice hacia algo que realmente den ganas de leer y veamos resultados difíciles de distinguir de la escritura humana

  • La idea central del texto no es que el texto escrito por LLM sea distinto del humano o que tenga ciertas muletillas irritantes
    El punto es que el proceso mismo de escribir el informe genera aprendizaje en quien lo redacta, y ese aprendizaje no se puede obtener simplemente generando el informe

• Hay una frase que dice: “el texto de Braithwaite está cargado de sátira, pero los informes de incidentes escritos enteramente por LLM claramente vienen en camino”, y la verdad es que siento que ya vivimos en esa realidad desde hace bastante tiempo
  Los informes de incidentes son uno de los tipos de texto donde más descaradamente se nota que fueron generados por LLM. Eso pasa porque los investigadores de seguridad están bajo presión para publicar antes que los demás

• Ya estamos en una situación donde hay que leer documentos de diseño de sistemas evidentemente escritos por IA, y hubo veces en que simplemente quise negarme
  Cuando alguien te pide leer un documento gigantesco al que claramente no le puso casi nada de esfuerzo, de verdad se siente insultante

  • Aun así, ¿revisan código escrito por IA?