Scrum Master Toolbox Podcast: Agile storytelling from the trenches

AI Assisted Coding: Stop Building Features, Start Building Systems with AI
What separates vibe coding from truly effective AI-assisted development? In this episode, Adam Bilišič shares his framework for mastering AI-augmented coding, walking through five distinct levels that take developers from basic prompting to building autonomous multi-agent systems.
Vibe Coding vs AI-Augmented Coding: A Critical Distinction
"The person who is actually creating the app doesn't have to have in-depth overview or understanding of how the app works in the background. They're essentially a manual tester of their own application, but they don't know how the data structure is, what are the best practices, or the security aspects."
 
Adam draws a clear line between vibe coding and AI-augmented coding. Vibe coding allows non-developers to create functional applications without understanding the underlying architecture—useful for product owners to create visual prototypes or help clients visualize their ideas. 
AI-augmented coding, however, is what professional software engineers need to master: using AI tools while maintaining full understanding of the system's architecture, security implications, and best practices. The key difference is that augmented coding lets you delegate repetitive work while retaining deep knowledge of what's happening under the hood.
From Building Features to Building Systems
"When you start building systems, instead of thinking 'how can I solve this feature,' you are thinking 'how can I create either a skill, command, sub-agent, or other things which these tools offer, to then do this thing consistently again and again without repetition.'"
 
The fundamental mindset shift in AI-augmented coding is moving from feature-level thinking to systems-level thinking. Rather than treating each task as a one-off prompt, experienced practitioners capture their thinking process into reusable recipes. This includes documenting how to refactor specific components, creating templates for common patterns, and building skills that encode your decision-making process. The goal is translating your coding practices into something the AI can repeatedly execute for any new feature.
Context Management: The Critical Skill For Working With AI
"People have this tendency to install everything they see on Reddit. They never check what is then loaded within the context just when they open the coding agent. You can check it, and suddenly you see 40 or 50% of your context is taken just by MCPs, and you didn't do anything yet."
 
One of the most overlooked aspects of AI-assisted coding is context management. Adam reveals that many developers unknowingly fill their context window with MCP (Model Context Protocol) tools they don't need for the current task. The solution is strategic use of sub-agents: when your orchestrator calls a front-end sub-agent, it gets access to Playwright for browser testing, while your backend agent doesn't need that context overhead. Understanding how to allocate context across specialized agents dramatically improves results.
The Five Levels of AI-Augmented Coding
"If you didn't catch up or change your opinion in the last 2-3 years, I would say we are getting to the point where it will be kind of last chance to do so, because the technology is evolving so fast."
 
Adam outlines a progression from beginner to expert:
 
Level 1 - Master of Prompts: Learning to write effective prompts, but constantly repeating context about architecture and preferences

Level 2 - Configuration Expert: Using files like .cursorrules or CLAUDE.md to codify rules the agent should always follow

Level 3 - Context Master: Understanding how to manage context efficiently, using MCPs strategically, creating markdown files for reusable information

Level 4 - Automation Master: Creating custom commands, skills, and sub-agents to automate repetitive workflows

Level 5 - The Orchestrator: Building systems where a main orchestrator delegates to specialized sub-agents, each running in their own context window

The Power of Specialized Sub-Agents
"The sub-agent runs in his own context window, so it's not polluted by whatever the orchestrator was doing. The orchestrator needs to give him enough information so it can do its work."
 
At the highest level, developers create virtual teams of specialized agents. The orchestrator understands which sub-agent to call for front-end work, which for backend, and which for testing. Each agent operates in a clean context, focused on its specific domain. When the tester finds issues, it reports back to the orchestrator, which can spin up the appropriate agent to fix problems. This creates a self-correcting development loop that dramatically increases throughput.
 
In this episode, we refer to the Claude Code subreddit and IndyDevDan's YouTube channel for learning resources.
 
About Adam Bilišič
Adam Bilišič is a former CTO of a Swiss company with over 12 years of professional experience in software development, primarily working with Swiss clients. He is now the CEO of NodeonLabs, where he focuses on building AI-powered solutions and educating companies on how to effectively use AI tools, coding agents, and how to build their own custom agents.
 
