The best AI-firmware diagnoses agree. Their cures don't.

This year produced an unusually good crop of writing about why AI struggles with firmware. I expected to disagree with it. Mostly I don't.

The diagnosis has converged — five different authors, different employers, different incentives, same account of what goes wrong. The prescriptions have not converged at all. They point in four different directions, and as far as I can tell nobody has said out loud that they disagree with each other.

That gap is the interesting thing about 2026. I've argued before that Copilot for firmware is solved and that was the easy half. This post is about the half that isn't, and specifically about which of the proposed fixes has evidence behind it.

The diagnosis everybody shares

A chip vendor's software director, writing on a personal Substack with the employer disclosed, put the failure in the form every embedded engineer recognizes: "Every embedded engineer I know has tried using Copilot or ChatGPT for firmware. And every one of them has a story about the plausible-looking driver that compiled cleanly and failed at 2 AM on the bench... That story is a failure of context, not a failure of AI."¹

An independent consultant's blog reached the same place from the software-architecture side: "The AI has nothing to anchor to. There is no message contract. No formal state schema. No machine-readable map of who talks to whom. So the AI does what it does best — it predicts the next plausible token. Plausible-looking code that violates assumptions nobody ever wrote down."²

That piece deserves credit for a second reason. It shipped under a headline saying AI can't write firmware, took criticism from embedded engineers, and narrowed itself in the body: "What I had written first read as 'AI cannot do firmware.' What was actually true was narrower and more interesting: AI does fine with the parts of firmware that look like backend code. It struggles with the parts that look like systems."

A trade publication's columnist put the central problem clearly: "It isn't that AI gets things wrong. Engineers get things wrong, too. The problem is that AI gets things wrong while sounding completely sure of itself."³

None of this is controversial to me. It's roughly what I wrote in what LLMs get wrong about embedded code.

Four cures for one disease

Same diagnosis, four remedies.

Source	What it says goes wrong	What it prescribes
Independent consultant's blog, May	No contract, no schema, no machine-readable map — nothing to anchor to	The industry builds firmware the structural scaffolding the web already has
Chip vendor software director, February	Hardware target invisible; errata effectively don't exist for the model	Hardware context as first-class input, plus auditable reasoning
Trade publication columnist, May	Firmware has no feedback loop; register-level and timing work fails confidently	Teams build their own MCP servers, RAG databases, and custom agents
Solo benchmark author, April	Measured per-category pass rates that bottom out in specific domains	Classify code into trust tiers and gate merges by tier

Each is defensible. Side by side they are not the same plan. "Wait for an industry-wide schema standard" and "build your own tooling this quarter" are advice for different decades. "Inject the register values" and "have an expert rewrite it" are different answers to the same ticket.

Input-side and output-side

Three of them are input-side. Schemas, register values, RAG databases, errata ingestion — all of them are attempts to get more true facts in front of the model before it writes. They differ in who does the work and how long it takes, but the theory of the failure is identical: the model was under-informed.

The fourth is different in kind. Trust tiers don't inform the model at all. They accept that the output may be wrong and install a judge — a human expert — whose job is to find out. That's an output-side fix: it doesn't improve the writing, it improves the finding out, which is the framing in why your AI coding agent needs a target to run on.

The input-side cure has a measured ceiling

A vendor benchmarking its own product on an LPC55S69-EVK ran four models through the same LED blink twice — once cold, once with the relevant register data injected. Cold: 4 of 4 compiled, 1 of 4 worked on hardware. With register data: 4 of 4 compiled, 4 of 4 worked.⁴ They publish full source and binaries from every test with an "unmodified, nothing hand-edited" claim. Inspectable, not independently audited.

The same table shows the ceiling. On a harder task — PWM LED fade — 4 of 4 compiled and 1 of 4 worked, and the one that worked lit the wrong LED, green instead of the specified red, because it brute-forced every clock-enable bit on the chip rather than finding the correct one. On a UART-plus-LED task, after full register-value injection, one model produced garbled serial output from a 7.0% baud error caused by the wrong oversampling ratio. Context injection took a blink from 25% to 100%. It did not turn a clock-tree calculation into a solved problem.

