La IA se pone a refactorizar C++ en OpenBMC: async monohilo, D-Bus y parches

Un hilo, un bucle de eventos, un bus D-Bus y un código heredado que da miedo tocar. Con ese material, un autor de Habr comprobó cómo se desenvuelve un asistente de IA al refactorizar código enterprise real en C++ dentro del ecosistema OpenBMC. El anuncio no menciona ni el nombre del modelo, ni el volumen de código, ni el porcentaje de cambios exitosos. Aun así, el planteamiento es más interesante que la mayoría de demos que generan aplicaciones de tareas: aquí no hay ejemplos de manual, sino código escrito durante años por distintas personas.

Qué es OpenBMC y por qué duele

Un BMC (baseboard management controller) es un pequeño ordenador independiente integrado en la placa del servidor. Vigila la alimentación, los ventiladores y los sensores de temperatura, ofrece una consola remota y puede reflashear el host incluso cuando el sistema principal está muerto. OpenBMC es una distribución Linux abierta para estos controladores. El proyecto nació dentro de Facebook y, desde 2018, se desarrolla bajo el paraguas de la Linux Foundation con la participación de grandes fabricantes de servidores y proveedores de nube.

La arquitectura es un conjunto de pequeños demonios. Cada uno se encarga de una parte: sensores, inventario, registros, gestión de energía. Se comunican a través de D-Bus, es decir, funcionan en esencia como microservicios, pero sobre un SoC con memoria limitada y un procesador modesto. El lenguaje principal es C++, normalmente con sdbusplus y Boost.Asio.

Async monohilo: cómodo y peligroso

El modelo async monohilo implica un único hilo y un único bucle de eventos. Cualquier operación, ya sea una consulta por D-Bus, la lectura de un sensor o un temporizador, se formula como una llamada asíncrona con su manejador. La ventaja es evidente: no hay carreras de datos clásicas y no hace falta repartir mutex por todo el código. El inconveniente también es conocido. La lógica se convierte en cadenas de lambdas anidadas, hay que seguir a mano el tiempo de vida de los objetos mediante shared_ptr y capturas, y el orden de ejecución solo se entiende con un depurador en la mano.

En un código así se pidió a la IA que pusiera orden. Es una buena prueba de estrés. Un modelo de lenguaje detecta muy bien los patrones locales, pero aquí la corrección suele depender de factores implícitos: quién posee el objeto, cuándo se disparará el callback, qué ocurre si el servicio se reinicia en mitad de una petición.

Qué se evalúa exactamente

El autor plantea dos preguntas: si la IA es capaz de refactorizar y en qué cede todavía sin paliativos ante el humano. A partir del anuncio se pueden reconstruir los límites del experimento:

• Plataforma: OpenBMC, sistemas embebidos, controladores de gestión de servidores.
• Lenguaje: C++ en un proyecto enterprise real, con código sobrecargado y enrevesado.
• Modelo de ejecución: asíncrono, monohilo, basado en un bucle de eventos.
• Transporte entre servicios: D-Bus.
• Tarea para la IA: refactorizar un fragmento de código seleccionado.
• No se revela en el anuncio: el modelo, la herramienta, el volumen de código, las métricas cuantitativas ni los resultados de las pruebas.

El último punto es importante. Mientras no se conozca el texto completo, no se pueden sacar conclusiones sobre la fortaleza o la debilidad de la IA. El «dolor» y los «parches» que menciona el autor sugieren más bien que el resultado será mixto.

Cómo aplicar esta experiencia en la práctica

Si vas a encargar a una IA el refactor de código embebido o asíncrono, varias reglas funcionan con independencia del modelo elegido.

1. Primero los tests, después los cambios. Sin un conjunto de pruebas no distinguirás un refactor limpio de un cambio silencioso de comportamiento.

2. Divide la tarea. Un demonio o una clase cada vez es más fiable que pedir «limpia el módulo».

3. Explica el contexto al modelo. Indica que el código se ejecuta en un solo hilo sobre un bucle de eventos, qué objetos son propietarios de los recursos y qué interfaces D-Bus no se pueden modificar.

4. Comprueba a mano el tiempo de vida de los objetos. Es el lugar más probable donde un código verosímil resulta incorrecto.

5. Añade automatización: clang-tidy, sanitizers, análisis estático y ejecución en la placa real o emulada. 6.

Mantén la revisión humana en cada cambio. La IA acelera la rutina, pero la responsabilidad por el comportamiento del firmware sigue siendo tuya.

Para los equipos que mantienen grandes bases de código en C++, un experimento como este resulta valioso sea cual sea el resultado. Muestra en qué nivel de complejidad el asistente deja de ayudar y empieza a romper. Las conclusiones completas del autor están en el artículo original de Habr.