The Agile Embedded Podcast

We explore how test-driven development (TDD) remains essential—perhaps more than ever—when working with AI coding tools. Luca shares his evolved workflow using Claude Code, breaking down how he structures tests in three phases: test ideas, test outlines, and test implementations. We discuss why TDD provides the necessary control and confidence when AI generates code, how it prevents technical debt accumulation, and why tests serve as precise specifications for AI rather than afterthoughts. The conversation covers practical challenges like AI's tendency toward "success theater" (overly generous assertions), the importance of maintaining tight control over code quality, and why the bottleneck in AI-assisted development isn't code generation—it's expressing clear intent. We also touch on code spikes, large-scale refactorings, and why treating AI development as pair programming keeps you in the driver's seat. If you're wondering whether TDD still matters when AI writes your code, this episode makes a compelling case that it matters more than ever. Key Topics [02:30] Why TDD still matters with AI: confidence and control over generated code [06:45] Tests as specifications: describing desired behavior to AI rather than writing prompts [09:20] The three-phase test workflow: test ideas, test outlines, and implementations [15:30] Pair programming with AI: staying at the conceptual level while AI handles implementation [20:15] Code spikes and exploration: using AI to answer questions before writing production tests [24:40] AI failure modes: over-mocking and "success theater" with weak assertions [28:50] Large-scale refactorings: how AI excels at updating hundreds of tests simultaneously [32:10] The real bottleneck: expressing intent and specifications, not code generation speed Notable Quotes "As far as I am concerned, test-driven development is just about writing prompts for the AI that it can then use to build what you want it to build." — Luca "If you expect that a five-line prompt resulting in 10,000 lines of code will not result in 9,995 lines of uncertainty, you're just deluding yourself." — Luca "You can be five times faster than you were before and still maintain a very high production level quality code, but you probably can't be a hundred times faster." — Jeff Resources Mentioned Claude Code - Terminal-based AI coding assistant that Luca uses for TDD workflows, keeping conceptual work separate from code-level work Embedded AI Podcast - Luca's separate podcast focusing on AI in embedded systems, co-hosted with Ryan Torvik Luca's AI Training Courses - Hands-on trainings for using AI in embedded systems development (and much more!) links to all of Luca's work - Training, consulting, podcasts, conference talks and everything else You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this second part of our series on engineering organizations, Jeff and Luca explore how companies that build products should focus their efforts differently depending on their stage and scope. We start with startups and early-stage companies desperately searching for product-market fit, where the brutal truth is: quality doesn't matter yet. Your MVP should embarrass you—if it doesn't, you waited too long. We discuss the critical mental shift from throwaway prototypes to proper engineering once validation arrives, and why technical founders often fail by solving the wrong problem brilliantly. Moving up the ladder, we examine narrow-focus companies that have found their niche—like the German firm that does nothing but maintain a 100-year-old anchor chain machine, or specialists in medium-power electrical switches. These companies win through efficiency and deep expertise, but face existential risk if the market shifts. Finally, we tackle wide-focus companies introducing multiple product lines, where the challenge becomes running internal startups while managing established products, each requiring radically different approaches. The key insight: your focus must match your product's lifecycle stage, whether that's ruthless speed, cost optimization, or high-level process learning. Key Topics [02:30] Startups and early-stage companies: the existential search for product-market fit [06:45] The MVP philosophy: if you're not embarrassed, you waited too long [11:20] Quality vs. speed vs. scope: why quality doesn't matter in early stages [15:40] The Potemkin village approach: building facades to validate demand [19:15] Embedded products and MVPs: when physical products need creative shortcuts [23:50] The critical switch: from prototypes to proper engineering after validation [28:30] Narrow-focus companies: German hidden champions and deep specialization [34:10] Wide-focus companies: running internal startups within established organizations [40:25] Product teams and parallel focuses: managing different lifecycle stages simultaneously [45:00] Large established companies: high-level process learning and avoiding organizational weight Notable Quotes "If you read the Lean Startup, they will explicitly say: if you weren't embarrassed by your MVP, you waited too long. It really has to be painfully flimsy because you cannot afford to do it well." — Luca "Quality doesn't even factor because you're very explicitly building mock-ups from chewing gum and paper mache. They are fully intended to be thrown away." — Luca "Getting that product-market fit is existential. You will die if you do not get it and get it relatively quickly." — Jeff Resources Mentioned The Lean Startup - Eric Ries' book discussing MVP philosophy and the importance of being embarrassed by your first product The Mom Test - Rob Fitzpatrick's book about getting real customer feedback and validation through financial commitment The Art of Innovation - Tom Kelley's book on IDEO's design process, including the clothespin switch story Luca's Website - Trainings on embedded agile, AI in embedded systems, and more Jeff's Website - Consulting services for medical device software development You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this first part of a two-part series, Jeff and Luca explore how different types of service-oriented engineering organizations should focus their learning and improvement efforts. Drawing from their consulting experience, they examine three distinct categories: product development firms that turn client ideas into reality, engineering development firms that sell specialized technical expertise, and solo engineers who package all necessary knowledge into one person.The core insight: what you should focus on learning depends entirely on what you're actually selling. Product development firms need to master the entire client journey and product design process, not just engineering excellence. Engineering development firms must become technical wizards in a specific domain that clients actually value. Solo engineers face the challenge of needing deep expertise while wearing every business hat. Across all three types, the common traps are the same: focusing too much on craft and too little on client experience, failing to specialize, and not investing enough in teaching as marketing.Throughout the discussion, Jeff and Luca emphasize that for service firms, you are the product - and that changes everything about where you should direct your improvement efforts. The conversation is grounded in real experiences, including some cautionary tales about firms that tried to be everything to everyone.Key Topics[00:00] Introduction: Two-part series on engineering organizations and their different focuses[02:30] Overview of the framework: Service firms vs. product-building companies[05:15] Product development firms: Why engineering excellence isn't enough[08:45] The critical importance of product design and client guidance over pure engineering[12:20] Process-level learning: Shortening cycle times and enabling rapid prototyping[15:40] The Irinos example: In-house board manufacturing to tighten feedback loops[18:30] Requirements will always change - designing for learning, not perfection[21:00] The danger of being a generalist: Why specialization matters for service firms[24:15] Engineering development firms: Selling technical expertise, not complete products[27:45] Technology-focused learning: Going deep on specific technical capabilities[30:20] The trap of becoming a commodity: Why domain expertise beats technology alone[33:40] The forklift invoice review example: You can't specialize too narrowly[35:30] Solo engineers: The complete package vs. temporary employee trap[39:00] Common failures across all service firms: Too much craft focus, too little client experience and marketing[41:30] Teaching as the best form of marketing for technical service firmsNotable Quotes"The customers don't actually hire them for their engineering skills. They are sort of a given. But what such a product development firm should offer the client is guiding them through the development process, which they don't have enough skills for to do it on their own." — Luca"Engineering is not the point. The unit of work is delivering a working product to the client that satisfies their business case, that has a reasonable cost to manufacture, and that you feel confident your own client has validated their market." — Jeff"It's not that engineering is irrelevant, but rather that it's table stakes. This is just taken for granted, but what such a product development firm should offer is guiding them through the development process." — Luca"You almost can't be narrow enough. I remember our friend Philip Morgan having this example of a company that specializes in reviewing invoices of forklift repairs. This is what they do. They review forklift repair invoices. And they're doing very well apparently." — Luca"Teaching and giving information and solving problems publicly is the best form of marketing. It's not advertising. It's building trust with an audience." — JeffResources MentionedIDEO - Prototypical design firm mentioned as an example of companies specializing in product designIRNAS - Product development firm with in-house board manufacturing capabilities, featured in previous episodes, exemplifying tight feedback loopsPhilip Morgan - Consultant and friend mentioned for his example about specialization (forklift invoice review company)Jeff Gable's website - Jeff's consulting services for medical device software development and advisoryLuca Ingianni's website - Luca's training products and resources for embedded systems, IoT, and AIConnect With UsStay tuned for Part 2, where we'll explore organizations that build products and what they should focus on when the market decidesIf you're in the medical device industry and need help with embedded software - either writing it or navigating the regulatory landscape - reach out to Jeff at jeffgable.comCheck out Luca's training products for embedded systems, IoT, and AI at luca.engineerReflect on your own organization: Are you focusing on the right things for the type of service firm you are? Are you specializing enough? You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this episode, we sit down with Milica Kostic, an embedded software architect from Belgrade, Serbia, to discuss her journey from C/C++ to Rust and what it means for embedded development. Milica shares her experience adopting Rust in production environments, starting with an embedded Linux project using a microservice architecture that allowed for clean isolation of Rust code.We explore the practical realities of learning Rust as an experienced C/C++ developer - yes, there's a learning curve, and yes, the compiler will slap you on the wrist frequently. But Milica explains how the development experience, with cargo as a package manager and built-in tooling for testing and static analysis, makes the journey worthwhile. She's candid about where Rust shines (embedded Linux, greenfield projects) and where challenges remain (microcontroller support, IDE tooling, vendor backing).The conversation touches on the bigger question facing our industry: with memory safety becoming critical in our connected world, what role should Rust play in new embedded projects? While Milica takes a measured stance - acknowledging that C and C++ aren't going anywhere - she's clearly excited about Rust's potential, especially in safety-critical domains like medical devices. Whether you're Rust-curious or still skeptical, this episode offers a grounded perspective from someone who's actually shipped production code in Rust.Key Topics[02:30] Milica's background in embedded systems and her journey from electrical engineering to embedded software development, with focus on safety-critical industries like medical devices[04:15] The path to adopting Rust: from first hearing about it in 2020 to finding a client project willing to embrace it, and the importance of having experienced Rust developers on the team[07:00] Choosing the right project for Rust adoption: embedded Linux with microservice architecture as an ideal starting point, avoiding complex C/C++ interoperability[10:45] The learning curve: getting used to the Rust compiler's strictness, discovering the ecosystem of unofficial but widely-used crates, and how learning Rust improved C++ skills[14:20] What makes Rust development pleasant: cargo as package manager, built-in testing and static analysis, cleaner code organization with modules, and writing unit tests alongside source code[17:30] Current limitations: lack of official vendor support for microcontrollers, community-driven development, potential gaps in certified stacks (like BLE), and IDE support challenges[20:15] Interfacing Rust with C and C++: C binding works well, C++ has limitations with inheritance and templates, and the safety considerations when using unsafe code blocks[25:40] Integrating Rust into legacy projects: when it makes sense (isolated new features requiring memory safety) and when it doesn't (just for experimentation), plus maintenance considerations[30:00] The big question: Is it irresponsible not to use Rust for new projects? Discussion of Philip Marcraff's strong stance and Milica's more nuanced view considering team knowledge, existing tooling, and project context[33:45] The influence between languages: how C++ is learning from Rust's memory safety features, and why the borrow checker is harder to retrofit than basic safety improvements[36:20] Rust in operating systems: adoption in the Linux kernel and Microsoft Windows, and major tech companies pushing C++/Rust interoperability forward[39:00] The future of Rust in embedded: Milica's view that C, C++, and Rust will coexist, each with their own use cases, advantages, and trade-offsNotable Quotes"Learning Rust has also made me a better C++ developer as well. Once you get used to those rules, you apply them in C++ as well." — Milica"Just like writing Rust code is pleasant. It flows much nicer than or easier than it would with C++, for example. The way you organize your code, in my opinion, is also cleaner." — Milica"If you are developing Rust for embedded systems on microcontrollers, you need to be aware that there is no official vendor support. Everything currently is open source and driven by the community." — Milica"You definitely do not lose benefits of using Rust for the rest of your codebase when using a C library. That C library is isolated, and if there are some memory issues, then you know where to look." — Milica"I think most of the benefits come from starting with Rust in the first place. So having a clean slate, starting a new product, new project with Rust. That's where you see the most benefits." — MilicaResources MentionedEmbassy - An async framework used in embedded Rust projects, mentioned as a good starting point for greenfield embedded developmentZephyr RTOS - Real-time operating system that is working on official Rust integration, though not fully there yetRust Rover - JetBrains' official IDE for Rust development, released about a year and a half ago, though with some limitations for embedded developmentZed - A new IDE written completely in Rust, mentioned as an emerging option for Rust developmentSlint - A Rust-based GUI framework for embedded systemsEmbedded Online Conference - Conference where Milica gave a talk on Rust for embedded systems - link to her presentation in show notesMilica's LinkedInMilica's talk on Rust at the Embedded Online Conference You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this discussion, Matt Trentini, a Principal Software Engineer with 25 years in embedded systems, shares his journey back to embedded development through MicroPython. He highlights the power of MicroPython's interactive REPL for rapid development and usability in medical devices. Matt dives into practical integrations with C code, discusses performance trade-offs, and shares real-time client feedback experiences. He sheds light on the benefits of MicroPython for junior developers and its limitations, making it essential listening for anyone interested in modern embedded development.

