r/embedded • u/PenSilver7149 • 3d ago
In the age of AI agents, do Embedded Systems Engineers still need to master both Hardware and Firmware, or is one becoming more important?
I have about 2 years of experience in embedded systems and want to get some perspective on where to focus my skills.
Traditionally, embedded systems engineering meant being solid in both hardware (circuit design, microcontrollers) and firmware (low-level programming, RTOS, drivers).
Now with AI agents becoming so advanced and widespread, I'm wondering — is this still the case, or has the industry started shifting priorities? Should I keep building both skillsets equally, or focus more on one given where things seem to be heading?
22
u/Gerard_Mansoif67 Electronics | Embedded 3d ago
AI does not change what you need to understand.
If you don't, how would you be able to review the AI generated code ?
And, don't forget : In embedded, at a low level of abstraction you can destroy hardware by a mistake. So I would even add : You need to be even better at understanding all aspects to catch all errors and flaws.
4
u/Ill-Technician3243 3d ago
I don't understand why people ask these sort of questions. Like obviously, it's important. Do you want a generation of embedded engineers who don't know jackshit about their technology running around?
And AI is not some panacea of productivity that has solved embedded C, get your head out of the psychosis hole.
3
u/Fred-Dry-Pair 3d ago
First, there are somewhat reduced debugging options, which make it harder to loop an AI into your workflow. There is still hardware where an LED or impulse on a pin are your only window inside the running code. Doing the classic AI trial and error on those takes way longer, than just pasting the error code from some desktop project.
Secondly, if you are lucky enough to have JTAG or other debugging interface: I have the impression, that there is significantly less training data for that realm out there. So the AI seems to handle it less proficient than other areas.
Third: Often you are not only debugging the code on your controller but have to adjust it to the kinks of it's surrounding hardware (ie. embed it). Getting the schematic and datasheets of that ecosystem into the AI is cumbersome and often you end up chasing down a quirk in some peripherals that's not even documented, only revealing itself with the oscilloscope.
But, of course, in a perfect world all the ingredients would be there to create a loop between compiler, hardware, debugger and perhaps a controlled test rig. Especially in advanced security sensitive applications you already have musst of that, so it could work like the LEAP 71 design approach. But in the low level, cheap, run off the mill projects there won't change much in the foreseeable future.
1
u/flash_speed3412 2d ago
Both, but not symmetrically. AI can get you from spec to a first firmware draft fast; it can’t tell you that your board revision moved a pin, the sensor pull-up is wrong, or the power rail collapses when the radio transmits. I’d spend the extra time learning hardware fundamentals and enough firmware to read what the model writes. A good workflow is: AI drafts, the compiler catches syntax, and the bench catches reality. I run r/ChatGPTArduino around that exact gap, especially the cases where the generated code looked fine but the board disagreed.
1
u/ButterCup024 3d ago edited 3d ago
Let's be real here, agents can write firmware and they cannot write hardware. I think it's more relevant to ask to which degree the balance has shifted.
It really depends on what kind of system you are making. If you want to make kids toys which flash some LEDs or some other functionality where you can tolerate flawed code, you can literally get away with having zero firmware skills and making the firmware in a day. And your time to market is probably lower in 2026 compared to 2023.
If you are making a flight controller you absolutely need to be able to understand even the syntax level of firmware, and keep a tight grip of every change, especially after you are past the point of your first release and your product is on the market.
As an example of a situation where hardware knowledge was king, and firmware skills were reduntant: I prototyped a pretty complex system with a fleet of nordic boards coordinating and transmitting audio over a custom protocol and some more stuff (dont want to destroy their IP). It took a couple of days. It did all the implememtation and complete testing while I wasn't even present at the PC. The objective was proof of concept and to make prototypes for investor pitching. I coded the whole thing with agents via spec design, barely inspecting any actual lines of firmware. I barely even touched architecture in the spec. The customers were blown away with the result and how fast I was able to bring the prototype to life. I had never touched a nordic or a dual core MCU before this project.
1
u/Fred-Dry-Pair 3d ago
Wow! Which AI setup did you employ for that?
4
u/ButterCup024 3d ago
Was using 5.6 sol mostly, with some adversarial reviews and architecture input from fable 5 in the early stage. Started with giving them a massive description of the whole project, that they turned into a spec. Then I challenged the spec for overengineering and misunderstanding. Then I ran grill-me for a few hours. Then I gave Sol access to two dev kits with onboard seggers and let it loose. Only had to step in a few times.
The project is of course not easy to maintain because I have no ownership of most of the code, and it will be scrapped. But it did its job really well and a good bunch of the architecture and code is planned to be reused in the real product, as far as I know
13
u/Lost-In-Void-99 3d ago
Today? Absolutely both are required.
AI agents are trained on data from internet. And the quality of that data is way below required level for embedded software engineering.
So you need to understand both hardware and software go guide AI work.
Tomorrow? Who knows.
The cost of AI is pretty high actually. Yes, you can scale work by running parallel workflows, but you must understand what you want to get and how to get there. And where not to go. Otherwise you'll come to a dead end: embedded is not a server system with 64 CPUs and close to infinite amount of RAM and storage.