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

AI makes software feel free, but a physical product carries mechanical, materials, electronics, and power constraints no prompt can wish away. An AI Builder cheat-sheet.

Why connected-product timelines slip in the firmware phase — and what actually moves the date. Reuse a proven foundation and put factory-floor experience in early to ship in weeks, not months.

Why firmware bugs pass on the bench and fail at the customer — the bench removes real power, real time, and real scale. If you can't reproduce it, make the field observable.

Never push a firmware update to a whole fleet at once. A canary (staged) rollout updates 1% first, watches health, and widens only on evidence — so a bad build stops at 1%, not 100%.

MikroTik patched the exploited MikroTrick RouterOS chain on Sep 3, 2026 and added a tamper self-check. Why a patch removes the way in, not what got in, and how to design for recovery.

Firmware is code judged by what the hardware does. The sense-decide-act loop under every connected product — and how to use AI on firmware without confidently wrong answers.

A single-sourced critical part is one point of failure for the life of your product. Why sourcing resilience is designed into the BOM early — second-source the parts that would stop your line.

A device that reports no errors can be silently failing. In the field you can only debug what was already recorded — so build observability in by default, not after the first failure.

Every cryptographic key a device ships with will eventually change. How to rotate keys across an IoT fleet safely — overlap, staged waves with rollback, a root of trust — designed in before you ship.

Ahead of embedded world North America (Sep 22-24, 2026, Anaheim): why embedded and edge became their own discipline, what to watch — edge AI, security, power, tooling — and why the value moved into software.

Getting a device online is the easy part. The real job is surviving dropped links and landing trustworthy data — device to fleet to data, and how to use AI on connectivity without shipping nonsense.

A working prototype answers 'can it work?'; manufacturing answers 'can we build a thousand that all work?' How DFM, staged builds, and factory-floor experience get a hardware product to volume.

Some devices run for weeks then crash for no visible reason — memory leaks, heap fragmentation, counter overflow. Why long-life reliability is designed in, and how to watch the trend.

Most of a device's firmware is third-party code, so its CVEs are your CVEs. Know what's inside (SBOM), know which devices run it, and be able to push a fix fast.

The embedded world North America 2026 keynotes point at agentic, autonomous edge devices. Before an AI agent may act through hardware, firmware must give it bounded states, a way to say no, and a record.

The model is the easy part of edge AI. Running it on-chip, watching it drift, updating it over the air, and securing it for years is firmware — and it decides the outcome.

Skip the hundred-chart dashboard. The five fleet-health metrics that matter — check-in rate, version spread, error rate, battery/resources, and update success.

Zero-touch onboarding is an identity problem, not a setup screen. How X.509 certificates, secure elements, and factory provisioning let a device join the right cloud with no hands.

T-Mobile retired the last US 2G network on August 3, 2026. Why stranded devices aren't broken, when network sunsets matter (5-10+ year devices), and how to design for a network's retirement.

AI doesn't reward the best prompt; it rewards the best context — and the awareness to verify. Why context beats prompting, why awareness beats mastery, and a tested prompt.

Firmware flags are hidden states that multiply into your hardest bugs. Name your states, decide transitions in one place, and the worst failures lose their hiding spots.

A shipment count isn't an inventory. Why you can't manage a fleet you can't enumerate, why device identity must start at the factory, and why inventory has to update itself.

AI doesn't reward the best prompt; it rewards the best context — and the awareness to verify. Why context beats prompting, why awareness beats mastery, and a tested prompt.

From 11 September 2026 the EU CRA requires a 24-hour early warning, 72-hour notification, and 14-day final report. Why meeting the clock is a fleet-visibility problem.

A datasheet describes a part under the maker's conditions, not yours. How part verification really works — build a bench, prove a sample against your use case, at design-in.

Reaching first boot proves a board is alive, not that it's reliable. The gap to working in the field — power loss, lost links, long uptime, bad input — is most of the job.

A prototype proves it works; a factory has to build it 10,000 times. The Design-for-X gap - assembly, tolerances, test, shipping - and what engineers miss.

For a decade the advice was 'specialize.' AI commoditised depth, so range is the new moat. Why generalists are back, what the word means now, and how to become one.

