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