Generative AI changes part of embedded development — but not the decisive part. What has shifted, what has intensified, and what you get as a client.
Generative AI can now produce standard drivers, simple state machines, and boilerplate code in SystemVerilog, VHDL, C, or Python. That is real, useful, and has reduced the effort needed for routine tasks.
This raises a legitimate question: what does an experienced embedded and FPGA developer still contribute in this environment?
The answer is concrete.
AI is a fast executor. It produces what you ask for — not what is needed. Asking an AI to “write me a UART driver” gets you a UART driver. But not the one that actually works with this clock domain, this pin assignment, this timing behaviour and this fault handling in the target environment.
The actual engineering work is not generating code. It is writing a precise specification: what exactly should happen, under what conditions, with what tolerances, with what behaviour in fault cases, in what temperature range, over what lifetime.
Better AI does not change this. On the contrary: the more capable the tools become, the more decisive it is to instruct them correctly.
AI does not add requirements the client did not think of. It does not invent special cases. It delivers exactly what is in the specification — and nothing beyond that. What is not specified is missing in the result.
This shifts the entire risk onto the specification itself. An inexperienced specification correctly describes what the customer asked for and overlooks everything the writer has never encountered: the rare sensor failure under specific temperature gradients, behaviour during simultaneous brown-out and I²C bus lock, watchdog reset during a flash write sequence, electromagnetic coupling on long sensor cables, behaviour at restart after an unintended reset during a critical write operation.
These points are not customer requirements. They are requirements that an experienced developer adds, knowing they would otherwise appear nowhere. A specification is therefore always also a risk catalogue — and its depth is proportional to the experience of whoever wrote it.
During a safety investigation on an infusion device, to which I was called in by a medical device manufacturer, a safety-relevant failure emerged from the simultaneous occurrence of two single faults: the hardware failure of a memory chip and a faulty integrity check routine for that very chip. Each fault on its own was manageable. Only the combination produced the undetected failure state.
It is precisely this combination analysis that must be actively added to a specification. From the requirement “check the memory” a tool generates a check routine. Experience adds the further requirement that failure of the check routine itself must not lead to a silent fault state. No tool formulates this second requirement on its own.
Add to that the hardware-level pitfalls that do not appear in datasheets but live in the heads of developers who have once had to chase them down:
For most tasks there are several solutions that fundamentally work. But only a few of them meet the safety, reliability and lifetime requirements that the actual product demands.
An AI system picks what was common in its training data. An experienced developer picks what does not lead to disaster in a safety-relevant system. This selection decision is not an implementation detail. It is the actual engineering.
In the event of damage, legislation requires proof that the product was state of the art at the time of placing on the market. This is the central condition for a manufacturer to argue out of product liability. With the new EU Product Liability Directive and the German implementing law that follows it, this burden of proof is explicitly tightened for software and software-integrated products.
State of the art is not a static condition. It is what is considered customary among professionals — and it is currently shifting at an accelerated pace as new tools and methods raise the market standard in short cycles.
It follows: anyone developing an embedded system today must know and use the more capable methods currently available. Failure to do so creates concrete liability risk for the client. This calls for a developer who has mastered both the established and the new tools and can make the right choice between them.
I use AI tools where they save measurable time without creating risk: first drafts of boilerplate, generation of testbenches, documentation, readability checks.
I do not use them as a replacement for:
The result: less effort spent on routine work, consistently high quality on the tasks that actually carry the project, and a documented development process that meets the current state of the art.
You hire a developer with over 35 years of experience in FPGA and embedded, who knows the current tools and can judge their limits. You get neither an “AI-generated project” nor an “AI-free project”. You get a working system for which a concrete person takes responsibility — and which, in the event of damage, can be demonstrated to have been developed in line with the state of the art.
If you have an embedded project that demands exactly this depth, let's talk directly. Initial consultation and rough assessment are free of charge and non-binding.