IA assume a refatoração de C++ no OpenBMC: async single-thread, D-Bus e gambiarras

Uma thread, um loop de eventos, um barramento D-Bus e um código legado que ninguém tem coragem de mexer. Foi nesse cenário que um autor do Habr testou como um assistente de IA lida com a refatoração de código C++ corporativo real no ecossistema OpenBMC. O anúncio não informa o nome do modelo, o volume de código nem o percentual de alterações bem-sucedidas. Ainda assim, a proposta é mais interessante que a maioria das demos que geram apps de lista de tarefas: aqui não há exemplos didáticos, só código escrito ao longo de anos por pessoas diferentes.

O que é o OpenBMC e por que ele dá tanta dor de cabeça

BMC (baseboard management controller) é um pequeno computador independente na placa do servidor. Ele monitora alimentação, ventoinhas e sensores de temperatura, oferece console remoto e consegue regravar o firmware do host mesmo quando o sistema principal está morto. O OpenBMC é uma distribuição Linux aberta para esses controladores. O projeto nasceu dentro do Facebook e, desde 2018, é desenvolvido sob a Linux Foundation, com participação de grandes fabricantes de servidores e provedores de nuvem.

Em termos de arquitetura, é um conjunto de pequenos daemons. Cada um cuida de uma parte: sensores, inventário, logs, gerenciamento de energia. Eles se comunicam pelo D-Bus, ou seja, na prática são microsserviços rodando em um SoC com memória limitada e processador fraco. A linguagem principal é C++, geralmente com sdbusplus e Boost.Asio.

Async single-thread: prático e perigoso

O modelo async single-thread significa uma única thread e um único loop de eventos. Toda operação, seja uma requisição D-Bus, a leitura de um sensor ou um timer, vira uma chamada assíncrona com um handler. A vantagem é óbvia: não há as clássicas condições de corrida em dados, e não é preciso espalhar mutexes pelo código. A desvantagem também é conhecida. A lógica se transforma em cadeias de lambdas aninhadas, o tempo de vida dos objetos precisa ser rastreado à mão com shared_ptr e capturas, e a ordem de execução só se entende com um depurador na mão.

Foi exatamente esse tipo de código que pediram para a IA organizar. É um bom teste de estresse. Um modelo de linguagem enxerga muito bem padrões locais, mas a correção aqui costuma depender de fatores implícitos: quem é o dono do objeto, quando o callback será disparado, o que acontece se o serviço reiniciar no meio de uma requisição.

O que exatamente está sendo testado

O autor faz duas perguntas: a IA consegue fazer a refatoração e em que ela ainda perde de forma categórica para o humano. Pelo anúncio, dá para montar o escopo do experimento:

• Plataforma: OpenBMC, sistemas embarcados, controladores de gerenciamento de servidores.
• Linguagem: C++ em um projeto corporativo real, com código sobrecarregado e confuso.
• Modelo de execução: assíncrono, de thread única, baseado em loop de eventos.
• Transporte entre serviços: D-Bus.
• Tarefa da IA: refatorar um trecho de código selecionado.
• Não revelado no anúncio: modelo, ferramenta, volume de código, métricas quantitativas e resultados de testes.

O último item é importante. Sem o texto completo, não é possível tirar conclusões sobre a força ou a fraqueza da IA. A "dor" e as "gambiarras" mencionadas sugerem, antes, que o resultado será misto.

Como aplicar essa experiência na prática

Se você pretende entregar à IA a refatoração de código embarcado ou assíncrono, algumas regras valem independentemente do modelo escolhido.

1. Primeiro os testes, depois as alterações. Sem um conjunto de verificações, não dá para distinguir uma refatoração cuidadosa de uma mudança silenciosa de comportamento.

2. Divida a tarefa. Um daemon ou uma classe por vez é mais seguro do que pedir "limpe o módulo".

3. Explique o contexto ao modelo. Informe que o código roda em uma única thread sobre um loop de eventos, quais objetos são donos de quais recursos e quais interfaces D-Bus não podem ser alteradas.

4. Verifique o tempo de vida dos objetos manualmente. É o ponto mais provável em que um código com aparência plausível acaba incorreto.

5. Use automação: clang-tidy, sanitizers, análise estática e execução na placa real ou emulada. 6.

Mantenha a revisão humana em cada mudança. A IA acelera o trabalho rotineiro, mas a responsabilidade pelo comportamento do firmware continua com você.

Para equipes que mantêm grandes bases de código em C++, esse tipo de experimento é valioso independentemente do resultado. Ele mostra em que nível de complexidade o assistente deixa de ajudar e passa a quebrar o código. As conclusões completas do autor estão no artigo original no Habr.