In September 2025, researchers Seyed Moein Abtahi and Akramul Azim at Ontario Tech University published a paper titled Securing LLM-Generated Embedded Firmware through AI Agent-Driven Validation and Patching (arXiv:2509.09970). They tested GPT-4-generated firmware on FreeRTOS in QEMU, ran it through fuzzing, static analysis, and runtime monitoring, and catalogued what they found.

Their headline finding: a structured validation pipeline could remediate 92.4% of vulnerabilities introduced by LLM-generated firmware, an improvement of 37.3% over baseline.

The corollary finding, which the paper does not state as bluntly as it could: without that pipeline, roughly one in three vulnerabilities in LLM-generated firmware would have shipped.

That is the gap this post addresses. We are not going to argue about whether to use AI-assisted firmware development, that argument is over, the tools are in every embedded team’s IDE already, and the productivity gains are real. The question that matters now is operational: how do you validate AI-generated firmware to a standard that does not ship preventable bugs?

This post is the methodology we use at Better Devices. It is informed by the Abtahi & Azim research, by the four bug patterns we have catalogued from real engagements, and by the harder lesson, that unit tests written by the same agent that wrote the code are not validation, they are a closed loop.

The Core Problem in One Sentence

Tests written by the agent that wrote the code verify what the code does, not what the spec requires.

Almost every operational problem with AI-generated firmware traces back to this. Unit test coverage looks excellent. CI is green. Functions have docstrings. The codebase appears reviewable. Then the firmware meets real silicon under conditions the test environment did not reproduce, and the bugs surface.

The Abtahi & Azim paper documents three vulnerability classes that consistently appear:

• Buffer overflows (CWE-120), typically from missing bounds checks the model omitted
• Race conditions (CWE-362), typically from shared state touched without synchronisation in concurrent firmware
• Denial-of-service (CWE-400), typically from missing input validation that allows resource exhaustion

These are the three categories the academic literature has measured. From engagement work, we add two more that the published research touches less directly:

• Hardware-software boundary bugs, DMA buffer alignment, cache coherency, peripheral register hazards
• ISR safety violations, excessive call depth, unprotected shared state, latency violations

The validation methodology that follows is designed to catch all five categories before code reaches production.

---

🔍 Already shipping AI-generated firmware?

If your team has been using Claude Code, Copilot, Cursor, or any other LLM-assisted tool for production firmware for more than six months and you have not run a structured validation pass, the academic literature suggests roughly one in three vulnerabilities introduced by AI assistance are still in your codebase.

We run focused validation engagements designed specifically to catch this class of bug before it ships at scale.

Request an Independent Validation Pass →

---

The Five-Layer Validation Stack

Each layer catches a different class of bug. None is sufficient on its own. The discipline is running all five, in this order, and treating gaps in any one as a stop-ship condition.

Layer 1, Static Analysis (Catches Known-Pattern Defects)

The cheapest layer to run and the first one most teams already have. The job at this layer is to catch the bug categories that pattern-matchers find reliably: buffer access without bounds checks, use-after-free, dereference of potentially null pointers, violations of MISRA or AUTOSAR coding rules if relevant.

Tools that work: Clang-Tidy, Cppcheck, Coverity, IAR C-STAT, LDRA. Run all of them. They have different strengths. The cost is a CI job; the value is finding the bugs that should never have shipped.

The specific configuration that matters for AI-generated code: turn on every check related to bounds, pointer arithmetic, and uninitialised values. The Abtahi & Azim paper specifically calls out Cppcheck and Clang Static Analyzer for detecting unsafe memory operations in LLM-generated code, these are the checks that earn their compute time.

What this layer does NOT catch: anything specific to hardware behaviour, anything specific to the build environment, anything race-condition-related under specific timing.

Layer 2, Independent Unit Tests (Catches Spec-vs-Code Divergence)

The critical word is independent. Tests written by the same LLM session that wrote the function verify the function does what the function does. They do not verify the function does what the spec requires.

Two practices make unit tests genuinely validating:

Practice 1, Tests are written from the spec, not from the code. The engineer reads the requirement, writes the test to verify the requirement, then checks whether the LLM-generated function satisfies that test. If the LLM wrote both, the closed loop is broken, either rewrite the test from the spec or scrap and start over.

Practice 2, Tests are written by a different actor than the code. Whether that actor is a different LLM session, a different engineer, or a deliberately adversarial prompt, the point is breaking the loop. The Abtahi & Azim paper achieves this through multiple specialised AI agents (Threat Detection, Performance Optimization, Compliance Verification) reviewing each other’s output rather than a single model reviewing its own.

What this layer does NOT catch: anything that requires real hardware to reproduce, anything where the test environment differs meaningfully from production.

Layer 3, Fuzz Testing (Catches Unhandled Input Cases)

The Abtahi & Azim paper relies heavily on fuzz testing, specifically, AFL++ and Syzkaller-style coverage-guided fuzzing, and reports it as one of the highest-yield techniques for surfacing LLM-introduced vulnerabilities. The reason is structural: LLMs are excellent at handling the cases they were prompted for and routinely poor at handling cases they were not. Fuzzing exposes the cases that were not prompted for.

