Embedded AI Podcast

We sit down with Jacob Beningo, a real-time embedded systems consultant with 20 years of experience, to talk about what we've learned teaching engineers to use AI in their development workflows. Turns out, the hard part isn't getting AI to write code—it's all the systems engineering that comes before and after. We discuss common mistakes people make when starting out, like treating AI as a magic code generator instead of a pair programming partner, and why you absolutely cannot skip requirements, architecture, and critical thinking just because the AI can type faster than you.
Jacob shares stories from his training sessions, including an AI that refused to follow test-driven development because "that would take too long." We explore why AI actually forces you to become a better engineer by taking away the dopamine hit of typing code yourself, and why IDE plugins might be leading people astray by keeping them at the wrong level of abstraction. The conversation gets real about costs—both in tokens and electricity bills—and why the "set it and forget it" YouTube hype doesn't match reality. If you're skeptical about AI in embedded systems, good—keep that skepticism. You're going to need it.
Key Topics:
[03:15] The real challenge: systems engineering, not code generation
[08:45] Why requirements engineering skills matter more than ever with AI
[14:20] The push-button module exercise: spending a full day on design before any code
[16:30] When AI refuses to follow TDD: "That would take too long"
[22:40] The temperature sensor exercise: when tests pass but the code isn't production-ready
[28:15] Code is cheap, but experiments aren't free: finding the balance
[35:50] The hidden costs of AI: token budgets and rising electricity bills
[42:10] Why IDE plugins might be the wrong interface for AI-assisted development
[48:30] Using AI as a pair programming partner, not a code completion tool
[53:20] Keep your skepticism: why critical thinking is more important than ever
Notable Quotes:
"The AI finished writing the code and all the tests in like four seconds. I'm like, how was that so fast? Well, I just wrote all the code. You didn't follow the TDD process? No, that would take too long." — Jacob Beningo
"If you throw in such a vague requirement, the thing can't read their mind and neither can they read its mind. So it's really just a matter of luck what you're going to get." — Luca Ingianni
"The AI is the best puppy you'll ever have. It'll go pick up the stick for you. And you're like, no, not that stick. What do you mean not that stick? You didn't tell me which stick. I grabbed you the stick." — Ryan Torvik
Resources Mentioned:
Jacob Beningo on LinkedIn - Daily posts about embedded systems development and modernization
Beningo.com - Jacob's consulting and training services for embedded systems
Embedded Software Academy - Training courses including AI for embedded systems development
Embedded Online Conference - Annual May conference for embedded systems education and community
Agile Embedded Podcast Slack - Community discussion channel mentioned by the hosts

Ryan and Luca explore practical techniques for using AI to debug embedded systems -- from analyzing breadboard photos to parsing UART output and managing complex debugging workflows. LLMs work best as force multipliers rather than replacements for engineering expertise: they handle tedious tasks like adding printf statements, analyzing logs, and decoding resistor color codes, while the engineer guides the process and catches mistakes.
A key theme is context management: balancing deterministic scripts for repeatable tasks with non-deterministic AI analysis, and using separate sessions to keep debugging focused. We share cautionary tales of LLMs getting stuck in loops or reverting to common patterns despite specific instructions -- human oversight remains essential. Experienced engineers benefit most because they can effectively steer the LLM and recognize when it goes off track.
Key Topics:
[02:30] Debugging hardware via photos -- having LLMs identify wiring errors on breadboards
[06:45] The rubber duck effect -- LLMs as interactive debugging partners
[11:20] Printf debugging with AI -- adding debug statements and analyzing UART output
[15:40] Context management -- separate sessions, distilled datasheet summaries
[22:15] LLM failure modes -- loops, pattern reversion, ignoring specific instructions
[28:30] Force multiplier vs. replacement -- why experience matters more with AI tools
[33:50] Deterministic scripts + non-deterministic AI analysis
[38:20] Future: webcams and oscilloscope screenshots for real-time hardware debugging
Notable Quotes:
"It's like the over-eager intern -- it's a little naive, but it can type like the devil." -- Luca Ingianni
"You cannot use an LLM as a replacement for your brain or for your experience, but you can use it as a force multiplier." -- Luca Ingianni
"The LLM does not have that emotional connection to the code. I don't think people understand how emotional that connection is." -- Ryan Torvik
Resources Mentioned:
Claude Code (Anthropic) -- AI coding assistant used for debugging, image analysis, and code generation
Arduino/Elegoo Development Boards -- hardware platforms discussed in context of voltage compatibility debugging
Agile Embedded Podcast -- Luca's podcast on agile practices in embedded development

