In this episode, Ryan and Luca sit down with Michael Lazarenko, co-founder of Embedd, to discuss the real-world challenges of using AI in embedded systems development.

Michael shares his journey from manufacturing physical devices to building AI-powered tools that parse datasheets and generate hardware abstraction layers. The conversation dives deep into when AI should—and critically, shouldn't—be used in embedded development.

Michael offers a refreshingly pragmatic perspective on AI adoption, explaining how Embedd uses AI to extract information from messy, unstandardized PDFs and technical manuals, while deliberately avoiding AI where deterministic approaches work better. The discussion covers the technical challenges of building RAG systems for embedded documentation, the importance of creating stable intermediate representations, and why accuracy matters more than speed when generating safety-critical code.

The episode also explores broader themes around AI adoption in conservative industries like automotive and aerospace, the gap between AI hype and reality in embedded development, and Michael's vision for a unified embedded development platform. Throughout, the conversation maintains a healthy skepticism about AI's current capabilities while acknowledging its potential—a balanced perspective that's rare in today's overheated AI discourse.

Key Topics:

• [02:30] The problem of hardware-software coupling and why embedded documentation is such a mess
• [08:45] When NOT to use AI: deterministic parsing vs. probabilistic approaches
• [15:20] Building RAG systems for technical documentation: chunking, context windows, and accuracy challenges
• [22:10] Creating stable intermediate representations (digital twins) for hardware components
• [28:40] The verification problem: why AI-generated embedded code is harder to validate than web applications
• [35:15] AI adoption in conservative industries: automotive, aerospace, and defense taking risks
• [42:30] The gap between AI hype and reality in embedded development workflows
• [48:20] How AI forces better testing and requirements engineering practices
• [54:00] The future of embedded development: unified platforms and model-based design

Notable Quotes:

"I would be slightly contrary and say at this point at least, I probably wouldn't use it in every possible place, especially in this specific problem set, given the context size that we're facing. AI performs best when the results are as defined and as limited as possible." — Michael Lazarenko

"If there is a register list in an SVD file that I can parse with 0% chance of probabilistic error, why would I use RAG? If there isn't one, then I have to use it, and then I need to find a way of using it that gives me the highest possible accuracy." — Michael Lazarenko

"The number of VCs that I've talked to in the past year who have told me that they don't need testing frameworks because the AI is just going to generate all the code for us. That's exactly why you need more thorough testing. That's why you need more guardrails." — Ryan

"Since I've been using AI seriously to generate code, I've become such a stickler for tests. It's quite remarkable. AI can be a forcing function to really force you to get your development processes in order." — Luca

"I'm seeing dumps of AI code going in that no one read. People are outputting requirements and then code that AI spits out, and it's really soul destroying for those who actually review the code." — Michael Lazarenko

Resources Mentioned:

• Embedd - Michael's company that creates stable representations of embedded hardware and generates hardware abstraction layers using AI

In this episode, Ryan and Luca welcome their first proper guest, Souvik Pal, Chief Product Officer at FiLabs. Souvik shares his eight years of experience helping customers bring embedded AI projects to life, walking us through two fascinating case studies that highlight the real challenges of deploying AI in resource-constrained environments.