Jeff and Luca explore the unique hurdles solo embedded developers face, like juggling multiple roles and managing stakeholder demands. They discuss the dangers of skipping documentation and code reviews, highlighting the risks of hidden technical debt. The duo suggest practical strategies such as forming mastermind groups and hiring external reviewers. They emphasize the importance of enforcing self-discipline and embracing ongoing training to sharpen skills, proving that even solo developers can thrive by adopting agile principles.

In this fascinating episode, we dive deep into the world of agile hardware development with Gregor Gross, a civil engineer who runs Alpha-board, a PCB design service company in Berlin, Germany. Gregor shares his unique perspective on applying agile principles to hardware projects, where you can't just hit compile and get a new increment.We explore the practical challenges of agile hardware development, from structuring contracts differently to breaking complex PCBs into testable modules and shields. Gregor discusses the importance of mixed hardware-software teams, the role of automated documentation, and why his engineers resist pair programming despite its proven benefits. The conversation also touches on the cultural barriers to adopting agile practices in traditional hardware companies and the innovative approaches needed to make agile hardware development work in a service provider context.Key Topics[02:30] Introduction to Alpha-board and agile hardware development services[05:15] Defining agile principles: functionality-focused development and prioritization[12:45] Contract challenges: moving from fixed-price to hourly service contracts[18:20] Practical agile hardware: breaking PCBs into testable modules and shields[25:10] Mixed teams and automated documentation for hardware-software collaboration[32:40] The pair programming experiment: better results but team resistance[38:55] Customer expectations and the need for end-user access in agile projects[44:30] Version control and Git integration for hardware design workflowsNotable Quotes"We are probably the only service provider in Germany that offers agile hardware development because I don't see so many people speaking about it." — Gregor Gross"Software is soft, hardware is hard. I was waiting to say that." — Gregor Gross"My experience from pairing was they work harder. They feel like they observe themselves... but there wasn't any mistakes. And actually they themselves said they were surprised by how much they did because they did more than twice what they expected." — Gregor Gross"It's better to have different shields and modules that have some of the functionality. And so you can start iterating through these functionalities and test them." — Gregor GrossResources MentionedAlpha-board - Gregor's PCB design and agile hardware development service companyZephyr OS - Real-time operating system mentioned for prototyping with sample boardsKiCad - Open source EDA tool recommended for mixed teams and transparencyAndrew Greenberg's KiCon Presentation - Presentation on schematic style guides for better readability You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this special crossover episode with the brand-new Embedded AI Podcast, Luca and Jeff are joined by Ryan Torvik, Luca's co-host on the Embedded AI podcast, to explore the intersection of AI-powered development tools and agile embedded systems engineering. The hosts discuss practical strategies for using Large Language Models (LLMs) effectively in embedded development workflows, covering topics like context management, test-driven development with AI, and maintaining code quality standards in safety-critical systems. The conversation addresses common anti-patterns that developers encounter when first adopting LLM-assisted coding, such as "vibe coding" yourself off a cliff by letting the AI generate too much code at once, losing control of architectural decisions, and failing to maintain proper test coverage. The hosts emphasize that while LLMs can dramatically accelerate prototyping and reduce boilerplate coding, they require even more rigorous engineering discipline - not less. They discuss how traditional agile practices like small commits, continuous integration, test-driven development, and frequent context resets become even more critical when working with AI tools. For embedded systems engineers working in safety-critical domains like medical devices, automotive, and aerospace, the episode provides valuable guidance on integrating AI tools while maintaining deterministic quality processes. The hosts stress that LLMs should augment, not replace, static analysis tools and human code reviews, and that developers remain fully responsible for AI-generated code. Whether you're just starting with AI-assisted development or looking to refine your approach, this episode offers actionable insights for leveraging LLMs effectively while keeping the reins firmly in hand. ## Key Topics * [03:45] LLM Interface Options: Web, CLI, and IDE Plugins - Choosing the Right Tool for Your Workflow* [08:30] Prompt Engineering Fundamentals: Being Specific and Iterative with LLMs* [12:15] Building Effective Base Prompts: Learning from Experience vs. Starting from Templates* [16:40] Context Window Management: Avoiding Information Overload and Hallucinations* [22:10] Understanding LLM Context: Files, Prompts, and Conversation History* [26:50] The Nature of Hallucinations: Why LLMs Always Generate, Never Judge* [29:20] Test-Driven Development with AI: More Critical Than Ever* [35:45] Avoiding 'Vibe Coding' Disasters: The Importance of Small, Testable Increments* [42:30] Requirements Engineering in the AI Era: Becoming More Specific About What You Want* [48:15] Extreme Programming Principles Applied to LLM Development: Small Steps and Frequent Commits* [52:40] Context Reset Strategies: When and How to Start Fresh Sessions* [56:20] The V-Model Approach: Breaking Down Problems into Manageable LLM-Sized Chunks* [01:01:10] AI in Safety-Critical Systems: Augmenting, Not Replacing, Deterministic Tools* [01:06:45] Code Review in the AI Age: Maintaining Standards Despite Faster Iteration* [01:12:30] Prototyping vs. Production Code: The Superpower and the Danger* [01:16:50] Shifting Left with AI: Empowering Product Owners and Accelerating Feedback Loops* [01:19:40] Bootstrapping New Technologies: From Zero to One in Minutes Instead of Weeks* [01:23:15] Advice for Junior Engineers: Building Intuition in the Age of AI-Assisted Development ## Notable Quotes > "All of us are new to this experience. Nobody went to school back in the 80s and has been doing this for 40 years. We're all just running around, bumping into things and seeing what works for us." — Ryan Torvik > "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 Ingianni > "Tests tell you how this is supposed to work. You can have it write the test first and then evaluate the test. Using tests helps communicate - just like you would to another person - no, it needs to function like this, it needs to have this functionality and behave in this way." — Ryan Torvik > "I find myself being even more aggressively biased towards test-driven development. While I'm reasonably lenient about the code that the LLM writes, I am very pedantic about the tests that I'm using. I will very thoroughly review them and really tweak them until they have the level of detail that I'm interested in." — Luca Ingianni > "It's really forcing me to be a better engineer by using the LLM. You have to go and do that system level understanding of the problem space before you actually ask the LLM to do something. This is what responsible people have been saying - this is how you do engineering." — Ryan Torvik > "I can use LLMs to jumpstart me or bootstrap me from zero to one. 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. Getting from that zero to one is now not days or weeks of learning - it's 20 minutes of playing with it." — Jeff Gable > "LLMs are fantastic at small-scale stuff. They will be wonderful at finding better alternatives for how to implement a certain function. But they are absolutely atrocious at large-scale stuff. They will gleefully mess up your architecture and not even notice because they cannot fit it into their tiny electronic brains." — Luca Ingianni > "Don't be afraid to try it out. We're all noobs to this. This is the brave noob world of AI exploration. Be curious about it, but also be cautious about it. Don't ever take your hands off the reins. Trust your engineering intuition - even young folks that are just starting, trust your engineering intuition." — Ryan Torvik > "As the saying goes, good judgment comes from experience. Experience comes from bad judgment. You'll find spectacular ways of messing up - that is how you become a decent engineer. LLMs do not change that. Junior engineers will still be necessary, will still be around, and they will still evolve into senior engineers eventually after they've fallen on their faces enough times." — Luca Ingianni  You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this episode, Jeff interviews Luca about his intensive experience presenting at five conferences in two and a half days, including the Embedded Online Conference and a German conference where he delivered a keynote on AI-enhanced software development. Luca shares practical insights from running an LLM-only hackathon where participants were prohibited from manually writing any code that entered version control—forcing them to rely entirely on AI tools.The conversation explores technical challenges in AI-assisted embedded development, particularly the importance of context management when working with LLMs. Luca reveals that effective AI-assisted coding requires treating prompts like code itself—version controlling them, refining them iteratively, and building project-specific prompt libraries. He discusses the economics of LLM-based development (approximately one cent per line of code), the dramatic tightening of feedback loops from days to minutes, and how this fundamentally changes agile workflows for embedded teams.The episode concludes with a discussion about the evolving role of embedded developers—from code writers to AI supervisors and eventually to product owners with deep technical skills. Luca and Jeff address concerns about maintaining core software engineering competencies while embracing these powerful new tools, emphasizing that understanding the craft remains essential even as the tools evolve.Key Topics[02:15] LLM-only hackathon constraints: No human-written code in version control[04:30] Context management as the critical skill for effective LLM-assisted development[08:45] Explicit context control: Files, directories, API documentation, and web content integration[11:20] LLM hallucinations: When AI invents file contents and generates diffs against phantom code[13:00] Economics of AI-assisted coding: Approximately $0.01 per line of code[15:30] Tightening feedback loops: From day-long iterations to minutes in agile embedded workflows[17:45] Rapid technical debt accumulation: How LLMs can create problems faster than humans notice[19:30] The essential role of comprehensive testing in AI-assisted development workflows[22:00] Challenges with TDD and LLMs: Getting AI to take small steps and wait for feedback[26:15] Treating prompts like code: Version control, libraries, and project-specific prompt management[29:40] External context management: Coding style guides, plan files, and todo.txt workflows[32:00] LLM attention patterns: Beginning and end of context receive more focus than middle content[34:30] The evolving developer role: From coder to prompt engineer to AI supervisor to technical product owner[38:00] Code wireframing: Rapid prototyping for embedded systems using AI-generated implementations[40:15] Maintaining software engineering skills in the age of AI: The importance of manual practice[43:00] Software engineering vs. software carpentry: Architecture and goals over syntax and implementationNotable Quotes"One of the hardest things to get an LLM to do is nothing. Sometimes I just want to brainstorm with it and say, let's look at the code base, let's figure out how we're going to tackle this next piece of functionality. And then it says, 'Yeah, I think we should do it like this. You know what? I'm going to do it right now.' And it's so terrible. Stop. You didn't even wait for me to weigh in." — Luca Ingianni"LLMs making everything faster also means they can create technical debt at a spectacular rate. And it gets a little worse because if you're not paying close attention and if you're not disciplined, then it kind of passes you by at first. It generates code and the code kind of looks fine. And you say, yeah, let's keep going. And then you notice that actually it's quite terrible." — Luca Ingianni"I would not trust myself to review an LLM's code and be able to spot all of the little subtleties that it gets wrong. But if I at least have tests that express my goals and maybe also my worries in terms of robustness, then I can feel a lot safer to iterate very quickly within those guardrails." — Luca Ingianni"Roughly speaking, the way I was using the tool, I was spending about a cent per line. Which is about two orders of magnitude below what a human programmer roughly costs. It really is a fraction. So that's nice because it makes certain things approachable. It changes certain build versus buy decisions." — Luca Ingianni"You can tighten your feedback loops to an absurd degree. Maybe before, if you had a really tight feedback loop between a product owner and a developer, it was maybe a day long. And now it can be minutes or quarters of an hour. It is so much faster. And that's not just a quantitative step. It's also a qualitative step." — Luca Ingianni"Some of my best performing prompts came from a place of desperation where one of my prompts is literally 'wait wait wait you didn't do what we agreed you would do you did not read the files carefully.' And I'd like to use this prompt now, even before it did something wrong. And then it apologizes as the first step. And I feel terrible because I hurt the LLM's feelings. But it is very effective." — Luca Ingianni"As you tighten your feedback loops, quality must be maintained through code review and tests. Test first, new feature, review, passing tests—you need to go through that red-green-refactor loop. You can just hopefully do it much more quickly, and maybe in slightly bigger steps than you did before manually." — Jeff Gable"A lot of what I'm doing is really intended to rein in an LLM's propensity to sort of ramble. It's very hard to get them to practice TDD because you can ask them to write the test first, then they will. And then they will just trample on and write the implementation right with it without stopping and returning control back to you." — Luca Ingianni"Those prompts tend to be to some degree specific to the particular code base or the particular problem domain. Every now and then you stumble across ways of making an LLM do exactly what you want it to do within the context of the particular code base. And once you find a nugget like this, you keep it. You don't just keep it in the generic library. Some of those tricks will be very specific to a particular code base." — Luca Ingianni"Just like humans, LLMs tend to pay more attention to the stuff at the beginning of the context and at the end, and the middle sort of gets not quite forgotten but kind of fuzzy. You really need to have a way to extract all of that before it becomes fuzzy and store it in a safe place where it can't be damaged, like a file." — Luca Ingianni"I think we will hit this weird valley in the coming five years where everyone's just using LLMs and no one knows how to write code anymore. And there will be a need for people who can leverage the tools, but still have the skills that serve as the solid foundation." — Jeff Gable"Maybe this is essentially software engineering finally becoming true to its name. At the moment, software engineering is sort of more like software carpentry. You're really doing the craft. You're laboring to put the curly brackets at the right places. And maybe now it's more about taking a step back and thinking in terms of architecture, and thinking in terms of goals, as opposed to knowing how to swing a hammer." — Luca IngianniResources MentionedEmbedded Online Conference - Premier online conference for embedded systems professionals featuring talks on AI integration, development practices, and cutting-edge embedded technologies. All sessions are recorded and available for on-demand viewing.Aider - AI pair programming tool mentioned for its ability to integrate web content into context using commands like '/web [URL]' to incorporate API documentation and other online resources directly into the development workflow.GitHub Copilot - AI-powered code completion tool integrated with VS Code and other IDEs, enabling context-aware code generation and assistance for embedded development workflows. You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/  

