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

1. Ask the better question

The anxious question is "will AI replace embedded engineers?" The useful question is the one underneath it: which engineers does AI make more valuable, and which does it quietly make redundant? Same technology, opposite outcomes, depending on what the engineer brings.

This post is for the embedded engineer who has felt the floor shift this past year — watched an agent write in seconds what used to take an afternoon — and wants to know where to stand. My answer, after 20+ years across more than 40 products: AI does not flatten the profession evenly. It commoditizes one kind of work and makes another kind scarce, and the gap between those two is widening. By the end you will have a one-line test for which side of that gap a given piece of your work sits on.

The reframe matters because it changes what you do on Monday. "Will I be replaced?" leads to fear and paralysis. "What does AI make scarce, and am I building that?" leads to a plan.

▸ First principle. The question is not whether AI replaces engineers. It is which engineers it makes scarce — and scarcity is where value goes.

2. What AI makes abundant

Start with the honest part. AI is genuinely good at a large, real slice of the work, and that slice is becoming abundant.

The first draft of a function. The driver scaffolded from a datasheet. The parser, the ring buffer, the boilerplate state handler, the unit test that covers the obvious cases. The known pattern, implemented competently, fast. This is not a small thing — it is a large fraction of what filled an embedded engineer's week, and it is now close to free.

When something becomes abundant, its price falls. That is not a moral statement, it is a market one. The engineer whose entire value was typing competent code faster than the next person is watching that value get cheap, because the agent types competent code faster than anyone. There is no comfort in pretending otherwise, and no need for it — because the same shift that cheapens that work makes something else expensive.

▸ First principle. When a skill becomes abundant, its price falls. AI made "writing competent code" abundant — so that, by itself, stops being where an engineer's value lives.

3. What it makes scarce

Here is the other side, and it is the larger one. The same agent that writes a flawless driver cannot tell you whether the driver should exist, what it must guarantee when the sensor browns out, or which of three architectures will survive the next migration. It cannot hold the whole system in its head and feel that something is wrong before it can prove it. It has never been paged at 2am.

Those are not coding skills. They are judgment, system ownership, and hardware truth — and AI makes them scarcer, not more abundant, because it floods the world with cheap code that still needs someone to decide whether it is the right code. The more code there is, the more valuable the judgment that governs it.

That is the whole shift in one sentence: AI lowers the price of producing code and raises the price of being right about the system. The engineer who lives on the second side does not just survive the change. They get more valuable because of it.

▸ First principle. AI raises the value of the judgment that decides whether the cheap, correct-looking code is the right code for the system.

4. A portrait, and a test

Let me make the irreplaceable engineer concrete, because "judgment" is too soft a word to act on.

They are the one who, handed a feature, asks what it must never do before asking how to build it. Who knows that the elegant message flow will starve under load because they have watched that exact failure on a shipped product. Who reads a field log and sees the bug three steps before the trace shows it. Who can tell the agent precisely what to build because they hold the contract, the failure modes, and the field reality the agent cannot see. The agent is their fastest hands; the judgment is theirs.

Here is the test for any piece of your work — which column is it in?

AI makes it abundant (cheap)AI makes it scarce (valuable)
Writing the functionDeciding the function should exist
Implementing the known patternChoosing which pattern survives scale
Generating the test casesKnowing which failure actually ships
Producing codeBeing right about the system
Answering "how do I write this?"Answering "what must this guarantee?"

Spend your week in the right column and the agent is your multiplier. Spend it in the left and the agent is your competition.

▸ First principle. Irreplaceable work answers "what must this guarantee, and should it exist?" — not "how do I write this?" The agent owns the second question; you own the first.

5. Why this engineer gets more valuable, not just safe

It would be enough if judgment merely kept you employed. It does better than that — it compounds.

An engineer with deep system judgment used to be bottlenecked by their own two hands. They could only design, write, and debug so much in a week. Pair that same judgment with a tireless agent and the bottleneck moves: now they direct far more output than they could ever type, and every unit of it is governed by their taste. One strong architect with an agent produces more good systems than three mid engineers without one, because the scarce ingredient — judgment — is now spread across far more code.

That is why the best embedded engineers I know are not nervous this year. They are faster. The agent did not take their job; it removed the part of their job that was never the point, and amplified the part that always was.

▸ First principle. Judgment plus an agent produces more good systems than either alone. AI turns the scarce skill into a multiplier instead of a bottleneck.

6. The one trap

There is exactly one way to lose here, and it is worth naming plainly so it can be avoided.

The trap is choosing to compete with the agent at the thing the agent is best at. Doubling down on typing speed. Measuring yourself by lines produced. Treating "I can write this faster by hand" as a point of pride rather than a task to hand off. That race is unwinnable, and it is the wrong race — it keeps an engineer's attention on the abundant work while the scarce work, the work that was always the real job, goes undeveloped.

The way out is not to work harder in the left column. It is to step into the right one: spend the time the agent frees up on the system, the contracts, the field, the judgment. The engineers who do that are pulling away. The shift is an opportunity with a short window, not a threat.

▸ First principle. The only way to lose is to race the agent at typing. The way to win is to climb to the judgment it cannot supply.

7. Irreplaceable is a direction

Irreplaceable is not a title you are granted or a seniority you age into. It is a direction you walk. Toward owning the system rather than a slice of it. Toward understanding the hardware and the field, not just the code. Toward the judgment that decides what is worth building and what it must never do.

AI did not make embedded engineers obsolete. It made a specific kind of embedded engineer more valuable than they have ever been — and it made the path to becoming that engineer clearer, because it took over everything else. The agent handles the abundant work. What is left is the work that was always the craft.

So point yourself at the scarce column and let the agent have the rest. That is not a defensive crouch. It is the best deal embedded engineers have been offered in a long time.

▸ First principle. Irreplaceable is not a credential; it is a direction — toward the judgment that does not commoditize.

Which part of your work got more valuable since the agents arrived — and which part are you still, out of habit, doing by hand?

More soon on the boundary itself — what an agent can safely own in a firmware system, and what stays yours.

Labeled: Opinion + Experience + Fact (50% opinion · 35% 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