En cuestión de semanas, AWS y Cloudflare se cayeron y arrastraron con ellos a buena parte de internet. Me apoyé en un análisis con IA para entender de verdad qué falló en cada caso, y debajo de los detalles técnicos encontré el mismo patrón que ya había visto con CrowdStrike: no fueron ataques, fueron cambios pequeños que se propagaron sin freno por sistemas que asumíamos sólidos. La lección no es sobre DNS ni sobre archivos de configuración. Es sobre cuánto dependemos de cuán poco, y sobre lo poco que aprendemos entre un apagón y el siguiente.
La deuda técnica no se elimina, se administra. Y administrarla bien es parte del oficio de cualquiera que lidere tecnología. Quiero pensarla en sus tres formas —la que se ve, la que se esconde y la que heredamos— y en la conversación más difícil de todas: explicarle al negocio por qué a veces hay que frenar para pagar algo que no se ve.
En la carrera por usar el modelo de IA más potente, solemos olvidar una pregunta sencilla: ¿lo necesitábamos? Elegir el modelo adecuado para cada tarea, en lugar del más grande por defecto, no es solo ahorrar dinero. Es una forma de responsabilidad técnica que tiene consecuencias económicas, operativas y ambientales. La eficiencia dejó de ser un lujo de optimización para volverse parte del criterio.
Hace medio año los agentes eran una posibilidad técnica prometedora. Hoy empiezan a correr tareas largas y autónomas en repositorios reales. El entusiasmo está justificado, pero la lección no cambió: cuanto más potente es lo que delegamos, más cuidado necesita el arnés con que lo conducimos. La capacidad creció; la responsabilidad de gobernarla, también.
Toda organización conoce sus dependencias visibles: la base de datos, la nube, el sistema de pagos. El problema son las invisibles, las que nadie anotó en ningún diagrama y que descubrimos recién cuando se caen. Mapearlas no es una tarea técnica más: es la base de cualquier resiliencia real, porque no se puede proteger ni recuperar lo que no se conoce.
El vibe coding me cambió la forma de ver el desarrollo de software. Pero el mismo día que me deslumbró, también vi el problema: sin versionado de especificaciones, sin organizar qué queremos que haga la IA, y especialmente al trabajar en equipo, esta forma de programar puede volverse un caos difícil de gobernar. No estoy en contra. Estoy a favor de entenderlo antes de que nos arrastre.
2024 no fue solamente otro año de novedades en inteligencia artificial. Fue el año en que empezamos a ver con más claridad que la IA aplicada necesita madurez: buenos datos, contexto, seguridad, resiliencia, arquitectura y liderazgo técnico.
La inteligencia artificial empieza a dejar de ser solamente una caja de texto para convertirse en una herramienta capaz de planificar, usar software, navegar, escribir código y ejecutar tareas. El desafío no es solo técnico: también es de arquitectura, seguridad, criterio y responsabilidad.
La IA puede ayudarnos a escribir código más rápido, pero la velocidad por sí sola no garantiza buen software. El verdadero valor aparece cuando la usamos con criterio, contexto, reglas claras, revisión técnica y una arquitectura que la guíe.
El incidente de CrowdStrike no fue solo una falla técnica. Fue una demostración global de lo conectados, dependientes y frágiles que pueden ser nuestros sistemas cuando una pieza crítica falla.