We explore a wearable safety device that needed to run computer vision on an ESP32 (spoiler: it didn't work), and a smart door system that had to juggle facial recognition, voice authentication, gesture detection, and 4K video streaming—all while fitting behind a door frame. Souvik breaks down the practical considerations that drive hardware selection, from power budgets and thermal management to the eternal struggle with Bluetooth connectivity. The conversation reveals how different constraints—whether it's battery life, space, or compute power—fundamentally shape what's possible with embedded AI.

Beyond the technical war stories, we discuss what makes AI products actually useful rather than just technically impressive. Souvik emphasizes the importance of keeping humans in control, building trust through transparency, and understanding your power budget before anything else. Whether you're working with microcontrollers or mini PCs, this episode offers practical insights into the messy reality of bringing AI-enabled embedded products from concept to reality.

Key Topics:

• [00:00] Introduction and welcoming first guest Souvik Pal from FiLabs
• [02:30] Evolution of embedded AI: from cloud-based processing to edge computing
• [04:00] Case study: Wearable safety device with rear-facing camera for threat detection
• [08:00] Attempting to run object detection on ESP32: memory constraints and quantization challenges
• [12:00] Moving to Raspberry Pi Zero: trade-offs between power consumption and capability
• [15:00] Model selection: working with COCO dataset and YOLO for embedded environments
• [20:00] Case study: Smart door system with 4K display, facial recognition, and voice authentication
• [25:00] Running multiple AI models concurrently: video streaming, object detection, voice recognition, and gesture detection
• [30:00] Wake word detection and voice command processing without full transcription
• [35:00] Hardware selection: from ESP32 to Raspberry Pi to mini PCs and thermal management
• [40:00] Linux audio challenges and managing concurrent AI pipelines
• [45:00] Building good AI products: user experience, trust, and keeping humans in control
• [50:00] Design process for AI-enabled products: power budget as the primary consideration
• [55:00] Hardware progression: ESP32, Raspberry Pi Zero, Pi 5, Jetson, and when to use each

Notable Quotes:

"The way I define embedded is where we have constraints, either cost in space or compute or power. And that's where it becomes really challenging to deploy any sort of advanced algorithmic solutions." — Souvik Pal

"A good AI would strike a balance between what it enables the user to do and what it does for itself. I think we should let the human know that they're interacting with an AI, however smart that AI might be." — Souvik Pal

"When I think of an AI solution, it starts with power. That's number one consideration. What is your power budget? That immediately restricts you in terms of what you can do." — Souvik Pal

"You know people worried about AGI... the amount of work you've had to do to replace a doorman in this situation." — Ryan Torvik

Resources Mentioned:

• COCO Dataset - Common Objects in Context dataset - a go-to dataset for object detection with 50+ pre-trained classes
• YOLO (You Only Look Once) - Object detection model well-suited for compute-constrained embedded environments, with recent versions showing promise for edge deployment
• Open Wake Word - Wake word detection engine used for voice-activated systems

In this episode, Ryan and Luca explore one of the most practical aspects of working with LLMs: context management. They discuss what tokens are, how context windows work, and why managing context often matters more than crafting perfect prompts. The conversation covers the challenges of context window limitations, the phenomenon of "recency bias" where LLMs pay more attention to information at the beginning and end of their context, and practical strategies for keeping your AI assistant focused on the right things.

The hosts share hands-on experiences with context compaction, using agents (or what Luca prefers to call "function calls") to segregate different tasks, and various methods for pulling in external information without overwhelming the LLM. They discuss everything from ingesting log files and design documents to using Model Context Protocol (MCP) for accessing external services. Throughout, they emphasize the importance of thinking like a product manager or requirements engineer when working with LLMs - breaking down problems into manageable chunks and deliberately curating what information the AI needs at each step.

The episode wraps up with practical advice on avoiding common pitfalls like context pollution, dealing with outdated API knowledge in LLMs, and knowing when to start fresh rather than trying to compact an overloaded context window.

Key Topics:

• [00:00] Introduction and defining tokens in LLMs
• [03:30] Understanding context windows and their limitations
• [07:15] The sweet spot: too little vs. too much context
• [10:45] Recency bias: why position matters in your context window
• [15:20] Context compaction and when to start fresh
• [21:00] Using agents (slash commands) to segregate tasks and manage context
• [28:30] Pulling in external context: files, documentation, and selective ingestion
• [35:45] Model Context Protocol (MCP) and accessing external services
• [40:15] Dealing with outdated LLM knowledge and API versions
• [45:00] Ingesting log files and serial output in embedded development
• [48:30] Thinking like a product manager: breaking down problems for LLMs

Notable Quotes:

"I find myself worrying about context quite a lot... the explicit instructions that you give to an LLM will often only be a very small part of the overall instructions that you pass to it." — Luca Ingianni

"As you're trying to do work, you can only think about so many things at the same time... I just need to sit down and compress this for a second. Let this kind of sink in and percolate and get rid of this stuff that I don't need to think about anymore." — Ryan Torvik

"If you want the LLM to pay particular attention to something, you should put it either at the beginning or at the end of your prompt. So it will be sort of very fresh in the LLM's mind." — Luca Ingianni

"You as the user need to be a better product manager and think globally about the problem you're trying to solve... Don't give it a task that's going to blow out the context window. Break down the problem into sufficiently small enough steps." — Ryan Torvik

"I used to be a requirements engineer. I find myself going back to my requirements engineering mindset and really thinking about, okay, what am I talking about? What do I need to define? What context do I need to give?" — Luca Ingianni

In this special crossover episode, Luca brings together his two podcasting worlds: the Agile Embedded Podcast with Jeff Gable and the Embedded AI Podcast with Ryan Torvik. What starts as Jeff admitting he's still a "noob" with LLMs turns into a practical deep-dive on how to actually use AI tools without coding yourself off a cliff.

The three explore the real challenges of working with LLMs: managing context windows that behave more like human memory than computer memory, the critical importance of test-driven development (even more so with AI), and why you absolutely cannot let go of the reins. Ryan and Luca share hard-won lessons about prompt engineering, the value of small iterations, and why your static analysis tools aren't going anywhere. They also tackle team-level questions: how code reviews change (or don't), why prototyping becomes a superpower, and what happens to junior engineers learning their craft in an AI-assisted world.

