Embedded AI Podcast

E23 How LLMs Tick

Ryan and Luca pull back the curtain on large language models, explaining what's really happening when you chat with an AI. They break down tokenization, context windows, and the stateless nature of LLMs—revealing why these tools aren't actually thinking or remembering, just generating the most likely next token based on massive matrices of weights. The conversation covers practical implications like why long sessions deteriorate, how caching affects costs, and why that apologetic "I won't do it again" from your LLM is meaningless. They also tackle the misleading anthropomorphization in AI marketing and share frustrations with features like Claude's opaque memory system. If you've ever wondered why your LLM seems to forget instructions or why it confidently states nonsense, this episode explains the mathematical reality behind the conversational illusion. Key Topics: [02:30] Tokenization: How LLMs break language into mathematical units [08:45] LLMs as stochastic algorithms: Predicting the next most likely token [12:20] Training models: Billions of parameters and matrix multiplication [15:10] Quantization: Trading precision for memory efficiency [18:00] Context windows and token limits: Why size matters and costs money [22:15] Stateless processing: LLMs don't remember, they reprocess everything [26:40] Caching and timeouts: The hidden costs of pausing your session [30:00] Hallucinations aren't bugs—they're the default mode of operation [35:20] Attention mechanisms and why large context windows cause degradation [40:15] Claude's memory system: Well-intentioned but problematic in practice [44:30] Mixture of experts: Sparse vs. dense models and routing tokens Notable Quotes: "The LLM doesn't even know what truth is, so it can't lie to you. It's not lying to the truth either. It's bullshitting—it doesn't care which way is true or false." — Ryan "All LLMs know how to do is hallucinate. They just generate chains of tokens. If you're lucky, those chains have some connection to the real world and are actually helpful." — Luca "I wish it wasn't programmed to just lie to me. If the LLM says 'I won't do it again,' yes it will, because it has no memory of this incident. It will behave the same way tomorrow." — Luca Resources Mentioned: Luca's Training and Consulting - Luca's website with links to AI and embedded systems training courses Tulip Tree Tech Emulator - Ryan's commercial emulator for embedded systems development (Raspberry Pi, STM, ESP, Microchip) Google's Attention Paper - The foundational 2013 paper introducing the attention mechanism that enabled modern LLMs On Bullshit by Harry Frankfurt - Philosophical work distinguishing bullshitting from lying—relevant to understanding LLM outputs Agile Embedded Podcast Slack - Community discussion channel where you can reach Ryan and Luca, with a dedicated sub-channel for Embedded AI topics

E22 deploying models on small microcontrollers

We talk with Sebastian Boblis and Marco Meder-Mendez from Bosch about the surprisingly challenging art of deploying AI models on resource-constrained embedded devices. They share insights from their work on ETAS Embedded AI Coder, a tool that generates optimized C code from neural network models for microcontrollers—sometimes with as little as 100 bytes of RAM available. The conversation covers practical strategies for model compression (often by factors of 100x or more), the counterintuitive benefits of float models over quantized ones on tiny devices, and why feature engineering still matters. Sebastian and Marco explain how they navigate the trade-offs between RAM, compute time, and accuracy, and why each project presents unique constraints—from confidential hardware specs to compiler quirks. They also discuss real-world applications, including Bosch's AI-powered wall scanner that uses radar and neural networks to detect cables in walls. Key Topics: [03:30] Why Bosch started exploring embedded AI on tiny hardware in 2020 [06:45] Real-world application: AI-powered wall scanner using radar to detect cables [09:20] How ETAS Embedded AI Coder generates C code from neural network models [12:00] Deploying models with as few as 300 parameters and 100 bytes of RAM [16:30] Model compression strategies: squeezing networks down by 100x or more [21:15] When float models outperform quantized ones on tiny devices [28:00] Trading off RAM vs. compute time through code generation techniques [33:45] Benchmarking challenges with confidential hardware and compilers [40:20] AutoML and architecture search for constrained embedded targets [46:00] Free tool access for universities and opportunities for students Notable Quotes: "We go down to applications where we use 100 bytes of RAM and you can still do something useful with this on a Cortex-M0. It's very surprising how small you can get with neural networks." — Sebastian Boblis "Sometimes we have to squeeze it down not by one or two X, sometimes it's up to 100 X and more. This is really a regular task for us." — Marco Meder-Mendez "One thing that's super counterintuitive for many people on these smaller devices is to go from a quantized model to a float model. It can actually help you. It's exactly the opposite of what people do on these larger systems." — Sebastian Boblis Resources Mentioned: ETAS Embedded AI Coder - Code generation tool for deploying neural networks on embedded devices; free for universities ARM CMSIS-NN - Library containing functions for neural network layers on Cortex-M devices MLPerf Tiny Benchmarks - Benchmarking suite for tiny ML systems that Sebastian's team participated in Bosch AI-powered Wall Scanner - Radar-based power tool using neural networks to detect cables in walls Agile Embedded Podcast Slack - Community discussion channel where you can reach Ryan and Luca, with a dedicated sub-channel for Embedded AI topics

