Movimiento de software lento: repensar el desarrollo de sistemas críticos

Fuentes: Slow Software: The Case for High-latency Systems Development

En un ensayo publicado en su blog, la investigadora de sistemas Irvindeep Bhusshar (en realidad atribuido a un autor vinculado a proyectos como Demikernel) defiende la creación de un movimiento de "software lento", inspirado en la filosofía slow food, para recuperar la correlación entre la importancia de un sistema y el tiempo dedicado a diseñarlo. La autora explica que, durante décadas, el desarrollo de sistemas de bajo nivel fue lento de forma natural: estaba ligado al hardware físico, a despliegues complejos y a herramientas básicas como ensamblador o C, lo que forzaba una relación directa entre esfuerzo invertido y criticidad del software. En los últimos veinte años, la computación en hiperescala, las nubes centralizadas y la programación asistida por inteligencia artificial han eliminado esas barreras, separando la velocidad de desarrollo del impacto potencial del software. El texto advierte de que la IA puede generar cambios en código de sistemas sin que el programador comprenda las garantías de consistencia o los modelos de almacenamiento subyacentes, lo que produce fallos con un "amplio radio de explosión" en servicios dependientes. La propuesta concreta consiste en reintroducir impedimentos artificiales en los entornos de desarrollo para los sistemas de infraestructura más críticos, de modo que los ingenieros dediquen más tiempo a validar decisiones de diseño antes de codificar. La autora aclara que el objetivo no es rechazar la IA —útil para prototipos, scripts de compilación o pruebas repetitivas—, sino reservar los desarrollos rápidos para código con bajo impacto y aplicar procesos más reflexivos a software con muchas dependencias o cuyo fallo sería catastrófico. El ensayo también aborda las consecuencias para la investigación en sistemas: la facilidad de prototipar ha inundado de propuestas poco meditadas las conferencias como SOSP, trasladando la carga de evaluar ideas a revisores experimentados y acelerando su agotamiento. La conclusión, truncada en el texto disponible, apunta a la necesidad de un mecanismo de limitación que devuelva a la investigación en sistemas un ritmo más pausado y deliberado.