Arm just built its first chip - but its dominance was never the core. Why the ecosystem above it is the real moat, and the lesson for builders.

At 100 devices the manual path works; at 100,000 it hits a wall. What breaks at IoT scale, and the device-side traits that make growth a non-event.

EmbedIQ is an open-source (Apache 2.0), RTOS-agnostic architecture layer for embedded and connected products - runs on your laptop today, observability built in.

Most firmware is a common layer every device needs; your product is the smaller slice on top. How to sort the two piles and spend your time on what is yours.

'Full-stack' names a slice of one product's build. The real stack - deep even for pure software, a superset for a device - is far bigger. Here is the full map.

Pushing one update to a whole fleet at once is risky. Roll it out as a staged campaign - canary, cohorts, full fleet - watched and reversible. Here is how.

A modern RTOS like Zephyr now maintains its own security - but proving your product's security across a fleet lives in the architecture above the kernel.

An RTOS is portable by design. Your architecture is the higher-leverage layer above it - here is how to design that layer so it carries to the next chip.

A key component goes end-of-life mid-production. Why it's a clock not a swap, the five things it sets off, and how to fix it upstream and stage the migration.

AI raises the floor in every domain - a 5,000-agent study found +34% for novices - but it's jagged. So the scarce skill is range. Part 1 of AI Builder.

The EU Cyber Resilience Act (Reg 2024/2847) makes device security a condition of market access. The deadlines (11 Sep 2026 reporting, 11 Dec 2027 full compliance), what it demands — SBOM, vulnerability handling, signed updates, CE marking — and why it's really an architecture decision, not paperwork. Plus the CRA FAQ.

Why connected products stall at the jump from one device to thousands, and the five jobs that carry you across: provision, monitor, update, recover, secure. Plus the FAQ on device provisioning, staged OTA rollout, and fleet monitoring.

Over-the-air update is not one thing, it is three: an update server that decides and stages, an update agent that fetches and verifies, and a bootloader that switches and recovers. The full architecture — signed, atomic, reversible — across MCU (MCUboot, ESP-IDF) and Linux (RAUC, Mender, SWUpdate), with EmbedIQ as open proof.

AI writes code faster than any of us, yet our quality went up. The reason is a shape we built around it: one human, two machines, and the rules between them. The full playbook — the three chairs, the layered rules, git as the single source of truth, the learning loop, the tests-first gate — with EmbedIQ as open proof.

You press enter and a page arrives from 6,000 miles away. Follow one request across the planet and back — DNS, routing, TCP, TLS, HTTP — and why it feels instant.

You type a sentence and a machine answers one word at a time. Four moves — words become numbers, attention weighs every token, and the answer is built one token at a time.

A working prototype feels like the hard part is over. It isn't. The gap between 'it works on the bench' and 'it ships from a factory, the same way, ten thousand times' is where well over half of hardware startups quietly stall. Introducing FactoryOpsLab: engineer-led CM search, production readiness, test fixtures, and end-of-line testing, so your engineers stay on the product.

A hardware team's most expensive people spend a surprising share of their week not designing the product — they're chasing a distributor, comparing datasheets, waiting on a sample, or proving a part does what its spec claims. We call it the sourcing tax. Introducing PartOpsLab: engineer-led part sourcing, verification, and bench-testing, so your engineers stay on the product.

You press power and a screen appears. It feels like one event. In the ~400 milliseconds in between, a chip that woke up with no running software pulls itself up by its own bootstraps — reset vector, startup runtime, the linker's map, drivers waking one bus at a time, a scheduler taking the wheel, the first pixel. Part two of the 'What Actually Happens When…' series, embedded-first.

You press power and a screen appears. You type a web address and a page arrives. You send a model a sentence and an answer comes back. Each feels instant — and none of them is simple. The opening of a new series that falls all the way down the stack: what a 'stack' actually is, why we built computing in layers, and why the layers vanish from view exactly when they work.

The anxious question is whether AI will replace embedded engineers. The useful question is which engineers it makes more valuable — and which it quietly makes redundant. AI commoditizes writing code and makes judgment scarce; the engineer who owns the system gets more valuable, not less. A one-line test for which side of that gap your work sits on.

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.