E21 AI security research and AI security

Ryan and Luca tackle the hot topic of AI-driven security research, sparked by the release (and brief containment) of Anthropic's Mythos tool. Ryan, drawing on his 20+ years in cybersecurity, delivers a surprisingly reassuring message: if you've been doing proper engineering, AI-found vulnerabilities aren't the existential threat the hype suggests. We explore how Mythos and similar tools are flooding the CVE database with thousands of new vulnerabilities, but discuss why this doesn't automatically mean more successful attacks. Ryan explains the crucial difference between finding a bug and actually exploiting it, and why embedded systems developers shouldn't panic—but should definitely have their update processes sorted. The conversation covers everything from botnet refrigerators to Ukrainian security cameras, threat modeling with AI assistance, and why AI makes such a relentlessly effective hacker (spoiler: it doesn't get bored). Bottom line: the weapons haven't changed, you just need to install the bulletproof glass you should have had all along. Key Topics: [02:30] Introducing Mythos: AI tool for finding software vulnerabilities, its May release, US containment, and recent re-release [05:15] The flood of AI-generated bug reports: distinguishing real vulnerabilities from noise, and the burden on maintainers [08:45] Mythos by the numbers: 6,000+ critical vulnerabilities found, 90% true positive rate, but does it matter for your system? [12:00] The reachability problem: having a bug vs. being able to exploit it, and why solid engineering processes matter more than bug counts [16:30] Embedded systems challenges: BSP version conflicts, regulatory approval nightmares, and the CRA/FDA compliance push [21:00] No uptick in actual attacks: why more CVEs doesn't equal more breaches, and what motivates attackers (hint: money, not bugs) [28:45] Embedded systems' blessing and curse: air-gapped devices vs. internet-connected vulnerabilities, and the botnet refrigerator story [35:20] Using AI for defense: network analysis, threat modeling, traffic pattern recognition, and why AI is the best grep you've ever seen [42:00] AI as the relentless attacker: no social norms, no contracts, just pure problem-solving—and why that's both powerful and concerning [47:30] The offensive vs. defensive mindset: why AI bridges both motivational patterns and what that means for security teams Notable Quotes: "Just because there's more CVEs doesn't really change the defensive posturing that you need to do. If you have a solid engineering process to provide updates to your system and test and verify those updates actually work, it doesn't matter how many bugs you find. You can find two. You can find 6,000." — Ryan Torvik "AI doesn't have social norms. AI will just go and do things. And yes, there are guardrails that they're trying to put on, but like, I don't know if you've seen AI just ignore parts of your prompt before." — Ryan Torvik "There's not a death star. This is not an existential crisis. This is not something new. It changes the game but not in a way that we can't handle. The weapons haven't changed, you just need to install the bulletproof glass." — Ryan Torvik Resources Mentioned: Anthropic's Mythos - AI tool for automated vulnerability discovery in software, released in May 2024, briefly restricted by US authorities, then re-released CVE Database - Common Vulnerabilities and Exposures database, currently experiencing significant growth due to AI-assisted vulnerability discovery Agile Embedded Podcast Slack - Community Slack channel where Ryan participates, sister podcast to Embedded AI Tulip Tree Tech - Ryan's company focused on improving embedded development processes, including emulator-in-the-loop solutions luca.engineer - Luca's website with links to training courses, LinkedIn, and other professional activities

E20: "AI Will Take My Job :-( " - Why Your Job Is (Probably) Safe

