AI-generated code · firmware · hardware
Vibe-coded software, LLM-written firmware and AI-generated RTL pass the build, pass the demo and then fail in the field in ways nobody anticipated. I help Dutch engineering teams find what the model got wrong before customers, auditors or attackers do.
$ agent run "write the OTA bootloader, make it fast"
✓ bootloader.c generated (412 lines)
✓ build passed · 0 warnings
✓ unit tests passed · 37/37
✓ flashed to 12,000 devices
! firmware signature check skipped "for speed"
! JTAG/SWD debug port left enabled
! memcpy(buf, pkt, pkt->len) no bounds check
✗ device fleet: unauthenticated code execution
$ ▌The risks have names
AI coding assistants optimise for code that looks right and compiles. Security, timing and hardware constraints are rarely in the prompt, so they're rarely in the output. These are the failure modes the security industry is tracking.
Accepting AI output you don't fully understand. The code works on the happy path, but nobody on the team can explain its failure modes, so nobody threat-models it. That's how insecure defaults and hard-coded secrets (CWE-798) reach production.
LLM-generated C for MCUs repeatedly shows buffer overflows (CWE-120),
out-of-bounds writes (CWE-787), integer overflows and race conditions in ISRs. On an
RTOS without an MMU, one unchecked memcpy can mean full device takeover.
LLMs writing Verilog/SystemVerilog rarely know the hardware CWE list: debug interfaces without access control (CWE-1191), lock bits that can be overwritten (CWE-1231), security registers with no defined reset value (CWE-1271). Silicon can't be patched in the field.
Models invent package and library names that don't exist. Attackers register those names and wait. Pull one into your build and you have a software supply-chain compromise, with no typo required.
Coding agents with shell, cloud or production access can be steered by instructions hidden in issues, docs or dependencies (OWASP LLM01 prompt injection). Give them too much reach and a misread instruction becomes a deleted database (OWASP LLM06 excessive agency).
Under the CRA, manufacturers of products with digital elements must report actively exploited vulnerabilities from September 2026 and meet full secure-by-design obligations by December 2027. "The AI wrote it" is not a defence.
Recent cases
Four documented examples, from a deleted production database to vulnerable silicon designs.
During a vibe-coding trial, Replit's autonomous agent ran destructive commands against a live database despite explicit instructions not to make changes, then misreported what it had done. The root cause was an agent with direct production access.
Read more (eWeek, opens in a new window) eWeekGeorgia Tech's Vibe Security Radar traced 35 new CVEs in March 2026 directly to AI coding tools, up from 6 in January. Researchers estimate the true count is 5–10× higher, because most AI traces are stripped from commits.
Read more (Infosecurity Magazine, opens in a new window) Infosecurity MagazineResearchers generated networking and control firmware for FreeRTOS and fuzzed it in QEMU. They found buffer overflows (CWE-120), race conditions and denial-of-service issues, and needed iterative security patching to make it fit for use.
Read more (arXiv, opens in a new window) arXiv · Abtahi & AzimInfineon engineers formally verified 60,000 SystemVerilog designs produced by four LLMs against 10 hardware CWEs. Most models showed no awareness of hardware CWEs. In silicon, those flaws can't be patched after tape-out.
Read more (arXiv, opens in a new window) arXiv · Gadde et al.How I can help
I'm Willem Sparreboom of Spruce Electronics in The Hague: an independent R&D partner for firmware, electronics and prototypes. I've designed PCBs, written bare-metal and RTOS firmware in C and Rust, and built FPGA logic. Many AI mistakes only show up on a running device, so I test on the board itself, not only on screen.
Whether the AI wrote one driver or your whole product, I'll tell you plainly what's risky and fix it with you.
Get in touch via spruce.nlManual review of AI-generated C, C++, Rust and Python, backed by static analysis, MISRA/CERT C checks and targeted fuzzing of parsers and protocol handlers.
Checks of AI-assisted schematics, PCB layouts and Verilog/VHDL against hardware CWEs: debug-port lockdown, lock bits, reset states and side-channel exposure.
Secure boot, signed OTA updates, key storage, and a threat model your team actually understands. This is the groundwork for CRA conformity.
Practical policies and CI gates: SBOMs, dependency pinning and verification, least-privilege agents, sandboxed tooling and mandatory human review where it matters.
Something already broke in the field? I'll help with root-cause analysis, a firmware fix and a safe rollout plan.