Can AI Write Code for Microcontrollers? Yes, But That's Not the Interesting Part

Can AI write code for microcontrollers?

Yes, AI can write code for microcontrollers. Give an LLM a prompt for Arduino, ESP32, or STM32 firmware and it hands you working boilerplate in seconds. The caveat matters more than the yes: that code is a draft, not a deliverable. It can quietly ignore the timing, register, and real-time constraints that make embedded work embedded.

That's the small answer. The bigger story is what's happening one layer down, where AI agents are no longer just writing code for known chips. They're reverse-engineering chips nobody wrote documentation for at all, and generating the circuit boards those chips sit on. The question stopped being "can AI write code for microcontrollers" and became "who gets to understand the hardware they already own."

How good is AI at writing microcontroller code today?

Ask anyone who does this daily and you get the same answer: useful, unreliable, needs a human in the loop. A Hackaday writer tested GitHub Copilot against STM32F411 embedded C++ using CMSIS macros and got HAL code instead, plus a completely invented register constant, PWR_CR_VOS_SCALE1, that doesn't exist in any datasheet. The resulting voltage-scaling code didn't work.

That's not an isolated complaint. Practitioners on r/embedded describe the same failure mode: answers that read as confident and correct but are wrong, likely because embedded and low-level hardware code is underrepresented in training data compared to web and app code. Shawn Hymel, who has written some of the more practical guidance on the topic, puts it plainly: treat AI output as a draft, because it can miss hardware configuration, real-time behavior, or resource limits. Think of it as an eager junior engineer, not a finished contractor.

So the short answer holds. AI writes microcontroller code well for well-documented parts and common patterns. It gets shaky fast once you're outside a datasheet's happy path. That's the ceiling for autocomplete. What's changed recently is that the same models are being pointed at problems autocomplete was never meant to solve.

How is AI moving from writing firmware to reading it?

The more startling use of AI in hardware right now isn't generation, it's recovery. Instead of asking a model to write code for a known chip, researchers and hobbyists are asking it to reconstruct the instruction set of a chip nobody published specs for.

A hobbyist pointed OpenAI's Codex at the firmware binary of an $8 AliExpress MP3 player with no dev kit, no documentation, nothing but the raw dump. Codex produced a patch that fixed a Bluetooth stutter and remapped the buttons. The story got attention for a reason beyond the hack itself: the seller reportedly doubled the price once people started buying the player just to repeat the experiment. That's a decades-old category of work, embedded reverse engineering, collapsing from a specialist months-long slog into an afternoon anyone can attempt.

Security firm Faraday took that idea further and formalized it. They built a hybrid pipeline: an LLM interprets the semantic meaning of disassembled instructions, while deterministic code handles the exact bit-level field mapping the LLM tends to fumble. Pointed at pi32v2, a completely undocumented instruction set inside the JieLi SoC found in cheap vapes, the pipeline produced a working Ghidra plugin in about 2.5 hours for roughly $25 of compute.

They validated the approach against MIPS, a known architecture, and recovered about 98% of its instructions. The more telling number: 91% of that recovery work was done with zero AI calls. Deterministic code did the heavy lifting; the LLM stepped in for reasoning about what instructions meant, not for getting the bits exactly right. A human reverse engineer at Quarkslab independently worked out pi32v2 by hand around the same time and landed on compatible results, which is the corroboration that keeps this from being an AI-generated fairy tale.

Cisco Talos ran a parallel experiment connecting LLMs to IDA Pro via MCP for malware analysis. Claude 3.7 Sonnet, run in the cloud, analyzed more functions and wrote better comments and variable names than a locally run Devstral:24b model. It also cost more: one deep-analysis prompt ran $13.24 in Claude versus $0 running locally, with the tradeoff being local models' greater risk of hallucination and context-window limits. That's the same build-versus-buy calculus this publication tracks in software, now showing up in silicon: cloud quality versus local cost and control, and we cover that tradeoff in more depth in our rundown of local, open-source AI infrastructure.

Where do the models actually break?

None of this means AI reverse engineering is solved. SRE-Bench, a contamination-controlled benchmark of 262 compiled binary instances spanning networking, games, file formats, malware, and bare-metal firmware, gives the clearest picture of the ceiling. The leading tested agent, GPT-5.6-sol, fully solved only 31.5% of instances end to end, even though it scored 61.4% on partial credit.

