AI in embedded systems

2026-03-03T00:00:00.000Z

I’ve been reflecting on a recent leadership conversation that stayed with me.

“Why can’t we just get AI to do it?”

That was a genuine question from our CEO during a discussion about delivery timescales and resourcing for a significant embedded software project. It wasn’t flippant or naive. It reflected a reasonable assumption that many leaders are now making: if AI can write code and increase productivity, shouldn’t it materially compress schedules — perhaps even substitute for additional engineers?

In my experience, particularly in embedded systems, that assumption is premature.

AI will certainly generate code, often with impressive speed and confidence. However, producing code is not the same thing as delivering a robust product. A real system has to hold together architecturally. It must respect hardware constraints, timing behaviour, memory limits, legacy interfaces and long-term maintainability. It must behave predictably under stress — not merely compile cleanly — and it must be structured in a way that remains understandable and supportable a year or two down the line. It has to be built so that the “you of next year” can still unravel it.

If we were to hand a complex embedded project entirely to AI today, we would undoubtedly receive output. What we would not receive, at least not without significant rework, is a coherent and durable architecture shaped by context and experience. Much of the apparent productivity gain would likely be offset by time spent tracing subtle behaviours, correcting misplaced assumptions and reshaping structure into something maintainable.

None of this diminishes AI’s value. In fact, I have found it extremely powerful — just not in the way headlines suggest. Its real strength lies less in raw code generation and more in structured thinking. Used well, it becomes an exceptionally effective partner in the early and middle stages of engineering work. In particular:

• It helps explore architectural and technology options.
• It forces clarity in requirements.
• It challenges assumptions that would otherwise go untested.
• It surfaces edge cases early in the design process.
• It reduces small but consequential oversights. And, quite frankly, it is the most effective “rubber duck” I have used in years.

Used in this way, it makes a senior engineer more deliberate. It shortens the path to clarity and improves the quality of decisions. What it does not yet replace is engineering judgement.

For boards and CEOs, the more useful question is not whether AI can write code, but where it genuinely reduces delivery risk — and where experienced architectural oversight remains essential. Treating AI as headcount replacement risks distorting expectations around cost, timelines and product resilience. Treating it as leverage within a well-guided engineering function is a far more powerful proposition.

AI is a remarkable tool. Used well, it strengthens engineering judgement — but it doesn’t remove the need for it.