You can connect with Adam Bilišič on LinkedIn and learn more at nodeonlabs.com. Download his free guide on the five levels of AI-augmented coding at nodeonlabs.com/ai-trainings/ai-augmented-coding#free-guide.

BONUS: When AI Decisions Go Wrong at Scale—And How to Prevent It
We've spent years asking what AI can do. But the next frontier isn't more capability—it's something far less glamorous and far more dangerous if we get it wrong. In this episode, Ran Aroussi shares why observability, transparency, and governance may be the difference between AI that empowers humans and AI that quietly drifts out of alignment.
The Gap Between Demos and Deployable Systems
"I've noticed that I watched well-designed agents make perfectly reasonable decisions based on their training, but in a context where the decision was catastrophically wrong. And there was really no way of knowing what had happened until the damage was already there."
 
Ran's journey from building algorithmic trading systems to creating MUXI, an open framework for production-ready AI agents, revealed a fundamental truth: the skills needed to build impressive AI demos are completely different from those needed to deploy reliable systems at scale. Coming from the EdTech space where he handled billions of ad impressions daily and over a million concurrent users, Ran brings a perspective shaped by real-world production demands. 
The moment of realization came when he saw that the non-deterministic nature of AI meant that traditional software engineering approaches simply don't apply. While traditional bugs are reproducible, AI systems can produce different results from identical inputs—and that changes everything about how we need to approach deployment.
Why Leaders Misunderstand Production AI
"When you chat with ChatGPT, you go there and it pretty much works all the time for you. But when you deploy a system in production, you have users with unimaginable different use cases, different problems, and different ways of phrasing themselves."
 
The biggest misconception leaders have is assuming that because AI works well in their personal testing, it will work equally well at scale. When you test AI with your own biases and limited imagination for scenarios, you're essentially seeing a curated experience. 
Real users bring infinite variation: non-native English speakers constructing sentences differently, unexpected use cases, and edge cases no one anticipated. The input space for AI systems is practically infinite because it's language-based, making comprehensive testing impossible.
Multi-Layered Protection for Production AI
"You have to put in deterministic filters between the AI and what you get back to the user."
 
Ran outlines a comprehensive approach to protecting AI systems in production:
 
Model version locking: Just as you wouldn't randomly upgrade Python versions without testing, lock your AI model versions to ensure consistent behavior

Guardrails in prompts: Set clear boundaries about what the AI should never do or share

Deterministic filters: Language firewalls that catch personal information, harmful content, or unexpected outputs before they reach users

Comprehensive logging: Detailed traces of every decision, tool call, and data flow for debugging and pattern detection

 
The key insight is that these layers must work together—no single approach provides sufficient protection for production systems.
Observability in Agentic Workflows
"With agentic AI, you have decision-making, task decomposition, tools that it decided to call, and what data to pass to them. So there's a lot of things that you should at least be able to trace back."
 
Observability for agentic systems is fundamentally different from traditional LLM observability. When a user asks "What do I have to do today?", the system must determine who is asking, which tools are relevant to their role, what their preferences are, and how to format the response. 
Each user triggers a completely different dynamic workflow. Ran emphasizes the need for multi-layered access to observability data: engineers need full debugging access with appropriate security clearances, while managers need topic-level views without personal information. The goal is building a knowledge graph of interactions that allows pattern detection and continuous improvement.
Governance as Human-AI Partnership
"Governance isn't about control—it's about keeping people in the loop so AI amplifies, not replaces, human judgment."
 
The most powerful reframing in this conversation is viewing governance not as red tape but as a partnership model. Some actions—like answering support tickets—can be fully automated with occasional human review. Others—like approving million-dollar financial transfers—require human confirmation before execution. The key is designing systems where AI can do the preparation work while humans retain decision authority at critical checkpoints. This mirrors how we build trust with human colleagues: through repeated successful interactions over time, gradually expanding autonomy as confidence grows.
Building Trust Through Incremental Autonomy
"Working with AI is like working with a new colleague that will back you up during your vacation. You probably don't know this person for a month. You probably know them for years. The first time you went on vacation, they had 10 calls with you, and then slowly it got to 'I'm only gonna call you if it's really urgent.'"
 