The real wall isn't stripped symbols or compiler optimization. It's realistic anti-analysis protection: control-flow obfuscation, anti-debugging tricks, virtualized loaders. Add those and the leading model's mean score fell from 4.69 to 2.50 out of 6. A weaker model went from 3.07 to 0.33, essentially failing outright. Models are good at guessing what code is trying to do. They are much worse at fighting through code that's actively trying to stop them from figuring that out.

That 32% ceiling is the honest headline. It's a genuine capability, not a magic trick, and it's still closer to a research preview than a production tool for anything adversarial.

How is AI moving onto the board itself?

While one branch of this trend reads silicon backward, another writes hardware forward. In October 2025, PCB design platform Flux.ai launched agentic features that take a plain-language project description and plan it, research parts, generate a schematic, connect nets, and route a full board. Flux CEO Matthias Wagner framed it directly: "LLMs are great at writing code, but until now they didn't have the context necessary to design PCBs," describing the tool as effectively a junior hardware engineer.

That's the same shift the software side has already been through with AI-generated UI components, applied to copper traces instead of divs, a parallel we've covered in the context of replacing design software with AI workflows. It won't replace a senior hardware engineer's judgment on power integrity or EMI any more than an AI-generated component replaces a senior frontend engineer's judgment on accessibility. But it moves PCB layout from a gatekept, expensive specialty toward something a founder or hobbyist can attempt on a Tuesday afternoon.

Who's actually building this stuff, and does IT know?

Here's the organizational version of the story. Employees are already building unsanctioned software with AI and calling it a Tuesday. Surveys put shadow AI usage at 65% of employees in one study and 59% in another, with speed and cost, not malice, cited as the top reasons people go around official tools.

Hardware hacking is heading the same direction, just with a longer fuse. When reverse-engineering an undocumented chip costs $25 and 2.5 hours instead of a specialist consultant's monthly rate, and PCB design costs a plain-language prompt instead of a licensed CAD seat, the barrier that used to keep this work inside a formal engineering pipeline mostly disappears. That opens the door to a few predictable problems:

• Unsanctioned firmware patches on production devices, applied by whoever figured out the AI-assisted workflow fastest, with no code review process behind them.
• Custom board revisions designed outside procurement, because an agentic tool made it cheaper to just build one than to file a request.
• Undocumented reverse-engineered components entering a supply chain with no paper trail explaining how anyone knows what's inside them.

That's shadow AI's hardware cousin, and it deserves the same governance instinct we've argued for around AI-generated code: know it's happening, then bring it under review rather than pretending it isn't, a stance we lay out in more detail in our governance rules for AI-generated code.

Can AI write both the bug and the patch?

The security angle cuts both ways, and that's worth sitting with. A 2025 academic study combined GPT-4-generated embedded firmware with an automated pipeline of fuzzing, static analysis, and runtime monitoring agents. On FreeRTOS/QEMU targets, the pipeline hit a 92.4% Vulnerability Remediation Rate, a 37.3% improvement over baseline AI-generated firmware, and 95.8% Threat Model Compliance, all while holding an 8.6ms worst-case execution time that real-time systems require. AI introduced the flaws. A different agentic layer caught and fixed most of them, without breaking the timing constraints that made the earlier Hackaday firmware unusable. The lesson isn't that AI-generated firmware is safe. It's that safety now depends on whether you built the validation pipeline, not just the code.

What does this mean for who owns the hardware?

Strip away the novelty and this is the same argument this publication has been making about software, just one layer lower. Reverse-engineering an undocumented chip used to require a specialist firm, a stack of equipment, and a bill measured in months. Now it takes an afternoon and the price of a few API calls. Designing a PCB used to require a licensed engineer and a CAD seat. Now it takes a prompt and a review pass.

That's not a toy trend. It's the same shift that turned owning your database or your dev workflow from a specialist's job into a team's decision, covered in our look at building versus buying database infrastructure. Silicon has always been the deepest black box in the stack, the one layer even software-ownership advocates usually shrugged at and rented by default. AI is prying that box open too, imperfectly, at a 32% full-solve rate on the hard cases, but for real, at $25 a pop. If you buy the argument that the software you run should be an asset you understand and control rather than a black box you rent, that argument doesn't stop at the OS. It runs all the way down to the chip.