Is AI in Embedded Hardware Engineering a Big Revolution?
#AIinIT #AI #AIissues #AICaseStudy
Introduction:
I’m the CTO of Embevity, and for the past year or so I’ve been watching how AI in embedded hardware engineering is becoming part of everyday embedded hardware design work, both in our team and in the wider community.
Let me say it straight away. In practice, this is not a revolution, although it is an interesting step forward.
An engineer’s work has always evolved together with the tools we use, and AI is simply the next step, another tool we have to learn to use well.
By: Krzysztof Czyż, CEO of Embevity
AI in Embedded Hardware Engineering: A Practical CTO Perspective
Almost everyone has hit the case where the same prompt gives different answers. And this isn’t just an impression [1].
Hallucination rates vary so wildly across models, tasks, and measurement methods that any single number is more misleading than helpful. In AI in embedded hardware engineering, this is not a theoretical issue. It shows up in everyday work. You can’t assume the model is right just because it sounds right. And it usually sounds right.
The model can also be naive, stubbornly off track, and entirely convinced when it’s talking nonsense, and the worst part is that models often lack self-awareness about their errors and tend to reinforce incorrect assumptions rather than flag them. It’s frustrating, but isn’t it something we’ve also seen with people?
Think of someone early in their career who already knows quite a bit but still needs context and guidance. If you work with that person well, they’ll take a real chunk of the work off your plate and free you up for the things that actually matter. If you don’t, things get messy and you spend your time sorting it out later.
It’s much the same with AI.
Where AI Helps in Embedded Hardware Design
1. Finding Information in Datasheets and Errata Faster
Hardware projects often mean going through dozens, sometimes hundreds, of datasheets, errata, and application notes. Anyone who has tried to track down a single timing parameter buried in the latest revision of a TI errata sheet knows what I’m talking about. Finding the right paragraph in the right revision used to eat up half a day. Now it goes much faster, and the model not only pulls out the information you need, it also catches inconsistencies between documents. At the same time, the rule that stays unchanged is simple. Every critical claim still has to be confirmed in the original source and the correct revision.
2. Access to other people’s experience
Papers, design guides, conference materials, forum posts. It’s valuable knowledge, however, there’s more of it than anyone could read in a lifetime. AI helps sift through it, summarize it, and point to the sources. Whether a given result actually applies to our problem still sits on our side of the table, but at least we have more time to think about it.
3. Rapid Prototyping with AI Tools
Simulations, Python scripts, testbench skeletons, test code. AI puts these together in no time, and your job is to judge whether it makes sense and works the way you planned. You can try several variants in parallel before you commit to one, and that’s where the real value sits.
4. Test automation and reporting
This is where AI shines. Test scripts, log parsing, measurement reports, tables, clean summaries from raw data. It used to be tedious work you just tolerated. The kind of thing nobody wants on their plate but somebody has to do, usually after hours. Now it goes faster, and the engineer has time for the things they’re actually needed for.
Where AI Falls Short in Embedded Hardware Engineering
It’s worth being honest about the other side too. AI is weakest exactly where hardware work gets hard.
- Can confidently misread a datasheet, mix up two revisions of the same document, or refer to pins that don’t exist on the part you’re using.
- Doesn’t know what your scope shows at 3 a.m., what the layout actually looks like, or how the prototype behaves under temperature.
- Will happily produce HDL that synthesizes cleanly, passes a smoke test, and then fails timing constraints two days later when you run it in the real system.
- Can generate driver code that compiles, passes unit tests, and falls over the first time you actually exercise the peripheral.
In practice, these aren’t edge cases.
They’re the normal failure modes you have to deal with.
Anything AI produces has to be treated like any other unreliable source. A good starting point, never a final answer.
A real example: Designing a Wideband TIA with 1 MΩ gain
At one point, not long ago, we faced a tough design decision. How to build a transimpedance amplifier with a gain on the order of 1 MΩ, with the widest possible bandwidth and low noise. These requirements pull against each other, and the project’s success depended on how well we could reconcile them.
Defining the Problem Before Using AI
We defined the problem ourselves. Photodiode type, bandwidth, noise budget, gain range. We also wrote out the risk list ourselves, covering stability, potential offset, and input capacitance. Only once we had this roughly sorted did we bring AI into the loop.
How AI Supported the Design Proces
It helped us line up candidate architectures, build decent physical models of the problem, and point out typical pitfalls that show up in designs like this. What was left for us as engineers was the part of the job we actually got into the profession for. Setting ourselves challenges, solving them, and prototyping.
Honestly, if AI ever takes that part away, I’ll change careers.
What Remained the Engineer’s Responsibility
Every candidate solution went through the full verification path, from documentation, through simulation, all the way to evaluating the whole signal chain with the chosen ADC.
One observation worth sharing. AI can also be a kind of sparring partner you share your doubts with. Tell it what you’re doing and ask. Questions like “where could this topology fall apart?”, “what are its strengths and weaknesses?”, “what trade-offs are typical with this choice?” push you to look in places where things are easy to miss. It doesn’t replace a real design review by the team, but it catches plenty of holes before they end up in someone else’s hands.
Final design decisions were made by the team, based on schematics, simulation results, and discussion about the trade-offs. AI didn’t replace knowledge. But it noticeably sped up our orientation, organized the options, and ruled out dead ends.
That much, and only that much.
Why Verification Still Matters in Engineering Work
It’s worth stressing one thing here. In AI in embedded hardware engineering, quality doesn’t come from tools. It comes from process. Quality is the hours spent on documentation review, simulations, prototype measurements, structured testing, and above all on team reviews and discussion.
We had one case where AI mixed up two revisions of the same datasheet and we didn’t catch it until layout review. Nothing dramatic. We caught it. The next one might not get caught, and that’s when it gets expensive: fixes late in the project, schedule slips, and in the worst case, problems at the customer’s site once the system is in the field. That’s the cost you pay for skipping verification.
AI in embedded hardware engineering is an excellent tool in experienced hands, and a serious liability when no one is checking the work. The deciding factor isn’t the tool, it’s the engineer using it.
What AI Means for Future Engineering Teams
And this is where I see the biggest temptation. On one hand we have a tool that needs a critical eye on what it produces, and that takes knowledge and experience. On the other hand, the same tool covers a lot of the basic work that people early in their careers used to do, and it does it faster.
It’s tempting to take the shortcut and conclude that, in the short run, it’s cheaper not to hire. I’ve caught myself thinking it. Then I remember who taught me how to design the things I now design, and the thought goes away. The engineers who can supervise powerful tools, who can run a design review, take responsibility, and keep a system safe and reliable, don’t appear by accident. They grow into it through real work, given a real chance. It’s on us, the more experienced engineers, to make sure the next generation gets that chance. So that a few years from now, they’re the ones keeping watch over even more capable generations of AI tools.
Final Thoughts: AI as a Tool, Not a Replacement
For me, AI in embedded hardware engineering is just another sensible tool. Used well, it buys you time to go deeper into the problem, look at more variants, and better understand what we’re actually trying to solve. Thanks to that, our customers can get not just a solution that works, but the one that fits their application best.
A tool this powerful is also a real responsibility.
AI shifts where your attention goes, not whether it’s needed. The engineer who uses it well isn’t the one who prompts the best – it’s the one who knows exactly where to stop trusting it. That takes judgment, and judgment takes years of real work. Which means the most important thing we can do right now isn’t optimize our prompts. It’s make sure the next generation gets the chance to build that judgment before we need them to apply it.
Tools change. The discipline of good engineering work doesn’t
In the end, that’s what AI in embedded hardware engineering is really testing.
Sources:
- Stanford AI Index Report 2026, Stanford Institute for Human-Centered AI, April 2026. aiindex.stanford.edu
