There is a great deal of noise about whether AI is coming for the programmer’s job. I think that is the wrong question, and embedded is a good place to see why: these tools eat the tedium, not the engineer. That is easy to say in the abstract, though, so here is the concrete version – what it is actually like to have an LLM riding shotgun while you work on embedded firmware, the kind of low-level C that flies drones rather than serves web pages.

Short version: it is genuinely useful, and it will also lie to you with total confidence about a register that does not exist. Both things are true. The skill is knowing which is which.

Where it genuinely earns its keep

There is a whole class of work where an AI pair is a clear, daily win:

  • Boilerplate and scaffolding. A new driver skeleton, a config table, the tenth near-identical target file. Tedious, pattern-heavy, low-risk – exactly its wheelhouse.
  • Explaining unfamiliar code. Drop in a gnarly function from a vendor SDK or a decade-old corner of the codebase and ask what it does. It is a fast, patient reader, and a brilliant rubber duck that talks back.
  • Datasheet and protocol lookups. “Remind me of the DSHOT frame format,” or “what does this status bit mean” – it gets you to the right mental model far quicker than scrubbing a 1,200-page PDF.
  • The fiddly stuff. Build-script incantations, a regex you will write once and never again, a mechanical refactor across forty files, a first cut of unit tests. It absorbs the friction that used to eat an afternoon.

None of this is glamorous, and that is the point. It clears the underbrush so you spend your attention on the part that actually needs a human.

Where it falls flat on its face

Then you point it at hardware, and the wheels come off in instructive ways:

  • No feedback loop. The model cannot see your board. It has never watched a pin on a scope or felt an ESC get hot. It is reasoning about your hardware entirely from text, which means it is reasoning about a plausible board, not yours.
  • Confident invention. Ask it to configure a peripheral and it will cheerfully call an SDK function that was never written, or set a register that does not exist on this silicon. It pattern-matches from the chips it has seen, and the RP2350 is not an STM32 no matter how much the answer wishes it were.
  • Errata blindness. The hard-won knowledge in embedded lives in errata sheets and forum threads at 2am, not in tidy documentation. The model has mostly read the tidy documentation.
  • Timing and concurrency. Anything touching interrupt latency, race conditions, DMA ordering or cycle-accurate timing is where it is weakest and most dangerous – because the wrong answer compiles, runs, and bites you three weeks later in the field.

The pattern that actually works

The trick is to treat it like exactly what it is: a fast, well-read junior who has never held a soldering iron. You would not let that person commit ISR changes unsupervised, but you would absolutely hand them the boring refactor.

So: keep yourself firmly in the loop. Feed it the real context – the actual datasheet section, the actual SDK header, the actual pin mux – rather than letting it run on memory. Verify everything against the chip in front of you, not the chip it imagined. And keep it well away from timing-critical code unless you are checking every line.

Do that, and it is a genuine multiplier. Skip it, and you have automated the production of bugs that look right. The engineer who knows the difference is not getting replaced – they are getting faster. That, in the end, is the whole point: the tedium is what is on the chopping block, and good riddance to it.