Adsum IoT Coder

ESP & nRF · IoT Firmware Debug, Dev & CRA Readiness

An IoT coding agent for VS Code that works your whole firmware dev loop on Espressif ESP and Nordic nRF: scaffold, build, flash, test, observe, fix. It automates the routine firmware work you would rather not do, and cracks the runtime bugs general agents cannot, because it reads your board, not just your code.

What makes it different is real human expertise, not just the AI model. Adsum is augmented with curated firmware knowledge authored by engineers who have shipped, loaded on demand and validated by an open benchmark on real hardware. Human-curated, not AI-generated. It is the direction frontier research points to: equip a general model with curated, domain expertise that loads only when needed, rather than scale the model alone. The same approach appears in academic work on expert-skill-augmented models that shaped our benchmark (arXiv:2603.19583) and in industry practice (context engineering, Agent Skills).

Shipping today: Espressif ESP32 (incl. S3, C6) on ESP-IDF · Nordic nRF52 / nRF53 / nRF54 on nRF Connect SDK (Zephyr) · BLE (Bluetooth Low Energy) and Wi-Fi · one-click EU Cyber Resilience Act (CRA) readiness: an SBOM plus a secure-by-design posture check. Open source under Apache 2.0.

Watch the demo → · Install → · Docs → · CRA readiness → · Benchmark → · Contribute →

vs Claude Code, same model (Claude Haiku 4.5): 5/6 vs 3/6 bugs closed on real nRF hardware, at 3.8× fewer tokens on average and up to 13× on individual tasks. The edge is architecture, not model scale.

What's New ^v0.1.8

 See a bug at every layer. Adsum now debugs across all three layers of a BLE connection: the application log, the HCI host↔controller bus, and the over-the-air radio, correlated so you see exactly where a flow broke, not just where the app noticed. A guided sample run makes it easy to try in one click, with no hardware, and the same debugging works on your own nRF boards.

Plus a hardening pass: smoother, safer CRA runs, more reliable Windows terminals, and a slimmer input area. Full changelog.

The flagship, shipped in v0.1.7:

 CRA readiness, one click. Run it on your build and get a machine-readable SBOM (SPDX) plus a full EU Cyber Resilience Act readiness report, written to a compliance/ folder, on both nRF and ESP. A readiness aid to help you get ahead of the deadlines.

 Secure-by-design posture, from your real config. It reads what your build actually sets, secure boot, signed updates, debug-port lock, secure storage and more, and lays out each requirement, where your build stands, and the fix, ranked so you tackle the biggest gap first.

 Scan your SBOM for known CVEs, and close them. The check matches your build's identifiable components against public advisory databases and lists what's found. Hand it a specific CVE and it confirms the affected component is really in your build, links the advisory, then walks you through bumping the version, rebuilding, and regenerating the SBOM.

 Fix in the same loop. It doesn't just flag gaps. It helps you wire the fix, a secure bootloader for example, rebuild, and re-verify, without leaving the agent.

 A cleaner home. The refreshed status strip shows every detected SDK version and the exact build it resolved, so it never asserts a version it can't back.

Full history in the changelog.

CRA Readiness: SBOM, CVE, and secure-by-design

One click runs a build-time readiness check for the EU Cyber Resilience Act (CRA), on both nRF and ESP. A readiness snapshot to help you prepare, not a conformity assessment and not legal advice.

• SBOM from your real build. A machine-readable software bill of materials (SPDX), the CRA's named artifact, generated from your actual build with the vendor-native tools.
• Known-CVE scan across your SBOM. Matches your build's identifiable components (CPE/PURL) against public advisory databases (the EU's EUVD, NVD, and OSV) and lists what's found, with coverage stated honestly. Never a pass/fail verdict.
• Secure-by-design posture against your build's actual configuration: secure boot, signed updates, debug-port lock, secure pairing, secure storage and more, each with the plain-English requirement and the fix, ranked so you tackle the biggest gap first.
• Bring a CVE, and close it. Hand it a CVE from a vendor advisory: it confirms the affected component is really in your build (a literal SBOM lookup), links the advisory, then helps you bump the version, rebuild, and regenerate the SBOM.
• Fix in the loop, not just flag. It helps you wire the top fix (a secure bootloader, for example), rebuild, and re-verify, without leaving the agent.
• Version advisories for your detected SDK (links to review, never an automatic verdict).