We tackle the elephant in the room: will AI take our jobs? Spoiler alert - probably not, but your job will definitely change shape. Ryan and Luca dig into what software development actually is (hint: it's not just mashing keyboards), why embedded systems might be particularly safe from AI disruption, and what we can learn from the Luddites and steam engines. Drawing on Luca's experience with DevOps transformations and Ryan's work running a company, we explore why engineers keep solving the wrong problems, what Black & Decker actually sells (it's not drill bits), and why vibe-coding your email server is a terrible idea. The real question isn't whether AI will replace you - it's whether you understand what your actual job is in the first place. Plus: Pokemon evolution as career advice, and why AI is the new Agile fairy dust. Key Topics: [02:30] The real job vs. the mechanical task - why writing code isn't actually your job [08:45] Why embedded systems are particularly safe from AI disruption - complexity, hardware interaction, and undocumented quirks [15:20] The Black & Decker lesson: selling holes in walls, not drill bits - understanding what customers actually want [22:10] Historical parallels: steam engines, DevOps, and why demand grows faster than automation [28:40] The reality check: most developers aren't using AI systematically yet - you're not behind the curve [32:15] AI as the new Agile fairy dust - why magic solutions never work without process and understanding Notable Quotes: "Your job is not writing code. Your job is making product. If you think about the Luddites, their job was not operating a loom. Their job was making clothes." — Ryan Torvik "Writing code is really the smallest part of software development. Most of it is sitting in front of the screen, looking up and to the left, and figuring out what code to write." — Luca Ingianni "The CEO of Black & Decker was once quoted as saying: We are not in the business of selling drill bits. We are in the business of selling holes in the wall. If we had laser cannons that made holes in walls, people would buy the laser cannons instead." — Luca Ingianni Resources Mentioned: Agile Embedded Podcast Slack - Community discussion channel where you can reach Ryan and Luca, with a dedicated sub-channel for Embedded AI topics Luca's Website - Contact Luca for consulting on using AI effectively in embedded systems contexts - multiple contact options available

• Transcript

E19: SDD frameworks, and WhittleSpec - Rethinking AI-Assisted Development with Feedback Loops

Luca unveils WhittleSpec, his new open-source framework for AI-assisted development that challenges the waterfall assumptions baked into most coding tools. Born from frustration with frameworks like SpecKit that treat specifications as static documents, WhittleSpec emphasizes continuous learning through retros, refinement, and test-driven development. We explore why most AI coding frameworks make typing faster but don't help with the hard part—the thinking—and discuss how proper feedback loops and vertical slicing can lead to more trustworthy software. The conversation ranges from the philosophy of whittling away what doesn't fit (versus plowing ahead blindly) to practical implementation details: specification, planning, task breakdown, TDD cycles, and retrospectives. Luca argues that professional software engineering requires systematic processes that support learning at every step, not just tools that generate code quickly. We also touch on the missing pieces in current frameworks: support for safety-critical development, long-term roadmaps, and embedded systems considerations. Key Topics: [02:30] Introducing WhittleSpec and the problem with current AI coding frameworks [08:45] Why AI tools make the easy part easier but leave the hard part hard [15:20] The waterfall trap: static specifications vs. living documents [22:10] Mapping the landscape of AI development frameworks (SpecKit, BMAT, Kiro, etc.) [28:40] How WhittleSpec works: decide, specify, plan, tasks, and TDD cycles [38:15] The critical role of retrospectives and the 'refine' skill for course correction [45:30] Vertical slicing vs. layer-by-layer implementation: tracing bullets through the stack [51:00] Missing pieces: safety-critical development, long-term roadmaps, and embedded considerations Notable Quotes: "No engineer ever said, 'I wish I could type curly brackets faster.' That was never quite the bottleneck. The hard part is sitting in front of your screen and going, 'hmm.'" — Luca Ingianni "SpecKit is just plain old horrendous waterfall. There are no provisions at all in it for learning. The idea is you specify something well enough and then you just walk away, sip a coffee, the machine does its thing. That approach has never ever worked." — Luca Ingianni "Your initial specification is not going to be right. As you implement the actual solution, you're going to learn things that's going to change what you need to accomplish with the spec. You might need to change completely what your expectations are." — Ryan Torvik Resources Mentioned: WhittleSpec - Luca's new open-source AI-assisted development framework emphasizing feedback loops, TDD, and iterative refinement SpecKit - GitHub's AI coding framework discussed as an example of waterfall-style specification-driven development Agile Embedded Slack - Community Slack channel now open to Embedded AI podcast listeners for discussion and questions Luca.engineer - Luca's website with links to all his projects and ways to reach him TulipTreeTech - Ryan's company working on AI-generated models for pre-silicon firmware validation