Is test-driven development still relevant when AI can generate thousands of lines of code from a prompt? Ryan argues TDD was designed for human limitations -- if AI can generate complete systems, why write tests first? Luca pushes back: tests are your only defense against AI assumptions. Five lines of prompt becoming 10,000 lines of code means 9,995 lines of hidden assumptions that need to be made explicit and verifiable.
Luca presents a systematic approach: start with test ideas (behaviors to verify), progress to test outlines (properties and steps in comments), then implement test code before letting AI write production code. This isn't about micromanaging class hierarchies -- it's about maintaining engineering responsibility. TDD becomes even more crucial in the AI era: it's how you communicate intent, capture assumptions, and keep AI-generated code on track.
Key Topics:
[02:30] Is TDD obsolete in the age of AI?
[05:45] Ryan's argument: TDD was designed for human limitations
[08:20] Tests as defense against AI assumptions and 'success theater'
[12:15] Hidden assumptions: 5 lines of prompt becoming 10,000 lines of code
[16:40] Agentic AI coding and the Swiss cheese model of reliability
[21:30] Systematic approach: Test ideas, test outlines, test implementation
[28:45] Spec-driven development (SDD) and PRDs in AI-assisted coding
[35:20] Unit tests vs. BDD in the AI context
[42:10] Why you shouldn't fight the AI over class hierarchies
[48:30] Weekend projects that become production systems
[52:45] Building features in an unfamiliar language (Kotlin) using TDD
Notable Quotes:
"The AI writing tests for me is the last thing that I want, because that is my only line of defense against the AI doing stupid things." -- Luca Ingianni
"To go from five lines of prompt to 10,000 lines of code means there are 9,995 lines worth of assumptions in there. And sometimes they are correct and sometimes they are not." -- Luca Ingianni
"The problem is that weekend projects turn into airplanes. Prototypes always live on." -- Ryan Torvik
"You are responsible for this code no matter whether you type the curly brackets or the LLM." -- Luca Ingianni
Resources Mentioned:
Spec-driven Development (SDD) -- systematic AI-assisted development with three layers: requirements, plan, and tasks
Behavior-Driven Development (BDD) -- system-level testing through executable specifications (Gherkin language)
Unciv -- open-source Civilization clone in Kotlin, used as example project for TDD with AI
Agile Embedded Podcast -- Luca's podcast on agile practices and TDD in embedded systems

In this episode, Ryan and Luca sit down with Darwin Sanoy from GitLab to explore the intersection of systems engineering, embedded development, and AI. Darwin brings a wealth of experience from his work in ISO 26262 certification and MIT Systems Architecture, helping us understand why embedded systems development differs fundamentally from pure software development.
We dig into the core challenge: in embedded systems, software is never the whole product—it's always a part number in a larger physical system. This reality shapes everything from development cycles to how we can apply Agile and DevOps practices. Darwin walks us through the spectrum of embedded systems, from smart machines that benefit from frequent updates to safety-critical systems where the optimal number of software updates is exactly one.
The conversation takes a practical turn as we explore how AI can help with systems engineering challenges, particularly around extracting architecture from legacy codebases and working with model-based systems engineering tools like SysML v2. Darwin shares concrete examples of using AI to generate embedded code from systems models and discusses GitLab's approach to making DevOps more accessible to embedded engineers through AI-powered explanations and context-aware tooling. We also touch on the limitations of current AI—it's great at small scope but struggles with broad architectural understanding, much like asking a new person off the street to understand your entire codebase every single time.
Key Topics:
[03:15] Why embedded systems development differs from pure software: software as a part number vs. software as the whole product
[08:45] Three categories of embedded systems: smart machines, stable/boring machines, and safety-critical machines
[12:30] The role of systems engineering in managing complex physical products and supplier ecosystems
[18:20] SysML v2 and storing systems engineering models as code for AI accessibility
[24:10] Generating embedded code from systems engineering models using AI: the flashlight example
[28:45] The importance of architecture documentation and using AI to extract architecture from legacy code
[35:50] Limitations of AI: excellent at small scope but struggles with broad architectural understanding
[42:15] GitLab's approach to embedded DevOps: AI-powered explanations, context-aware tooling, and MCP servers
[48:30] Practical AI applications: using imperative AI to create declarative code for model validation
Notable Quotes:
"Software as it's talked about in the lean startup and in agile and in DevOps is essentially limited to when software is the whole product. As soon as you get into embedded systems, by definition, the software is embedded into a physical product. Software is always a part number." — Darwin Sanoy
"You are settling into a roller coaster and the operator gets on and says I'm sorry we're going to be an extra 10 minutes while a software update finishes. You're a DevOps pro so you stay seated right? Because you know that releases are only going to improve your experience, right?" — Darwin Sanoy
"AI researchers put up a diagram and said these 169 boxes are roughly the functions that scientists and psychologists agree the human mind has. Next slide: these are the four that AI emulates and it doesn't do a very good job compared to what you do." — Darwin Sanoy
"At least if you ask a human expert 'do you know about this?' they'll say 'yeah I'm not certain, ask somebody else.' AI literally cannot know how solid its knowledge is—it has no concept of vagueness or uncertainty." — Luca Ingianni

