Embedded Is Becoming Embedded AI: Where We Fit in the Next Five Years
For a long time, embedded work meant getting the most out of a small, constrained device: a sensor loop, a control law, a few kilobytes of memory, a deadline measured in microseconds. That has not stopped being true. But the workload on the device is changing. More and more, the thing running on that constrained hardware is a neural network, and embedded development is quietly turning into embedded AI.
The intelligence is moving to the edge
The reason is simple: intelligence is moving out of the cloud and onto the device itself. Latency, privacy, cost, connectivity and energy all push in the same direction. A car cannot wait for a round trip to a data centre to decide whether to brake. A device in the field cannot assume a network is there. So the model has to run locally, on real and limited silicon, in real time. And the money is following that shift. BMW and the German carmakers are putting serious investment into in-vehicle and edge AI for driver assistance and automation. Closer to home in Baden-Wuerttemberg, Heilbronn's Innovation Park for Artificial Intelligence, backed by the Schwarz Foundation, is being built to be one of the largest AI hubs in Europe. A lot of that money is not for AI in a data centre. It is for AI that has to run on constrained hardware at the edge.
This is an embedded problem
Here is the part that matters for people like me. Running a model on a microcontroller or a small accelerator is not a different profession from embedded. It is embedded. It is memory budgets, real-time deadlines, power envelopes, quantising a model so it fits, and making it run deterministically on silicon that was never generous to begin with. TinyML, neural accelerators, NPUs, hardware-aware optimisation: these are our problems, wearing new names. The engineer who understands both the model and the chip it runs on is exactly who this transition needs, and there are not many of them yet.
AI at the edge is not a new profession. It is an embedded problem, wearing a new name.
And the hard part is ours too
In the domains I work in, it goes further. It is one thing to run a model on a device. It is another to make that model trustworthy enough to be allowed near a vehicle or an aircraft: deterministic behaviour, bounded timing, understood failure modes, and evidence a regulator will accept. That is the intersection of AI and functional safety, and it is genuinely hard. It is also exactly where embedded and safety-critical engineers have the most to offer, because we already know how to make constrained systems behave predictably and prove that they do. The scarce skill of the next few years is not training a model. It is making one run correctly, safely, and efficiently on real hardware.
Where we see ourselves in five years
So where does an embedded engineer sit five years from now? Not replaced. Repositioned. The fundamentals do not become obsolete: real-time behaviour, memory, power, drivers and functional safety are not going anywhere, and they turn out to be the exact foundation that AI at the edge has to be built on. The engineers who do best will be the ones who add one line to their profile, that they can deploy and verify AI on constrained, safety-relevant hardware, on top of everything embedded already demanded. The value does not move away from us. It stacks on top of what we already do.
And the geography is not an accident either. The money going into edge AI at the carmakers and into places like Heilbronn means the demand is concentrating exactly where a lot of embedded work already is, here in the south of Germany. For an embedded engineer, the next five years look less like a threat and more like the best window in a while, for anyone willing to lean into the intersection. Embedded is not being replaced by AI. It is becoming the place AI actually has to run, and the people who can make intelligence work on a small, constrained, safety-critical device, and prove that it does, are going to be the ones the next five years are built around.