E18: Shawn Hymel on Edge AI - NPUs, Deployment Challenges, and the Future of Embedded ML

Ryan and Luca sit down with Shawn Hymel, an educator and course creator focused on edge AI and embedded systems. We explore what's changed in the past few years—from basic keyword spotting to full object detection on microcontrollers, thanks to integrated NPUs. Shawn walks us through the messy reality of deploying ML models to embedded hardware: vendor-specific toolchains, dependency hell, and the ongoing challenge of making edge AI accessible. We discuss what students and experienced engineers need to learn (or unlearn) to work effectively in this space, and look ahead to exciting developments like reinforcement learning on tiny devices and neuromorphic computing. It's a candid, technical conversation about where edge AI stands today and where it's headed. Key Topics: [03:30] Why run ML on microcontrollers? Power, size, and application-specific advantages [06:00] Keyword spotting as the original killer app for edge AI [08:45] The game-changer: NPUs enabling full object detection on microcontrollers [13:20] Privacy benefits of on-device processing vs. cloud-based inference [16:00] How NPUs work under the hood and the vendor-specific deployment reality [24:30] The painful parts: dependency hell, graph compilers, and memory arena sizing [29:00] Using AI tools (LLMs) to navigate vendor documentation and generate code [33:45] What CS students and ECE students each need to learn for edge AI [40:15] Shifts in university enrollment: ECE rising, CS declining [44:00] When you don't need AI: PID loops and deterministic solutions still matter [47:30] Looking ahead: reinforcement learning on microcontrollers and neuromorphic computing Notable Quotes: "Five, six years ago, we didn't have full object detection on microcontrollers. Now with NPUs, we can do things like full YOLO on a 320x320 image—milliwatts of power, full object detection. That was not a thing five years ago." — Shawn Hymel "Expect to spend a day or two getting inference to actually run. The docs are still new, the graph compilers are fairly new. You're going to end up in dependency hell—both on the Python side and when you bring it over to the embedded side." — Shawn Hymel "If a PID loop solves your need, there is absolutely no reason to put AI on there. That is a solved problem. Don't do it—just use a PID loop." — Shawn Hymel Resources Mentioned: Shawn Hymel's Website - Shawn's main site with links to free and paid courses on edge AI and embedded systems OpenMV - Computer vision platform for microcontrollers, including the new AE3 board with NPU support Edge Impulse - Platform that simplifies ML model deployment to embedded devices, supporting various NPUs Andrew Ng's Coursera ML Course - Foundational machine learning course recommended for understanding the math behind ML TensorFlow Lite for Microcontrollers (LiteRT) - Framework for running ML models on microcontrollers across different platforms

E17: Switching Providers - Insulating Yourself from AI Vendor Lock-in

Ryan and Luca tackle a challenge many AI users are facing: what happens when your AI provider starts acting up? Drawing from recent experiences with Anthropic's capacity issues, secret billing practices, and model degradation, we explore practical strategies for avoiding vendor lock-in. We discuss the three layers of complexity: the model itself, the harness (like Claude Code or GitHub Copilot), and your authored content (skills, MCP servers, prompts). Each layer presents different challenges when switching providers. Ryan shares his approach of stepping back to simpler, more granular prompting to stay provider-agnostic, while Luca experiments with maintaining escape hatches to other platforms. We also look at the realities of running local models and the tradeoffs between convenience and control. The bottom line? Pick one system, get proficient, but prepare your exit strategy - because in this volatile landscape, you'll likely need it sooner than you think. Key Topics: [02:30] Anthropic's recent troubles: capacity issues, model degradation, and gaslighting users [06:45] The Hermes.md billing scandal - secret charges for having a specific filename [10:20] Ryan's approach: stepping back to simpler, granular prompting for provider independence [15:00] The three layers of complexity: model, harness, and authored content [18:30] Why models aren't interchangeable - different flavors, tokenizers, and caching strategies [24:15] Luca's tone-of-voice challenge: getting consistent writing style across models [30:00] Running local models and private inference as alternatives to frontier models [35:45] Practical strategies: maintaining escape hatches without parallel systems [40:20] Luca's solution: versioning authored content separately with symlinks Notable Quotes: "The more you actually make use of AI in your work, the more you use it as a force multiplier, the more painful it becomes if that force multiplier goes away." — Luca "It's about total clock time. If you get a one shot and then have to redo it again, how much of that clock time is being used effectively?" — Ryan "Pick one, stick with it, be proficient in it. But prepare yourself to have to escape eventually, because the situation is so volatile." — Luca Resources Mentioned: Claude Code - Anthropic's AI coding assistant with hooks and skills support OpenCode - Provider-agnostic AI coding harness that supports multiple models GitHub Copilot CLI - Multi-provider AI assistant with dropdown model selection MCP (Model Context Protocol) - Protocol for extending AI capabilities across different harnesses Ollama - Tool for running local AI models on your own hardware

