Imagine you had an assistant who'd read and digested a thousand different firmware projects. That'd be a handy person to have around. That's roughly what these tools are — and for firmware, it turns out to be more complicated than it sounds.
The short version: AI is very, very good at boilerplate. Stubbing out an entire project from nothing is honestly great. But firmware lives and dies on the details it's worst at, so how you use it matters a lot.
First, get your docs into Markdown
One concrete thing before anything else: get comfortable with Markdown. It's a simple text-based format, and AIs parse it cheaply and reliably — they've read enormous amounts of it. Think of it as budget word-processing in plain text.
A lot of the documentation you write for your firmware and hardware is probably sitting in Word. You can leave it there — most models will convert it on the fly — but every one of those extra steps costs you time and money. Keep your docs in Markdown and the model spends its effort on your problem instead of on file conversion. And if you've got a pile of existing Word docs, you can ask an AI to convert them and keep as much fidelity as it can. The frontier models do a decent job of that now.
Second, convert your schematic for agents
So most of us are used to working on firmware with a schematic in PDF or image format. That's fine for humans, but it's terrible for AI.
Most people will just try to upload the PDF or image to a frontier AI and get middling results at best. Most of the time if an AI parses a schematic PDF it will make many mistakes. An agent who doesn't understand how things are connected will do real damage, such as breaking working code, because it thinks connections are wrong. It's better to feed it nothing about the schematics.
So instead of feeding PDF schematics, if you can get your schematic into a machine-readable format — KiCad, Altium, or ideally a netlist — the model can reason about it and help you much more effectively.
Netlists are the best because they are a simple text format that describes the connections between components. If you can get your schematic into a netlist, you can feed that to the model, and it will have a much better understanding of how your hardware is connected.
Keep your engineers in front
Understand going in: your firmware engineers are still phenomenally better at this than any AI is likely to become. The gap is bigger than it looks — it's just hard to see until you start using the tools yourself. We hire firmware engineers because we need someone to write this kind of code, and yes, the models can write code pretty well. The difference shows up everywhere else.
How I'd actually use it — debugging
Here's the workflow I'd start with. When you hit a bug, don't start typing into the AI. Open a notepad — whatever editor you like — and write about a paragraph describing the problem. Then write another describing your product and how the firmware interacts with it, because the model has no context for your system. It has general knowledge, but far less than you'd think about the specifics of how your product actually works.
Then hand all of that to something with access to your source — Claude Code, Codex, whatever you use — and talk through the problem with it. Tell it what you've already tried. Ask it to interview you: to ask questions and walk through possible causes interactively. Fully describing the problem up front is usually what gets the thing rolling, and the back-and-forth that follows is genuinely useful — rubber-duck debugging that talks back and helps you think.
For this, use the highest-end model you can get your hands on — Fable, GPT-5.6, whatever's top of the line for you. The better models give you a meaningfully better set of candidate causes. This is the opposite of the flashy "I built a whole app from scratch in ten minutes" demo. This is the deep, in-the-weeds debugging session, and it's where I get a lot of the value.
How I'd use it — adding something new
If you need to build something from scratch, or bolt a feature onto an existing project, and you're new to this, here's my suggestion: give a frontier model your source code and say, "I want to add X, Y, and Z. Make as few changes as possible, or isolate your changes to a new file I'll integrate myself." That keeps the blast radius small and keeps you in control of the integration. It's a great way to test the water. Then you can review the changes, and if you like them, you can ask it to do more. If you don't like them, you can ask it to try again. The frontier models are good at this — they can make a lot of changes quickly, and you can iterate with them.
Be careful with agents and firmware
Just because the model writes syntax-perfect source code does not make it more correct than a firmware engineer. I find the more a firmware project uses agents, the more guardrails it requires. Things like unit tests, regression tests, static analysis, and hardware-in-the-loop testing are all critical to ensure the code is correct. The more you leverage agentic programming, the more these guardrails are table stakes. If you don't have them, you will be in a world of hurt.
The one rule
Whatever you do, don't let the AI take over or own the product-knowledge side. The engineering limits of your product are something it can never fully understand the way a person can — and you do not want to hand off that liability, or let it own a recall for you. Your engineers stay firmly in charge.
Used that way, it honestly does speed things up — a lot — if you know how to apply it.
If you're trying to figure out where it fits your firmware process, I'm happy to talk.