Tools that work: AFL++ for general coverage-guided fuzzing, libFuzzer for in-process fuzzing of specific functions, Syzkaller for kernel-level fuzzing on embedded Linux. For protocol handlers, custom fuzzers using boofuzz or Peach Fuzzer.

The specific bug category fuzz testing finds in AI-generated firmware: malformed input handling. Models routinely write parsers that work for the happy path and fail silently or catastrophically on malformed input. Fuzzing finds these in hours.

What this layer does NOT catch: bugs that require specific hardware peripheral state to reproduce.

Layer 4, Hardware-in-the-Loop Testing (Catches Hardware-Software Boundary Bugs)

This is the layer that catches the bugs the other four layers cannot. If a team is going to invest in one layer beyond static analysis and unit tests, this is the one.

A HIL test bench runs the actual firmware on the actual silicon, with instruments injecting realistic stimuli on the actual peripherals. DMA buffer alignment behaves the way the silicon actually behaves. Cache coherency interacts with the actual cache. Peripheral registers have their actual latencies and side effects.

The specific bug category HIL testing finds in AI-generated firmware: DMA alignment, peripheral register hazards, ISR latency under real interrupt load, cross-peripheral interference. These are the bugs that pass every software-only validation layer and surface in the field at units 200, 2,000, or 20,000 deployed.

The cheapest HIL bench that does this work costs under €5,000 in hardware and 2–4 weeks of engineering to set up. Most teams do not need a six-figure commercial platform. We covered the bench-build approach in detail in the post on building a HIL test bench.

What this layer does NOT catch: bugs that only manifest under specific environmental conditions (extreme temperature, EMI, supply voltage transients) or after long-term operation.

Layer 5, Runtime Monitoring and Fleet Telemetry (Catches Field-Only Bugs)

The Abtahi & Azim paper measures worst-case execution time (WCET) and task jitter as real-time performance metrics, specifically reporting 8.6ms WCET and 195µs jitter as the post-validation targets. These are runtime measurements, not static properties.

In production, the equivalent is fleet telemetry that captures the same metrics across deployed devices. Devices that exceed WCET thresholds, devices that miss deadlines, devices with rollback events, each of these is a signal that the validation pipeline missed something.

Tools that work: Memfault, Golioth, AWS IoT Device Defender, custom instrumentation. The specific implementation matters less than the discipline of treating fleet telemetry as feedback into the validation pipeline, not just as a customer-support tool.

This is also the layer where CRA compliance becomes operationally relevant, per-device update status, vulnerability handling timelines, and security update evidence all flow from this telemetry. We covered that linkage in the CRA draft guidance post.

---

💬 Need help building the HIL layer?

Layer 4, hardware-in-the-loop testing, is the layer most teams skip and the layer that catches the bugs AI-generated firmware most often introduces. Most teams skip it because they assume HIL means a six-figure commercial platform. It does not.

We design and build HIL benches under €5,000 in hardware that catch the bug categories software-only testing cannot.

Talk to a HIL Engineer →

---

The Workflow That Ties the Five Layers Together

The layers are necessary but not sufficient on their own. The discipline is the workflow that runs them in the right order, with the right gates, on every change.

On every commit:

• Layer 1 (static analysis) runs in CI
• Layer 2 (independent unit tests) runs in CI
• Build fails if either layer flags a regression

On every pull request:

• Layer 3 (fuzz testing) runs against changed functions for a fixed time budget
• Coverage report is generated and reviewed
• PR cannot merge if fuzz coverage regresses against affected code paths

On every release candidate:

• Layer 4 (HIL testing) runs the full bench suite against the release-candidate firmware on real hardware
• Worst-case execution time and task jitter are measured against published thresholds
• Release is gated on HIL pass

Continuously in production:

• Layer 5 (fleet telemetry) reports per-device firmware version, update status, rollback events, deadline misses
• Anomalies feed back into the validation pipeline as new test cases

The Abtahi & Azim paper formalises a version of this workflow with three specialised AI agents (Threat Detection, Performance Optimization, Compliance Verification) operating in an iterative loop. The agentic approach is interesting and worth tracking, but the core discipline is the workflow itself, agents or human reviewers, the gates and feedback loops are what catch bugs.

What to Do If You Inherit a Codebase

If you are reading this and your team is already shipping AI-generated firmware without the layers above in place, the recovery workflow is different from the prevention workflow.

Step 1, Inventory. How much of the codebase is AI-generated? Most teams cannot answer this cleanly. Use git blame, commit message patterns, doc-comment fingerprints, and conversations with the team to estimate. If the estimate is above 30%, treat the codebase as high-risk by default.

Step 2, Prioritise. Not all AI-generated code is equally risky. Sort by exposure: anything in the bootloader, OTA pipeline, security-critical paths, ISRs, or DMA handlers gets validated first. UI logic, configuration parsing, and non-critical paths come later.

