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

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.