This isn't hype about AI replacing developers - it's three engineers figuring out how to use a powerful but unpredictable tool to write better code faster, while keeping their engineering judgment firmly in the driver's seat.

Key Topics:

• [02:30] Three ways to interact with LLMs: web interfaces, CLIs, and IDE plugins - and why the right interface matters
• [08:45] The art of prompting: being specific without writing pages of instructions, and learning from your mistakes
• [15:20] Context management: why LLMs forget like humans do, and how to keep them focused on what matters
• [22:10] Test-driven development with AI: why tests matter even more when you're not writing the code yourself
• [28:45] Avoiding 'vibe coding off a cliff': small iterations, frequent commits, and knowing when to start fresh
• [35:30] Code reviews and team dynamics: what changes and what stays the same when AI enters the workflow
• [42:15] Prototyping as a superpower: getting from zero to one in minutes instead of weeks
• [46:00] Junior engineers and learning: why you still need to bash your head against problems to gain experience

Notable Quotes:

"All of us are new to this experience. There's not somebody that went to school back in the 80s and like, I've been doing this for 40 years. Like nobody has that level of experience. So we're all just running around, bumping into things and seeing what works for us." — Ryan

"An LLM is just a token generator. You stick an input in, and it returns an output, and it has no way of judging whether this is correct or valid or useful. It's just whatever it generated. So it's up to you to give it input data that will very likely result in useful output data." — Luca

"The LLM is like the happiest developer that I've ever worked with. Just so excited and happy to do more work than you could ever possibly imagine. Like, oh, my gosh." — Ryan

"Don't ever let go of the reins. They will just sort of slowly slip out of your hands and all of a sudden you find yourself sitting there like a fool with nothing in your hands." — Luca

"I can use LLMs to jumpstart me or bootstrap me from zero to one. And once there's something on the screen that kind of works, I can usually then apply my general programming skill, my general engineering taste to improve it." — Jeff

Resources Mentioned:

• Aider - Command-line AI coding assistant mentioned by Luca as his preferred tool for interacting with LLMs
• Claude Code (Anthropic) - AI coding tool discussed for its ability to search codebases and manage context
• VS Code - IDE with AI integrations that Ryan mentions using despite being a former command-line purist
• RooCode - Tool Ryan used that had a prompt enhancement feature, though he no longer uses it

In this episode, Ryan and Luca dive into their real-world AI coding workflows, sharing the tricks, tools, and hard-learned lessons from their daily development work. They compare their approaches to using AI agents like Claude Code and discuss everything from prompt management to context hygiene. Luca reveals his meticulous TDD approach with multiple AI instances running in parallel, while Ryan shares his more streamlined VS Code-based workflow.

