20+ years building.
Here’s what’s real.

Every week now someone asks me whether AI is going to replace embedded engineers. After 20+ years shipping firmware across 40+ products, bench to factory floor, here's the honest answer: AI changes the cost of writing code, not the cost of being wrong about the system. What startups taught me about what breaks, what factories taught me about what scales, and the part of the work that gets more valuable as AI gets better.

Of all the modules every embedded team rebuilds, OTA is the one I've watched the same engineer write five different ways across five products. The same is true for NVM, the watchdog, time sync, and logging. Write the hard parts once, above the product, and let every product inherit the hardening.

AI can write a clean driver but loses the thread on the whole system. The gap is not the model — it is structure that lives in two engineers' heads instead of on disk. Seven properties make a firmware codebase legible to the agent that now reads and runs it.

The hardest firmware bugs are the ones that only surface in the field. The move that closes the gap is older and simpler than most teams reach for: run the same firmware on your laptop with a faked HAL, and the change-to-result loop collapses from minutes on hardware to seconds.

Debugging is the largest hidden cost in firmware. The fix is the smallest bucket. Reproducing the bug is the largest. The team that measures it for the first time stops debating tooling priorities for the rest of the quarter.

Every firmware product has dozens of state machines. The form that compounds — for the team, the auditor, and the AI agent — is the flat five-column table. Boring to look at. Calm to extend. Hard to get wrong.

Shared state ships fast and reasons slowly. Message-driven costs an extra day of design and removes whole classes of bug — races, priority inversion, ambiguous ownership. It is also the only model an AI agent can reliably extend, because every interaction has a contract the agent can read.

A brilliant engineer. Six weeks chasing one field bug. The serial log had one line: ERROR: timeout. The fix took two hours. The move that changes that six-to-one ratio is structural — a bounded event taxonomy written once in the layer above the RTOS, captured by default.

Mbed OS reaches end of maintenance in July 2026. The conversation usually starts at the RTOS — Zephyr, FreeRTOS, NuttX. But the architecture above the RTOS is the part of the choice that compounds, across this migration and the next.

Every embedded codebase has the same shape: hardware, RTOS, application. Between the RTOS and the application is a space most teams have lived with implicit. The shift in 2026 is that this space has a name — and naming it on day one is the move that compounds across the team and the AI agent.

Every embedded codebase has three readers now: the team, the next hire, and the AI agent. The application-architecture spec is what each of them reads first. Six elements, a few pages, written once — compounding across all three.

AI agents already write good firmware at the function level — drivers, helpers, register-level code. The gap is one level up, at the architecture. Here's why, and what actually fixes it.

Every few months I watch a team debate RTOS choice for weeks, then ship code with the same structural problems regardless. The decision they're skipping is the one that matters.

A Fortune 500 hardware company, an external vendor, and the same class of bug appearing every sprint. What I eventually understood changed how I think about firmware quality forever.

20+ years of building. First year of writing. Here is the rule I am bringing with me.