Step 3, Layer-by-layer retrofit. Run Layer 1 (static analysis) against the whole codebase first; triage findings. Then Layer 2 against the prioritised functions, rewriting tests from spec where the original tests were AI-generated. Then Layer 3 fuzzing on the protocol handlers. Then Layer 4 HIL on the prioritised paths.

Step 4, Establish the workflow going forward. New code cannot ship without the five layers running. The retrofit catches existing debt; the workflow prevents new debt from accumulating.

This recovery work typically takes 4–8 weeks for a mid-size firmware codebase. It is meaningfully cheaper than the alternative, which is discovering the bugs in the field.

---

🛠️ Want this methodology applied to your codebase?

The five-layer validation stack and the recovery workflow above are how we approach every engagement involving AI-generated firmware. We can run them against your codebase as a standalone audit, typically four to eight weeks, scoped to your highest-risk modules first.

Scope a Firmware Validation Audit →

---

What This Means for How Teams Should Use AI-Assisted Development

The Abtahi & Azim research, paired with what we see on engagements, supports a practical position: AI-assisted firmware development is appropriate when validation investment scales with productivity gain.

If a team is shipping firmware 2–3 times faster with AI assistance, the validation investment needs to scale proportionally. That is the operational test. Teams that pass it see net productivity gains and acceptable defect rates. Teams that fail it see velocity gains and concentrated risk in field failures 12–18 months later.

The five-layer stack above is one way to scale validation. It is not the only way. The principle is the discipline matters more than the specific tools.

We expect this conversation to mature significantly over the next 12–24 months as more academic research like Abtahi & Azim’s lands and as more teams accumulate production experience with AI-generated firmware. The methodologies will change. The principle, that the validation investment must match the speed gain, will not.

---

Frequently Asked Questions

How do you validate AI-generated firmware?

A defensible validation methodology requires five layers in combination: static analysis (Layer 1), independent unit tests written from the spec rather than from the code (Layer 2), fuzz testing for malformed input handling (Layer 3), hardware-in-the-loop testing on the real silicon (Layer 4), and runtime monitoring with fleet telemetry (Layer 5). No single layer is sufficient on its own.

Why are unit tests insufficient for AI-generated firmware?

Tests written by the same LLM session that wrote the function verify the function does what the function does, not what the spec requires. This closed loop produces high coverage numbers and undetected spec divergence. The Abtahi & Azim (2025) research found this is one of the most common operational failures in LLM-generated firmware validation.

What does academic research say about AI-generated firmware vulnerabilities?

The Abtahi & Azim (2025) paper Securing LLM-Generated Embedded Firmware through AI Agent-Driven Validation and Patching (arXiv:2509.09970) found that a structured validation pipeline could remediate 92.4% of vulnerabilities in GPT-4-generated firmware, an improvement of 37.3% over baseline. The most common vulnerability classes were buffer overflows (CWE-120), race conditions (CWE-362), and denial-of-service threats (CWE-400).

Can fuzz testing catch AI-generated firmware bugs? Yes, particularly the category of bugs related to unhandled input cases. LLMs are typically excellent at handling cases they were prompted for and routinely poor at handling cases they were not. Coverage-guided fuzzing with tools like AFL++, libFuzzer, or Syzkaller surfaces these gaps in hours.

Is hardware-in-the-loop testing necessary for AI-generated firmware?

For firmware that interacts with peripherals (DMA, SPI, I²C, network interfaces), HIL testing is the single highest-leverage validation layer. It catches the class of bugs, alignment, cache coherency, register hazards, ISR latency, that software-only testing cannot reproduce. A HIL bench capable of doing this work can be built in under €5,000 of hardware and 2–4 weeks of engineering.

Does the EU Cyber Resilience Act require validation of AI-generated firmware?

Not specifically, but the CRA’s general requirements for documented vulnerability handling, SBOM generation, and secure update mechanisms apply equally to AI-generated and human-written firmware. A validation methodology that satisfies the CRA for human-written firmware will typically satisfy it for AI-generated firmware. The risk is teams who scale AI-assisted productivity without scaling validation, leaving them with more code and the same validation budget.

What is the recovery workflow if my team is already shipping unvalidated AI-generated firmware?

The recovery workflow is: (1) inventory how much of the codebase is AI-generated, (2) prioritise by exposure (bootloader, OTA, security paths, ISRs first), (3) retrofit the five validation layers layer-by-layer against the prioritised functions, (4) establish the validation workflow going forward so new code cannot ship without it. Typical timeline is four to eight weeks for a mid-size codebase.

---

At Better Devices, we help embedded teams build the validation infrastructure that makes AI-assisted firmware development safe at scale. Our approach is informed by current academic research, including the work of Abtahi & Azim at Ontario Tech University, and refined through real engagements pulling apart production AI-generated firmware. Related reading: Vibe-Coded Firmware in Production: What We Found After Three Months, How to Build a HIL Test Bench for Embedded Devices, and Security by Design: Protecting Embedded Systems. If you would value an independent validation pass on AI-assisted firmware before it ships at scale, we should talk.