En el mundo moderno, el software se ejecuta en todo, desde los teléfonos en nuestros bolsillos hasta los enormes centros de datos que alimentan internet. Aunque a menudo pensamos que el consumo de energía es un problema del hardware —de cuánta electricidad consume un servidor o una batería—, el propio software desempeña un papel fundamental. Del mismo modo que dos rutas diferentes para llegar al mismo destino pueden requerir diferentes cantidades de tiempo y combustible, dos fragmentos de código distintos que realizan exactamente el mismo trabajo pueden consumir cantidades de energía muy diferentes. Cuando este software se ejecuta millones de veces al día, esas pequeñas diferencias se acumulan en costos y emisiones de carbono significativos. El desafío para los desarrolladores ha sido durante mucho tiempo que este costo energético es invisible. Cuando un programador escribe código, recibe retroalimentación inmediata sobre si funciona correctamente o qué tan rápido se ejecuta, pero no recibe ninguna señal que le indique si su cambio hizo que el software fuera más o menos eficiente energéticamente. Esta brecha significa que el código ineficiente suele filtrarse en producción, donde continúa desperdiciando energía sin ser detectado.

Un equipo de investigadores de la Universidad Tecnológica de Lappeenranta-Lahti en Finlandia se propuso hacer visible esta energía invisible dentro de las mismas herramientas que los desarrolladores usan a diario. Probaron un sistema diseñado para actuar como un bucle de retroalimentación, conectando tres pasos distintos: realizar un cambio en el código, medir automáticamente la energía de ese cambio y señalar cualquier aumento en el uso de energía como un fallo, de forma muy similar a una prueba que busca errores (bugs). Para ver si esto funcionaba en el mundo real, aplicaron su sistema a dos aplicaciones de software de código abierto y a un flujo de trabajo de pruebas automatizadas estándar. No solo propusieron una nueva idea; la construyeron, la ejecutaron y midieron los resultados. Su trabajo demuestra que es posible detectar el desperdicio de energía en el momento en que un desarrollador envía un cambio, distinguiendo entre un problema genuino en el código y las fluctuaciones normales y sin importancia que ocurren cuando las computadoras funcionan en infraestructuras compartidas.

Los investigadores comenzaron probando si cambios específicos en el código podían medirse realmente para mostrar una diferencia en el uso de energía. Seleccionaron dos aplicaciones de software muy conocidas e introdujeron cambios específicos en cada una. En la primera aplicación, eliminaron un paso redundante donde el software buscaba la misma información dos veces en una base de datos. En la segunda, reorganizaron cómo el software recuperaba artículos, consolidando pasos repetidos en un proceso único y más limpio. Luego ejecutaron la suite de pruebas del software veinte veces para cada versión —diez veces con el código original y diez veces con el nuevo código— en una máquina dedicada para asegurar una comparación justa. Los resultados fueron claros. La primera aplicación mostró una reducción en el uso total de energía de aproximadamente un ocho por ciento, mientras que la segunda mostró una reducción de más del veintiuno por ciento. Crucialmente, los investigadores descubrieron que estos ahorros se debieron principalmente a que el software terminó sus tareas más rápido, en lugar de porque consumiera menos potencia en un momento dado. Esta distinción es vital: el código era simplemente más eficiente al completar su tarea rápidamente, lo que naturalmente redujo la energía total consumida.

Tras haber demostrado que los cambios en el código podían medirse, el equipo pasó al siguiente desafío: integrar esta medición en un flujo de trabajo vivo y automatizado. Construyeron un flujo (pipeline) que se ejecuta cada vez que un desarrollador envía nuevo código, un proceso conocido como integración continua. Este sistema medía la energía en dos niveles. Primero, observaba la suite de pruebas en su totalidad. Segundo, medía la energía de solicitudes individuales, como una búsqueda única o una recuperación de datos individual, para ver exactamente dónde se estaba utilizando la energía. Descubrieron que en las computadoras compartidas utilizadas para estas pruebas, las lecturas de energía eran sorprendentemente estables. La variación natural entre ejecuciones era lo suficientemente pequeña como para que el sistema pudiera distinguir de forma fiable entre el ruido normal y un problema real. Esta estabilidad permitió al sistema establecer una línea base, o un estándar de rendimiento normal, contra el cual cada nuevo código podía ser comparado.

La prueba final consistió en ver si el sistema podía detectar un error. Los investigadores inyectaron deliberadamente dos tipos de errores de desperdicio de energía en el código para ver si el flujo de trabajo los señalaría. En un escenario, cambiaron el código para que solicitara información a la base de datos uno por uno en lugar de todos a la vez, un error común que causa una ineficiencia masiva. En el otro, añadieron una tarea de computación pesada a solo algunas partes específicas del software. El sistema funcionó exactamente como se esperaba. Cuando el error afectó a todo el sistema, el flujo de trabajo marcó toda la compilación como un fallo. Cuando el error se localizó en solo algunas funciones específicas, el sistema identificó correctamente esas funciones específicas como el problema, permitiendo que el resto del software pasara. Esta capacidad de señalar la ubicación exacta del desperdicio es lo que hace que el enfoque sea práctico para los desarrolladores, ya que les indica exactamente qué deben corregir.

El estudio también destacó las realidades prácticas del uso de un sistema así. Debido a que las computadoras que ejecutan estas pruebas son recursos compartidos que pueden cambiar con el tiempo, el sistema necesitaba una forma de ajustar sus estándares. Los investigadores descubrieron que si el hardware de la computadora subyacente cambiaba, las lecturas de energía se desplazaban drásticamente, lo que podría causar falsas alarmas. Para resolver esto, su sistema incluye un mecanismo para recalibrar automáticamente su línea base cada vez que el código se integra con éxito, asegurando que los estándares siempre reflejen el entorno actual. Esto evita que el sistema bloquee código bueno simplemente porque la computadora en la que se está ejecutando ha cambiado. Los investigadores señalaron que, aunque el sistema funcionó bien en sus pruebas controladas, las cifras específicas que encontraron —como las reducciones del ocho por ciento o el veintiuno por ciento— dependen de las aplicaciones específicas y del tipo de cambios realizados en el código. No afirmaron que cada cambio de código ahorraría tanto, sino que el método para medir y señalar estos cambios es viable.

En última instancia, esta investigación proporciona una prueba de concepto de que la eficiencia energética puede tratarse como un control de calidad rutinario, al igual que la comprobación de errores o la velocidad de rendimiento. Al hacer que el consumo de energía sea visible y accionable dentro del flujo de trabajo de desarrollo, el sistema permite a los desarrolladores tomar decisiones informadas antes de que su código sea lanzado. El estudio confirma que los tres componentes técnicos —medir el código, integrar los datos en el flujo de trabajo y detectar regresiones— pueden trabajar juntos como un único bucle. Si bien los investigadores reconocen que la adopción más amplia requerirá una evaluación adicional de cómo responden los desarrolladores a estas señales, el hallazgo central es sólido: es posible construir un sistema que detecte el desperdicio de energía en tiempo real, convirtiendo un problema invisible en una parte gestionable del proceso de creación de software.