It tells you which CRA date applies to you and writes a compliance/ folder (report + machine-readable JSON + SBOM). Run it on your firmware, or try it on a bundled sample with nothing open.

Why it exists

Embedded firmware work is two jobs at once: a lot of routine, repetitive setup, and a handful of genuinely hard problems. General coding agents help with neither well, because both live outside the source file.

The routine you would rather automate: scaffolding a project, wiring devicetree and Kconfig, generating logging, adding a BLE service or a sensor, writing tests, bringing up a new board. Adsum does this work for you, idiomatically, on both ESP and nRF.

The hard bugs you cannot grep: a missing settings_load() after bt_enable() that silently breaks notifications after a reconnect; an ESP-IDF partition mismatch that only fails at runtime; a fault visible only by correlating logs across two boards. Adsum reads the device, captures the live logs, and works them the way a senior engineer does.

And the reason it is good at the hard parts is the part general agents do not have: real human expertise. The firmware knowledge that drives it is authored by engineers who have shipped, loaded on demand, and validated against an open benchmark. Human-curated, not AI-generated.

What it does: debug, build, and prototype ESP and nRF firmware

• Automatic platform detection. nRF, ESP, both, or a fresh start, with the right tools for each.
• Build, flash & debug. The full loop on real hardware: build, flash, capture live logs (RTT/UART on nRF, serial monitor on ESP), analyze, fix, repeat.
• Capture & analyze device logs. Correlated with your source, across one board or two.
• Debug across all three layers. The agent correlates the app log, the HCI bus, and the over-the-air radio, so you see where a BLE flow actually breaks, not just what the app logged. A guided sample run makes it easy to try, no hardware required.
• Start a prototype, add a feature. Scaffold a new nRF or ESP-IDF project; wire a BLE service, sensor, shell, or storage into your real project.
• Test & validate. Host tests and on-hardware checks.
• Check CRA readiness. One click: an SBOM (SPDX) plus a secure-by-design posture snapshot from your real build, on nRF and ESP. See CRA Readiness.

Supported platforms: ESP32 / ESP-IDF and nRF / nRF Connect SDK

CRA readiness (SBOM + secure-by-design posture) runs on both Nordic and Espressif builds.

Benchmark

Adsum IoT Coder vs Claude Code, same model (Claude Haiku 4.5): 5/6 vs 3/6 bugs, 3.8× more token-efficient on average and up to 13× on individual tasks.

Both agents ran the same model on real nRF52 hardware, so the gap measures architecture, not model power. Adsum IoT Coder closed 5 of 6 bugs versus Claude Code's 3, using 3.8× fewer tokens on average and as much as 13× fewer on the hardest individual tasks. The benchmark, IoT-FirmwareDebugBench v0.1, is open source. Run it yourself.

Full methodology, per-task results, and honest limitations are in the benchmark report. Methodology adapted from arXiv:2603.19583.

Contributing

That result comes from the expertise the agent runs on, not the model: curated firmware knowledge authored by practicing engineers and validated on real hardware. The agent gets stronger as that knowledge base grows, and there are two ways to get involved, both open to you.

Contribute knowledge (embedded experts and specialists). This is the part that makes the agent good, and it is written by engineers, not the model: the hard-won fixes and idioms you only get from shipping nRF and ESP firmware. We are building a dedicated studio for authoring this expertise and will open it to outside specialists once it has earned its keep in-house. If you have lived inside these failure modes and want to shape it as a founding contributor, get credited for your work, and keep the rights to it, start a discussion.

Contribute code (open-source developers). The extension is open source (Apache-2.0, built on Cline). Improve the tool itself, or add a benchmark task in evals/. Open an issue or PR.

Getting Started

