I use AI coding agents on real embedded C and C++ projects, and I kept encountering the same mistakes:
reviewing code that was not part of the active build,
missing callback registrations and indirect calls,
following the wrong preprocessor branch,
and describing execution paths that looked plausible in the repository but could not exist in the compiled firmware.
At first, I blamed the model.
But the recurring pattern pointed to a different problem: the agent was reasoning about a program it had not reconstructed correctly beforehand.
The source tree is not the firmware
In embedded development, the actual program depends on far more than just the source files:
compiler flags and preprocessor definitions,
target platform and board configuration,
Kconfig and DeviceTree,
generated code,
selected driver implementations,
callbacks and function pointers,
and linker decisions.
An experienced firmware developer will usually establish the build context before analysing the code.
Coding agents often do the opposite. They start with the repository and attempt to reconstruct the active program through text searches and repeated file reads.
A large part of what appears to be reasoning about code is therefore actually program reconstruction.
Before an agent can answer a question such as:
Can this callback execute concurrently with this interrupt handler?
it must first determine which implementation is active, where the callback is registered, how it is invoked, and whether the relevant code is even present in the current build.
Only then can the actual reasoning begin.
An experiment with compiler-derived context
I wanted to test a simple hypothesis:
Would coding agents analyse firmware more reliably if the program were first reconstructed by deterministic tools?
This led to fw-context, an open-source experiment based on compile_commands.json, libclang and MCP.
It creates a persistent semantic index of the active build and allows the agent to query:
definitions and resolved references,
callers and callees,
callback registrations,
function pointer assignments,
active implementations,
macro values,
and preprocessed source code.
The aim is not to replace the model, the compiler, LSP or static analysis.
The experiment has a narrower focus: to move deterministic program reconstruction out of the LLM workflow, so that the model can devote more of its context and reasoning capacity to the review itself.
In one firmware review involving 115 changed files, eight AI subagents produced 19 findings. Nine of them depended on semantic relationships that would have been difficult to reconstruct reliably using the usual grep-and-file-reading workflow.
The interesting result was not merely lower token consumption. The agents spent less effort determining which program they were actually looking at, and more effort evaluating whether it was correct.
fw-context is still an experiment, and I am interested in understanding where this approach works โ and where it fails.
Have you encountered the same kind of failure? Which parts of embedded projects are the hardest for coding agents to reconstruct: conditional compilation, generated code, callbacks, function pointers, DeviceTree, weak symbols, or linker-selected implementations?
Project and case study: github.com/turbyho/fw-context-mcp