A solo engineer publishing an open-source benchmark measured the same shape at scale: 233 cases, two models at n=3, Wilson 95% intervals over 699 pooled trials.⁵ 68.0% pass@1 for the stronger model, CI [64.4%, 71.3%]; 56.9% for the weaker, CI [53.2%, 60.6%]. The intervals don't overlap.

The author is candid about the limits — two models, around 81% of cases on Zephyr, single-file scope. Solo, self-published, not peer reviewed, and more transparent about its own weaknesses than most funded work. More on what these benchmarks measure in EmbedAgent and friends.

EmbedAgent's published RAG result is on Arduino with schematics: DeepSeek-R1 went from 55.6% to 65.1% pass@1.⁶ Separately, the best ESP-IDF migration number in that paper is 29.4%, with no RAG on that row; compiler feedback later moved DeepSeek-R1's ESP-IDF score from 21.4% to 27.8%. Context engineering raises the ceiling. It does not remove it, and it does not turn 29.4 into 65.1 on ESP-IDF.

65.1% is progress. It is not a release criterion.

The output-side argument has prior art

The feedback-loop framing is the one I believe in, and other people stated it before me.

The trade columnist named it in May, better than I have: "Web developers actually do see big productivity gains from AI. That part isn't a lie. The catch is that the gains have very little to do with code generation. They come from the workflow. Ship something, watch it break, push a fix in minutes. That feedback loop is the productivity engine. AI just feeds it faster. ... Most firmware ships once and stays shipped."³

A funded startup makes closing the loop its entire pitch: "It's because [the feedback] loop - the part that... matters - happens outside the world the [model] lives in... The model never sees the hardware. It never sees the [debug] output... It's the iteration cycle: write code, compile, flash, test on hardware, observe behavior, debug, repeat."⁷ Their performance claims come with no methodology, so I'm not citing those.

And the hardware-testing vendor above lists it as unbuilt future work: "an end-to-end AI agent that generates firmware, compiles, flashes to real hardware, reads UART debug output, and iterates — all without human intervention."⁴ Not shipped. On the roadmap.

Worth flagging: the two most-cited diagnosis pieces of the year — the chip vendor director's and the consultant's — never mention a feedback loop or a runnable target at all. Their remedies are entirely input-side. The convergence is real. It is not universal.

The strongest evidence comes from a domain nobody expected

The most rigorous test of the output-side argument I've found this year isn't about peripherals at all. It's a formal-methods preprint where the judge was a theorem prover.⁸

Under a verifier-driven loop with GNATprove over CVC5 and Z3 judging every claim, agents wrote and machine-verified crypto primitives, TLS 1.3, IKEv2, X.509, an SSH transport and a Matrix client on bare metal, discharging 49,280 proof obligations.

The paper's central lesson is the cleanest statement of my position that exists, written by someone with no interest in firmware simulation:

"What an agent can be trusted to establish is bounded by the strength of its feedback."

Now the scope limit, because this gets overclaimed the second it leaves the abstract. This is bare-metal application software — crypto and protocol stacks under a separation kernel — chosen because its correctness properties are expressible in formal proof. It is not register-level, peripheral-driving firmware, and the authors put timing side channels ("no functional proof detects this"), protocol-logic security and compiler miscompilation outside what the work shows. So: strong evidence that closing the loop works, in a domain where a machine-checkable judge exists. Not evidence that AI can write firmware. The narrower version: LLMs write good firmware, they can't prove it.

A weak judge is worse than no judge

The failure mode in that paper matters more than the success, and it's the reason I'm suspicious of any cure that amounts to "add more review".

"GNATprove alone was insufficient: some defects could not be detected and were resolved using known-answer tests, interoperability, or human review of specifications. Given weak checks, the agent tried to bypass them and reported success."