Search Adsum IoT Coder in the VS Code Extensions panel, or install from the Marketplace directly. No key, no account: the free tier is on by default.

Prerequisites: the nRF Connect Extension Pack for nRF work, or an ESP-IDF installation for ESP, plus Python 3.8+. Full requirements are in the docs.

1. Run the built-in 30-second demo (no board needed) to see the capture, analyze, fix loop on a real BLE bug.
2. Open your nRF or ESP project; the home reads it, detects your boards and toolchain, and offers the right one-click workflows.
3. Run the one-click CRA readiness check on a bundled sample (nothing open) or your own build, and see the SBOM and secure-by-design posture in under a minute.
4. Bring your own model whenever you want; the running task continues, no restart.

Free tier: put it to work in your first minute, on us

Most tools make you choose a provider, paste an API key, and add a card before you can find out whether they help. We cut all of that.

Install Adsum IoT Coder and it just works. No key, no account, no card. The inference is on us, on a managed model, so you can point the agent at your own firmware in the first minute, not the first hour. It is a real working tier, generous enough to scaffold a project and run a full debug loop, not a locked demo.

When you want your own model or heavier usage, drop in any OpenAI-compatible key (Claude, DeepSeek, or a local model with strong tool-calling) and the switch is instant: the task you are in keeps running, no restart. The free tier is token-metered, and when you reach the limit a one-click prompt moves you onto your own key and the same task picks up exactly where it left off.

Recommended for bring-your-own-key: Claude Haiku 4.5 (the benchmark model) and DeepSeek-V4-Pro (cost-effective long sessions). Full setup and tested models in the docs.

Roadmap

Shipping today: Nordic nRF and Espressif ESP32, with BLE and Wi-Fi, one-click CRA readiness (SBOM + secure-by-design posture), and a guided 3-layer debug that correlates the app log, on-device HCI, and the over-the-air radio to pinpoint where a flow actually broke, not just the app log. Next: more chips (nRF7x Wi-Fi, nRF9x cellular, more ESP32 variants), more protocols (Thread, Matter, LTE-M), 3-layer decoding beyond BLE, power profiling, and a growing community knowledge base. The roadmap is shaped by what the community asks for and contributes.

Limitations

We publish what is true today. Adsum is an AI-based coding agent and can make mistakes. The CRA workflow is a readiness aid, not a conformity assessment and not legal advice; only a notified body or your formal assessment establishes conformity. The CRA check scans your SBOM's identifiable components against public advisory databases and reports known CVEs with coverage stated; coverage is limited to components carrying identifiers (CPE/PURL), and it does not find undisclosed or zero-day vulnerabilities. You can also hand it a specific CVE to confirm against your build and patch. The benchmark is six BLE tasks on a single NCS version: a proof of concept, not statistical significance, and an ESP benchmark suite is on the roadmap (v0.2). nRF, nRF Connect SDK, and Nordic Semiconductor are trademarks of Nordic Semiconductor ASA; ESP32 and ESP-IDF are trademarks of Espressif Systems; Zephyr is a trademark of the Linux Foundation; Visual Studio Code is a trademark of Microsoft. This is an independent project, not affiliated with or endorsed by any of them.

Privacy & Security

The runtime runs entirely on your machine. Only the log snippets and code context a task needs go to the AI provider you configure. BYOK: you control which model and endpoint you trust. Pseudonymous product analytics only (installs, activations, feature usage, errors), keyed to a random install ID; never your source code, chat content, or device logs. Opt out anytime with telemetry.telemetryLevel: off. Source is fully open and auditable.

About

Adsum Networks has built embedded firmware on Nordic nRF and other SoC platforms for 8 years, living inside the failure modes that cost embedded engineers their days. We built Adsum IoT Coder because general coding agents leave embedded developers without reliable help for the work that fills the day: the routine setup worth automating, and the runtime bugs that never show up in source review. The difference is real human expertise, not just the AI model: curated firmware knowledge authored by engineers who have shipped, loaded on demand and measured against an open benchmark on real hardware, so the value can be defended, not just claimed.