Highlights from Microelectronics UK in Embedded Software Development

"Do You Really Expect Developers to Write Code?"

It was not the question I expected to hear at our booth during Microelectronics UK. Yet it perfectly captured one of the biggest shifts happening across the embedded industry today.

When I introduced IAR and our embedded development platform, this visitor genuinely seemed surprised by the idea of developers writing code themselves. It quickly became clear that I had failed to communicate the real value of modern embedded development.

The answer, of course, is that developers absolutely can write code if they want to. They can work in our IDE on Windows or Linux, in Visual Studio Code, Eclipse, or their preferred environment. They can also use AI-assisted development tools and code-generation solutions. The important point is not how the code is created. The important point is that whatever route developers take, they need confidence that the resulting software can be built, tested, verified, and trusted.

In modern embedded development, consistency matters. The code that works on a developer's machine must be the same code that passes through automated CI/CD pipelines and ultimately ships in a product. As embedded software teams scale, automated workflows are becoming critical for maintaining quality and traceability across the development lifecycle.

That conversation became a recurring theme throughout the event. Everywhere I looked, the industry was talking about AI. But the most interesting discussions were not about whether AI will be used. They were about how to use it responsibly.

AI Is Changing the Workflow, Not the Need for Engineering

One of the highlights of the event was a panel discussion on AI transformation across the microelectronics value chain, featuring IAR's William Headley alongside experts from across the industry. The session addressed several challenges that are becoming increasingly important as AI tools enter embedded software development.

For organizations building safety-critical systems, regulatory compliance remains a major consideration. Standards such as ISO 26262 and IEC 61508 require development tools to be assessed and qualified, with evidence that their behavior is deterministic and understood.

Whether developing for automotive, industrial, medical, or aerospace applications, teams need development tools that support certification efforts and compliance requirements.

Intellectual property protection is another challenge. Many companies cannot send proprietary source code to cloud-based AI services because of security, confidentiality, or regulatory concerns. Even when cloud services are permitted, organizations must carefully consider how their intellectual property is handled and whether AI-generated results could introduce licensing or provenance concerns.

Beyond Code Generation: AI in the Debugger

At the same time, we are beginning to see AI move beyond code generation and into the broader engineering toolchain. One example is the MCP Connector for the IAR C-SPY Debugger, available on GitHub, which enables AI models to interact directly with debugging tools. Instead of simply generating code, AI can help developers inspect software behavior, collect diagnostic information, and accelerate troubleshooting.

This shift is significant because it changes the role of AI from code author to engineering assistant. The greatest value may not come from generating more code but from helping developers better understand, validate, test, and debug the systems they build.

The Skill We Cannot Automate

If there was one theme that emerged consistently throughout the event, it was that AI is changing how engineers work but not eliminating the need for engineering expertise. As development becomes increasingly automated, human judgment becomes even more important.

The future engineer will undoubtedly work alongside AI. They will use new tools, new workflows, and new ways of developing software. But the fundamental ability to question assumptions, solve problems, and make sound engineering judgments will remain invaluable.

Looking Ahead

Looking back on the event, the question I heard at our booth reflected a broader shift in how our industry is thinking about AI. The conversation is no longer about whether AI belongs in embedded development. It is about how we can use it while maintaining the reliability, safety, and trust that embedded systems demand.

The real challenge is understanding where it delivers value, where it introduces risk, and how we can integrate it into processes that demand reliability, safety, security, and trust.

At IAR, these are exactly the conversations we have with customers every day. Engineering teams want to take advantage of AI-assisted development, modern cloud-based workflows, and faster software delivery. At the same time, they must satisfy increasingly demanding requirements for quality, cybersecurity, traceability, and functional safety.

That is why we believe the conversation should not be about AI replacing engineers, nor about writing code faster. The real opportunity lies in helping teams build software that can be trusted, regardless of how that software is created. Whether code is written by a developer, generated by AI, or produced through model-based development, it must still be tested, analyzed, and verified before it reaches a product.