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

1. The question I get asked now

Every week now, someone asks me a version of the same question: is AI going to replace embedded engineers? It comes from junior engineers who are worried, from managers who are hopeful, and from founders trying to plan a team. After 20+ years shipping firmware across more than 40 products — bench to factory floor, firmware to cloud — I have an honest answer, and it is not the one either camp expects.

This post is for the firmware engineer watching a coding agent write a clean driver in thirty seconds and wondering what that means for a twenty-year career. My answer comes in three parts, drawn from the three teachers I have actually had: startups taught me what breaks, factories taught me what scales, and AI — recently — taught me what amplifies. By the end you will have a simple table for where AI is strong, where the engineer still owns the outcome, and why the gap between those two is where the job is heading.

The short version: AI changes the cost of writing code. It does not change the cost of being wrong about the system. Those are different costs, and in embedded the second one has always been the expensive one.

▸ First principle. AI lowers the price of the first draft. In firmware the first draft was never the bottleneck — being wrong about the system was.

2. What startups taught me — what breaks

The first decade taught me what breaks. Startups put me close to the moment a product meets reality, and reality is where the assumptions you did not know you were making come due. The driver that worked perfectly on the eval board. The state machine that was airtight until a customer power-cycled the device at exactly the wrong millisecond. The field bug that took six weeks to reproduce and two hours to fix once it was finally cornered.

None of those failures lived in a function. They lived in the spaces between functions — in the timing, the ownership, the assumption that two modules agreed on something they had never written down. That is the part of firmware that is hard, and it has nothing to do with how fast you can type the code.

A coding agent is genuinely fast at the first draft of a function. It is fast the way a strong junior is fast. But the breakage I spent a decade learning to anticipate is not a typing problem. It is a system problem, and the system is mostly the part nobody wrote down.

▸ First principle. Speed of the first draft was never the constraint. The constraint is everything that happens after the code ships and meets the field.

3. What factories taught me — what scales

The second teacher was the factory. Taking a product from a working bench unit to ten thousand units coming off a line is a different discipline entirely — design for manufacturing, design for test, the EVT-DVT-PVT march, the factory test station that has to catch the one board in a thousand that will fail in a customer's hands.

The factory taught me the distance between "it works" and "it works every time." A thing that works once is a demo. A thing that works ten thousand times, across temperature, across silicon lot variation, across a tired operator on a night shift, is a product. The distance between those two is filled almost entirely with judgment — knowing which failure modes are real, which corners actually get cut, and what a yield number is quietly telling you.

An AI agent does not see the line. It has never watched a reflow oven drift, never debugged a test fixture, never held a returned unit and traced a hairline crack back to a design decision made a year earlier. That knowledge is not in the training data because it was never written down. It lives in the hands of people who have shipped.

▸ First principle. A thing that works once is a demo; a thing that works ten thousand times is a product. The distance between them is judgment, and judgment is the part that is hardest to write down.

4. What AI actually changed — what amplifies

I am not an AI skeptic. The third teacher has been AI itself, and it has genuinely changed how I work. It is a real amplifier. It writes the boilerplate I used to grind through. It drafts the register-level driver from a datasheet faster than I can find the page. It is a tireless pair for the parts of the job that were always more typing than thinking.

Here is the honest map of where it is strong and where the engineer still owns the result:

LevelWhere AI is strongWhat the engineer owns
The function — a driver, a parser, a helperwriting a clean first draft, fastnaming what it must guarantee
The module — a subsystemfilling in a known patternthe contract at its boundary
The system — how it all behaves togethersummarizing what is already written downwhat happens when one part fails
The product — ten thousand units in the field—the judgment that it will hold

Read the table top to bottom and the pattern is clear. AI is strongest at the top, where the work is local and the answer is mostly known. The engineer's ownership grows as you go down, toward the system and the field, where the cost of being wrong is highest and the relevant knowledge is least written down.

▸ First principle. AI multiplies whatever you bring it. Bring it a clear system and it accelerates you; bring it a vague one and it accelerates the mess.

5. The part it cannot reach yet — the system

The reason an agent can write a flawless driver and still lose the thread of the whole system is not that the model is weak. It is that the system is the part that lives in two engineers' heads instead of on disk. The agent reads what is written. Most firmware writes down the functions and leaves the architecture — the message contracts, the lifecycle, the failure policy — as tribal knowledge.

I made this argument in full in AI Can Write Your Frontend. It Can't Write Your Firmware. The gap is one level up from the code. And the fix turns out to help the human just as much as the machine: when the structure of a system is written down — a structured application layer above the RTOS, with typed contracts and a legible state machine — both the next hire and the agent can finally read it the same way.

That reframes the engineer's job in a useful direction. The value is moving away from writing every function by hand and toward deciding what is worth writing down — the structure that makes the whole system legible to whoever, or whatever, reads it next.

▸ First principle. AI reads what is written down. The engineer's value is increasingly in knowing what is worth writing down in the first place.

6. The engineer who gets more valuable

So here is the part that should be encouraging rather than frightening. When the cost of producing code falls, the things that do not get cheaper become more valuable, not less. Knowing what to build. Knowing why one architecture survives the next migration and another does not. Knowing which failure mode will actually show up in the field. Knowing, from having shipped, what "done" really means.

AI raises the floor on code and raises the premium on judgment. The engineer who owns the system — the hardware truth, the architecture, the failure modes — becomes more useful as agents get better, because every cheap line of code an agent produces still needs someone who can tell whether it is the right line. The fear assumes the job was the typing. It never was.

The engineers I would bet on in the next five years are not the ones racing the agent at writing functions. They are the ones using the agent to clear the boilerplate so they can spend more time on the system, the contracts, and the judgment that the agent cannot supply.

▸ First principle. When the cost of code falls, the value of knowing what to build with it rises. AI raises the floor on code and the premium on judgment.

7. So — will AI replace embedded engineers?

No. But it will redraw the job, and that is a real thing to take seriously.

The embedded engineer whose value was in typing functions faster than the next person has a harder road ahead. The embedded engineer who understands systems, owns the hardware truth, and treats the agent as an amplifier has a better one than ever — more reach, less grind, more time on the part of the work that was always the point. After 20+ years I am more optimistic about this craft, not less. The agent is the best junior I have ever worked with and the worst architect, and knowing the difference is the whole skill.

The job was never the code. The job was being right about the system. AI just made that the only part that is hard to fake.

▸ First principle. AI is not the end of the embedded engineer. It is the end of the embedded engineer who only writes functions.

After 20 years I would happily never hand-write another ring buffer. But there is one decision I would never hand to an agent. What is the one thing you would never let AI own on your firmware — and the one thing you would gladly never write by hand again?

More soon on what changes, and what stays exactly the same, when the second reader of your code is a machine.

Labeled: Opinion + Experience + Fact (45% opinion · 40% experience · 15% fact)

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.

— Ritesh | ritzylab.com

#EmbeddedSystems #Firmware #AIAgents #EngineeringCareers #FirstPrinciples