Firmware 2035: The Future of Embedded Development

Embedded systems are becoming more capable, more connected, and more complex. At the same time, expectations around delivery speed, quality, safety, and maintainability continue to rise. While hardware has advanced rapidly, embedded software development practices have struggled to keep pace, forcing teams to rethink how firmware is designed, built, and validated.

In this keynote, we’ll explore what embedded development may look like by 2035 and the forces already shaping that future today. Using the Embedded Technology Atlas as a framework, we’ll examine emerging and accelerating trends such as AI-assisted development, simulation-first workflows, application-centric architectures, and continuous quality pipelines. Rather than focusing on speculation, this talk highlights practical signals already visible across modern embedded teams.

Attendees will gain a clearer understanding of how the role of the embedded engineer is evolving, what aspects of firmware development are changing, and which fundamentals, such as timing, hardware constraints, and engineering responsibility, remain constant. This session is designed to help developers, technical leads, and engineering managers better prepare for the next decade of embedded systems development.

Topics covered in this keynote will include:

• Forces shaping the future of embedded software development
• The role of AI and automation in firmware workflows
• Simulation-first and application-centric design approaches
• How embedded engineering roles are evolving
• What will change and what will not by 2035

What this presentation is about and why it matters

What will embedded development actually look like when AI, simulation, and automation are no longer side topics, but part of the daily workflow? Jacob Beningo uses this keynote to explore that tension through a forward-looking, opinionated talk grounded in real embedded practice, his consulting work, and live demonstrations. Rather than focusing on a single product or board, he maps out the pressures reshaping the field, then shows how they affect architecture, verification, debugging, and the role of the engineer. This is especially useful if you want a practical lens on where the industry may be heading, and how to think about your own team’s next steps.

Who will benefit the most from this presentation

• Embedded engineers who are feeling the pressure of late delivery, heavy debugging, or too much low-level work
• Tech leads or architects who want a broader view of how AI and simulation may affect system design
• Teams considering more automated verification, hardware-in-the-loop testing, or simulation-first workflows
• Engineers curious about how their role may shift toward systems-level work over the next decade
• Managers or consultants looking for a vocabulary to discuss modernization without pretending the hardware disappears

What you need to know

No deep prerequisites, but the talk will land better if you already live in the embedded world and are comfortable with the usual development loop: requirements, implementation, debugging, testing, and hardware bring-up.

• Familiarity with embedded firmware development
• Basic awareness of CI/CD, simulation, and AI-assisted tools
• Some exposure to system architecture or verification practices

Glossary (terms used in this talk)

• Architecture Decision Record (ADR): A short, written record of an architecture or design decision, including context, alternatives, and consequences. ADRs help preserve the reasoning behind choices so they can be reviewed later.
• Simulation: The use of models or synthetic processes to generate data that approximates real-world behavior for analysis or training.
• Application-centric architecture: An approach where software structure is driven by the application’s behavior, data flow, and user needs, rather than by the shape of a particular chip or peripheral set. It helps separate system design from hardware choice.
• Hardware-in-the-loop testing: A testing setup where real hardware is included in an automated test flow, so software can be exercised against physical interfaces and timing behavior. It is often used to close the gap between simulation and deployment.
• RAG (Retrieval-Augmented Generation): A pattern that combines a language model with an external knowledge source, such as a document store or vector database, so responses can be grounded in specific reference material. It is useful when accuracy depends on exact product data, manuals, or datasheets.
• Model Context Protocol (MCP): A protocol for connecting AI clients to external tools and data sources through a standard interface. It lets applications expose capabilities such as files, devices, instruments, or services to an agent in a structured way.
• AI agent: A software system that can decide on steps, call tools, and carry out tasks with limited supervision. In practice, agents are used to automate multi-step work rather than just answer questions.
• Skill: A reusable package of instructions, inputs, outputs, and workflow rules that guides an AI system toward a specific task. Skills are often used to make repetitive work more consistent and more testable.

Toolbox (mentioned in this talk)

• Logic analyzer / bus sniffer: Hardware tool for capturing and decoding digital signals on buses and interfaces to diagnose IO/peripheral timing, bus contention and protocol issues.
• oscilloscope: A measurement instrument used to visualize electrical signals over time. In embedded performance work, it can be used to measure timing around code sections via GPIO toggling.
• Renode: An open-source platform for emulating embedded hardware and connected devices. It is used to run firmware in a simulated hardware environment.
• Zephyr: Zephyr is an open-source real-time operating system for resource-constrained devices, supported by many embedded toolchains and debuggers.
• Claude Code: A code-focused offering/variant from Anthropic's Claude family intended for code analysis and generation tasks.
• Zephyr RTOS: A scalable real-time operating system for connected and resource-constrained devices. It often owns much of the system startup flow, including hardware initialization and thread setup.

Final thoughts

Opinionated, practical, and unusually broad in scope, this keynote gives you a systems-level lens on how embedded work may evolve under pressure from AI and automation. The value is less in any single prediction than in the framing, a way to think about architecture, verification, and day-to-day engineering as parts of one changing workflow. It will especially help engineers and leads who want to modernize without losing sight of hardware reality. The talk leaves you with a strong sense that the ground is moving, and that the interesting work is moving with it.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.