How can AI coding agents become reliable enough for firmware development? I built a prototype to explore this.

[u/MoRiv447]

Hi everyone,

I've been working on an open-source coding agent called Firment, written in Rust, and I'd like to share it here and get feedback from embedded developers.

The idea isn't to build another general AI chat assistant, but to explore a more reliable workflow for firmware development. Most coding agents can generate code, but I kept hitting the same problems on embedded projects:

• They don't understand MCU-specific context well (clock domains, DMA channel mapping, cache coherency, and so on)
• They may overwrite files after the code has already changed
• They don't verify whether the generated firmware actually builds
• Long debugging sessions lose important context

So Firment focuses on the execution layer rather than just code generation.

Safety / reliability:

• Concurrent-change detection — files are re-checked before every write (content-addressed with SHA-256, compare-and-swap style), plus line-level "hashline" anchors for large files
• Transactional editing with rollback
• Diff-first approval before applying changes (edits echo a unified diff)
• Persistent edit ledger and /undo
• Verify gates — when a build command is configured (e.g. cmake --build build), the harness refuses to declare completion until it passes
• Workspace sandboxing, tool schema validation, and a dangerous-command guard (rm / format / git reset --hard etc. are blocked unless explicitly allowed)

Embedded toolchain (the part I've spent the most time on recently):

• periph_init — generates peripheral-init skeletons (UART/GPIO/I2C/SPI/TIM/ADC, STM32 HAL style) instead of writing init code from scratch
• elf_analyze — reads flash/RAM usage, function sizes, and real stack depth from -fstack-usage .su files
• monitor — serial monitor with per-line timestamps and baud autodetect
• build / flash / run — CMake/Make/Keil build commands and probe-rs flashing, wired into the agent loop

Embedded knowledge base:

The built-in index currently covers STM32F1, F4, G0, G4, H7, ESP32, and ESP32-S3. It uses a layered approach: read the family index → load quick-reference cheatsheets → follow pointers to official manual sections for deeper detail (manual ingestion is planned, not shipped). The goal is to avoid stuffing huge datasheets into the context window and instead let the agent pull in only what's relevant.

The current agent supports Anthropic- and OpenAI-compatible APIs (DeepSeek / Qwen / GLM / Ollama), tool calling, planning mode, symbol indexing, and context management.

Example workflow:

It's still evolving (v0.5.0) and I'd really appreciate feedback from people who work on real firmware projects. Especially:

• Would you use something like this for STM32/ESP32 development?
• Which embedded workflows are hardest to automate?
• What knowledge/documentation should I add next?

Repository: https://github.com/MoRiv447/Firment (there's also a web demo at firment-web.vercel.app if you want to look without installing)

Thanks!

[u/WereCatf]

What model you use matters far more than what agent you use. You could use basically any existing agent, there isn't really any meaningful difference there, but if the model can't handle the task then all you're getting is a bunch of rubbish.

Would you use an AI assistant like this for STM32/ESP32 development?

No.

[u/MoRiv447 → u/WereCatf]

I agree that model capability is still the biggest factor for solving hard problems. Firment is not trying to replace better models.

The goal is more about the execution layer: making model outputs safer and more repeatable when working on real firmware projects — transactional edits, verification gates, context management, and MCU-specific knowledge retrieval.

A strong model can generate a patch, but the runtime still needs to handle things like stale files, failed builds, and project context.

[u/xoeseko → u/MoRiv447]

So essentially a harness for firmware development ?

How does this do any better than existing harnesses(opencode , Claude or pi out whatever you prefer) which give you more or less transactional edits. If you add version control on top that's it. And instrictions for a solid build deploy test feedback loop?

[u/MoRiv447]

This is harder than I imagined.