Show Notes
What if vibe coding is the worst thing you could do with AI agents? The developers seeing the biggest gains aren’t prompting harder. They’re planning smarter, spec-first, and treating AI as a facilitator rather than a code generation engine. In this episode, Brian Madison, creator of the BMad Method, shares how a year of late-night AI experiments led him to a structured, Agile-inspired approach to building software with AI agents. Brian explains why jumping straight into agent mode without upfront planning (what most people call vibe coding) reliably hits a wall, and how a disciplined spec-first workflow breaks through that ceiling. He walks through the BMad Method’s core workflow: brainstorming, PRD, architecture, UX design, and context-rich user stories, each feeding into the next so the agent always has exactly what it needs. Brian also recounts a transformative two-week sprint he ran with his team where engineers were given permission to fail, and how that single experiment changed the way his entire organisation works with AI. Finally, he reflects on what this shift means for the future of software engineering — where the unit of work is moving from tasks and stories to full features and epics, and every engineer can operate more like a tech lead. Key topics discussed: Why vibe coding hits a wall and how spec-driven dev fixes it Using AI as a facilitator, not just a code generator The BMad Method: PRD → architecture → context-rich stories How a 2-week “no typing” sprint transformed his engineering team Giving teams permission to fail as a leadership tool The shift from user stories to epics as the unit of work Why problem decomposition is engineers’ biggest AI superpower Timestamps: (00:00:00) Trailer & Intro (00:02:44) How Did the US Army Shape Brian’s Journey into Software Engineering? (00:06:35) How Can Engineers Overcome Imposter Syndrome and Build Self-Confidence? (00:10:23) What Does BMad Actually Stand For? (00:13:49) What Is the BMad Method? (00:22:11) How Does BMad Approach Context and Spec Engineering? (00:29:02) What Sparked the Creation of the BMad Method? (00:44:55) What Productivity Gains Has the BMad Method Produced? (00:48:36) How Will AI Change the Unit of Work for Software Engineers? (00:55:51) How Does BMad Keep Specs and Code in Sync Over Time? (01:01:01) What Is the Best Way to Get Started with the BMad Workflow? (01:05:00) Which AI Models and Tools Does the BMad Method Support? (01:08:21) 4 Tech Lead Wisdom _____ Brian Madison’s Bio Brian Madison is the creator of the BMad Method, an open-source framework that treats AI as a facilitator for workflows across any domain—software development, product management, operations, and beyond. Used globally, the BMad Method helps people work through complex processes using AI personas, from engineers driving spec-driven development to product managers crafting better PRDs and requirements. Currently a Senior Engineering Manager at Extend, Brian led product engineering teams toward becoming an AI-native organization and now leads the entire AI SDLC transformation for the company, using the BMad Method as a framework, reimagining how AI flows through the full software development lifecycle. Brian’s approach to leadership was forged during his service in the U.S. Army, where he learned the values of servant leadership, discipline, and mission-first execution. Follow Brian: LinkedIn – linkedin.com/in/bmadcode BMad Website – bmadcode.com Docs – docs.bmad-method.org GitHub – github.com/bmad-code-org/BMAD-METHOD Discord – discord.gg/gk8jAdXWmj YouTube – youtube.com/@BMadCode X – x.com/BMadCode Facebook – facebook.com/@BMadCode
Like this episode? Show notes & transcript: techleadjournal.dev/episodes/255. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Buy me a coffee or become a patron.
More from Tech Lead Journal
Why do the best developers often make the worst software architects? The skills that make someone a hero developer can become the habits that hold their team back once they move into architecture. In this episode, Lee Atchison, software architect and author of “The Software Conductor”, explains what changes when you move from writing code to leading through other people. He shares why he rewrote his book three times before settling on a story format, and how the orchestra conductor analogy captures the architect’s role. Lee walks through the four ways architects fail in hero mode, the five questions a conductor asks that architects can use to spot problems early, and why most system failures are really broken connections between people. He also explains why architects should act as mentors who remove obstacles and offer a test for whether you taught or just decided. Finally, he shares his view on AI, why judgment matters more than any particular role, and why he expects the dark factory trend to fade. Key topics discussed: Why the hero developer mindset fails in architecture roles The four ways architects fail when they stay in hero mode Five conductor questions that expose problems before they break Why most system failures are really broken team connections A simple test: can the decision be made without you? Why architects work with sand, not big rocks Why judgment matters more than role titles in the AI era Why AI-native apps should embrace non-determinism Timestamps: (00:00) Trailer & Intro (02:53) What Is the Story Behind Writing “The Software Conductor”? (06:22) Why Do Promoted Heroes Struggle as Software Architects? (10:52) What Does a Fractional Software Architect Actually Do? (12:29) Is Software Architecture an IC or Management Path? (16:08) Do You Need to Know Everything to Lead with Influence? (18:08) What Are the Four Ways Architects Fail in Hero Mode? (21:06) What Five Questions Help Architects Spot Problems Before They Break? (25:57) Why Is Empathy at Scale a Crucial Skill for Software Architects? (29:34) Why Should Software Architects Act as Mentors Rather Than Dictators? (33:49) How Do Architects Manage Constant Context Switching? (37:37) Why Was AI Excluded from “The Software Conductor” Book? (40:24) Does AI Really Turn Every Software Developer into a Tech Lead? (44:34) Is AI Policy and Governance Part of the Software Architect Role? (48:41) What Are the Dangers of the AI Dark Factory Trend? (53:23) What Are the Most Important Aspects of Being an AI-Native Team? (57:52) 3 Tech Lead Wisdom _____ Lee Atchison’s Bio Lee Atchison is a software architect, author, and speaker focused on cloud computing, scalable system design, and the developer-to-architect transition. He is the author of Architecting for Scale (O’Reilly), Overcoming IT Complexity (O’Reilly), and The Software Conductor, and the creator of courses for O’Reilly Media and LinkedIn Learning. He writes the Software Architecture Insights newsletter and guest hosts on Software Engineering Daily. With three decades in the industry, including seven years at Amazon and AWS and eight at New Relic, Lee has worked with engineering teams at Nike, Disney, Starbucks, MLB, and Bank of America, and presented at AWS re:Invent and similar conferences. He works with organizations through his practice, Atchison Technology, and most recently served as CTO at Product Genius. Follow Lee: LinkedIn – linkedin.com/in/leeatchison The Software Conductor – thesoftwareconductor.com Software Architecture Insights – softwarearchitectureinsights.com Personal Website – leeatchison.com
Why can’t you “move fast and break things” in a factory? Because a small software bug doesn’t just crash an app, it can shut down a plant the size of a small city. David and Willem explain the hidden world of operational technology, where safety always comes before speed. In this episode, David Ariens and Willem van Lammeren, co-authors of “The IT/OT Handbook” and hosts of the IT/OT Insider podcast, break down the divide between IT and OT, information technology and operational technology, and why closing it matters more than ever as manufacturing digitalizes. They explain why OT prioritizes safety and integrity over confidentiality and share a war story where a single form change in China left hundreds of trucks stranded outside a factory. David and Willem walk through the seven cooperation patterns from their book, from “good shadow IT” to facilitation, project teams, and full product teams, and explain why breaking down silos too early can backfire. They also discuss why factories still run Windows XP decades past the end of life, why generative AI’s impact on manufacturing will be slower and different from software, and why the real shortage in this industry isn’t AI, it’s automation engineers. Timestamps: (00:00:00) Trailer & Intro (00:02:42) What Is the Story Behind the Book and the Podcast? (00:06:31) What Is the Main Difference Between IT and OT? (00:11:58) Are Software Developer Skill Sets Interchangeable Between IT and Operations? (00:15:23) How Did The Phoenix Project and Team Topologies Inspire IT/OT Cooperation Patterns? (00:22:41) What Are Some Industry War Stories That Highlight the Challenges Between IT and OT? (00:30:57) What Collaboration Patterns Can Help Resolve Tension Between IT and OT? (00:39:43) Is Tesla the Ultimate Reference Model for Modern Product Teams? (00:42:41) How Can OT Teams Adopt CI/CD Through a Data Platform Abstraction Layer? (00:44:37) What Will Be the Real Impact of AI on Operational Technology? (00:51:54) What Is Driving the Shortage of Automation Engineers in Operations? (00:54:51) Are Humanoid Robots Overhyped for Manufacturing? (01:01:52) 3 Tech Lead Wisdom _____ David Ariens’s Bio David Ariens is a mathematical engineer, co-founder of The IT/OT Insider and The IT/OT Handbook. Previously the Industrial Digitalization Director at BASF Antwerp and former manager of Analytics For Industry, David focuses on industrial cybersecurity, data platforms, and bridging IT and OT through human-centric digital transformation. Willem van Lammeren’s Bio Willem van Lammeren is a chemical engineer, co-founder of The IT/OT Insider and The IT/OT Handbook. He serves as Tech Lead for Industrial IT at Syensqo (formerly Solvay) with extensive experience spanning Barry Callebaut and BASF, focusing on industrial digitalization and operational data architectures. Follow: David’s LinkedIn – linkedin.com/in/davidariens Willem’s LinkedIn – linkedin.com/in/willemvanlammeren The IT/OT Handbook – https://itrevolution.com/product/itot-handbook/ The IT/OT Insider – itotinsider.com
What’s the one rule that matters most when AI writes most of your code? Emilie says it comes down to a single line: don’t outsource your thinking. In this episode, Emilie Schario, co-founder of Kilo Code, unpacks what it actually means to lead in a world where AI can write most of your code. She explains why Kilo went all-in on being model agnostic, supporting over 500 models instead of betting on a single lab. Emilie shares her core rule for using AI responsibly: never outsource your thinking, especially when it comes to auth, billing, or security. She introduces a metric more companies should be tracking, spend per merged pull request, as a better signal of value than raw AI cost. Emilie also talks about the “killing problem” that comes with software becoming nearly free to ship, and why teams now discover product-market fit after shipping rather than before. She closes with how engineers are shifting from producers to reviewers, and what that means for anyone now managing a team of AI agents instead of just their own code. Key topics discussed: Why Kilo Code refuses to bet on a single AI model The one rule for not losing control to AI agents A better way to measure AI spend: cost per merged PR Why shipping software is nearly free, and why that’s risky How AI-native teams find product-market fit after shipping Why senior engineers adapt to AI agents the fastest Building a council of reviewers for high-risk code changes What the Anaconda acquisition means for Kilo Code Timestamps: (00:00) Trailer & Intro (02:27) What Is Kilo Code All About? (03:31) How Do You Avoid Getting Overwhelmed by 500 Plus AI Models? (04:34) How Does a Multi-Platform Approach Benefit Developers? (07:19) How Does Kilo’s Agent Harness Differ From Other Tools? (09:51) Why Will Model Choice Matter Less Over Time? (11:20) What Tools Help You Pick the Right Model for Each Task? (14:16) What Does the Anaconda Acquisition Mean for Kilo Code? (15:43) Why Should You Measure AI Spend Per Merged Pull Request? (18:54) How Do You Balance Speed and Control in AI Development? (20:28) Why Should Companies Treat AI as Operational Infrastructure? (23:31) How Do AI-Native Organizations Run Their Day-to-Day Workflows? (27:58) How Will High-Performing AI Organizations Differentiate Themselves in the Future? (30:11) What Is the “Killing Problem” Now That Shipping Software Is Free? (32:40) How Do You Shift to a Metrics-First Mindset? (34:24) How Is the Product Manager’s Role Changing in AI-Native Teams? (37:06) How Do You Balance Rapid Feature Delivery With Product Quality? (41:48) How Is the Software Engineer’s Role Evolving in the Age of AI? (43:57) What Is the Best Advice for Junior Engineers Entering an AI-Native World? (45:51) How Can Developers Handle the Cognitive Load of Code Reviews? (49:11) How Should Docs and Code Attribution Evolve With AI Agents? (53:06) How Can AI Improve Your Life Outside of Work? (55:04) 3 Tech Lead Wisdom _____ Emilie Schario’s Bio Emilie is VP, Engineering at Anaconda and the former cofounder of Kilo (acquired by Anaconda), where she focuses on turning AI investment into real engineering output. She operates at the intersection of AI tooling, engineering org design, and the day-to-day realities of running high-performing teams, helping organizations translate innovation into measurable impact. Follow Emilie: LinkedIn – linkedin.com/in/emilieschario Playbooks and Priority newsletter – emilie.substack.com Kilo Code – kilo.ai/
If you’re not using AI five times an hour, you’re already behind, says the man who built the first AI assistant back in 1998. Kevin explains why that pace is now the baseline, not the exception, for developers who want to stay employed. In this episode, Kevin Surace, the inventor of the first AI assistant and CEO of Appvance, joins to unpack six decades of AI evolution, from hidden Markov models to the LLM breakthroughs now powering coding agents. Kevin shares how his work at General Magic became the licensed technology behind Siri and Alexa, and how he ended up inventing post-training before anyone had a name for it. He explains why the only developers losing their jobs are the ones refusing to adopt AI, and how the role is shifting from writing code to specifying, coordinating, and testing it across a fleet of agents. Kevin also introduces AI Script Generation Bug Hunter, the testing technology uncovering thousands of bugs humans never catch. The conversation closes with his new book, Joy-Success Cycle, and why he believes joy has to come before success, not after. Timestamps: (00:00) Trailer & Intro (02:27) How Did Kevin Become the Father of AI Assistant? (07:45) How Did AI Evolve From Hidden Markov Models to the LLM Breakthrough? (11:51) How Were Siri and Alexa Built on Kevin’s Licensed AI Technology? (14:25) How Should Software Developers Evolve in the Age of AI? (20:39) Should Developers Fear the Rise of Agentic AI? (25:25) How Does Appvance Use AI to Find Bugs Humans Miss? (32:18) Why Did Kevin Write the Book Joy-Success Cycle? (38:20) How Can We Reclaim Positive Emotions Amid Global Crises and AI Anxiety? (46:44) How Do Purpose and Curiosity Work Together to Guide Your Life? (48:49) How Can a Simple To-Do List Become a Powerful Source of Joy? (50:20) How Did the Joy-Success Method Transform a Sales Team’s Attitude? (52:52) 3 Tech Lead Wisdom _____ Kevin Surace’s Bio Kevin Surace is an AI pioneer and human effectiveness authority helping people thrive while AI reshapes how we work and live. Widely recognized as the father of the virtual assistant, he holds 95 worldwide patents and has been named INC Magazine’s Entrepreneur of the Year, a CNBC Top Innovator of the Decade, and a World Economic Forum Tech Pioneer. He is the author of The Joy-Success Cycle, a practical framework for sustained human effectiveness during rapid change. Follow Kevin: LinkedIn – linkedin.com/in/ksurace Personal Website - kevinsurace.com The Joy-Success Cycle – joysuccesscycle.com
Does moving faster with AI mean you get to skip the laws that governed every software project before it? Milan Milanovic argues the opposite, the old laws of software engineering now apply twice as hard. In this episode, Milan Milanovic, CTO and author of Laws of Software Engineering, returns to unpack why the laws that have quietly governed software projects for decades are more relevant than ever in the AI era. He walks through Gall’s Law and why AI lets teams generate complex systems on unvalidated assumptions faster than ever, Conway’s Law and how it now runs twice, shaping both human organizations and agent topologies, and Goodhart’s Law and the trap of “tokenmaxxing” as a metric. Milan also covers Hofstadter’s Law and the 90-90 rule, explaining why the last 10% of a project still takes as long with AI in the loop, and the Dunning-Kruger effect, where vibe coders overestimate their skills while senior engineers underestimate theirs. The conversation closes with his advice for juniors entering the field, his top five must-read books, and how he personally uses AI for research and planning rather than implementation. Key topics discussed: Gall’s Law: the trap of generating complex systems with AI Conway’s Law now runs twice, on humans and on AI agent topology Why software architects should help design your org chart Goodhart’s Law and the danger of “tokenmaxxing” as a metric The 90-90 rule: why AI’s last 10% still costs half the project Dunning-Kruger effect on vibe coders and experts Why less code beats more, even with AI writing it for free Timestamps: (00:00) Trailer & Intro (03:02) What Inspired Milan to Write Laws of Software Engineering? (05:32) How Did a Book on Software Laws Reach Such a Global Audience? (06:49) How Should You Read the Laws of Software Engineering Book? (08:51) Why Does the Book Cover People and Planning, Not Just Technical Laws? (11:07) What Is Gall’s Law in Software Engineering? (14:46) How Can You Apply Gall’s Law When Using AI? (17:34) What Is Conway’s Law in Software Engineering? (19:34) How Should Big Corporations Build New Products Without Structural Reorganization? (21:26) How Does Conway’s Law Apply to Small AI-Powered Product Teams? (23:25) What Is Goodhart’s Law in Software Engineering? (25:52) What Are the Best Examples of Counterbalance Metrics for Leaders Today? (28:06) What Kind of Outcomes Should You Actually Measure? (31:01) What Is Hofstadter’s Law in Software Engineering? (33:35) How Does Hofstadter’s Law Apply in the Age of AI? (36:41) What Is the Dunning-Kruger Effect? (40:10) How Does the Dunning-Kruger Effect Apply to Experienced Engineers Learning AI? (42:46) Are Any of These Laws Becoming Less Relevant Because of AI? (44:32) What Does the Lindy Effect Say About the Fate of Software Developers? (47:49) What Is the Best Career Advice for Junior Developers Entering the AI Landscape? (50:34) What Are the Top Five Must-Read Books for Software Engineers? (55:46) How Can Software Engineers Apply These Laws in Their Daily Work? (57:26) 3 Tech Lead Wisdom _____ Milan Milanovic’s Bio Milan Milanović is the CTO and the author of Laws of Software Engineering. He holds a PhD in Computer Science, has more than 20 years of experience across .NET, Azure, and mobile development, and is a Microsoft MVP. He runs Tech World With Milan, a software engineering newsletter and community followed by more than 400,000 engineers. He writes about architecture, engineering leadership, and how AI is changing the way software gets built. Follow Milan: LinkedIn – linkedin.com/in/milanmilanovic Twitter / X – @milan_milanovic Personal website – milan.milanovic.org Book’s website - lawsofsoftwareengineering.com Newsletter - newsletter.techworld-with-milan.com