Is test-driven development still relevant when AI can generate thousands of lines of code from a prompt? Ryan argues TDD was designed for human limitations -- if AI can generate complete systems, why write tests first? Luca pushes back: tests are your only defense against AI assumptions. Five lines of prompt becoming 10,000 lines of code means 9,995 lines of hidden assumptions that need to be made explicit and verifiable.

Luca presents a systematic approach: start with test ideas (behaviors to verify), progress to test outlines (properties and steps in comments), then implement test code before letting AI write production code. This isn't about micromanaging class hierarchies -- it's about maintaining engineering responsibility. TDD becomes even more crucial in the AI era: it's how you communicate intent, capture assumptions, and keep AI-generated code on track.

Key Topics:

• [02:30] Is TDD obsolete in the age of AI?
• [05:45] Ryan's argument: TDD was designed for human limitations
• [08:20] Tests as defense against AI assumptions and 'success theater'
• [12:15] Hidden assumptions: 5 lines of prompt becoming 10,000 lines of code
• [16:40] Agentic AI coding and the Swiss cheese model of reliability
• [21:30] Systematic approach: Test ideas, test outlines, test implementation
• [28:45] Spec-driven development (SDD) and PRDs in AI-assisted coding
• [35:20] Unit tests vs. BDD in the AI context
• [42:10] Why you shouldn't fight the AI over class hierarchies
• [48:30] Weekend projects that become production systems
• [52:45] Building features in an unfamiliar language (Kotlin) using TDD

Notable Quotes:

"The AI writing tests for me is the last thing that I want, because that is my only line of defense against the AI doing stupid things." -- Luca Ingianni

"To go from five lines of prompt to 10,000 lines of code means there are 9,995 lines worth of assumptions in there. And sometimes they are correct and sometimes they are not." -- Luca Ingianni

"The problem is that weekend projects turn into airplanes. Prototypes always live on." -- Ryan Torvik

"You are responsible for this code no matter whether you type the curly brackets or the LLM." -- Luca Ingianni

Resources Mentioned:

• Spec-driven Development (SDD) -- systematic AI-assisted development with three layers: requirements, plan, and tasks
• Behavior-Driven Development (BDD) -- system-level testing through executable specifications (Gherkin language)
• Unciv -- open-source Civilization clone in Kotlin, used as example project for TDD with AI
• Agile Embedded Podcast -- Luca's podcast on agile practices and TDD in embedded systems

In this episode, Ryan and Luca sit down with Darwin Sanoy from GitLab to explore the intersection of systems engineering, embedded development, and AI. Darwin brings a wealth of experience from his work in ISO 26262 certification and MIT Systems Architecture, helping us understand why embedded systems development differs fundamentally from pure software development.

We dig into the core challenge: in embedded systems, software is never the whole product—it's always a part number in a larger physical system. This reality shapes everything from development cycles to how we can apply Agile and DevOps practices. Darwin walks us through the spectrum of embedded systems, from smart machines that benefit from frequent updates to safety-critical systems where the optimal number of software updates is exactly one.

The conversation takes a practical turn as we explore how AI can help with systems engineering challenges, particularly around extracting architecture from legacy codebases and working with model-based systems engineering tools like SysML v2. Darwin shares concrete examples of using AI to generate embedded code from systems models and discusses GitLab's approach to making DevOps more accessible to embedded engineers through AI-powered explanations and context-aware tooling. We also touch on the limitations of current AI—it's great at small scope but struggles with broad architectural understanding, much like asking a new person off the street to understand your entire codebase every single time.

Key Topics:

• [03:15] Why embedded systems development differs from pure software: software as a part number vs. software as the whole product
• [08:45] Three categories of embedded systems: smart machines, stable/boring machines, and safety-critical machines
• [12:30] The role of systems engineering in managing complex physical products and supplier ecosystems
• [18:20] SysML v2 and storing systems engineering models as code for AI accessibility
• [24:10] Generating embedded code from systems engineering models using AI: the flashlight example
• [28:45] The importance of architecture documentation and using AI to extract architecture from legacy code
• [35:50] Limitations of AI: excellent at small scope but struggles with broad architectural understanding
• [42:15] GitLab's approach to embedded DevOps: AI-powered explanations, context-aware tooling, and MCP servers
• [48:30] Practical AI applications: using imperative AI to create declarative code for model validation