E16 Running LLMs Locally: Privacy, Performance, and Practical Trade-offs

We explore what it really means to run AI models locally instead of relying on cloud providers like OpenAI or Anthropic. From powerful desktop setups with dual NVIDIA RTX 3090s to tiny models running on embedded systems, we cover the full spectrum of local AI deployment. Luca shares hands-on experience running local models for client work, explaining the hardware requirements (spoiler: you need fast VRAM, not just lots of RAM), performance trade-offs, and practical tools like Ollama and LM Studio. We discuss how modern open-weight models from Meta, Google, and Chinese companies compare to hosted solutions - typically about a year behind state-of-the-art but surprisingly capable. We also look at edge AI applications, from elderly fall detection to traffic accident monitoring, where compact models shine. The conversation covers context window limitations, quantization techniques, and why getting started is easier than you might think - though you'll need to manage expectations about what local models can deliver compared to their cloud-based cousins. Key Topics: [00:00] Introduction: What are local models and why run them? [02:30] Hardware requirements: VRAM vs system RAM, and why graphics cards matter [05:45] Luca's setup: dual RTX 3090s and real-world client work with local models [08:20] Performance metrics: time to first token, tokens per second, and output quality [12:00] Tiny models for edge AI: Google's 270M parameter model and specific use cases [15:30] Tools and workflows: Ollama, LM Studio, and OpenAI-compatible APIs [18:45] Where models come from: Hugging Face, Meta's Llama, and the open-weight ecosystem [22:10] Context window limitations and quantization techniques [25:00] Getting started: realistic expectations and practical first steps Notable Quotes: "What those models really need is tons of memory and as fast memory as you can get it. This is why people like Macs because they've got the unified memory architecture." — Luca Ingianni "Modern models are actually pretty good. They are smaller, so they will have less knowledge. They are a tad slower. They struggle with much smaller context windows. But if you can work within those bounds, they work pretty well." — Luca Ingianni "Using AI is a different mindset. It's a different way of thinking about solving a problem, but it's just another tool in your toolbox and it's just another way of getting work done." — Ryan Torvik Resources Mentioned: Ollama - Docker-like tool for running local LLMs with simple pull/run commands and OpenAI-compatible API LM Studio - Graphical user interface for downloading and running local models easily Open WebUI - Web interface for local models that mimics ChatGPT's chat interface Hugging Face - Repository with hundreds of thousands of models in various sizes and configurations Meta Llama - Open-weight model family from Meta that helped start the local LLM movement Google Gemma - Model family from Google including compact vision-capable models (270M parameters)

• Transcript

E15 Julia Imlauer on introducing AI into organizations

