We built an AI coding agent specifically for ESP-IDF — because general agents can't debug firmware

We built an AI coding agent specifically for ESP-IDF — because general agents can't debug firmware

# iot# ai# esp32# arduino
We built an AI coding agent specifically for ESP-IDF — because general agents can't debug firmwareOmar Morceli

I'm one of the people building Adsum IoT Coder, an open-source VS Code agent purpose-built for...

I'm one of the people building Adsum IoT Coder, an open-source VS Code agent purpose-built for embedded firmware. We just shipped ESP32 (ESP-IDF) support, and I want to explain why a general-purpose coding agent — even a very good one — structurally can't do this job, and who this is actually for.

Why a generic agent can't do this

General coding agents are trained to read and write source code. Embedded firmware bugs mostly don't live in the source. They live at runtime — in a boot log, a crash backtrace, a BLE handshake that times out, a peripheral that misbehaves only on real silicon. A generic agent can suggest plausible fixes from reading your .c files, but it never looks at what your board is actually doing, because it has no concept of "the board" as a thing to observe.

Adsum is built around the opposite assumption: the agent should read the board, not just the code. It captures live logs from your hardware and works the loop embedded engineers actually use — scaffold, build, flash, observe, fix — instead of doing a single source-level guess.

We didn't want to just assert this, so we built an open benchmark, IoT-FirmwareDebugBench v0.1. Both agents ran the same model (Claude Haiku 4.5) on real nRF52 hardware, isolating the architecture as the only variable. Result: Adsum closed 5/6 bugs vs. 3/6 for a leading general agent, using about 3.8x fewer tokens on average. Full methodology and per-task results — including the one task it failed — are in the repo.

Who this is for

If you're doing ESP32 in the Arduino framework and you've started hitting its ceiling — real BLE control, RTOS behavior, power management — the usual next step is ESP-IDF, and the usual experience is that ESP-IDF is a wall. This agent is built to make that jump survivable: it helps you scaffold, build, and debug ESP-IDF projects without already knowing the whole SDK.

If you're already an ESP-IDF developer, this isn't a generic assistant that happens to know some embedded terms — it's tuned specifically for the ESP-IDF build/flash/debug loop and for reading what your chip is doing at runtime. The goal is to cut the time you spend chasing a bug that only shows up on hardware.

Try it

  • No signup, no API key, no card — there's a free tier and a built-in 30-second demo that runs with no board attached.
  • Open source under Apache-2.0.
  • Supports ESP32 / S3 / C6 (ESP-IDF) and Nordic nRF52/53/54 (nRF Connect SDK), BLE + Wi-Fi.

Docs: https://docs.adsumnetworks.com/introduction
Repo: https://github.com/adsumnetworks/Adsum-IoT-Coder

Would love feedback from anyone here doing ESP32 or nRF52 firmware work — especially where it breaks on a real project.