ИИ взялся за рефакторинг C++ в OpenBMC: однопоточный async, D-Bus и костыли

Один поток, один цикл событий, одна шина D-Bus и легаси, которое боятся трогать. На таком материале автор Habr проверил, как ИИ-ассистент справляется с рефакторингом реального enterprise-кода на C++ в экосистеме OpenBMC. В анонсе нет ни названия модели, ни объёма кода, ни процента успешных правок. Зато сама постановка задачи интереснее большинства демо с генерацией todo-приложений: здесь нет учебных примеров, а есть код, который писали годами и разные люди.

Что такое OpenBMC и почему там больно

BMC (baseboard management controller) — маленький отдельный компьютер на серверной плате. Он следит за питанием, вентиляторами и температурными датчиками, отдаёт удалённую консоль и умеет перепрошивать хост, даже когда основная система мертва. OpenBMC — открытый Linux-дистрибутив для таких контроллеров. Проект стартовал внутри Facebook, а с 2018 года развивается под крышей Linux Foundation при участии крупных вендоров серверов и облаков.

Архитектурно это набор небольших демонов. Каждый отвечает за свой кусок: сенсоры, инвентаризацию, логи, управление питанием. Общаются они через D-Bus, то есть по сути это микросервисы, только на SoC с ограниченной памятью и слабым процессором. Основной язык — C++, обычно с sdbusplus и Boost.Asio.

Однопоточный async: удобно и опасно

Модель async single-threaded означает один поток и один цикл событий. Любая операция, будь то запрос по D-Bus, чтение датчика или таймер, оформляется как асинхронный вызов с обработчиком. Плюс очевиден: нет классических гонок за данные, не нужно размазывать мьютексы по коду. Минус тоже известен. Логика превращается в цепочки вложенных лямбд, время жизни объектов приходится отслеживать вручную через shared_ptr и захваты, а порядок выполнения читается только с отладчиком в руках.

Именно в такой код ИИ и попросили внести порядок. Это хороший стресс-тест. Языковая модель отлично видит локальные паттерны, но корректность здесь часто зависит от неявных вещей: кто владеет объектом, когда сработает коллбэк, что случится, если сервис перезапустится посреди запроса.

Что именно проверяется

Автор ставит два вопроса: справится ли ИИ с рефакторингом и в чём он пока безоговорочно уступает человеку. Из анонса можно собрать рамки эксперимента:

• Платформа: OpenBMC, встраиваемые системы, серверные контроллеры управления.
• Язык: C++ в реальном enterprise-проекте, с перегруженным и запутанным кодом.
• Модель исполнения: асинхронная, однопоточная, на цикле событий.
• Транспорт между сервисами: D-Bus.
• Задача для ИИ: рефакторинг выбранного фрагмента кода.
• Не раскрыто в анонсе: модель, инструмент, объём кода, количественные метрики и результаты тестов.

Последний пункт важен. Пока нет полного текста, выводов о силе или слабости ИИ делать нельзя. Заявленная «боль» и «костыли» говорят скорее о том, что результат будет смешанным.

Как использовать этот опыт на практике

Если вы собираетесь отдавать ИИ рефакторинг встраиваемого или асинхронного кода, несколько правил работают независимо от выбранной модели.

1. Сначала тесты, потом правки. Без набора проверок вы не отличите аккуратный рефакторинг от тихой смены поведения. 2. Дробите задачу. Один демон или один класс за раз надёжнее, чем просьба «почисти модуль». 3. Объясняйте модели контекст. Укажите, что код работает в одном потоке на цикле событий, какие объекты владеют ресурсами и какие интерфейсы D-Bus нельзя менять. 4. Проверяйте время жизни объектов вручную. Это самое вероятное место, где правдоподобный код оказывается неверным. 5. Подключайте автоматику: clang-tidy, санитайзеры, статический анализ и прогон на целевой или эмулированной плате. 6. Оставляйте человеческое ревью для каждого изменения. ИИ ускоряет рутину, но ответственность за поведение прошивки остаётся на вас.

Для команд, которые поддерживают большие C++-кодовые базы, такой эксперимент ценен независимо от итога. Он показывает, на каком уровне сложности ассистент перестаёт помогать и начинает ломать. Полные выводы автора лежат в оригинальной статье на Habr.