En informática, consideramos que un sistema es observable cuando podemos conocer su estado sin interrumpir su funcionamiento ni tener que acceder al mismo. Solo con la información emitida por dicho sistema.
 
Asegurar la observabilidad de nuestro software siempre ha sido clave para crear tecnología eficiente y con sentidiño, pero en un momento en el que no solo escribimos menos código —también leemos menos— cobra especial importancia comprobar cómo está funcionando. Si ignoras cómo lo está haciendo, al menos debes estar seguro de qué carallo está haciendo.
 
El software del futuro será observable o no será, pero seguir concibiendo la observabilidad únicamente como una simple técnica de desarrollo sería un grave error. La IA la ha transformado en una disciplina clave para asegurar nuestra propia existencia.
 
Porque uno de los grandes retos a los que se enfrenta el sector informático es la incorporación de profesionales sin experiencia cuando la inteligencia artificial ha separado el proceso de construcción del de aprendizaje.
 
Durante décadas, escribir código fue también la manera de aprender a desarrollar software. Tomábamos decisiones, nos equivocábamos y, a base de prueba y error, interiorizábamos buenas prácticas y asimilábamos conceptos.
 
Los séniors disfrutamos de ese proceso, pero los que aterrizan ahora en un sector que ha delegado la implementación en agentes no tendrán esa oportunidad para entender por qué una solución es mejor que otra. Para aprender a contradecir a la máquina.
 
¿Qué pasará cuando los veteranos vayan jubilándose si quienes los sustituyan apenas han tenido ocasión de desarrollar ese criterio? ¿Renunciaremos a entender mínimamente cómo funciona el software que usamos? ¿A nuestra capacidad para aportar algo en su proceso de construcción y mantenimiento?
 
Kunal Bhalla define esa rendición cognitiva: aceptar lo que los agentes generan sin espíritu crítico, sin reflexionar, explorar ni considerar alternativas.
 
Kunal reconoce que trabajar así resulta extremadamente rápido y no exige un gran esfuerzo, lo que lo hace muy tentador, pero también advierte del círculo vicioso en el que nos atrapa: cuanto menos comprendemos un sistema, más dependemos de un agente para repararlo o modificarlo. Y con cada cambio que aceptamos sin entenderlo aumenta esa dependencia.
 
Multiplicamos nuestra capacidad de producir cambios mientras reducimos nuestra capacidad de evaluarlos. Corremos el riesgo de acabar convertidos en meros meat proxies. Que el único valor que aportemos sea «preguntar a la IA».
 
La observabilidad puede ayudarnos a romper ese círculo vicioso, siempre que ampliemos lo que pretendemos observar.
 
Para empezar, la observabilidad no debe limitarse al rendimiento o la disponibilidad del software, sino que también debe ser capaz de medir el valor que aporta.
 
Imaginemos que observamos una aplicación que gestiona devoluciones para una gran cadena de moda. Tan necesario es saber cuánto tardan de media las peticiones a la base de datos como saber cuántas devoluciones se completan correctamente.
 
Y para conseguirlo, hoy por hoy, debemos observar dos capas: tanto el comportamiento del software generado por la IA como las posibles interacciones con ella.
 
De nada me sirve observar el código que gestiona una devolución si el mismo incluye una llamada a un LLM para calcular los gastos de envío de la que desconozco tanto el contexto aplicado como las instrucciones suministradas.
 
La clave es tener todas las pruebas necesarias para cuestionar lo que la máquina asegura que ha hecho y, en caso de error, saber qué tenemos que corregir o mejorar.
 
Un buen ejemplo es esta publicación de Pablo Rodríguez, que lleva bastante tiempo trabajando para aplicar observabilidad a la IA. En ella se ve cómo una ejecución se había quedado bloqueada porque Git había abierto un editor interactivo que esperaba respuesta (un problema de proceso), pero también cómo una instrucción demasiado amplia cerraba los tests de otras aplicaciones (problema de contexto).
 
El propio sistema propone cambios en el entorno y restricciones para evitar repetir esos incidentes, permitiendo que el humano pueda no solo corregir errores, sino también aprender de ellos para tratar de evitarlos en un futuro.
 
Pablo conoce perfectamente la diferencia entre el comando kill (cierra un proceso) y pkill (cierra todos los procesos que coincidan con un patrón, por ejemplo, todos los tests), pero un júnior no tendría por qué saberlo. Aún menos hasta qué punto multiplica la capacidad de liarla parda el aparentemente inocuo parámetro -f.
 
Y en este punto tendremos que resistirnos a tomar otro atajo tentador: encargarle a la propia IA que observe el sistema, interprete las trazas y decida si sus correcciones han funcionado. Esa ayuda puede ahorrarnos mucho trabajo, pero también devolvernos a la caja negra de la que intentamos escapar: aceptar una conclusión que no sabemos contrastar.
 
Alguien tiene que decidir qué significa hacer bien el trabajo y revisar si lo estamos midiendo correctamente. Una reducción de reclamaciones en nuestra aplicación de devoluciones puede significar que hemos mejorado el servicio o que los usuarios se han cansado de insistir. La observabilidad exige criterio para elegir qué observar y entender qué conclusiones podemos sacar de ello.
 
Y también puede ayudarnos a desarrollarlo. El que está empezando necesita tener la oportunidad de investigar un fallo, formular una hipótesis y comprobar si estaba en lo cierto. Las ejecuciones que observamos pueden ofrecer esas oportunidades, aunque el código lo haya escrito un agente.
 
Ese criterio es lo que nos aleja de la rendición cognitiva; no podemos delegarlo.
 
Por eso tenemos que hacer sitio para adquirirlo y cultivarlo. Para dedicar una parte del tiempo que ahorramos escribiendo código a comprender cómo se comporta nuestro software y compartir lo que descubramos con los que llegaron después de nosotros.
 
Me gusta pensar en la observabilidad como una última línea de defensa de nuestra responsabilidad y criterio como desarrolladores, que debemos levantar desde el principio.
 
La derrota llegará el día que permitamos que la única prueba de que una máquina ha hecho bien su trabajo sea que la propia máquina nos lo asegura. El día que renunciemos a nuestra capacidad de entender qué pasa dentro de la caja negra. Es igual quién —o qué— la construya.

¿Quieres ayudarme a difundir este texto?