AI Takes on C++ Refactoring in OpenBMC: Single-Threaded Async, D-Bus and Kludges

One thread, one event loop, one D-Bus bus, and legacy code nobody wants to touch. On this material, a Habr author tested how an AI assistant handles refactoring real enterprise C++ code in the OpenBMC ecosystem. The announcement gives no model name, no code volume, and no percentage of successful edits. Still, the setup is more interesting than most demos that generate todo apps: there are no toy examples here, just code written over years by many different people.

What is OpenBMC and why does it hurt?

A BMC (baseboard management controller) is a small, separate computer on a server board. It monitors power, fans, and temperature sensors, provides a remote console, and can reflash the host even when the main system is dead. OpenBMC is an open-source Linux distribution for such controllers. The project started inside Facebook, and since 2018 it has been developed under the Linux Foundation with participation from major server and cloud vendors.

Architecturally, it is a set of small daemons. Each one handles its own piece: sensors, inventory, logs, power management. They talk to each other over D-Bus, so in essence these are microservices, only running on an SoC with limited memory and a weak processor. The main language is C++, usually with sdbusplus and Boost.Asio.

Single-threaded async: convenient and dangerous

The single-threaded async model means one thread and one event loop. Every operation, whether a D-Bus request, a sensor read, or a timer, is written as an asynchronous call with a handler. The upside is obvious: there are no classic data races, and you don't have to scatter mutexes across the code. The downside is just as well known. Logic turns into chains of nested lambdas, object lifetimes have to be tracked by hand through shared_ptr and captures, and the execution order can only be read with a debugger in hand.

This is exactly the kind of code the AI was asked to tidy up. It makes a good stress test. A language model is excellent at spotting local patterns, but correctness here often depends on implicit things: who owns an object, when a callback fires, what happens if the service restarts in the middle of a request.

What exactly is being tested

The author poses two questions: can AI handle the refactoring, and where does it still lose to a human outright? The announcement lets us piece together the boundaries of the experiment:

• Platform: OpenBMC, embedded systems, server management controllers.
• Language: C++ in a real enterprise project, with overloaded and tangled code.
• Execution model: asynchronous, single-threaded, built on an event loop.
• Transport between services: D-Bus.
• Task for the AI: refactoring a selected piece of code.
• Not disclosed in the announcement: the model, the tool, the code volume, quantitative metrics, and test results.

The last point matters. Until the full text is available, you cannot draw conclusions about the strength or weakness of the AI. The "pain" and "kludges" the author mentions suggest, if anything, that the result will be mixed.

How to apply this experience in practice

If you plan to hand an AI the refactoring of embedded or asynchronous code, a few rules apply regardless of the model you choose.

1. Tests first, edits second. Without a set of checks, you cannot tell a clean refactoring from a silent change in behavior.

2. Break the task down. One daemon or one class at a time is more reliable than a request to "clean up the module."

3. Explain the context to the model. State that the code runs in a single thread on an event loop, which objects own resources, and which D-Bus interfaces must not change.

4. Check object lifetimes by hand. This is the most likely place for plausible-looking code to turn out wrong.

5. Bring in automation: clang-tidy, sanitizers, static analysis, and runs on a target or emulated board. 6.

Keep human review for every change. AI speeds up routine work, but responsibility for the firmware's behavior stays with you.

For teams that maintain large C++ codebases, an experiment like this is valuable whatever its outcome. It shows the level of complexity at which an assistant stops helping and starts breaking things. The author's full conclusions are in the original article on Habr.