We talk with Julia Imlauer, Director for AI Strategy and Development, about the practical realities of introducing Gen AI tools into engineering organizations. Julia shares her experience training engineers and management across multiple companies, revealing what actually works—and what doesn't—when rolling out LLM-based coding assistants. The conversation covers the adoption curve from early enthusiasts to skeptics, the importance of giving engineers dedicated time to experiment, and why "word of mouth" matters more than top-down mandates. We discuss the messy reality of legacy codebases where LLMs shine, the challenge of managing AI-generated code in pull requests, and the emerging cost crisis as providers shift from subsidized to consumption-based pricing. Julia also addresses common fears about junior developer training and the misconception that LLMs can replace human expertise. Key Topics: [02:30] Julia's background in robotics and machine learning, and how she started introducing Gen AI tools into development workflows [05:15] Why LLMs help with messy, historically-grown codebases more than pristine template-based workflows [09:45] Different developer preferences: IDE integration vs. separate LLM interfaces [13:20] The adoption curve: early adopters, skeptics, and the crucial middle mass that needs convincing [16:00] Training sessions that work: giving engineers blocked time to experiment, not step-by-step tutorials [19:30] The power of word-of-mouth and why ambassador programs sometimes help spread adoption [24:10] Training management and executives: IP protection, managing AI-generated code in pull requests, and supporting skeptical engineers [29:45] The billing nightmare: token consumption, opacity in pricing models, and the shift away from all-you-can-eat plans [35:20] Common skeptic concerns: fear of replacement, adoption pain, and outdated first impressions from early LLM versions [38:50] Junior developer training with LLMs: why pair programming and code reviews still matter more than writing every line by hand [43:15] Communication breakdowns between departments: translating vocabulary between IT, legal, and engineering [46:30] Looking ahead: the need for agentic frameworks, standardization, and routing models to manage costs Notable Quotes: "What they do for you is really, they free your engineers to focus on things that matter. They write the boilerplate code. They write the code which you don't want to think about, which is a necessity, which you need to have to make everything work. But it's just like a doing concept." — Julia Imlauer "It sounds stupid when you say you need kind of a education training session for engineers to use this tool, but exactly this is what I experienced—they don't need you know a training in the ways of you need to click here and here and here. What they need is blocked two hours out of their daily coding hustle and really get kind of a free mind to take a look at the tool." — Julia Imlauer "There is this misconception of, okay, we don't need junior developers anymore. They just cost and then an LLM can do that. And let's just pile more on our senior developers. I mean, this is not working. And everyone who is in software development understands that." — Julia Imlauer Resources Mentioned: Caveman - A GitHub repo that compresses prompts to very basic words to reduce context window size and token consumption Open Claw / Nemo Claw - Open source agentic framework projects exploring standardized interfaces for LLM agents MCP (Model Context Protocol) - An emerging standard for LLM tool integration mentioned as a potential path toward provider-agnostic frameworks

• Transcript

E14 Kwabena Ageyman on OpenMV

We sit down with Kwabena Ageyman, co-founder of OpenMV, to explore how microcontrollers have evolved from simple 8-bit chips to AI-capable systems that rival desktop computers. Kwabena walks us through OpenMV's journey from the CMU Cam days to their latest products—the OpenMV Cam AE3 and N6—which pack neural network accelerators, image signal processors, and H.264 encoders into single-chip packages. What makes these systems remarkable isn't just raw performance (250+ gigaops for AI inference), but what they enable: battery-powered computer vision deployments with no infrastructure requirements. Kwabena demonstrates running a complete web server with live video streaming—all in MicroPython on a microcontroller. We discuss the practical implications: doorbell cameras that don't phone home, parking lot monitors that run on solar panels, and industrial vision systems that don't require conduit runs. The conversation touches on hard technical choices (why debayer images even for AI?), the underappreciated value of MicroPython for complex applications, and the infrastructure costs that kill many promising AI deployments. Kwabena also previews what's coming: transformer support on microcontrollers and WiFi HaLow for long-range, high-bandwidth connectivity. For anyone working on edge AI or embedded vision, this episode offers both practical insights and a glimpse of what's possible when hardware acceleration meets thoughtful software design. Key Topics: [00:03] Introduction to OpenMV and the evolution from "impossible" computer vision on microcontrollers to AI-capable systems [00:05] Technical specs of the AE3 and N6: 250 gigaops performance, 5-64MB RAM, image signal processors, and H.264 encoding [00:12] Why image processing steps like debayering matter even for AI applications [00:18] The infrastructure cost problem: why power, connectivity, and deployment logistics kill many AI projects [00:28] Running MicroPython on microcontrollers: web servers, RTSP streaming, and complex applications without Linux [00:35] Live demo: complete web interface with video streaming running on a microcontroller [00:42] Real-world use cases: YOLO object detection, face tracking, drowsiness detection, and parking lot monitoring [00:52] The future: transformer support on microcontrollers and WiFi HaLow for long-range connectivity Notable Quotes: "Ten years ago when we started, if you Googled for computer vision on microcontrollers, you got a single Stack Overflow reply about how that was impossible. Since then, a lot has changed." — Kwabena Ageyman "The product dies when you have to tell people: I want you to put 10,000 of these in the field. They look at the infrastructure cost and say, what does that look like end to end? Is that actually going to be a net benefit, or is it just sexy and looks cool?" — Kwabena Ageyman "Having AI on the edge actually unlocks privacy. It is a decision to collect all the data and store it forever. If you have Edge AI locally on these devices, the device manufacturer can say: we're actually not going to go into a format where we have infinite data collection of everything." — Kwabena Ageyman Resources Mentioned: OpenMV - OpenMV's website with products, documentation, and community resources Roboflow - Cloud platform for training computer vision models, partnered with OpenMV Edge Impulse - Edge AI development platform, OpenMV partner for model training WiFi HaLow - Long-range, low-power WiFi technology (up to 10 miles) mentioned for future connectivity Embedded Online Conference - Conference where Kwabena, Luca, and Ryan will be speaking

