What this is.
Opinion + Experience + Fact (50% opinion · 30% experience · 15% fact · 5% fiction)
Written in collaboration with AI — I discuss, I do not outsource.

Chapter 1. The Frontend Works. The Firmware Crashes.

Ask an AI agent to build a React dashboard. You will get something that runs 🚀.

Ask the same agent to write a sensor driver on FreeRTOS for a real product. It compiles. Maybe. And it falls over at 3am under load.

That gap has been the strangest part of the past year-plus for me. I have watched AI coding tools get genuinely good — for web, for mobile, for backend. For firmware and edge systems, the same tools are still guessing. And the gap looks like it is widening.

▸ First principle. The same AI that ships React in minutes still struggles to ship firmware that survives a real production load — and the reason is not the model.

Chapter 2. The Pushback That Sharpened the Argument

A few weeks ago I posted a shorter version of this thesis on LinkedIn. It landed. But the most thoughtful response was not disagreement — it was refinement.

"AI does write good firmware. You just have to scope it right. Helpers. Drivers. Register-level glue." That came back from senior embedded engineers who have actually shipped real product. They are correct 🤝.

What I had written first read as "AI cannot do firmware." What was actually true was narrower and more interesting: AI does fine with the parts of firmware that look like backend code. It struggles with the parts that look like systems. Once I sat with the comments, the real argument got sharper. So this is the refined cut.

▸ First principle. The best critique on a thesis usually does not reverse it — it locates the boundary more precisely than the original draft did.

Chapter 3. Where AI Already Wins — The Function Level 🛠️

I have watched AI agents write surprisingly clean flash drivers. POSIX wrappers around lower-level filesystem APIs. Register-level helpers for chips most engineers would not recognise the part number of. One example I read recently — an agent stitched together ARM on-chip debug register addresses from hints across forums and datasheets, in a way that is genuinely impressive.

That is real value. Function-level firmware looks a lot like backend code — small, scoped, well-described inputs and outputs. The AI fills in the blanks beautifully when the blanks are already well-defined.

This is the layer of firmware where an AI agent today can save hours. Sometimes days. Teams that are not using AI for this layer are leaving work on the table 🎯.

▸ First principle. Function-level firmware is well-described work — and AI does well-described work very well.

Chapter 4. Where AI Falters — The System Level

The gap is one level up.

Stitch together a tangle of tasks and ISRs. Drop in a state machine that lives half in code and half in the lead engineer's head. Add a "shared globals" page that has not been updated since the original architect moved on. Now ask an AI to add a feature that touches three of those tasks and one of those ISRs.

The AI has nothing to anchor to. There is no message contract. No formal state schema. No machine-readable map of who talks to whom. So the AI does what it does best — it predicts the next plausible token. Plausible-looking code that violates assumptions nobody ever wrote down 💥.

I have seen this pattern across 40+ products over 20+ years. The teams that struggle most with AI-assisted firmware are not the ones with weak engineers. They are the ones with strong engineers — and no structure above the RTOS.

▸ First principle. AI guesses where the structure is missing — and at the system level, firmware leaves most of the structure unwritten.

Chapter 5. Why Web Frameworks Made AI Look Brilliant 🧠

Here is the part that took me a while to see.

React did not make AI good at frontend. The framework did. Components have typed props. State has a contract. Routing has a schema. Data fetching has clear patterns. When the AI agent reads a React app, it is not guessing — it is reading a structure that has already been decided.

Next.js, Django, FastAPI, Express — same story. Each one is a decision tree somebody else has already locked. The AI just fills in the leaves.

Firmware has the RTOS, and then a void. Every team rebuilds the rest. Every project carries a different convention. There is no shared "this is how we wire components together" the way React has "this is how we wire components together."

▸ First principle. Frameworks make AI look brilliant; the absence of a framework makes the same AI look incompetent. The variable is the structure, not the model.

Chapter 6. Helpers Fill In Blanks. Architecture Decides What the Blanks Are.

That is the real line.

It is not that AI cannot write firmware — it is that firmware does not yet have the structural scaffolding that lets AI write systems, not just functions. Web has it: typed props, route schemas, reducer contracts, ORM models. Firmware has the RTOS, and then a void.

Helpers fill in blanks. Architecture decides what the blanks are. An AI agent without an architecture is a fast typist with no idea what it is typing toward 😊.

▸ First principle. Architecture is the act of writing down what was previously unwritten — and that is exactly the gift an AI agent needs to do work above the function level.

Chapter 7. The Fix Isn't a Smarter Model 📐

The next jump for AI on firmware will not come from a bigger LLM. It will come from firmware finally having the same kind of scaffolding the web has.

A typed message bus, so every message between components carries a contract the AI can read.

A state machine described as a table, not a switch statement buried five files deep that only the original author understands.

Components that carry their own metadata — what they consume, what they produce, what they depend on, what state they own.

When that scaffolding exists, an AI agent generates firmware the same way it generates a React app today. By reading the structure. By filling in the logic. Not by guessing ✨.

▸ First principle. The leverage in AI-assisted firmware will come from making firmware structure machine-readable — not from waiting for a smarter model.

Chapter 8. What I'm Building 🛠️

I am working on exactly this. A structured layer above the RTOS that gives an AI agent something to anchor to — typed messages, table-driven state machines, components with metadata. Apache 2.0 open source. More to share when it is ready.

To anyone who has already commented or messaged asking what I mean — you know how to find me 😊.

▸ First principle. The right time to commit publicly to a piece of work is the moment it has earned the right to a soft signal — confidence shown through the work, not the announcement.

Chapter 9. The Real Question ✍️

Here is what I would love to hear from anyone reading this.

If you sat down today and had to write down — for an AI agent to read — the one architectural contract in your firmware that you have been carrying in your head for years, which one would you pick first? The message format between subsystems? The state machine for your main control loop? The shared-data ownership rules between an ISR and a task? Something else entirely?

The answer to that question is the first plank in the framework that finally lets AI write firmware the same way it writes web 🎯.

Next: the pattern I have watched repeat on project after project — and the one architectural decision that finally stops it.

▸ First principle. The first architectural contract you write down is also the first one an AI agent can build on — start there, and the rest follows.

Labeled: Opinion + Experience + Fact
(50% opinion · 30% experience · 15% fact · 5% fiction)

Sources:

(Written in collaboration with AI — I discuss, I do not outsource.)

New to this labeling? Read the framework → 20+ Years of Ideas. Articulation Is the Craft. Here's How I Write Now.

— Ritesh | ritzylab.com