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