Notable Quotes:

"Software as it's talked about in the lean startup and in agile and in DevOps is essentially limited to when software is the whole product. As soon as you get into embedded systems, by definition, the software is embedded into a physical product. Software is always a part number." — Darwin Sanoy

"You are settling into a roller coaster and the operator gets on and says I'm sorry we're going to be an extra 10 minutes while a software update finishes. You're a DevOps pro so you stay seated right? Because you know that releases are only going to improve your experience, right?" — Darwin Sanoy

"AI researchers put up a diagram and said these 169 boxes are roughly the functions that scientists and psychologists agree the human mind has. Next slide: these are the four that AI emulates and it doesn't do a very good job compared to what you do." — Darwin Sanoy

"At least if you ask a human expert 'do you know about this?' they'll say 'yeah I'm not certain, ask somebody else.' AI literally cannot know how solid its knowledge is—it has no concept of vagueness or uncertainty." — Luca Ingianni

In this episode, we sit down with Joe Schneider, founder of Dojo5 and creator of the EmbedOps framework, to explore how AI is transforming embedded development pipelines. We discuss the practical applications of AI in CI/CD workflows—from summarizing build outputs and triaging static analysis results to enabling smarter hardware-in-the-loop testing through visual analysis.

Joe shares his perspective on where AI adds real value: condensing complex data, identifying anomalies, and helping teams move faster without sacrificing quality. We also tackle the challenges: the brittleness of traditional testing approaches, the difficulty of tracking dependencies in embedded systems, and the risks of over-automation. Throughout the conversation, we explore the balance between deterministic tools and AI-assisted workflows, and why human judgment remains essential—especially when it comes to security updates and edge cases that no test script would catch.

Whether you're skeptical about AI hype or curious about practical applications, this episode offers a grounded look at how AI can strengthen your development pipeline without replacing the engineers who build it.

Key Topics:

• [00:00] Introduction: Meet Joe Schneider and the focus on AI in embedded DevOps
• [02:30] The complexity challenge: Why modern embedded development needs better pipelines
• [05:15] Bob's machine and the problem with manual, hero-driven development
• [08:00] What AI is good at: Summarization, classification, and expansion
• [12:45] Exploratory testing: Can AI fish for bugs more effectively than random testing?
• [18:20] Visual analysis in hardware-in-the-loop testing: Using AI to evaluate screens and physical behavior
• [24:00] Walking through the pipeline: Build stage, static analysis, and AI-assisted triage
• [30:15] Compiler flags and configuration: Where AI can help optimize and catch mistakes
• [35:40] PR review automation: AI as a code reviewer—benefits and limitations
• [42:00] Self-healing pipelines: Automatic dependency updates and security patching
• [48:30] The human-in-the-loop debate: When automation goes too far
• [52:15] Hardware testing challenges: From pixel-perfect comparisons to AI-based visual validation
• [58:00] War story: Debugging a silicon bug that only appeared under specific conditions

Notable Quotes:

"In 2025, there are still many companies that build and release firmware from a folder on a share drive somewhere that says V1.2, or it's Bob's machine. Somebody's literally clicking the build button, and that's just very sad." — Joe Schneider

"If your product is destined for a human user, then you need a human to test it at some point in your stack. Humans are not good at following a test script for the 50th time, but they're great at finding the things you didn't think to test for." — Joe Schneider

"AI is very helpful when you have a bunch of different situations and you can ask it: does this fall into this bucket or that bucket? That classification capability can be extremely useful in analyzing what's happening in your system or pipeline." — Luca Ingianni

"I don't trust the scripts that I write. There's still people clicking buttons and mashing screens to make sure that things are working correctly, because we don't even trust the people that were downstream of us doing this work before." — Ryan Torvik

"I think testing a lot like fishing. You don't just drive your boat a random amount in a random direction and drop the line. Fishermen know where the fish are—over in the weeds, under the dock. AI can learn those signals too." — Joe Schneider

Resources Mentioned:

• Dojo5 - Custom firmware development company founded by Joe Schneider
• EmbedOps - Industry-leading embedded development DevOps framework created by Dojo5
• Zephyr RTOS Security Tool - Tool within Zephyr that evaluates compiler flags and security posture—often underutilized
• PC-Lint - Traditional static analysis tool for C/C++, known for verbose output