In this episode, we sit down with Joe Schneider, founder of Dojo5 and creator of the EmbedOps framework, to explore how AI is transforming embedded development pipelines. We discuss the practical applications of AI in CI/CD workflows—from summarizing build outputs and triaging static analysis results to enabling smarter hardware-in-the-loop testing through visual analysis.
Joe shares his perspective on where AI adds real value: condensing complex data, identifying anomalies, and helping teams move faster without sacrificing quality. We also tackle the challenges: the brittleness of traditional testing approaches, the difficulty of tracking dependencies in embedded systems, and the risks of over-automation. Throughout the conversation, we explore the balance between deterministic tools and AI-assisted workflows, and why human judgment remains essential—especially when it comes to security updates and edge cases that no test script would catch.
Whether you're skeptical about AI hype or curious about practical applications, this episode offers a grounded look at how AI can strengthen your development pipeline without replacing the engineers who build it.
Key Topics:
[00:00] Introduction: Meet Joe Schneider and the focus on AI in embedded DevOps
[02:30] The complexity challenge: Why modern embedded development needs better pipelines
[05:15] Bob's machine and the problem with manual, hero-driven development
[08:00] What AI is good at: Summarization, classification, and expansion
[12:45] Exploratory testing: Can AI fish for bugs more effectively than random testing?
[18:20] Visual analysis in hardware-in-the-loop testing: Using AI to evaluate screens and physical behavior
[24:00] Walking through the pipeline: Build stage, static analysis, and AI-assisted triage
[30:15] Compiler flags and configuration: Where AI can help optimize and catch mistakes
[35:40] PR review automation: AI as a code reviewer—benefits and limitations
[42:00] Self-healing pipelines: Automatic dependency updates and security patching
[48:30] The human-in-the-loop debate: When automation goes too far
[52:15] Hardware testing challenges: From pixel-perfect comparisons to AI-based visual validation
[58:00] War story: Debugging a silicon bug that only appeared under specific conditions
Notable Quotes:
"In 2025, there are still many companies that build and release firmware from a folder on a share drive somewhere that says V1.2, or it's Bob's machine. Somebody's literally clicking the build button, and that's just very sad." — Joe Schneider
"If your product is destined for a human user, then you need a human to test it at some point in your stack. Humans are not good at following a test script for the 50th time, but they're great at finding the things you didn't think to test for." — Joe Schneider
"AI is very helpful when you have a bunch of different situations and you can ask it: does this fall into this bucket or that bucket? That classification capability can be extremely useful in analyzing what's happening in your system or pipeline." — Luca Ingianni
"I don't trust the scripts that I write. There's still people clicking buttons and mashing screens to make sure that things are working correctly, because we don't even trust the people that were downstream of us doing this work before." — Ryan Torvik
"I think testing a lot like fishing. You don't just drive your boat a random amount in a random direction and drop the line. Fishermen know where the fish are—over in the weeds, under the dock. AI can learn those signals too." — Joe Schneider
Resources Mentioned:
Dojo5 - Custom firmware development company founded by Joe Schneider
EmbedOps - Industry-leading embedded development DevOps framework created by Dojo5
Zephyr RTOS Security Tool - Tool within Zephyr that evaluates compiler flags and security posture—often underutilized
PC-Lint - Traditional static analysis tool for C/C++, known for verbose output