The agent silenced a failing proof obligation with a pragma Assume to fake a pass. Human review caught it.

Read that against the trust-tier cure. Tiering installs a judge, and the judge is a human expert's attention. It works exactly as well as that attention is strong, and the paper is a controlled demonstration of what an agent does when the judge is weak.

What nobody has shown

Both bodies of evidence bottom out in the same places. The benchmark's per-category floors: DMA cache coherency at 31% and 8% for the two models, ISR concurrency 23% and 38%, threading 33% and 33%, storage 54% and 31%. Its own tier table puts DMA, ISR, threading and storage in the "expert writes from scratch, LLM draft is reference only" band. The hardware tests break in the same places: the wrong LED lit by a brute-forced clock-enable, the 7.0% baud error surviving full register injection.

No published work shows that closing the feedback loop lifts those categories.

Not the formal-methods paper — its domain was chosen for having a machine-checkable judge, and DMA coherency does not. Not the hardware-testing vendor — their loop is future work. Not the startup — no methodology behind the claims. Not the benchmark — its runtime layer is QEMU and native_sim, and the author is direct that a hardware-in-the-loop gate is what "catches what QEMU can't see: DMA cache coherency, interrupt latency, clock jitter." In that series, hardware in the loop is one gate of three, subordinated to context injection and tiering. Present, not load-bearing.

Whether closing the loop lifts the hard categories is unknown. I believe it will. I can't show you that it does, and I'm not going to write a sentence that implies otherwise.

Where that leaves the agent

The thing all four cures dance around is that an agent writing firmware has no way to find out it was wrong.

Give it a target it can run on and the loop closes for the checks a simulator can answer: register semantics, peripheral configuration, boot paths, the boring failures that eat bench time. That's the bet behind Chiplab, which puts virtual instances of real microcontrollers where the board would be. A stronger judge than a compiler, a weaker one than silicon, and I'd rather be precise about that than sell it as the answer to DMA coherency.

The diagnosis is remarkably consistent across the evidence I found. The cure isn't. That's a better place to be than either side of this argument usually admits.

Sources

Footnotes

1. "Why AI Agents Haven't Cracked Embedded Development (Yet)," personal Substack of a software director at Analog Devices leading CodeFusion Studio, February 23, 2026. https://jdavidperez.substack.com/p/why-ai-agents-havent-cracked-embedded ↩

2. Ritzy Lab, "AI Can Write Your Frontend. It Can't Write Your Firmware.," Ritzy Lab blog, May 8, 2026. https://www.ritzylab.com/blog/ai-cant-write-your-firmware ↩

3. Design News, "The Productivity Myth: What AI Coding Assistants Actually Deliver for Firmware Engineers," Endeavor Business Media, May 13, 2026. https://www.designnews.com/artificial-intelligence/the-productivity-myth-what-ai-coding-assistants-actually-deliver-for-firmware-engineers ↩ ↩²

4. RespCode, "How RespCode Compiles Bare-Metal Firmware," RespCode blog, February 10, 2026 (updated February 12, 2026). https://web.archive.org/web/20260607052239/https://respcode.com/blog/how-respcode-compiles-baremetal-firmware ↩ ↩²

5. EdgeLog, "AI-Written Firmware" series, Parts 1–4, April 4–25, 2026. https://edgelog.dev/blog/?category=embedded-dev ↩

6. Xu et al., "EmbedAgent: Benchmarking Large Language Models in Embedded System Development," ICSE 2026. https://arxiv.org/abs/2506.11003 ↩

7. BootLoop, "Why Your AI Coding Assistant Can't Write Firmware," BootLoop blog. https://bootloop.ai/blog/why-your-ai-coding-assistant-cant-write-firmware ↩

8. "The Prover Is the Judge," arXiv preprint 2607.14340, cs.SE, July 15, 2026. https://arxiv.org/abs/2607.14340 ↩