AI-Assisted Embedded Development: A Workflow That Works, and Where It Fails

The honest starting point

AI coding assistants are good at embedded work in some places and dangerous in others, and the dangerous places are exactly the ones where embedded differs from web or application code. The assistant has read a great deal of code and a great many datasheets, but it has never touched your board. It does not know which silicon revision you have, which errata apply, how long your trace is or what your power supply does under load. Used carelessly, it produces code that compiles, looks right and fails on hardware in a way that takes days to find. Used with a workflow that keeps the hardware as the final judge, it saves a great deal of time. This article describes the workflow we use.

Where an assistant earns its keep

• Boilerplate and scaffolding. Project structure, build files, a driver skeleton, a device tree node, a state machine outline, a unit test harness. These are patterned, checkable and tedious.
• Reading what you already have. Explaining an unfamiliar vendor SDK, summarising a module, tracing how a request flows through a code base, finding every place that touches a shared variable.
• Log and crash triage. A long boot log, a hard fault register dump or a protocol trace is a text problem. The assistant is fast at spotting the line that matters and at proposing hypotheses, which you then test. See our article on giving an assistant access to a serial port.
• Code review. A second reader that looks for missing error checks, integer overflow, unsafe interrupt use, forgotten volatile qualifiers and inconsistent locking. It does not replace a human review, but it catches the dull mistakes cheaply.
• Tests and tooling. Host-side unit tests for parsing and state logic, scripts for flashing, log analysis and test reporting.
• Documentation and migration. Turning code and notes into readable docs, porting between similar platforms, updating an API across many files.

Where it fails, and how it fails

• Hardware facts. Register names, bit positions, addresses, clock tree values, pin alternate functions, timing numbers. An assistant will produce plausible ones that are wrong for your exact part. Never accept a register fact that you have not checked against the reference manual or the vendor header.
• Silicon quirks. Errata, undocumented behaviour, the sequence a peripheral really needs. These are in the experience of people who have been burned, not in the text it was trained on.
• Timing and concurrency. Code that is correct in a single thread and wrong with an interrupt. Races, priority inversion and memory ordering are weak spots.
• Version drift. APIs change between SDK and kernel versions. An assistant may write to an old interface that your version no longer has, or invent one.
• Resource limits. It will happily allocate a big buffer on a device with a few kilobytes of RAM, or use a library that does not fit.
• Overconfidence. It rarely says "I do not know". It says something fluent.

The workflow

1. Give it the facts instead of letting it recall them. Paste or attach the relevant datasheet pages, the register description, the vendor header and the errata note. Ask it to quote the page or the register definition for each hardware claim. A claim with no source is a guess.
2. Keep a project guide file in the repository, which the assistant reads at the start: the chip and revision, the toolchain and versions, the coding conventions, the memory limits, which APIs are forbidden in interrupt context, how to build, flash and test. Write down the rules you would tell a new engineer on day one.
3. Ask for small steps. One function, one driver feature, one test at a time, each reviewed. Large unreviewed changes are where hallucinated details hide.
4. Close the loop with the hardware. Build, flash, run, read the log, compare with what was expected. The most effective set-up gives the assistant a way to do this itself, through a command-line flash tool and a serial console it can read, so that it tests its own change. Start read-only, and keep a person watching anything that can drive hardware.
5. Test on the host where you can. Parsers, protocols, state machines and calculations can be built as ordinary programs and run thousands of times in a second. Have the assistant write those tests first, then the code.
6. Review the diff like any other change, especially configuration, interrupt and DMA code, and anything that touches clocks, power or memory layout.
7. Record why. When the assistant and the hardware disagree and the hardware is right, write the lesson into the project guide so that the next session starts with it.

Safety and confidentiality

• An assistant that can send commands to a device can also send a harmful one. Do not connect it to hardware where an unexpected command damages equipment or injures someone.
• Logs and source code are shared with the model provider unless you run a local model. Keep keys, tokens, customer data and unreleased designs out of what the assistant sees, and check your contract and the provider's terms for what is retained.
• Check the licence of anything generated or imported. Generated code is not exempt from your licensing rules.
• Decide who is accountable. The engineer who merges the change owns it, whoever wrote the first draft.

What to expect

For routine firmware work, the gain is real and comes mostly from removing the tedious: scaffolding, logs, tests, reading unfamiliar code. For work at the edge of the hardware, such as bring-up of a new board, a marginal bus or a power problem, the assistant is a fast note-taker and hypothesis generator, and the bench, the oscilloscope and the experience of the person holding the probe still decide. The teams that benefit most are the ones that already had good build, test and review habits, because the workflow above is a faster version of them, not a replacement.

A tool we built for this

For the log and console part of the loop we built xtell-serial, an open-source serial terminal with a window that your assistant can drive through the Model Context Protocol, so you and the assistant read the same log. We use AI assistants in our own bench work, and our embedded software and firmware development services are delivered by engineers who check the hardware, not just the generated code.