• Transcript

E13 Ryan visits Luca (and they talk abut spec-driven development)

For E13 we recorded live in Luca's garden in Munich, with Ryan dropping by ahead of Embedded World week. Ryan and Luca talk about spec-driven development in the AI era: where the discipline came from, what changes when an LLM is doing the typing, and the failure modes that show up over and over again in trainings. The short version: vibe coding will get you something that demos beautifully, but the moment a stranger asks "what does this button do?", it tends to expose how little was actually thought through. The conversation circles around a few recurring themes — the iterative loop you cannot skip even when the AI lets you, the temptation to one-shot whole projects, and the awkward fact that the AI itself seems to actively prefer working in waterfall mode. We also get into why requirements engineering and product ownership matter more (not less) with AI in the picture, why TDD doubles as a way of describing the goal to your assistant, and why the engineer staying in the loop — with that loop running tighter and faster — is what actually makes this work in practice. Plus an honest digression about all the ditches Luca has fallen into building Claude Code skills around his daily workflow. Key Topics: [02:24] Three artifacts of spec-driven development — and what each one means in the AI era [05:45] Trainings, vibe-coded games, and the "what does this button do?" moment [11:27] Long-lived branches, three months of code in an hour, and why both fail for the same reason [22:25] Beningo's multiplier metaphor: what if the engineer's value is between -1 and 1? [24:25] Engineering as conversations; curly brackets as a side effect [27:17] Why requirements engineering and product ownership become more important with AI [30:59] The AI wants waterfall — and you need to fight it [33:54] One-shot prompts for whole projects: lying to yourself in five lines [37:27] Staying in control: one unit of work, AI in the loop, integrate, done [41:32] Filling ditches one at a time: Luca's Claude Code skills setup [43:06] TDD as the act of describing the goal — to yourself and to the AI Notable Quotes: "If you've got a five-line prompt that generates 10,000 lines of code for you, then there's just going to be a lot of blank spots in there, a lot of ambiguity in there. That can't be good." — Luca Ingianni "I've had teammates create a long-lived branch and tell me 'I'll see you in a few months.' And I'm like — no. They don't understand how this is going to interact with the rest of the system. And you're basically doing that same thing — writing three months worth of code in an hour. Cool, now what?" — Ryan Torvik "Engineering is what happens when engineers talk to one another, and the differential equations and the C++ code are just side effects of those conversations." — Luca Ingianni Resources Mentioned: embeddedai.academy — Luca's AI trainings for embedded teams Agile Embedded Podcast — sister show, more on agile in the embedded world Embedded World — annual embedded systems trade fair in Nuremberg, where Ryan was heading next Claude Code — the AI coding tool Luca built his "skills" workflow around Jacob Beningo's "multiplier" framing for AI in development teams (referenced from E12)

• Transcript

E12 Learning AI-powered development with Jacob Beningo

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

• Transcript

E11 debugging embedded systems using AI

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

• Transcript

E10 TDD and AI

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

• Transcript

E09 AI Systems Engineering with Darwin Sanoy

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

• Transcript

E08 - AI-Powered Pipelines with Joe Schneider

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

• Transcript

E07 - Embedd, and using AI safely, with Michael Lazarenko

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

• Transcript

E06 integrating AI into embedded products with Souvik Pal

In this episode, Ryan and Luca welcome their first proper guest, Souvik Pal, Chief Product Officer at FyeLabs. 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 FyeLabs [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

• Transcript

E05 Context Management

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

• Transcript

E04 Crossover with the Agile Embedded Podcast

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

• Transcript