The path to trusting AI systems mirrors how we build trust with human colleagues. You don't immediately hand over complete control—you start with frequent check-ins, observe performance, and gradually expand autonomy as confidence builds. This means starting with heavy human-in-the-loop interaction and systematically reducing oversight as the system proves reliable. The goal is reaching a state where you can confidently say "you don't have to ask permission before you do X, but I still want to approve every Y."
 
In this episode, we refer to Thinking in Systems by Donella Meadows, Designing Machine Learning Systems by Chip Huyen, and Build a Large Language Model (From Scratch) by Sebastian Raschka.
 
About Ran Aroussi
Ran Aroussi is the founder of MUXI, an open framework for production-ready AI agents. He is also the co-creator of yfinance (with 10 million downloads monthly) and founder of Tradologics and Automaze. Ran is the author of the forthcoming book Production-Grade Agentic AI: From Brittle Workflows to Deployable Autonomous Systems, also available at productionaibook.com.
 
You can connect with Ran Aroussi on LinkedIn.

BONUS: Why Embedding Sales with Engineering in Stealth Mode Changed Everything for Snowflake
In this episode, we talk about what it really takes to scale go-to-market from zero to billions. We interview Chris Degnan, a builder of one of the most iconic revenue engines in enterprise software at Snowflake. This conversation is grounded in the transformation described in his book Make It Snow—the journey from early-stage chaos to durable, aligned growth.
Embedding Sales with Engineering While Still in Stealth
"I don't expect you to sell anything for 2 years. What I really want you to do is get a ton of feedback and get customers to use the product so that when we come out of stealth mode, we have this world-class product."
 
Chris joined Snowflake when there were zero customers and the company was still in stealth mode. The counterintuitive move of embedding sales next to engineering so early wasn't about driving immediate revenue, it was about understanding product-market fit. Chris's job was to get customers to try the product, use it for free, and break it. And break it they did. This early feedback led to material changes in the product before general availability. The approach helped shape their ideal customer profile (ICP) and gave the engineering team real-world validation that shaped Snowflake's technical direction. In a world where startups are pressured to show revenue immediately, Snowflake's investors took the opposite approach: focus on building a product people cannot live without first.
Why Sales and Marketing Alignment Is Existential
"If we're not driving revenue, if the revenue is not growing, then how are we going to be successful? Revenue was king."
 
When Denise Persson joined as CMO, she shifted the conversation from marketing qualified leads (MQLs) to qualified meetings for the sales team. This simple reframe eliminated the typical friction between sales and marketing. Both leaders shared challenges openly and held each other accountable. When someone in either organization wasn't being respectful to the other team, they addressed it directly. Chris warns founders against creating artificial friction between sales and marketing: "A lot of founders who are engineers think that they want to create this friction between sales and marketing. And that's the opposite instinct you should have." The key insight is treating sales and marketing as a symbiotic system where revenue is the shared north star.
Coaching Leaders Through Hypergrowth
"If there's a problem in one of our organizations, if someone comes with a mentality that is not great for us, we're gonna give direct feedback to those people."
 