The conversation covers practical topics like managing AI forgetfulness, avoiding the pitfalls of over-mocking in tests, and the importance of being strict with AI-generated code. They also explore the addictive, game-like nature of AI-assisted coding and why it feels like playing Civilization - always "just one more turn" until the sun comes up. This is an honest look at what actually works (and what doesn't) when coding with AI assistants.

Key Topics:

• [02:30] Tool preferences: Command line vs VS Code for AI coding
• [05:45] Prompt management strategies and the ginormous prompt problem
• [08:15] Context management and AI forgetfulness over time
• [12:00] Luca's three-option planning approach to avoid first-thought bias
• [15:30] Test-driven development with AI: Why it's essential and how to do it right
• [20:45] The mocking problem: When AI tests interfaces instead of functionality
• [25:00] Running multiple AI instances in parallel for complex projects
• [30:15] The Civilization effect: Why AI coding becomes addictively engaging
• [35:00] Code hygiene and post-generation cleanup strategies

Notable Quotes:

"I've learned the hard way that you must not do that. I was like, oh, this is really nice. I wrote like 10,000 lines of code this week. You know I'm fantastically productive and then I paid for it by going over those same 10,000 lines for the next three weeks and cleaning up the mess that it had made." — Luca Ingianni

"I must use TDD if I use AI coding. Otherwise it's so easy to get off the rails." — Luca Ingianni

"I don't have to code with the shift key ever again." — Ryan Torvik

"Coding with AI assist just feels exactly the same way for me [as Civilization]. It just sort of sucks you in." — Luca Ingianni

"Make sure that your AI coding agent doesn't tie your shoelaces together. Because it will." — Ryan Torvik

Resources Mentioned:

• ADA - Open source command line AI coding tool mentioned by Luca
• Claude Code - AI coding assistant used by both hosts, available as command line tool and VS Code extension
• Continue.dev - AI coding assistant mentioned by Ryan as one he tried early on
• RueCode - AI coding tool with task management features that Ryan used before switching to Claude Code

Connect With Us:

• Try implementing TDD with your AI coding workflow - start small with just 3 tests at a time
• Create your own prompt management system - whether it's a prompts.md file or slash commands
• Share your own AI coding workflows and tricks with us - we'd love to hear what's working for you

Ryan and Luca explore Retrieval Augmented Generation (RAG) and its practical applications in embedded development. After Ryan's recent discussions at the Embedded Systems Summit, we dive into what RAG actually is: a system that chunks documents, stores them in vector databases, and allows AI to query specific information without hallucinating. While it sounds perfect for handling massive datasheets and documentation, the reality is more complex.

We discuss the critical challenge of chunking - breaking documents into the right-sized pieces for effective retrieval. Too big and searches become useless; too small and you lose context. Luca shares his hands-on experience trying to make RAG work with datasheets, revealing the gap between theory and practice. With modern LLMs offering larger context windows and better document parsing capabilities, we question whether RAG has missed its window of usefulness for most development tasks. The conversation covers when RAG still makes sense (legal contexts, parts catalogs, private LLMs) and explores alternatives like having LLMs use grep and other Unix tools to search documents directly.

Key Topics:

• [02:15] What RAG is: Retrieval Augmented Generation explained
• [04:30] RAG for embedded documentation and datasheets
• [07:45] The chunking problem: breaking documents into searchable pieces
• [12:20] Vector databases and similarity search mechanics
• [16:40] Luca's real-world experience: challenges with datasheet RAG
• [20:15] Modern alternatives: LLMs using grep and Unix tools
• [25:30] When RAG still makes sense: legal contexts and parts catalogs
• [30:45] RAG vs. larger context windows in modern LLMs
• [35:20] Private LLMs and when RAG becomes relevant again

Notable Quotes:

"Data sheets are inaccurate. You still have to engineer this. You cannot just go and let it go." — Ryan

"It's so difficult to get the chunking right. If you make it too big, that's not useful. If you make it too small, then again, it becomes difficult to search for because you're losing too much context." — Luca

"These days, LLMs are good enough at just ad hoc-ing this. You can do away with all of the complexity of vector stores and chunking." — Luca

"We have the hardware. We can actually prove it one way or another. If it doesn't work on hardware, then it's not right." — Ryan

"RAG is quite tempting and quite interesting, but it's deceptively simple unless you have good reason to believe that you can get it working." — Luca

Resources Mentioned:

• Google NotebookLM - Tool mentioned for ingesting PDFs and creating AI-generated podcasts from documents
• TreeSitter - Syntax tree analysis tool used as alternative to RAG for code analysis
• Embedded Systems Summit - Jacob Beningo's conference where RAG and AI topics were discussed

Connect With Us:

• Try experimenting with modern LLMs and their built-in document parsing capabilities before investing time in RAG implementation
• Share your experiences with RAG in embedded development - we'd love to hear what worked and what didn't
• Consider the trade-offs between public LLMs and private models when deciding if RAG is worth the complexity for your use case

Welcome to the inaugural episode of the Embedded AI Podcast! Ryan and Luca kick things off by exploring the fascinating intersection of AI and embedded systems. From fog computing (AI happening everywhere around us - in coffee shops, traffic lights, and cars) to vibe coding (using AI to generate code through natural language), we dive into what this new landscape looks like for embedded engineers.

We share our real-world experiences with AI in development, including Ryan's struggles getting an STM32 to print "Hello World" using AI-generated code, and Luca's insights from the German Aerospace Conference where traditional AI dominated over LLMs. The conversation reveals both the promise and pitfalls of AI in embedded development, touching on everything from sound-based machine monitoring to the security implications of learning algorithms in the field. Whether you're curious about AI or skeptical about its place in embedded systems, this episode sets the stage for our ongoing exploration of how AI is reshaping our industry.

Key Topics

* [02:30] Fog computing explained - AI processing happening everywhere around us

* [05:15] Vibe coding - using natural language to generate code with AI

* [08:45] Luca's insights from German Aerospace Conference - traditional AI vs LLMs

* [15:20] Sound-based machine monitoring using AI for predictive maintenance

* [22:10] Ryan's STM32 Hello World struggles with AI-generated code

* [28:30] Security implications of learning algorithms in embedded systems

* [35:45] How AI is changing developer roles - from coding to systems engineering

Notable Quotes

> "Fog computing is taking that and flipping it over again. Instead of doing the mass of the computing in a data center, you're doing it on the outside edge on these tiny devices in the forest." — Ryan

> "AI is here to stay, and it is really, really useful and really, really helpful if you apply it well and if you apply it to the right things." — Luca

> "I had a friend yesterday asked me if I thought that I was losing my brain because I've been vibe coding so much. I just don't have to use the shift key anymore." — Ryan

> "How can this thing be so smart and so stupid at the same time?" — Luca

> "Good, bad, or otherwise, we need to get involved in this, or you're going to get swept up and left behind." — Ryan