LLMs write good firmware. They can't prove it.

The papers all say the same thing.

EmbedAgent tested 10 LLMs on 126 embedded tasks across 3 hardware platforms. DeepSeek-R1, the best performer, hit 55.6% pass@1 with schematics provided and 50% without.¹ On ESP-IDF, the top model reached 29.4%. Englhardt et al. ran 450 trials and found that even when LLMs fail to produce working code, they generate helpful reasoning—but the reasoning doesn't translate to working hardware.² Promwad's analysis is blunt: GenAI works for boilerplate and documentation. It breaks on timing, concurrency, DMA, and real-time constraints.³

These papers measure code generation. But LLM firmware code generation is not the same as firmware that works.

The benchmark-to-production gap

Benchmarks measure what's easy to measure. A test case has an input, a model produces output, and you check if the output is correct. Pass or fail. Clean. Quantifiable. Perfect for a paper.

Firmware in production has a different shape. It compiles. It runs. It produces output. It doesn't crash under interrupt load. It doesn't corrupt memory when DMA and the CPU access the same buffer. It meets timing deadlines. It works on the actual silicon, not a simulation. It passes certification.

A benchmark can check the first two. It cannot check the rest without hardware.

We've made this exact point about CI before: a green build doesn't guarantee firmware that runs. Same gap, different layer.

Requirement	Benchmark measures	Production requires	Who verifies
Code generation	Yes	Yes	Compiler
Compilation	Sometimes	Yes	Compiler
Correct output on ideal conditions	Yes	Yes	Virtual board or HIL
Correct output under interrupt load	No	Yes	Real hardware
DMA buffer safety	No	Yes	Real hardware
Timing constraints met	No	Yes	Real hardware
Pin routing and electrical behavior	No	Yes	Real hardware
Certification compliance	No	Yes	Auditor + real hardware

The benchmarks are honest about this. EmbedAgent's abstract says it "enables end-to-end assessment from circuit design to cross-platform deployment." But "end-to-end" in the paper means: given a schematic, generate code. It does not mean: flash the code onto a board and verify it works. Englhardt et al. explicitly note that their testbench is "automated" and measures "LLM performance on embedded programming tasks"—not whether the firmware actually runs on hardware.²

This is not a flaw in the benchmarks. It's the boundary of what benchmarks can do. They're measuring generation. They're not measuring execution.

The feedback loop that never closes

The real problem lives here.

When you write firmware, you get a receipt. You compile. You flash. You run. The UART prints something, or it doesn't. The LED blinks, or it hangs. The sensor reads, or it returns garbage. You see the failure immediately. You fix it. You iterate.

The loop is tight. Feedback is fast. You learn what works and what doesn't.

It generates code. The code is evaluated by a benchmark: does it compile? Does it produce the right output in simulation? Pass or fail. But the model never sees what happens when that code runs on real hardware under real constraints. It never learns that DMA buffers can't live in flash. It never learns that interrupt masking has to happen before accessing shared state. It never learns that the UART baud divisor is wrong because the clock tree is different on this chip.

Every model that writes firmware is operating blind. It has no feedback from the machine.

This is why the benchmarks show what they show. EmbedAgent's 55.6% pass rate on simple tasks reflects models generating code in a vacuum, without feedback from the machine.

Promwad's analysis captures this exactly: "GenAI generates plausible code, not verifiable system behavior."³ Plausible is what you get without feedback; verifiable is what you get when you run the code and see what it does.

What LLM firmware code generation benchmarks actually measure

Let's be precise about what each benchmark is testing:

The EmbedAgent benchmark measures code generation on embedded tasks with and without schematic information. The "pass" criteria is that the generated code compiles and produces correct output in simulation. It does not test the code on real hardware. The 55.6% pass rate means: "55.6% of the time, the model generates code that compiles and works in simulation." It does not mean: "55.6% of the time, the model generates firmware that works on a real board."¹

Englhardt et al. tested LLMs on embedded programming tasks using an automated testbench. They found that LLMs can generate helpful reasoning and debugging suggestions, but their code often fails on cross-domain hardware-software tasks. The study explicitly notes that "embedded systems design and programming straddles the hardware-software interface and requires a cross-domain understanding of how devices interact with the physical world."² The testbench measures code generation. It does not measure whether the code works on hardware.

MDPI's benchmark (Babiuch & Smutný) evaluates LLMs on microcontroller-driven IoT applications. Like the others, it measures code generation and compilation. The scope is explicit: embedded systems programming in IoT contexts. It does not include hardware validation.⁴

Promwad's analysis is the most honest about the boundary. It separates where GenAI works (boilerplate, documentation, test scaffolding, code navigation) from where it breaks (timing, concurrency, DMA, real-time constraints, vendor SDK behavior). The key insight: "Firmware is not evaluated only on correctness at the function level. It is evaluated on deterministic behavior across interrupts, DMA transactions, memory boundaries, and timing constraints."³ Benchmarks measure function-level correctness. Production measures system-level behavior.

Why this matters

The gap between "code that compiles" and "code that works" is where most embedded bugs live.

In our earlier test of what LLMs get wrong about embedded code, we cold-prompted two models for hello-world firmware on three boards. Both models' HAL attempts failed to compile—the compiler caught stale APIs. Good. But their raw-register attempts all compiled clean. Six attempts, zero compilation errors. Then we ran them on virtual hardware. One of the small model's attempts produced zero output for five seconds. The code was syntactically correct, logically plausible, and completely broken. The compiler had no opinion. The benchmark would have passed it. The hardware said no.

That's the gap. That's where the loop breaks.

Code generation is valuable. But it's not the same as firmware that works. And as long as models have no feedback from hardware, they have no way to learn the difference.

The empty slot

This is where Chiplab fits: treating hardware as an API agents can call.

The benchmarks measure generation. Production needs execution. The gap is the feedback loop that closes the circuit.

An LLM that can generate code is useful. An LLM that can generate code, compile it, run it on virtual hardware, see the output, and iterate is something else entirely. That's a system with a receipt. That's a loop that closes.

The models won't get better at firmware by being better at language. They'll get better by getting feedback from the machine.

---

Footnotes

1. Jiang et al., "EmbedAgent: Benchmarking Large Language Models in Embedded System Development," arXiv:2506.11003v3, 2025. https://arxiv.org/html/2506.11003v3 ↩ ↩²

2. Englhardt et al., "Exploring and Characterizing Large Language Models for Embedded System Development and Debugging," CHI EA '24, May 2024. https://doi.org/10.1145/3613905.3650764 ↩ ↩² ↩³

3. Promwad, "GenAI for Firmware: Where LLM Code Generation Breaks Down in Real Embedded Systems," April 2026. https://promwad.com/news/genai-for-firmware-llm-code-generation-certification-risks ↩ ↩² ↩³

4. Babiuch & Smutný, "Benchmarking Large Language Models for Embedded Systems Programming in Microcontroller-Driven IoT Applications," Future Internet, vol. 18, no. 2, 2026. https://www.mdpi.com/1999-5903/18/2/94 ↩