Chris and Denise maintained tight alignment at the top level of their organizations through four CEO transitions. Their partnership created a culture of accountability that cascaded through both teams. When either hired senior people who didn't fit the culture, they investigated and addressed it. The coaching approach wasn't about winning by authority—it was about maintaining partnership and shared accountability for results. This required unlearning traditional management approaches that pit departments against each other and instead fostering genuine collaboration.
Cultural Behaviors That Scale (And Those That Don't)
"We got dumb and lazy. We forgot about it. And then we decided, hey, we're gonna go get a little bit more fit, and figure out how to go get the new logos again."
 
Chris describes himself as a "velocity salesperson" with a hyper-focus on new customer acquisition. This focus worked brilliantly during Snowflake's growth phase—land customers, and the high net retention rate would drive expansion. However, as Snowflake prepared to go public, they took their foot off the gas on new logo acquisition, believing not all new logos were equal. This turned out to be a mistake. In his final year at Snowflake, working with CEO Sridhar Ramaswamy, they redesigned the sales team to reinvigorate the new logo acquisition machine. The lesson: the cultural behaviors that fuel early success must be consciously maintained and sometimes redesigned as you scale.
Keeping the Message Narrow Before Going Platform
"Eventually, I know you want to be a platform. But having a targeted market when you're initially launching the company, that people are spending money on, makes it easier for your sales team."
 
Snowflake intentionally positioned itself in the enterprise data warehousing market—a $10-12 billion annual market with 5,000-7,000 enterprise customers—rather than trying to sound "bigger" as a platform play. The strategic advantage was accessing existing budgets. When selling to large enterprises that go through annual planning processes, fitting into an existing budget means sales cycles of 3-6 months instead of 9-18 months. Yes, competition eventually tried to corner Snowflake as "just a cute data warehouse," but by then they had captured significant market share and could stretch their wings into the broader data cloud opportunity.
Selling Consumption-Based Products to Fixed-Budget Buyers
"Don't believe anything I say, try it."
 
One of Snowflake's hardest challenges was explaining their elastic, consumption-based architecture to procurement and legal teams accustomed to fixed budgets. In 2013-2015, many CIOs still believed data would stay in their data centers. Snowflake's model—where customers could spin up a thousand servers for 4 hours, load data, while analysts ran queries without performance impact—seemed impossible. Chris's approach was simple: set up proof of concepts and pilots. Let the technology speak for itself. The shift from fixed resources to elastic architecture required changing not just technology but entire mindsets about how data infrastructure could work.
 
About Chris Degnan
Chris Degnan is a builder of one of the most iconic revenue engines in enterprise software. As the first sales hire at Snowflake, he helped scale the company from zero customers to billions in revenue. Chris co-authored Make It Snow: From Zero to Billions with Denise Persson, documenting their journey of building Snowflake's go-to-market organization. Today, Chris advises early-stage startups on building their go-to-market strategies and works with Iconiq Capital, the venture firm that led Snowflake's Series D round.
 
You can link with Chris Degnan on LinkedIn and learn more about the book at MakeItSnowBook.com.

Prabhleen Kaur: The Art of Coaching Product Owners on What vs. How
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
The Great Product Owner: Master of Stakeholder Relationships and the Power of No
"The best PO is the person who has the superpower of saying no, and they can deal with the stakeholders with the same prowess." - Prabhleen Kaur
 
Prabhleen describes working with a Product Owner who managed multiple stakeholders—not just a handful, but a significant number with competing priorities. What made him exceptional was his deep understanding of each stakeholder's pulse and motivations. He knew when to push back and how to frame the "no" in a way that stakeholders could accept. This wasn't random resistance—it came from thorough preparation manifested in clear roadmaps that made most incoming work predictable for the team. 
His user stories stood out for their richness in context: beyond the business requirements, they included information about who would be impacted, which proved invaluable for a team dealing with multiple interconnected systems. 
He leveraged JIRA's priority field effectively, ensuring the moment anyone opened the board, they could immediately understand what mattered most. Prabhleen emphasizes that this PO understood his role as the "what" while respecting the team as the "how." By maintaining strong stakeholder relationships built on mutual understanding, he created space for the team to prepare, plan, and deliver without constant firefighting.
 
Self-reflection Question: Does your Product Owner have the preparation and stakeholder relationships needed to confidently say "no" when priorities compete, or does every request become an emergency?
The Bad Product Owner: Technical Experts Who Manage the Sprint Backlog
"The PO is the what, and the team is the how. When POs start directing the team about how to do things, the sprint goal gets compromised." - Prabhleen Kaur
 
Prabhleen addresses a common anti-pattern she's observed repeatedly: Product Owners with technical backgrounds who cross the line from "what" into "how." When POs come from developer or technical roles, their expertise can become a liability if they start prescribing solutions rather than defining problems. 
They direct the team on implementation approaches, suggest specific technical solutions in user stories, and effectively manage the sprint backlog instead of focusing on the product backlog. The consequences are predictable: stories keep getting added or removed mid-sprint, the sprint goal becomes meaningless, and the team ends up delivering nothing because focus is constantly shifting. 
Prabhleen's solution starts in backlog refinement, where she ensures conversations about technical approaches happen openly with the whole team during estimation. When a PO suggests a specific implementation, she facilitates discussion about alternatives, allowing the team to voice their perspective. 
The key insight: everyone comes from a good place—the PO suggests solutions because they believe they're helping. The Scrum Master's role is to create space for the team to own the "how" while helping the PO see the value in stepping back.
 
Self-reflection Question: When your Product Owner has technical expertise, how do you help them contribute their knowledge without directing the team's implementation choices?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Prabhleen Kaur
 
Prabhleen is a Certified Scrum Master with 7+ years of experience helping teams succeed with SAFe, Scrum and Kanban. Passionate about clean backlogs, powerful metrics, and dashboards that actually mean something. She is also known for making JIRA behave, driving Agile transformations, and helping teams ship value consistently and confidently.
 
You can link with Prabhleen Kaur on LinkedIn.

Prabhleen Kaur: When Team Members Raise Concerns with Clarity, Not Anger
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"My idea of success as a Scrum Master is when you look around, you see motivated people, and when something goes wrong, they come to you not in anger, but with concern." - Prabhleen Kaur
 
Prabhleen offers a refreshing perspective on measuring success as a Scrum Master that goes beyond velocity charts and feature counts. She shares a pivotal moment when her team was in production, delivering relentlessly with barely any time to breathe. A team member approached her—not with frustration or blame—but with thoughtful concern: "This is not going to work out." He sat down with Prabhleen and the Product Owner, explaining that as the middle layer in an API creation team, delays from upstream were creating a cascading problem. 
What struck Prabhleen wasn't just the identification of the issue, but how he approached it: with options to discuss, not demands to make. This moment crystallized her definition of success. When team members feel safe enough to voice concerns early, when they come with ideas rather than accusations, when they see themselves as part of the solution rather than victims of circumstances—that's when a Scrum Master has truly succeeded. 
Prabhleen reminds us that while stakeholders may focus on features delivered, Scrum Masters should watch how well the team responds to change. That adaptability, rooted in psychological safety and mutual trust, is the true measure of a team's maturity.
 
Self-reflection Question: When problems emerge in your team, do people approach you with defensive anger or constructive concern? What does that tell you about the psychological safety you've helped create?
Featured Retrospective Format for the Week: Keep-Stop-Happy-Gratitude
Prabhleen shares her favorite retrospective format, born from necessity when she joined an established team with dismal participation in their standard three-column retrospectives. She transformed it into a four-column approach: (1) What should we keep doing, (2) What should we stop doing, (3) One thing that will make you happy, and (4) Gratitude for the team. The third column—asking what would make team members happy—opened unexpected doors. Suggestions ranged from team outings to skipping Friday stand-ups, giving Prabhleen real-time insights into team needs without waiting for formal working agreement sessions. The gratitude column proved even more powerful. "Appreciation brings a space where trust is automatically built. When every 15 days you're sitting with the team making a point to say thank you to each other for all the work you've done, everybody feels mutually respected," Prabhleen explains. This ties directly to the trust-building discussed in Tuesday's episode—using retrospectives not just to improve processes, but to strengthen the human connections that make teams resilient.
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Prabhleen Kaur
 
Prabhleen is a Certified Scrum Master with 7+ years of experience helping teams succeed with SAFe, Scrum and Kanban. Passionate about clean backlogs, powerful metrics, and dashboards that actually mean something. She is also known for making JIRA behave, driving Agile transformations, and helping teams ship value consistently and confidently.
 
You can link with Prabhleen Kaur on LinkedIn.