In this comprehensive episode, Luka Mustafa, founder and CEO of Irnas Product Development, provides an in-depth exploration of Zephyr RTOS and its transformative impact on embedded development. We dive deep into how Zephyr's Linux Foundation-backed ecosystem enables hardware-agnostic development, dramatically reducing the time spent on foundational code versus business-value features. Luka shares practical insights from five years of specializing in Zephyr development, demonstrating how projects can achieve remarkable portability - including running the same Bluetooth code on different chip architectures in just an hour, and even executing embedded applications natively on Linux for development purposes.The discussion covers Zephyr's comprehensive testing framework (Twister), CI/CD integration capabilities, and the cultural shift required when moving from traditional bare-metal development to this modern RTOS approach. We explore real-world applications from low-power IoT devices consuming just 5 microamps to complex multi-core systems, while addressing the learning curve challenges and when Zephyr might not be the right choice. This episode is essential listening for embedded teams considering modernizing their development practices and leveraging community-driven software ecosystems.Key Topics[03:15] Zephyr RTOS fundamentals and Linux Foundation ecosystem benefits[08:30] Hardware abstraction and device tree implementation for portable embedded code[12:45] Nordic Semiconductor strategic partnership and silicon vendor support landscape[18:20] Native POSIX development capabilities and cross-platform debugging strategies[25:10] Learning curve challenges: EE vs CS background adaptation to Zephyr development[32:40] Resource requirements and low-power implementation on constrained microcontrollers[38:15] Multi-vendor chip support: STMicroelectronics, NXP, and industry adoption trends[42:30] Safety-critical applications and ongoing certification processes[45:50] Organizational transformation strategies and cultural adaptation challenges[52:20] Zbus inter-process communication and modular development architecture[58:45] Twister testing framework and comprehensive CI/CD pipeline integration[65:30] Sample-driven development methodology and long-lived characterization tests[72:15] Production testing automation and shell interface utilization[78:40] Model-based development integration and requirements traceability[82:10] When not to use Zephyr: Arduino simplicity vs RTOS complexity trade-offsNotable Quotes"With Zephyr, porting a Bluetooth project from one chip architecture to another took an hour for an intern, compared to what would traditionally be months of effort." — Luka Mustafa"How many times have you written a logging subsystem? If the answer is more than zero, then it shouldn't be the case. Someone needs to write it once, and every three years someone needs to rewrite it with a better idea." — Luka Mustafa"The real benefit comes from doing things the Zephyr way in Zephyr, because then you are adopting all of the best practices of developing the code, using all of the subsystems to the maximum extent." — Luka Mustafa"You want to make sure your team is spending time on things that make money for you, not on writing logging, for example." — Luka MustafaZephyr Project - Linux Foundation-backed RTOS project providing comprehensive embedded development ecosystemTwister Testing Framework - Zephyr's built-in testing framework for unit tests, hardware-in-the-loop, and CI/CD integrationZbus Inter-Process Communication - Advanced event bus system for modular embedded development and component decouplingiirnas - Open-source examples of Zephyr best practices and CI/CD pipeline implementationsCarles Cufi's Talk - Detailed presentation on Nordic's strategic decision to support Zephyr RTOS You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer.Want to join the agile Embedded Slack? Click hereAre you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/