When AI generates the code, what does the Zephyr RTOS actually provide?

The pace at which artificial intelligence (AI) is influencing embedded software development has moved faster than most people in the industry anticipated. For those working with open-source platforms like the Zephyr real-time operating system (RTOS), this shift is challenging assumptions about who builds embedded software, who is responsible for maintaining it, and the importance of open-source projects themselves.

TI moderated a panel at Open Source Summit Europe 2026 in Prague titled, “If AI Can Write Drivers, Why Do We Need Zephyr and Should We Make Zephyr AI Ready?” which covered this topic with industry experts, including design engineers, equipment manufacturers and members of the open-source software community. This article highlights points from the discussion, with some insights on the evolution of AI and the role of embedded software engineers.

Deep expertise matters more than ever

AI does not devalue embedded engineering expertise; it raises the stakes for it. As Sean Lyons from Texas Instruments phrased it:

“The core of being an embedded engineer is knowing the interface to the hardware – knowing how your hardware works on a deep, almost intuitive level.”

What is changing is where that knowledge gets applied. Writing new code is becoming a smaller part of the job. A significant shift is from purely a developer to more of a systems architect and maintainer role, focused on tasks such as system architecture decisions and balancing performance and power. AI can’t reliably replicate or solve these tasks, particularly in resource-constrained systems where every design decision comes with trade-offs.

During the panel, the discussion led to questions about how AI use will impact the next generation of developers. As Lenka Koskova Triskova, an embedded software specialist, teacher and researcher at the Technical University of Liberec explained, developers still need to do foundational work themselves to create their own hardware intuition:

“If you’re a senior developer, you can use AI effectively, the way you’d direct a junior engineer writing code for you. But if you’re a junior with no real prior coding experience, developing with AI is like trying to run a marathon without ever having run before in your life.”

Open-source platforms like the Zephyr RTOS are becoming more valuable

When AI can generate a functional driver in minutes, it might seem like the case for shared platforms weakens.

The aspiration to upstream code back to the Zephyr RTOS creates a quality incentive that matters more in an AI-assisted world. This trend is ultimately pushing developers toward the kind of human scrutiny that AI-generated code needs the most, while also reducing the risk of one-off implementations becoming long-term technical debt.

For high-risk work such as security hardening or cryptoaccelerator integration, existing APIs for the Zephyr RTOS, reference implementations, and ongoing safety certification efforts provide a community-validated starting point that significantly improves the odds of getting complex implementations right. The Zephyr RTOS is also actively adapting to AI workflows, with documentation now accessible through a Model Context Protocol (MCP) server that agents can query directly when working on new drivers.

Trust, correctness and long-term ownership in an AI-enabled world

The reliability gap in AI-generated embedded code is more about organizational fit than errors. Different models default to different frameworks, patterns and assumptions based on what they were trained on.

That tendency is harmless enough in rapid prototyping or hobbyist contexts, but can introduce challenges in large-scale engineering organizations because of technical debt. The solution is to use AI deliberately and shape its contributions. Expert engineers are still essential to adapt and constrain AI outputs to steer code generation to their organization’s established coding standards, testing frameworks and architectural conventions.

When applying that discipline, AI genuinely operates as a productive team member. When it is absent, each generated file becomes a small incremental divergence from the codebase’s coherence, and those divergences accumulate. The challenge is that this discipline requires active effort to maintain.

If the engineer cannot actively manage and understand the boundaries of AI’s involvement, then it may not be possible to reliably maintain the codebase’s coherence, nor the organizational knowledge needed to manage it long term.

What’s next? When AI generates the code, the Zephyr RTOS helps provide the community

The challenge facing the open-source community is one that it’s uniquely positioned to meet: deliberately combining AI and engineering expertise. For the Zephyr RTOS specifically, that work is already underway, and moving fast.

Benjamin Cabé from the Zephyr Project was candid about where things stand today, and the potential for AI-enabled workflows during development:

“As the documentation maintainer I’m biased, of course, but we have good documentation that out-of-the box AI is usually pretty good at using. Agents can directly tap into this data through an MCP server when answering a question like, ‘How should I add a new driver?’ rather than [the agent] trying to figure it out by just looking at the code.”

From Benjamin’s perspective, the current state of AI implementation isn’t perfect yet, but those gaps are being closed:

“The goal is to get to the point where adding a test, flashing something to a board, and verifying that results actually work becomes systematic and repeatable.”