AI Coding Is Coming to Embedded, and Faster Than You Think

2026 May / By Semir Haddad, Chief Product and Strategy Officer at MicroEJ

The software world is in the middle of a seismic shift. Over 25% of new code at Google is now generated by AI. GitHub Copilot has surpassed 1.8 million paid subscribers. Developers using AI assistants report completing tasks 55% faster in controlled studies, and 76% of developers say they are using or planning to use AI tools. Andrej Karpathy coined the term “vibe coding” to describe a new paradigm where entire applications are built primarily through AI prompts.

Yet if you work in embedded systems, you could be forgiven for thinking this revolution is happening on a different planet. While web and cloud developers are rewriting their workflows around AI, most firmware engineers are still watching from the sidelines. That gap is about to close, and much faster than many expect.

The Pioneers Are Already Here

The embedded world is not entirely untouched. Early adopters have been quietly proving what is possible. Jacob Beningo, a well-known embedded consultant, was already exploring AI and ML techniques for embedded development back in 2023. More recently, he demonstrated full firmware code generation using Claude Code, building a complete push-button module with an AI agent handling the heavy lifting. These are not toy demos. They are real, functional embedded components.

The results are encouraging, but they also highlight a fundamental truth: the embedded world is just scratching the surface.

The Case Against, and Why It Falls Short

Some cautious engineers raise familiar objections. Embedded code mixes hardware and software constraints in ways that general-purpose LLMs struggle with. AI tools trained primarily on Python and JavaScript have limited understanding of register maps, interrupt priorities, and real-time constraints. Safety-critical industries like automotive, medical, and aerospace require traceability and formal verification that AI-generated code cannot easily provide. And some engineers have seen only modest productivity gains. A recent METR study even found that experienced open-source developers were 19% slower when using AI tools on large, complex codebases, despite believing the tools had helped.

These are legitimate concerns, but they describe today’s limitations, not tomorrow’s ceiling.

Consider the trajectory. Two years ago, AI coding assistants could barely autocomplete a function. Today, they generate entire modules, write tests, and reason across large codebases. The models improve every few months. The tooling ecosystem is exploding: Cursor raised $400 million at a $9 billion valuation in early 2025, signaling massive confidence in where this is headed. And critically, training data for embedded development is growing as more firmware code enters public repositories and more engineers share their work.

These cautious voices are essentially arguing that because the current generation of tools was not built for embedded, they never will be. History suggests otherwise. Every major productivity revolution in software (from compilers to IDEs to version control) eventually reached embedded development. AI will be no different.

Beyond Code Generation: The Real Revolution

The confusion may come from the various and evolving modalities of interacting with AI. There are many ways to work with AI, as explained in the 4D Framework for AI Fluency designed by Academics for their students and promoted by Anthropic.

What is seen as “Vibe coding” is usually the modality where the engineer delegates the coding work to AI, and uses the results without any understanding or judgement of what was actually produced. I wouldn’t recommend that for embedded systems, and any system in fact.

The second modality is the “coding assistant”, where the engineer uses the AI to generate code, test, document, but always stays in the loop, reviewing and vetting everything. While it may seem the “safe” way, this approach is the one that explains the 19% loss of productivity in the METR study. Indeed, the study highlights that the developers accepted less than 44 percent of the code generated by AI without modification, which demonstrates a heavy involvement of the human at every step.

Here is where it gets truly interesting. AI trailblazers have found ways to overcome this productivity barrier. For them, code generation is just the tip of the iceberg. They realized the transformative potential of AI with what they call compound engineering: integrating AI across the entire development lifecycle, not just the editor.

The financial analogy is apt: compound interest generates exponential returns because gains are continuously reinvested. Compound engineering works the same way: each completed task accelerates the next. The codebase self-documents, tests for one feature validate assumptions in the next, feedback loops close automatically, without a human in the critical path.

The productivity formula becomes code velocity multiplied by feedback quality multiplied by iteration frequency. Vibe coding improves only the first variable but degrades the two others. Coding assistant addresses the first two terms but slows the third one. Compound engineering compresses all three simultaneously. That is why the numbers diverge so sharply: 30 to 70 percent gains with coding assistant, versus 300 to 700 percent in early compound engineering implementations.

The key insight is that code generation is no longer the bottleneck. The whole code life cycle (test, validation, deployment) is. The teams achieving real gains are the ones who have invested in making the life cycle fast, automated, and comprehensive.

What Compound Engineering Means for Embedded

Test-driven development is the foundation, not as a best practice that gets skipped under pressure, but as the mechanism that makes AI output trustworthy. Write the test first, ask the AI to implement, run the test, iterate on failures. The test becomes a specification the AI verifies against.

Specification quality matters more than prompt quality: vague instructions produce plausible-looking code that fails on edge cases. Precise specifications, type constraints, executable contracts, architectural context in prompt templates, guide AI toward correct outputs from the start.

The mindset shift is worth naming. Traditional embedded culture values careful upfront design because late mistakes are expensive. In compound engineering, that calculus changes: mistakes are cheap to regenerate, fixes propagate in minutes. The discipline shifts from “get it right before you build” to “build guardrails that make wrong answers visible immediately.” Not a lower standard, but a different kind of rigor.

But here is what the METR study actually tells us: the problem is not AI. It is environments not designed for AI-assisted development.

The Missing Piece: The Right Software Foundation

There is a reason AI tools work so well in web development. Modern web frameworks provide clean abstractions, well-documented APIs, standardized patterns, and rich ecosystems of tests and examples. The AI has a structured, predictable environment to reason about.

Embedded development, by contrast, has historically meant hand-crafted code tightly coupled to specific hardware, with limited abstraction and few standardized patterns. That was a reasonable trade off when hardware was severely constrained, even if it has been a challenge for human developers for decades. Now it is becoming an unbearable liability.

The path forward is not waiting for models to improve at reverse-engineering undocumented hardware quirks. It is giving AI the same structured foundation that makes it so effective in other domains: hardware abstraction layers that decouple application logic from specific silicon, sandboxed environments where modules can fail safely, simulation environments where AI-generated code can be tested without physical hardware in the loop, and standardized patterns that give AI something predictable to reason about.

The engineers and organizations that start experimenting now, that build the software foundations AI needs to be effective, and that embrace compound engineering as a strategy rather than dismissing code generation as a novelty will have a decisive advantage.

The embedded world has always been cautious, and rightly so. But caution should not become complacency. The tools are improving, the pioneers are proving it works, and the trajectory is unmistakable. The question is not whether AI will transform embedded development. It is whether you will be ready when it does.

Three investments make sense for embedded teams right now, regardless of where AI tooling goes.

• Improve test coverage and harness speed. A fast test suite is the foundation compound engineering depends on.
• Invest in software abstractions. Tightly coupled code is hard for humans and AI alike.
• Identify weak links in your CI/CD pipeline. Start experimenting on bounded, lower-risk tasks to learn which parts of your workflow are ready and which need more structure first.

These three steps will pay dividends and prepare you to integrate a standard embedded platform, which at MicroEJ we see as the necessary next step to accelerate AI-powered development and bring the era of compound engineering. This is a domain that we are actively researching, hoping to make some major contribution soon.

In the meantime, I would love to hear from fellow embedded engineers: where are you seeing real gains, and where are the walls? The conversation is just getting started.