Podcasts about SDLC

"Czy robiliśmy review lat temu trzy? Nie, nie robiliśmy, tylko wszyscy okłamywali się, że robią review porządnie i klikali: tak, tak, tak może iść."

Co trzeba zmienić w software developmencie, kiedy napisanie kodu przestaje być najdroższą częścią procesu?Omawiamy AI-Native SDLC Playbook od Anthropic, porównujemy go z 10xDevs i zastanawiamy się, jak zmienia się rola programisty, gdy agenci przejmują większość implementacji.Rozmawiamy też o agentach OpenAI, które spontanicznie zaczęły ze sobą współpracować, oraz o tym, czy rzeczywiście powstały „cywilizacje AI”, czy raczej mieliśmy do czynienia z efektownym security facepalmem. Na koniec: SpaceX kupuje Cursora za 60 mld dolarów, Grok 4.6 trafia do edytora, a OpenAI zapowiada wycofanie swoich modeli.Materiały z odcinka:

In episode 332, the discussion focuses on how artificial intelligence is reshaping the Software Development Lifecycle (SDLC). The episode analyzes Anthropic's blog post regarding an "AI-native SDLC," evaluating its vision of replacing traditional development bottlenecks with AI workflows. The commentary critiques Anthropic's reliance on simple Markdown files for tracking development decisions, noting that replacing deterministic tools with probabilistic LLMs in core SDLC processes introduces significant reliability risks, context drift, and excessive token costs. The conversation turns to OpenAI's "Collective Call for Cyber Defense" initiative, examining its push for frontier AI model regulation and critiques of open-weight models, which are viewed as an effort to establish vendor lock-in. Exploring the concept of "Rumor as the Exploit," the discussion highlights how public mentions or minor disclosures of vulnerabilities now allow AI-driven testing harnesses to rapidly discover and generate working exploits across unmaintained software ecosystems. To counter this accelerated threat landscape, the episode evaluates defensive strategies, including runtime verification, reachability analysis, and cooling-off periods for new package releases, emphasizing that security defenders must move beyond thin wrapper solutions and build robust systems combining deterministic controls with model capabilities. Episode sponsored by Guardsquare (guardsquare.com).

BONUS: How AI Took the Boring Out of Agile Coaching—Where Scrum Masters Should Actually Start, With Michael Dougherty Today we speak with Michael Dougherty — "Agile Mike" — about how a 30-year veteran of solution development and product leadership made AI a working part of his Agile coaching practice. Michael walks us through the journey from early ChatGPT curiosity, to documentation as the first real win, to the personal-passion project that built his comfort with the tools, and finally to where every Scrum Master should start: the retrospective. From Curiosity to Toolbox: A Slow Burn That Started With User Stories "I tried, and I thought it sucked at that. I'd rather write this by hand."   Michael's AI journey started in late 2022 with ChatGPT — like most coaches, he tried to make it write user stories and acceptance criteria. It didn't work. The output wasn't usable, and he went back to writing them by hand. What looks like a failure was actually the first lesson: not every coaching task is a good fit for AI, and the way to find out is to try. He kept experimenting in the background through 2023 and 2024 — Claude, Grok, Perplexity — while keeping personal use and business use cleanly separated. The real shift came at the Department of Homeland Security, where he sat alongside ex-Googlers, ex-OpenAI people, and an Anthropic alumnus on the team building DHS's internal chatbot. Watching what AI could do inside a heavily-protected enterprise environment changed his frame: this wasn't a productivity hack anymore, it was infrastructure. The Boring, Tedious, Now Quicker: Documentation as the First Real Win "AI has taken all those boring, tedious tasks and made them quicker, more valuable, and more fun to boot."   The first AI practice that stuck was documentation — the part of Agile coaching nobody enjoys but every client demands. Michael had spent years writing SDLC docs from blank pages, and his co-author on Shift: From Product to People used to look at empty docs and ask for help getting started. AI removed that blank-page problem. He'd give the model the team context, the client's documentation requirements, and a template — and get a draft to edit. He stayed in the loop as the human, bringing context, judgment, and final shape, but he no longer started from zero. The same shift happened with presentations: instead of fighting PowerPoint spacing, he tells the AI to drop content into a template and gets back a formatted deck. Small tasks, but multiplied across a coaching week, they bought back real time. The Personal Project Trick: Find Something You Love First "Find something you have a passion with, something you really enjoy. That made me feel comfortable with AI so I could do more."   Michael's strongest advice for coaches who feel intimidated by AI isn't to start at work — it's to build something for yourself, in a domain you care about. His own example: the Nordic Metal Tour Tracker, a personal AI agent for tracking heavy metal bands across Northern Europe (and Spain and Portugal). It plays music. It maps tours by country. It exists purely because he loves heavy metal. The trick isn't the tool — it's that working on something he actually cared about removed the fear and built the muscle memory. Once the comfort was there, transferring it to work became a small step instead of a leap. He references the rundown AI as a daily input that keeps him aware of how others — even people in their 80s — are using AI for everything from gardening to balanced school lunches. A Week With Preppy Paul: Agents, Connectors, and the End of Inbox Drudgery "Preppy Paul gives me a list of all my meetings today and the top three items I should have on each one — based on my notes, my email, my calendar."   Michael's current weekly routine looks nothing like his Agile coaching week from three years ago. He works at Zion Cloud Solutions as a Tier 1 Google AI partner, splitting time across three roles: about 20–30% traditional Agile project management (coaching a Scrum Master on a state of Illinois project), and the rest as an AI Growth Engineer and AI delivery lead on short 4–6 week projects with 3–5 person teams. The backbone is Google Gemini Enterprise — a platform that lets him run Claude, ChatGPT, or any major model behind enterprise protection (Model Armor, the SAIF framework). Inside it, connectors pull in Gmail, Outlook, Calendar, Confluence, Jira, Slack, Teams, monday.com, and thousands of other tools — each agent inherits only the permissions the user already has. A few practical patterns he runs every week:   Preppy Paul — an agent that prepares him for the day's meetings, pulling top topics per meeting from his notes, email, and calendar. Meeting-to-email — AI records and summarises every meeting, and he asks the agent to draft updates to specific team members directly from the summary. LinkedIn drafts in his voice — hashtags, formatting, and tone all match his style; he edits lightly and posts.   The pattern across all of these: the agent isn't replacing the work. It's removing the friction between the meeting and the next conversation. The Retrospective: The Best Place for Every Scrum Master to Start "Don't have it be the same darn Jira spreadsheet of the same darn three questions every time. Go to AI and eat your heart out with it."   When pushed for one thing a Scrum Master could try tomorrow morning, Michael was clear: the retrospective. It's the one Scrum event where creativity is usually welcome, where format experimentation has a low cost, and where teams are already expecting something new. Ask AI for retrospective formats that fit the team's current situation — review five or ten options, pick one, run it. The signal you watch for within a week is double: how many improvements the team generated, and how many of them actually got done. The simpler signal is the team's reaction. If at the end someone says "that was fun" — and then you tell them you used AI to design the format — you've shown the team what AI is good for without a single slide or framework. It's the smallest possible experiment with the largest possible upside. Experiment Like a Scientist, Not a Spectator "Don't be afraid of it. Try whatever you can with it. Have the viewpoint of a scientist."   The trap Michael sees most coaches falling into is curiosity without commitment — reading about AI, watching demos, talking about it, but never building anything. His framing is the opposite: be a scientist. Run experiments. Some will fail (his user-story attempt did). Some will quietly become essential (documentation did). The way to find out which is which is to keep trying, in low-stakes contexts, with both personal projects and small work experiments. The coaches who'll be useful to their teams in 18 months aren't the ones who can describe AI accurately — they're the ones who've built enough small things to know what AI is bad at, what it's surprisingly good at, and where the human in the loop has to stay.   About Michael Dougherty   "Agile Mike" has over 30 years of experience with solution development and product leadership, working in nearly every IT role that exists and literally hundreds of companies during his career. Michael has taught multiple Agile courses to over 1000 people, spoken at multiple events and podcasts, written dozens of blogs, and has been recently serving the US Government. He is the other co-author of Shift: From Product to People.   You can link with Michael Dougherty on LinkedIn and find more about his work at shiftingpeople.com and AP8XGlobal.com.

This week I'm joined by Arnav Mishra, who is co-founder and CTO of DOSS. We are exploring the world where AI meets ERP and how DOSS are transforming the ERP landscape and the challenges that come with.Introduction into the problem space of ERP and the problems you're solving.Historical ERP costs, consultancies and fragmentation and why the problem space is ripe for innovation.The way in which DOSS are re-building ERP from the ground up; There's a great SDLC analogy they stand by.Arnav helps us understand what “great” looks like for DOSS.Understanding some of the engineering challenges, particularly around data, the right data and scale at DOSS.How do engineers think in the abstract ways to build ANY business application.Building blocks, pattern matching, distribured systems, folder builders, UI/UX, agents, Distributed systems etcArnav helps us understand what/if any challenges you've walked into with the rise of: AIDeploying custom built software / module based, low-code software- From a technology/customer standpoint – where are you placing bets on the next 6-12 months?- Hiring and growth at DOSS and why you should join?If you're keen to share your story, please reach out to us!Guest: https://www.linkedin.com/in/arnav-mishra/DOSS Blog: https://www.doss.com/eng-blogPowered by Artifeks!https://www.linkedin.com/company/artifeksrecruitmenthttps://www.artifeks.co.ukhttps://www.linkedin.com/in/agilerecruiterLinkedIn: https://www.linkedin.com/company/enginearsioTwitter: https://x.com/EnginearsioAll Podcast Platforms: https://smartlink.ausha.co/enginearsHosted on Ausha. See ausha.co/privacy-policy for more information.

What happens when a business-focused professional discovers that AI can translate vision into working software?In this episode, we follow the journey of a business-aligned leader who never saw herself as a developer. Armed with curiosity, domain expertise, and increasingly sophisticated prompting techniques, she crosses the Rubicon from consumer of technology to creator of technology.We explore how modern AI tools are redefining who gets to build software, contribute to projects, experiment with emerging technologies, modernize financial systems, and solve real-world business problems. The conversation examines what changes when technical barriers fall, and domain expertise becomes a superpower.This isn't a story about replacing developers. It's a story about expanding the circle of creators. Host Peter Smulovics (Distinguished Engineer at Morgan Stanley and FINOS Zenith Lead) sits down with Fintech Product Manager Sarah Hilton-Burroughs for a special edition of the Open Source in Finance Podcast. Together, they explore how domain experts are leveraging AI agents, Spec-Driven Development (SDD), and custom component prompts to build full-stack RegTech platforms—without abandoning architectural guardrails or regulatory auditability.

Send us Fan MailA rogue AI agent didn't “hack the future” so much as exploit the oldest security problems in the book: weak boundaries, over-trusted inputs, exposed endpoints, and credentials lying around. We walk through the Hugging Face intrusion story like a CISO briefing a board, step by step, translating a fast-moving AI-red-team narrative into the kind of clear threat modeling logic you need for ISC2 CISSP Domain 1.10 and for real risk decisions. From there, we shift into training mode and get concrete about threat modeling concepts and methodologies. We define threat modeling the way the exam cares about it: proactive, iterative, and designed to produce security requirements and prioritised countermeasures that feed your SDLC and risk register. We break down the three starting perspectives (asset-centric, attack-centric, and system-centric), then anchor STRIDE to data flow diagrams and trust boundaries so you can identify what security property is actually being violated, not just recite acronyms. We also cover the difference between identifying and ranking threats so you don't fall into the classic traps: DREAD ranks threats you already found, while PASTA starts with business objectives and risk appetite and is built for risk-centric outputs leaders can fund. We talk attack trees, why MITRE ATT&CK is an input rather than a methodology, and why your threat actor catalog must include authorized non-human identities and vendor integrations that can operate outside intended scope. If this helps, subscribe, share it with a study buddy, and leave a quick review so more CISSP candidates can find it.Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

It is about time—we took a (very) long summer break filled with travel, a new webinar series, and new and updated apps from What's Your Baseline? :-) Oh, and crossing that 75,000 download mark and celebrating our fifth anniversary—all in this month!But now we are back in the saddle, as they say, and we are starting Season 11 with a conversation between J-M and Roland, in which we dive into our shared painful experiences of process programs who have failed in on or another way. And the graphic below will give you the seven main reasons that we've seen in an overview. But without further ado, in this week's episode of the podcast we are talking about:BPMOS Updates: Roland highlights the release of new BPMOS apps and use cases covering learning and enablement, SDLC from requirement to implementation, planning and procedure factory exercises, and tool selection. The Root of All Evil: The hosts establish that practice failures almost always stem from people making poor decisions, setting up major categories like strategy, structure, governance, technology, and process. Financial Institution Redux: J-M shares a story about a major North American financial institution that struggled with employee happiness initiatives because "too many cooks in the kitchen" forced 30 different capabilities instead of a core MVP. Winning Through Jealousy: To fix the financial institution's fractured program, the team focused on making a single lead stakeholder look exceptionally successful using clear dashboards and KPIs to spark community engagement. The 10-Second Login Disaster: Roland shares a horror story of a healthcare company that bought thousands of software licenses, only to see a 10% login rate with average sessions lasting 10 to 15 seconds due to a total lack of use case definition. Vendor Accountability: The software vendor experience proved that overselling without clear internal commitment or matching use cases leads straight to corporate blacklists and shelfware. Airline System Silos: J-M recounts working with an international airline where a major ERP re-implementation was restricted to a strict "project bubble," causing massive scoping failures when touching unmapped system interfaces. The Business Therapist: Navigating severe adversarial relationships between vendors and corporate clients requires consultants with high emotional intelligence to act as mediators and keep the project alive. Process Mining Roadblocks: Roland details a financial institution that loved process mining initial proofs-of-concept but ultimately stalled out because rigid 8-to-10-week data request cycles choked agility.Top-Down Power: The lesson from the process mining hurdle is that bottom-up enthusiasm is great, but getting data and capabilities moving requires the backing of executive “big guns."The Lifer Employee Challenge: Working with decades-long corpor“lifers” who reject new methodologies requires understanding their unique values and reaching out early to secure true buy-in.Whiteboards vs. Repositories: The hosts lament seeing critical organizational processes mapped solely on office sticky notes, physical whiteboards, or locked filing cabinets rather than a digital twin repository.Summary of Failure Pillars: The episode wraps up by reiterating the core pillars of failure: strategy, people alignment, technology choices, process sustainment, structural design, governance, and value achievement.Please reach out to us by either sending an email to hello@whatsyourbaseline.com or signing up for our newsletter and reading articles about process and architecture on our Substack … Go and subscribe at whatsyourbaseline.substack.com.And if you like to support “the little podcast that could,” become a Patron at https://www.patreon.com/c/whatsyourbaseline. We appreciate you!

Spinning up an agent is like hiring a brilliant engineer on day one: capable of almost anything, completely in the dark about how your organization actually works. That gap is expensive, and most teams are only starting to feel it.Dennis Pilarinos, founder and CEO of Unblocked, has been thinking about this problem longer than most. His argument is that the hardest part of software engineering was never writing code. It was always the context layered around it: the architectural call buried in a Slack thread, the incident postmortem that quietly changed a naming convention, the tribal knowledge that lived in someone's head until they left. AI made that problem viscerally visible. Agents burn tokens chasing answers that experienced engineers already carry.Dennis and Rob dig into what it actually takes to compete on context beyond just indexing source code, why the pull request is quietly becoming the uber class of the modern SDLC, and why the tokenomics reckoning that's coming for engineering leaders might finally give us the through-line from AI spend to business outcomes that the industry has never had.Dennis built developer tools across every major platform shift of the last 20 years, from the .NET framework at Microsoft to AWS, mobile CI at Buddybuild, and now agentic infrastructure at Unblocked.Why agents are "disgustingly inefficient" without organizational contextThe limits of source code alone, and what fills the gapHow the pull request is changing form and function in an agentic worldContext-powered code review and what it surfaces that standard tools missConnecting AI spend to business outcomes: closer than ever, further than we thinkThe 3-5% of engineers who are "AI-pilled" and what they've already figured outSubscribe wherever you get your podcasts.

Every engineering team wants to build its own custom AI agent, but what if all your organization needs is a standardized skill or a stateless MCP server? This week on Dev Interrupted, Andrew sits down with AWS Senior Principal Engineer Clare Liguori to untangle the ecosystem of modern agentic architecture. They work through how a team decides which AI building blocks to own, and how to get that reach without inheriting a maintenance burden. Clare shares her perspective on the simplified MCP 7.28 spec and why stripping away heavy custom scaffolding is how enterprise AI scales.That same shift is what makes MCP a gamechanger for LinearB customers, bringing your SDLC context layer, git, project management, and software delivery, into any agentic surface. What could your agents achieve if they can query your SDLC?Get the guide: The AI engineering productivity gap - how elite teams pull ahead in 2026Register: Dev Interrupted Presents: The Software Factory RoundtableFollow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's guest:Strands Agents SDK: Explore the open-source framework for building model-driven agents at strandsagents.comMCP 7.28): Dive into the new stateless specification at modelcontextprotocol.ioFollow Clare: LinkedIn | X OFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

In this podcast, Michael Stiefel spoke to Tracy Bannon about the role of artificial intelligence in software and the attendant risks in the areas of security, software development, and society at large. While it might be reasonable to assume a certain amount of trust within a software ecosystem, the risks escalate when the boundary between two software ecosystems is crossed. Bannon emphasized that the discovery and exploitation of software vulnerabilities by AI is not a new issue, but it is just part of the evolution of cybersecurity threats. The discussion then continued to highlight that the traditional software development process was designed for humans. What the SDLC looks like in a world of agentic development has yet to be determined. Among the many challenges is testing an agent that is non-deterministic and whose behavior changes as it is tested, and reinitializing the test environment at the appropriate time. The use of AI agents has imposed a tremendous cognitive load on software professionals because they must review the massive amount of code and documents that an AI agent can generate. For both software professionals, and the public at large, the overreliance on artificial intelligence is leading to diminishing human skills, especially in complex domains. The question is - are we outsourcing our intelligence to automated models? Read a transcript of this interview: https://bit.ly/4qeyr70 Newsletter: Subscribe to the Software Architects' Newsletter, a monthly roundup of the patterns and technologies senior practitioners are working through, with the news and lessons from people doing the work: https://www.infoq.com/software-architects-newsletter InfoQ Online Certification Programs: 5-week online cohorts for senior engineers and architects, built around QCon talks. Programs now cover software architecture, AI engineering, and organizational architecture. Each week you join a four-hour live session with a confidential peer group of practitioners from other companies, apply frameworks from QCon talks to the decisions you're making at work, and earn an InfoQ certification. You leave with new approaches, or confirmation that the calls you're already making are the right ones. Learn more: https://certification.qconferences.com/ Upcoming Events: QCon San Francisco 2026 (November 16-20, 2026) https://qconsf.com/ QCon London 2027 (April 13-16, 2027) https://qconlondon.com/ The InfoQ Podcasts: Weekly conversations with senior software leaders about how they build systems and teams, including what they'd do differently. Listen to all our podcasts and read interview transcripts: The InfoQ Podcast: https://www.infoq.com/podcasts/ Engineering Culture Podcast by InfoQ: https://www.infoq.com/podcasts/#engineering_culture Generally AI: https://www.infoq.com/generally-ai-podcast/ Follow InfoQ: Mastodon: https://techhub.social/@infoq X: https://x.com/InfoQ LinkedIn: https://www.linkedin.com/company/infoq/ Facebook: https://www.facebook.com/InfoQdotcom Instagram: https://www.instagram.com/infoqdotcom/ YouTube: https://www.youtube.com/infoq Bluesky: https://bsky.app/profile/infoq.com Write for InfoQ: Share what you've learned building software with a community of senior practitioners, and get your work in front of the people who read InfoQ. https://www.infoq.com/write-for-infoq

Send us Fan MailA supply chain attack that leaves your Git history spotless should change how you think about “secure code.” We walk through ChainDrop, a worm discovered in the NPM ecosystem that poisoned 444 packages while evading the places defenders usually look. The unnerving twist is that it can trigger without a classic npm install and can hide in the space between your repository and the package archive your CI/CD pipeline actually pulls, which is exactly why code review alone can't be your finish line.From there, we tie the real-world scenario directly to CISSP Domain 8 Software Development Security and the secure SDLC. I lay out a clear, exam-friendly framework for assessing third-party and acquired software risk: Software Composition Analysis (SCA), Software Bill of Materials (SBOM), vendor and publisher risk assessment, and runtime plus pipeline controls. We talk about why SCA is necessary but incomplete, how a living SBOM enables fast exposure checks when a new campaign hits, and why Executive Order 14028 is pushing SBOM adoption into “expected” territory for many organisations.We also get practical about CI/CD pipeline security: dependency pinning, trusted publishing workflows, signed commits, OIDC, and package signing and verification approaches like Sigstore and Cosign. Finally, we run through scenario-based practice questions that highlight common CISSP traps and the manager mindset the exam rewards. If you want more episodes like this, subscribe, share it with a developer or security lead, and leave a quick review so more CISSP candidates can find the show.Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

This week on the Friday Deploy, Ben and Andrew explore Uber's strategy of "rearward deploying" engineers to spread agentic AI workflows into departments like legal and marketing. They also dive into Anthropic making Claude Code's Auto Mode the default, Meta's new on-device Muse Glimmer model, and Tim O'Reilly's case for an open source AI ecosystem. Finally, they break down context engineering for the SDLC and examine new research showing why generalized agent skills outperform personalized ones. Register: Dev Interrupted Presents: The Software Factory RoundtableFollow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's stories:After starting the tokenmaxxing panic, Uber's CTO is back with a very different AI storyAuto mode is now the default in Claude Code for Pro, Max, and Team plansIntroducing Muse Glimmer: An Open Agentic Model That Runs on Your DeviceWhy Open Source Matters for AIYour SDLC is your context engineeringDo personalized skills help coding agents? An empirical study of developer interaction historiesOFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubCheck out more here:https://gotopia.tech/episodes/451Ajay Chankramath - Founder & CEO at Platformetrics & Co-Author of "The Platform Engineer's Handbook"Kaspar von Grünberg - Founder & CEO at Stealth & Author of "Thinking in Platforms"RESOURCESAjayhttps://www.linkedin.com/in/chankramathhttps://github.com/achankrahttps://x.com/ajchantwhttps://chankramath.comhttps://platformetrics.comKasparhttps://www.linkedin.com/in/kvgruenberghttps://github.com/Kasparvongruenberghttps://kasparvongruenberg.comLinkshttps://peh-packt.platformetrics.comDESCRIPTIONAjay Chankramath — author of The Platform Engineer's Handbook — joins Kaspar von Grünberg to unpack why he wrote a 14-chapter, code-first practitioner's guide instead of another theory-heavy platform book. The conversation's core thesis: the reason developers don't adopt platforms isn't a technology gap, it's a product discipline gap — a failure to treat developer experience as a first-class outcome with a real feedback loop. Ajay walks through the book's arc, from Kubernetes and service-mesh foundations through self-service portals to enterprise-grade concerns like policy-as-code and FinOps, and makes a pointed case for building on 100% open-source, vendor-agnostic tooling as a hedge against geopolitical and licensing whiplash.The most relevant thread for engineers building with AI today: citing a McKinsey finding that only 6% of AI initiatives show real productivity gains, Ajay argues that agentic AI doesn't reduce the need for platform engineering — it raises the stakes. As coding agents become genuine actors in the SDLC rather than tools, IDPs need a new layer for agent context, memory, tool registries, and guardrails, and that layer "must be built, owned, and operated by you," not bought off the shelf.His conclusion: the differentiator in the AI era isn't which frontier model you use — it's whether your platform foundations are solid enough to make agents safe and productive at all.RECOMMENDED BOOKSAjay Chankramath • The Platform Engineer's Handbook • https://amzn.to/4eCSibMAjay Chankramath & Eamonn Ryan • Domain-Driven Platform Engineering • https://amzn.to/3TdiC3JChankramath, Cheneweth, Oliver & Alvarez • Effective Platform Engineering • https://amzn.to/3OnxN8iKaspar von Grünberg & Luca Galante • Thinking in Plat­forms • https://weaveintelligence.io/thinking-in-platforms-bookGregor Hohpe • Platform Strategy • https://amzn.to/4cxfYdbBlueskyInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Introduction Most carriers have stopped asking whether AI works. So why does so little of it ever leave the pilot? Kurt Diederich has spent 25 years building the core policy, billing, and claims systems that property and casualty insurers run on. Two years ago he looked at AI and, in his words, thought it was a pile of trash. He kept retrying it every six months anyway, and the thing that flipped him was a bread recipe. He asked a model to cut it in half, it correctly turned tablespoons into one and a half teaspoons, and he went in with both feet. That arc is the episode. Kurt walks through the adoption curve he sees in most organizations, from skepticism, to being wowed, to badly overestimating what the technology can do, and then the hard landing into execution where the roadblocks show up. His argument is that the software was never the constraint. The constraint is whether a company will restructure how it works, put the right people in front of the change, and actually measure what it gets. Guest Bio Kurt Diederich is the Chief Executive Officer and co-founder of Finys, a Troy, Michigan software company whose Suite covers policy administration, billing, claims, portals, and business intelligence for P&C carriers, mutuals, and state FAIR Plans. He started writing assembly-language games as a teenager on TRS-80s and Apple IIs, worked his way through college as a consultant, and has been an entrepreneur ever since. He spent the 1990s building custom claims and policy systems for carriers, then founded Finys in 2001 and went all in on insurance, building the platform on Microsoft .NET. Finys marked its 25th anniversary in 2026 and employs roughly 175 people. Key Topics -The four-stage adoption curve - Skepticism, then being wowed, then overestimating what AI can do, then the drop into execution where the real roadblocks appear. -30% versus three to five times - Let people work the way they always have and you get a modest lift. Restructure the work into small pods and the number changes completely. -The SDLC becomes the AI PLC - Kurt argues the software development lifecycle is turning into a product lifecycle, where the idea of developers sitting down to write code starts to go away. -The 40-point measurement gap - Studies found developers predicting a 20% productivity gain while actually running a 20% deficit, and most organizations never measure at all. -Champions rather than training - Training wears off because people default back to old habits. Kurt uses people who have already done it to coach teams through real work, repeatedly. -Why carriers have it harder - Governance and regulatory exposure slow carrier adoption compared with a software company, and improper usage draws regulators. -Spending AI dollars badly - Everyone reaches for the frontier model. Kurt watches an internal credits leaderboard, argues most problems are solved by cheaper models, and says AI should be used to build deterministic solutions rather than being run over and over. Notable Quotes "Developers were predicting they're getting a 20% productivity lift with AI when in reality they were at a 20% productivity deficit. So you've got a 40% gap between reality and perceived value." "If you allow the developers to just work as they've always worked, what we find is you get maybe a 30% productivity lift. By restructuring the way you work, you see these huge productivity lifts." "I don't think the typical worker is going to have that aha moment where they realize what they've been doing for the last ten, fifteen, or twenty years is wrong. They've been successful at it." "The AI industry has kind of done themselves some harm by saying you're not going to need all the people to do the work anymore." Resources Guest: Finys: https://finys.com/ Finys on LinkedIn: https://www.linkedin.com/company/finys/ Kurt Diederich on LinkedIn: https://www.linkedin.com/in/kurt-diederich/ Host & Organization: Joshua R. Hollander on LinkedIn: https://www.linkedin.com/in/joshuarhollander/ Horton International (USA): https://www.horton-usa.com/ Insurtech Leadership Podcast (LinkedIn Showcase): https://www.linkedin.com/showcase/insurtech-leadership-show Subscribe & Review If you enjoyed this episode, subscribe on your favorite platform and leave a review. The Insurtech Leadership Podcast is available on YouTube, Podbean, Apple Podcasts, and Spotify.

AI isn't just transforming the way we work, but also the way we write the software that people use for work. In this episode, we talk to two engineering productivity leads at Dropbox: Uma Namasivayam, senior director of software engineering productivity, and Anuradha Agarwal, director of software engineering. Whether it's writing tests, fixing bugs, tackling tech debt, or accelerating migrations, they explain how Dropbox engineers are using agentic AI—including in-house tools like Nova—to build the future of Dropbox, and create more space to do impactful work. ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck.  Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

Tim Bozarth is a Corporate Vice President in Microsoft CoreAI, where he leads engineering for next-generation developer experiences and Microsoft's Engineering Thrive initiative. Throughout his career at Microsoft, Google, Netflix, and Box, he has focused on developer productivity, engineering systems, and organizational effectiveness.In this episode of Engineering Enablement, Tim joins host Brian Houck to discuss Engineering Thrive, Microsoft's framework for measuring and improving engineering productivity. They explore why AI makes outcome-based metrics more important than ever, where new bottlenecks are emerging in the software development lifecycle, and why verification and confidence may become more valuable than code generation itself. Tim also shares why the purpose of engineering remains the same despite rising levels of abstraction, the skills that remain durable in an AI-driven world, and why engineering leaders should focus on outcomes rather than activity metrics.Where to find Tim Bozarth:• LinkedIn: linkedin.com/in/tbozarth Where to find Brian Houck: • LinkedIn: ⁠https://www.linkedin.com/in/brianhouck⁠In this episode, we cover:(00:00) Intro(02:13) What Engineering Thrive is and the problem it solves(04:46) Why Engineering Thrive isn't specific to Microsoft(09:10) The impact of Engineering Thrive at Microsoft(14:31) Why AI makes outcome-based productivity metrics more important(18:22) Where AI is creating new bottlenecks in the SDLC(24:37) Why more abstraction doesn't change the purpose of engineering(27:25) The durable skills of good engineers (33:03) The changing economics of software development(36:56) Advice for leaders: measure outcomes, not activityReferenced:• DX Core 4 Productivity Framework• EngThrive: Make It Fast and Easy to Do Great Work: Building a durable model for outcome-oriented engineering measurement• Quote by Eliyahu M. Goldratt: “Tell me how you measure me and...”• Jevons paradox - Wikipedia

In this episode of Software People Stories, I speak with Mario Lewis, a manufacturing specialist turned IT expert with over 35 years of experience. He talks about his career that began far away from software—in mechanical engineering, manufacturing, operations, and quality—and eventually found its way into the software services world. We talk about what manufacturing can teach software teams, why domain knowledge and business understanding matter, how to stay adaptable through career transitions, and Mario's experiment with AI-assisted software development through Project Klyve. It's a thoughtful conversation about learning, reinvention, and doing meaningful work—even when the path is unexpected.Highlights from this conversation:Early passion for aviation led to mechanical engineering, manufacturing, and operations research.Manufacturing taught lessons in process rigor, quality, planning, and business constraints.Software became a chosen path, not a passion, but Mario approached it with discipline and curiosity.Adaptability emerges as a key career skill across industries and eras of change.Mario argues that technology is an enabler; real value comes from solving business problems.Domain depth and tacit knowledge are becoming more important, especially in GCC-style models.Project Klyve tested how far AI and agentic tools could go in building a complete application.Advice for early-career professionals: master fundamentals, understand hardware, networks, data, and security.Advice for mid-career professionals: keep learning, build domain depth, and understand market forces.Retirement feels comfortable because IT was meaningful work, but not Mario's core passion.Mario began his career on the shop floor with planning and manufacturing optimization roles in machine tool and switchgear manufacturing. That early focus on physical manufacturing and basic operations grounded his transition into IT services and enterprise software, where he spent over 35 years leading delivery, consulting, operations and business teams. Along the way, in 2006, he authored a book on the realities of IT service offshoring based on his practical experience in the field.At the end of 2024, Mario stepped away from full-time corporate roles into retirement. He spent that time building Klyve, an automated desktop software factory that implemented an SDLC to build full software applications using agentic AI. It was built around strict engineering controls, deterministic design, and local data privacy.For Mario, managing career shifts comes down to fundamentals. Staying useful across changing industries requires an openness to lifelong learning, disciplined routine, steady execution, and personal standards while tracking industry and technology trends."Mario may be reached at: mariolewis @ gmail.com.The Klyve repo is at https://github.com/mariolewis/klyve_factoryHis book (from 2006) is available at https://www.amazon.in/Application-Service-Offshoring-Insiders-Guide/dp/0761935258

Danil Chernyshev: The MIA Product Owner vs. The One Who Owned the Outcome 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: Communicating Value, Inviting the Right People 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.   "It's basic Scrum—but it's not basic." - Danil Chernyshev   The best Product Owner Danil ever worked with was Jamie Spence, on a Master Data Management re-architecture at Canadian Tire. The goal wasn't only to upgrade a system—it was to rethink how a major retailer with many different banners should work across all of them. Jamie didn't write user stories; the BAs did that. What he did was communicate, in a super-clear way, the value expected at every step. He didn't attend every daily Scrum, but he was there whenever the team wanted him, allocating his time on demand. He cared about user experience and lived for the feedback loop—"this sprint I want to deliver this part and see how it goes." And he invited the proper stakeholders to each sprint review: a small, deliberately varied group chosen by what had been delivered and whose feedback the team actually needed. As Danil and Vasco agree, it sounds obvious—and that's exactly why it's worth celebrating. Obvious and common are not the same thing.   Self-reflection Question: Does your Product Owner communicate expected value at every step—or just hand over user stories and disappear? The Bad Product Owner: Present on Paper, Missing in Action 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.   "On paper, you have a Product Owner. But you don't have a Product Owner." - Danil Chernyshev   The most common—and worst—anti-pattern Danil sees is the MIA, or "missing in action," Product Owner: a person with the title who doesn't actually own the product. Sometimes it's a BA or a tech lead wearing the label; sometimes it's someone who simply can't make decisions, or doesn't understand what they're responsible for because they're busy doing another job. The fix starts with clarity: first understand what the product even is, then put in place a Product Owner who makes decisions, owns the end-user experience, and maximizes value. Danil also flags a structural trap—one Product Owner per product, not one per team. He stretches the idea with vivid examples: an Agile coach leading a transformation is effectively the Product Owner of the process, with Scrum Masters as the developers; and Steve Jobs was the Product Owner of the iPhone while also being a customer for other Product Owners building pieces of it. Ownership is about maximizing value for the customer—not about who writes the user stories.   In this segment, we refer to the great Product Owner pattern Danil shares above, and how the Scrum Master's job is to help the Product Owner grow into real ownership.   Self-reflection Question: Is your Product Owner empowered to make decisions and own outcomes—or just a title on an org chart?   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Success Is Synergy—When the Team and the Product Both Win 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.   "Success is when team members say thank you, and praise others for delivering a successful product." - Danil Chernyshev   For Danil, success as a Scrum Master is never one thing—it's a combination. It's the moment team members thank each other and credit the whole group for a product that actually landed with customers. As he reminds us, Scrum Masters, Product Owners, and developers are all there for the same reason: to deliver a product and solve real problems for the end user. A healthy team that has fun together but ships nothing has only spent time and money. A team that delivers but burns everyone out, until no one wants to see each other again, isn't a success either. Real success is the synergy of both: a productive team, happy customers and stakeholders, and people who still have the energy to keep going. Danil also turns the lens inward—success means understanding where you are in your own journey. And it grows from action: when teams get stuck overthinking, he guides them back to what's inside their control, helps them find the smallest valuable step, and gets them experimenting. Start where you are, do what you can, then learn from it.   Self-reflection Question: Are you optimizing for a happy team, a delivered product, or the synergy of both—and how would you know the difference? Featured Retrospective Format for the Week: Lean Coffee (paired with 1-2-4-All and 5 Whys) Danil doesn't lock himself into a single retrospective format—he chooses based on the sprint, guided by "common sense in Scrum." His default is to keep a running list of topics gathered throughout the sprint, then open the retrospective with a Lean Coffee session to democratically decide what to discuss. From there, a light topic gets a quick Lean Coffee conversation, while a deeper one moves into 1-2-4-All from Liberating Structures or a 5 Whys. The non-negotiable for Danil: every retrospective must end with actionable action items. A retro that produces only conversation and no change, he says, was a waste of time—maybe fun, but still a missed opportunity to reflect, learn, and adapt.   [The Scrum Master Toolbox Podcast Recommends]

Danil Chernyshev: Coaching the Outsider In—Helping a Distrustful Team Through Transformation 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.   "Developers and QAs know each other very well, but they don't trust anybody else." - Danil Chernyshev   This week's coaching conversation starts with a hard situation. A subcontractor's developers—people who had always worked isolated from the business, with no plans and no communication—were brought back inside the "mother firm" as part of a digital transformation. Overnight they faced new teams, Scrum, SDLC, CI/CD, and full transparency. The developers and QAs trusted each other completely and trusted no one else: not the Scrum Master, not the Product Owner, not the BAs. Forced to estimate with story points, every story came back as a 3 or a 5, with no conversation. When Danil asked why, the answer was always "we'll discuss internally and tell you tomorrow"—he suspected a second, hidden daily Scrum without him. As he and Vasco unpack it, the real issue is transparency itself: a team used to hiding now feels exposed and doesn't know the consequences of being open. Vasco offers an experiment—build a "trio" of the Product Owner, the Scrum Master, and one friendly insider from the team to prepare refinements together. The Product Owner is always the outsider; pairing them with a trusted insider lets ideas and experiments spread faster. Before you can improve the Scrum, you first have to bring the outsiders in.   Self-reflection Question: Where on your team is trust the real bottleneck—and who is the "insider" who could help an outsider earn it?   [The Scrum Master Toolbox Podcast Recommends]

How do you prove AI is shipping more features? Amos Haviv leads the Developer Workflow teams at Booking.com, supporting 4000 engineers operating 8000 repos.Everybody is burning through their AI budget right now and almost nobody can answer what it bought them. Amos can, because his team spent four years building an event system to debug their own SDLC before AI upped the urgency.In this video, we cover:Why verification is the bottleneck right now, and where it moves nextBuilding an event store that separates KTLO from real feature deliveryWhy static dashboards create the metric they measure, and the cobra story behind itAgent cost, model routing, and why Booking ignores token maxing entirelyRunning a developer survey with a 92% response rate across 3k+ engineersWho should own skills and MCPs: a central platform team or the domain experts?For platform engineers, engineering leaders, and anyone being asked to prove ROI on AI tooling this quarter.Timestamps:00:00:00 - Everyone is burning through their budget00:00:32 - Verification Is the Bottleneck Every Team Hit00:03:35 - 4,000 Engineers and 8,000 Repos at Booking.com00:06:48 - Why Copying Google and OpenAI Will Break You00:09:21 - Verification Is a Stack of Agents, Not One Review00:13:27 - Cost Is Becoming a Bottleneck of Its Own00:17:14 - Was the Internet a Bubble? What That Teaches Us00:25:32 - What Working With the Frontier Labs Looks Like00:28:26 - Debugging the SDLC With Four Years of Event Data00:30:24 - Do Engineers Using AI Actually Ship More Features?00:37:13 - Where to Start If You Measure Nothing Today00:45:01 - The Cobra Effect: When a Metric Becomes a Target00:52:23 - Everyone Is a Builder Now, and Everything Needs Support01:01:21 - Is AI Turning Every Engineer Into a Manager?01:03:46 - The Developer Survey With a 92% Response Rate01:10:09 - Who Owns Skills, MCPs, and the Enterprise Harness01:17:46 - Great Developer Experience Is High VelocityMentioned in the episode:High Output Management by Andy GroveThe Sovereign Individual (1997)The story of General MagicViews expressed are Amos's own and do not represent Booking.com.#AI #SoftwareEngineering #DeveloperExperience

Danil Chernyshev: Why Teams Always Adapt—And How Bad Rules Push Them Into Zombie Scrum 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.   "Teams always adapt. You only get to decide what they adapt to." - Danil Chernyshev   Most dysfunction doesn't start with the team—it starts with the structure around them. Danil shares the story of a classic metrics-driven organization where Scrum Masters reported to a dedicated manager who measured their success by team velocity. That manager tracked retrospectives in a separate log, and would show up at the daily Scrum to confirm everyone answered the three questions. The result was predictable: the retrospective became a clock to survive, the daily became a checkbox with no real conversation, and velocity turned into theater—stories closed as "done," then reopened as "part two" in the next sprint. There was never a real done increment. Danil refuses to blame the team. They were doing exactly what teams always do—adapting to survive the rules and boundaries handed to them. As he and Vasco explore, the only real choice a leader has is not whether a team adapts, but what they adapt to. Dictate bureaucracy, and they'll adapt to surviving it. That's how productive, enjoyable work quietly turns into zombie Scrum. Servant leadership exists precisely so someone helps the team adapt toward value—not toward compliance.   In this segment, we talk about User Story Mapping by Jeff Patton and Peter Economy, and you can hear Jeff Patton on the podcast.   Self-reflection Question: Look at a behavior on your team you find frustrating—what rule or structure might that team be adapting to in order to survive? Featured Book of the Week: Actionable Agile Metrics for Predictability by Daniel Vacanti Danil calls this book eye-opening. It changed how he thinks about metrics—not as a reporting tool for executives, but as something teams can use for themselves to understand what to do next and how to improve. As he puts it, "after that book, you will probably know that a lot of cumulative flow diagrams that you saw in your past, they doesn't work well, and need to be rebuilt." The book makes flow metrics serve the team first, while still giving leadership the transparency they need. You can also hear Daniel Vacanti on the podcast, and get the book here: Actionable Agile Metrics for Predictability by Daniel Vacanti.   [The Scrum Master Toolbox Podcast Recommends]

AI makes it easier than ever to find and act on information—especially now that teams can connect to and search across all the apps they use for work. So how do you ensure that only the right people and the right tools can access your team's most sensitive content? In this episode, we talk with Jess Jimenez, the head of security at Dropbox, about what security looks like in the age of AI at Dropbox-scale—from building AI products securely to building trust with the people who use them. Jess talks about the importance of access control lists, defending against the latest AI threats, and how Dropbox Protect helps teams securely share content with both humans and AI so they can collaborate more safely. ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck.  Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

Danil Chernyshev: Forged in the Fire—Why the Scrum Master Role Tests Even Experienced Leaders 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.   "From my story, you can probably say that I was forged in the fire." - Danil Chernyshev   Danil had already climbed the ladder. He started with Scrum in 2010 as a developer, grew into a development manager, and reached executive level, running a department of 70 developers in his home country. Then he immigrated to Canada and had to start his career fresh. Certified by Scrum.org as both Scrum Master and Product Owner, the first role he landed was Scrum Master—and that's where the trouble began. He knew SDLC inside out, he knew how developers think, he knew Scrum from the trenches. What he didn't know was how to be a servant leader: how to balance serving and leading, how to measure his own success, how to even notice the small wins. After years at the top, he was suddenly the person who knew the least. In this episode, Danil shares why he stayed in the role instead of walking away—he loves building processes that help teams evolve, and he couldn't resist a real challenge. His advice to anyone at that same crossroads: be patient, reflect, build a feedback loop, and never stop learning. A certification proves you understand the base theory. Everything that matters comes after.   In this episode, we refer to the Tuckman model of team development, and how the storming phase tests every team—and every newcomer.   Self-reflection Question: When was the last time you were the person on the team who "knew the least"—and what did that teach you about your own growth?   [The Scrum Master Toolbox Podcast Recommends]

"I need to stop using Opus. This doesn't work." That was Heitor Lessa's conclusion after a refactor cost him 200 million tokens, and it forced him to rebuild the entire agent workflow now available for 1400 engineers. Heitor spent 11 years at AWS, built Lambda Powertools to 230 billion API calls a week, and in this episode he walks through the full SDLC workflow on screen, from discovery to merge check.In this episode, we cover:The product loop: discovery, whiteboarding, and the /roadmap commandSpec-driven development with Open Spec and why vanilla setups failThree model tiers: SOTA for planning, mid-tier for implementation, cheap models for reviewsMerge checks with adversarial reviewers and attestations that catch agents fabricating test resultsThe /retro command: using the Socratic method to make your workflow more deterministicIf you're an engineer figuring out how to work with agents at team scale without losing trust in your codebase, this is the workflow to steal. This is also the first Beyond Coding episode with visuals on screen, so let me know what you think of the format.Timestamps:00:00:00 - The Math Doesn't Add Up00:00:43 - Amazon Hypergrowth: 11 Years, 8 Different Roles00:03:29 - Learning From the Trenches as a Technical Account Manager00:08:38 - Developer Identity and the Birth of Lambda Powertools00:10:20 - The Hard Parts of Working in Public00:13:12 - How Powertools Hit 230 Billion API Calls a Week00:16:42 - Career Advice: Learn Adjacent Roles, Not More Tech00:19:37 - When Leadership Decisions Don't Make Sense to You00:23:21 - The Product Loop Starts With Discovery00:25:22 - From Whiteboard to /roadmap00:27:37 - Why Humans Plan First and Agents Come Second00:30:33 - Commands vs Skills Across 32 Different Models00:33:38 - Adversarial Reviewers on Every Plan00:36:07 - The Socratic Method, Explained00:40:29 - Why He Only Takes Paper Notes00:44:43 - The Five-Line Paper Trick for High-Stakes Meetings00:48:18 - /new-work: Capturing Scope Creep Without Derailing00:54:03 - The Dev Loop Begins: Open Spec Explore00:56:34 - Three Model Tiers: SOTA, Mid, Cheap00:57:43 - The $5,000/Month Per Engineer Question00:58:57 - Guardrails vs Autonomy for 1,400 Engineers01:04:22 - Auto-Sizer: Does This Task Even Need a Spec?01:07:26 - Decision Fatigue and Why Frameworks Win01:09:10 - The Plan Phase: Specs, Design, Formal Verification01:13:07 - The Refactor That Cost 200 Million Tokens01:15:11 - When Agents Forge Evidence They Ran Your Tests01:17:27 - Local-First Architecture Explained01:23:04 - The Apply Phase: Fully Autonomous Loops01:24:30 - Coding Was Never the Bottleneck01:26:39 - Why This Workflow Is an Investment01:27:39 - Decision Logs and the /onboarding Command01:29:06 - Running Agents Locally With Enterprise Governance01:32:42 - Hooks: Making Quality Gates Deterministic01:36:02 - Merge Checks: 15 Adversarial Reviewers Per Change01:38:30 - /retro: Interviewing Yourself to Improve the Loop01:43:12 - Trust, Loss of Trust, and Recovery With Agents01:48:02 - Experience, Scars, and Critical Thinking01:49:32 - Why Right Now Is the Time to Experiment01:52:04 - Conviction Comes From Being in the Loop#softwareengineering #aiagents #aws

Not all work happens in writing. Teams that work with photos, videos, and audio need AI that works for them too. This is why, with Dropbox, you can search within multimedia content for key moments and important information—not just text. In this episode, we talk with Appu Shaji and Hicham Badri, two Dropbox machine learning engineers who are part of the team that makes all of this possible. They explain how multimodal search works—from understanding the context of the initial query, to identifying objects and actions in complex scenes—and how they ensure those models work fast, even at Dropbox-scale. ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck.  Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

AWS Morning Brief for the week of July 13th with Corey Quinn. Links:AWS Security Hub extends unified security management to Microsoft AzureAmazon EKS Auto Mode reduces GPU management fees by up to 60%Amazon RDS for Oracle now supports Oracle Database 26aiAWS Builder Center Now Offers Free Sandbox EnvironmentsAWS Security Hub now offers Network Scanning to identify publicly reachable resourcesAmazon Cognito now supports self-service provisioned API rate limitsAWS Security Hub adds impact analysis for exposure findingsBlazing a Trail: How Peloton Rebuilt the SDLC for the Agentic Era with Amazon BedrockHow United Airlines solved IP exhaustion with Private NAT GatewayBuilding secure AI agents at scale: Introducing Loom for AWSWhat does it cost to answer one question? Measuring per-request cost in agentic workloadsDesigning for the inevitable: System prompt leakage and mitigations in generative AI applicationsThe CISO's guide to post-quantum mandates and migrationsTwo CVEs on the theme of guarding keys badly

Send us Fan MailA six-instruction timing glitch in the Linux kernel can be the difference between “low-priv user” and full root control, and that is why we dig into the Bad EPoll vulnerability from a CISSP-ready, manager-first angle. We start by grounding what the Linux kernel EPoll subsystem does, why it is foundational to high-performance I/O, and why “just disable it” is not a real option when you're dealing with production Linux servers, desktops, cloud workloads, and Android devices.Then we unpack the security mechanics in clear terms: a use-after-free race condition, an impossibly thin race window, and the way memory corruption turns into privilege escalation. We also talk about what makes this case extra concerning, including the report that it can be triggered from inside Chrome's rendering sandbox. If you've ever relied on sandboxing, kernel boundaries, or “we run scanners” as your safety net, this story forces a more honest view of defense in depth.From there we connect the dots to CISSP Domain 8 software development security and real secure SDLC practice. We walk through where SAST, DAST, fuzzing, KASAN-style instrumentation, and AI-assisted code review help and where they fail, especially for concurrency bugs. The real takeaway is a layered detection strategy: automated testing plus manual secure code review for high-blast-radius code, support for external researchers through bug bounty programmes, and a patch management process that moves in days with verification and regression testing so incomplete fixes do not slip through.If this helps you think like a manager, subscribe, share the episode with a study buddy, and leave a review so more CISSP candidates can find it.Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

When AI is at its best, the conversations can feel uncanny—almost magical in their accuracy, relevance, and speed. For that you can thank the AI agents that work together behind the scenes to search, reason, and sift through all your content to get you what you need to do your job. We talk with Jongmin Baek and Marta Mendez, two Dropbox machine learning engineers, about building conversational AI that's helpful, useful, and grounded in your team's shared context, so you can spend more time on the work that really matters. ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck.  Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

In this closing panel from DX Annual, Rafe Colburn, Chief Product and Technology Officer at Etsy; Jesse Adametz, Senior Director of Engineering, Platform Engineering at Twilio; Eirini Kalliamvakou, Research Advisor at GitHub; Collin Green, Senior Staff UX Researcher at Google; and Brian Houck, Senior Principal Applied Scientist at Microsoft debate some of the biggest questions surrounding AI and engineering productivity.They discuss whether AI will reduce the need for engineers, how AI is affecting technical debt, the future role of software engineers in an agentic world, and whether organizations should mandate AI adoption. They also explore how bottlenecks are shifting across the software development lifecycle, the challenges facing junior engineers, and why learning, culture, and change management may ultimately matter more than the tools themselves.Where to find Rafe Colburn:• LinkedIn: https://www.linkedin.com/in/rafeco• Blog: https://rafe.codesWhere to find Eirini Kalliamvakou: • LinkedIn: https://www.linkedin.com/in/eirini-kalliamvakou-1016865• X: https://x.com/irina_kAlWhere to find Brian Houck: • LinkedIn: https://www.linkedin.com/in/brianhouckWhere to find Jesse Adametz: • LinkedIn: https://www.linkedin.com/in/jesseadametz • X: https://x.com/jesseadametz • Website: https://www.jesseadametz.com Where to find Collin Green: • LinkedIn: https://www.linkedin.com/in/collin-green-97720378In this episode, we cover:(00:00) Intro(01:16) Why an AI-first SDLC doesn't mean fewer engineers (03:09) The debate over AI and technical debt(07:40) AI-generated code and the future role of engineers(14:16) Why mandating AI use doesn't necessarily lead to better outcomes(20:43) Predictions for the future of junior engineers (23:22) Where the bottlenecks are in the SDLC now(28:25) How risk influences AI use (32:38) Why the human side is the biggest AI adoption challengeReferenced:• Etsy• GitHub• Microsoft• Twilio• Google • Stewart Reichling• What is the SPACE framework and when should you use it?

In this session from DX Annual, Uma Namasivayam, Senior Director of Engineering Productivity at Dropbox, shares how the company's developer productivity efforts evolved from improving developer experience to preparing for the agentic era.He explains how Dropbox approached AI adoption across its engineering organization, the impact it had on developer productivity, and why faster code generation is creating new bottlenecks in areas such as code review, validation, and CI/CD. He also discusses Dropbox's efforts to rethink engineering systems, measurement, and workflows, including the development of agentic tooling and new metrics designed to move beyond PR throughput and toward product velocity.Where to find Uma Namasivayam:• LinkedIn: https://www.linkedin.com/in/unamasivayIn this episode, we cover:(00:00) Intro(00:57) The beginning of Dropbox's DX journey(02:34) AI adoption at Dropbox: what made it work  (04:46) The results of Dropbox's AI adoption efforts(05:39) What the results mean for the business (06:55) The phases of AI adoption and where they are now(08:00) The new bottlenecks(09:16) Three challenges Dropbox faces moving into agentic engineering(10:05) How Dropbox is redesigning the SDLC for agentic engineering(15:46) The new metrics that matter (19:16) Final takeawaysReferenced:• Dropbox • Developer Experience Index (DXI) | DX • DX Core 4 Productivity Framework• Cursor• Claude Code | Anthropic's agentic coding system• JetBrains • Visual Studio Code• Jira | Project Management for the AI Era | Atlassian• GitHub 

Volodymyr Sydorenko lives in London, and collects mechanical keyboards. His most unusual hobby is that he does clay sculptures of characters, or random people at times. He has 2 cats, and likes to spend time outdoors. In fact, in 3 weeks time from this recording, he will traveling to Switzerland to do the Via Ferrata. To add to all of this, he has started to write children's books and hopes to publish them someday.Vitalii Sydorenko currently lives in Lisbon, Portugal. He is into sports, loves to hit the gym and regularly tracks his calories. Last year he started playing tennis and finds that he can't stop. He enjoy hiking, which is great in Lisbon. And in the past, he spent many years building startups, exiting, and also in venture capitalYou may have noticed that Volodymyr and Vitalii have the same last name... that is because they are brothers. As kids growing up, they did a lot of boxing together, as well as cling to classic films like Back to the Future.Fourteen years ago, Volodymyr got interesting in building solutions, and realized he could only get so far by himself... so he decided to build a team to deliver these solutions. Two years ago, Vitalii and Volodymyr started to consider all the of the shifts in the SDLC, and what that meant for the current business. Vitalii decided to bring his prior startup and VC experience and join the team.This is the creation story of Gearheart.SponsorsUnblockedTECH DomainsMezmoBraingrid.aiLinkshttps://gearheart.io/https://codestory.co/podcast/e6-jon-darbyshire-smartsuite/https://www.linkedin.com/in/gearheart/https://www.linkedin.com/in/vitalii-sydorenko-%F0%9F%92%AA%F0%9F%87%BA%F0%9F%87%A6-24b4ba35/Our Sponsors:* Check out Cash App and use my code CASHAPP10 for a great deal: https://click.cash.app/ui6m/mt82fpxl #CashAppPod. Cash App is a financial services platform, not a bank. Banking services provided by Cash App's bank partner(s). Prepaid debit cards issued by Sutton Bank, Member FDIC. See terms and conditions at https://cash.app/legal/us/en-us/card-agreement. Cash App Green, overdraft coverage, borrow, cash back offers and promotions provided by Cash App, a Block, Inc. brand. Visit http://cash.app/legal/podcast for full disclosures.* Check out Plaud AI and use my code CODESTORY for a great deal: https://plaud.aiAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

Volodymyr Sydorenko lives in London, and collects mechanical keyboards. His most unusual hobby is that he does clay sculptures of characters, or random people at times. He has 2 cats, and likes to spend time outdoors. In fact, in 3 weeks time from this recording, he will traveling to Switzerland to do the Via Ferrata. To add to all of this, he has started to write children's books and hopes to publish them someday.Vitalii Sydorenko currently lives in Lisbon, Portugal. He is into sports, loves to hit the gym and regularly tracks his calories. Last year he started playing tennis and finds that he can't stop. He enjoy hiking, which is great in Lisbon. And in the past, he spent many years building startups, exiting, and also in venture capitalYou may have noticed that Volodymyr and Vitalii have the same last name... that is because they are brothers. As kids growing up, they did a lot of boxing together, as well as cling to classic films like Back to the Future.Fourteen years ago, Volodymyr got interesting in building solutions, and realized he could only get so far by himself... so he decided to build a team to deliver these solutions. Two years ago, Vitalii and Volodymyr started to consider all the of the shifts in the SDLC, and what that meant for the current business. Vitalii decided to bring his prior startup and VC experience and join the team.This is the creation story of Gearhart.SponsorsUnblockedTECH DomainsMezmoBraingrid.aiLinkshttps://gearheart.io/https://beyondthewow.iohttps://codestory.co/podcast/e6-jon-darbyshire-smartsuite/https://www.linkedin.com/in/gearheart/https://www.linkedin.com/in/vitalii-sydorenko-%F0%9F%92%AA%F0%9F%87%BA%F0%9F%87%A6-24b4ba35/Our Sponsors:* Check out Cash App and use my code CASHAPP10 for a great deal: https://click.cash.app/ui6m/mt82fpxl #CashAppPod. Cash App is a financial services platform, not a bank. Banking services provided by Cash App's bank partner(s). Prepaid debit cards issued by Sutton Bank, Member FDIC. See terms and conditions at https://cash.app/legal/us/en-us/card-agreement. Cash App Green, overdraft coverage, borrow, cash back offers and promotions provided by Cash App, a Block, Inc. brand. Visit http://cash.app/legal/podcast for full disclosures.* Check out Plaud AI and use my code CODESTORY for a great deal: https://plaud.aiAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy

Developers are like water: if you make your security protocols too difficult, they will find a way to flow right around them. This week on Dev Interrupted, bestselling author and OWASP Top 10 Project Leader Tanya Janca returns to unpack why vibe coding has officially made the list of the most critical security risks in software development. Tanya breaks down the psychology of bad code, explains why the modern software engineer has become the primary attack surface, and shares actionable strategies for shifting security left directly into your AI prompts. Finally, she provides practical, behavioral solutions for building a golden path that makes secure coding the easy choice for your engineering team. Register here: for the June 25th workshop, Life Beyond Tokenmaxxing, to learn how to measure real AI impact and ROI across the SDLC.Follow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelLeave us a ReviewFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's guest:SheHacksPurple: Learn secure coding from Tanya at shehackspurple.caDevSec Station: Listen to Tanya's bite-sized security podcast for developers at devsecstation.comSecure My Vibe: Download Tanya's free AI secure coding prompt library at securemyvibe.ca The Psychology of Bad Code: Read Tanya's insightful blog series on behavioral economics and application security on the SheHacksPurple BlogOWASP Top 10: Learn more about the most critical security risks to web applications at owasp.orgTanya's Newsletter: Sign up for Tanya's newsletter at  newsletter.shehackspurple.ca  Connect with Tanya: LinkedIn | Twitter/XOFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

This week on the Friday Deploy, Ben and Andrew unpack the sudden disappearance of Fable 5 and discuss whether Meta's aggressive pivot to AI data labeling is destroying its legendary engineering culture. The hosts also explore the rise of highly capable open source Chinese models like GLM 5.2 and why tech giants are considering them to slash skyrocketing inference bills. Finally, they dive into new research proving that as AI execution takes over, human domain expertise and strict production observability are more critical than ever. Register here: for the June 25th workshop, Life Beyond Tokenmaxxing, to learn how to measure real AI impact and ROI across the SDLC.Follow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelLeave us a ReviewFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's stories:KayfableWhy is Meta destroying its engineering organization?AI demands more engineering discipline. Not lessZ.ai's open-weights GLM-5.2 beats GPT-5.5 on multiple long-horizon coding benchmarks for 1/6th the costMicrosoft Mulls China's DeepSeek for Copilot, Probably to Trump's ChagrinAgentic coding and persistent returns to expertiseOFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

Yahoo is not just adding AI on top of existing products. It is using AI across product experiences, internal tools, engineering workflows, and modernization efforts.In this episode of The Tech Trek, Lee Zen, CTO at Yahoo, joins Amir Bormand to talk about modernizing at massive scale, moving from on prem infrastructure to the cloud, rebuilding internal tools with AI, and how engineering organizations need to rethink process when agents can move faster than people.Lee also shares how Yahoo views AI as a coworker, not just a tool, and why the next bottleneck in software delivery may be human judgment.Practical Takeaways• Modernization at scale often means operating in two worlds at once, keeping proven systems running while new cloud based services move faster.• AI can help teams move past legacy tools by reverse engineering requirements and rebuilding modern versions from scratch.• The real unlock is not only code generation. It is connecting agents to documents, chats, emails, production context, and internal knowledge with the right permissions.• As agents speed up execution, engineering teams need to rethink where human approval, judgment, and review should live.• The build versus buy equation is changing because some tools that were too expensive to build before may now be realistic to create internally.Timestamped Highlights00:31, Yahoo's mission and why the internet still feels hard to navigate02:01, Where AI fits across Yahoo products and engineering work03:30, The challenge of moving from on prem data centers to cloud based infrastructure05:27, How Yahoo has used AI to rebuild internal tools and leave technical debt behind07:25, Why agents need access to engineering context, not just code10:20, AI as a coworker and the shift from human speed to machine speed16:27, Why parts of the SDLC may need to change as AI increases delivery speedOne Line That Stuck“AI as a coworker, not just as a tool.”The Tech Trek is for technical leaders thinking through how teams build, operate, modernize, and adapt as AI changes the work. Subscribe or follow for more conversations with engineering, product, data, and technology leaders.

#355: Picture your engineering team a year from now. A coding agent doing the coding. A testing agent on tests. A security agent on security. An infrastructure agent on infrastructure. All of them wired into GitHub and Jira, all of them working right alongside the humans. Not science fiction either - Atlassian and GitHub are already shipping these features. So out come the stats everyone loves to quote. AI code introduces 1.7 times more issues. Half of it ships with security holes. Code duplication is through the roof. AI-assisted PRs take four to five times longer to review. The response to most of it: so what? If you have a way to detect the issue and feed it back, that is just the SDLC doing its job. Couldn't care less if it is 1.7x or 50x more issues - what matters is what is left at the end, per feature shipped. Security holes? You have scanners. Detect, fix, ship. The only real problem is when you skip the detection or sit on the fix for months, and that has nothing to do with AI. Here is the one stat that actually sticks: PR reviews backing up. Speed up coding and leave everything downstream at human speed, and you have not sped up delivery - you have just moved the pile from Jira tickets to pull requests. The review pipeline was built for human speed, and now it is the bottleneck. The blunt fix: stop letting AI write 10,000-line PRs, work in smaller chunks, and accept that the job is about to get mentally harder. Delegate the tedious work and what is left is the demanding work - architecture, taste, is this even the feature we should ship. The silly stuff, does every function have a comment, is it camel case, goes to the machine. Spend your time there and you are wasting your talent. Offshoring never worked when the only goal was cheaper - chase the cheapest engineers, then chase even cheaper ones, and you end up dragging the work back in house. Same trap with AI. Offshore to Opus, then Sonnet, then Haiku, then Llama on a laptop. If cheaper is your primary motivation, you are doing it wrong. The win is qualitative, not the price tag. Where does it land? Three people per product, end to end - frontend, backend, database, deployments. Augmented at every stage, not autonomous. A human still pushes the final button to prod, the way you never let a Jenkins pipeline deploy straight to production without a check. Full autonomy is coming the way self-driving cars came: not in a year, not everywhere at once, and not by flipping it on at 4pm on a Friday. Even when the technology is ready, you are not. And if you think none of this touches your job, there is a story here about a textile factory built in the eighties that ran on five people. Knowledge work is next. The only exception is a monopoly, and you probably do not have one.   YouTube channel: https://youtube.com/devopsparadox   Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/   Slack: https://www.devopsparadox.com/slack/   Connect with us at: https://www.devopsparadox.com/contact/

Karl Moll (Technical Project Advocate at FINOS) sits down with Grizz Griswold to discuss how CALM (Common Architecture Language Model) is acting as the structural glue connecting compliance projects across the banking ecosystem. He breaks down the momentum behind the Open SDLC Controls Framework and how these tools together build a secure, governable pipeline for unpredictable AI deployments.

What if the secret to fixing your overwhelmed SDLC is not a better AI coding model, but a smarter productivity context engine? This week on Dev Interrupted, LinearB founders Ori Keren and Dan Lines join the show to discuss the messy middle of AI adoption and the painful transition from the traditional SDLC to the Agentic Development Life Cycle. They unpack why the era of cheap AI experimentation is over, how rising token costs are forcing engineering leaders to prioritize strict business ROI, and how autonomous tools are fundamentally changing the daily workflow of developers.Register here: for the June 25th workshop, Life Beyond Tokenmaxxing, to learn how to measure real AI impact and ROI across the SDLC.Follow the show:Subscribe to our Substack Follow us on LinkedInSubscribe to our YouTube ChannelLeave us a ReviewFollow the hosts:Follow AndrewFollow BenFollow DanFollow today's guest:LinearB: Learn how to transform your SDLC and build an engineering context engine at linearb.iogitStream: Explore LinearB's workflow automation tool for routing pull requests at linearb.io/platform/gitstreamFollow Ori and Dan on LinkedIn: Ori Keren | Dan LinesOFFERSStart Free Trial: Get started with LinearB's AI productivity platform for free.Book a Demo: Learn how you can ship faster, improve DevEx, and lead with confidence in the AI era.LEARN ABOUT LINEARBAI Code Reviews: Automate reviews to catch bugs, security risks, and performance issues before they hit production.AI & Productivity Insights: Go beyond DORA with AI-powered recommendations and dashboards to measure and improve performance.AI-Powered Workflow Automations: Use AI-generated PR descriptions, smart routing, and other automations to reduce developer toil.MCP Server: Interact with your engineering data using natural language to build custom reports and get answers on the fly.

How do you build AI that actually understands you and the work you do? It all starts with having the right context.  We talk with Dropbox staff product manager Noorain Noorani and principal engineer Sean-Michael Lewis about the art of context engineering and how Dropbox connects to all the tools your team needs for work—so you get AI that works wherever you do.  ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck. Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

In this episode, host Sandy Vance chats with Brad Schoffstall, Vice President of Health and Compliance Programs at CGI, and Dr. James Peake, Senior Vice President and former Secretary of Veterans Affairs and Army Surgeon General. They have a wide-ranging and practical conversation about what it actually takes to modernize data infrastructure at federal health agencies. With Brad's 35 years at CGI and Dr. Peake's 16 years, this is a conversation grounded in hard-won experience rather than theory. Today's conversation is a refreshingly honest and deeply practical perspective for anyone working at the intersection of government, healthcare, and AI.  In this episode, they talk about: Federal health agencies are running some of the largest healthcare operations in the world, with the VA equivalent in size to a Fortune 5 company Data silos created by contract-by-contract procurement are the primary barrier to AI-ready infrastructure at federal agencies Federated data platforms allow data to stay in its own repositories while being discoverable, mappable, and usable across the organization Policy is often the biggest obstacle to data sharing, and changing it requires executive-level support and shared governance Technology is the third most important factor in transformation; policy and business understanding come first and second CGI improved NHS Spine performance tenfold while reducing infrastructure to a tenth of its original size, saving a million euros in annual expenses Improper payments across federal health programs run into billions of dollars annually and represent one of the highest-impact areas for AI-driven improvement AI for AI's sake is not the answer; start with the business problem and work backward to the data strategy Start small with two or three systems, demonstrate value, and build from there rather than attempting a massive all-at-once implementation A Little About Brad and James: Brad Schoffstall has wide-ranging experience, deep knowledge, and skills in information technology. He has led multiple digital transformation efforts. He has 37 years of experience with a diverse set of architectures, operating systems, languages, and technologies. His experience includes enterprise architecture, cloud migration, and hands-on development. He also has significant experience in business development and project management. He has implemented large, complex systems on platforms ranging from mainframes to Microservices. He has successfully performed many solution architecture and SDLC engagements that include characteristics like high-volume processing, DevOps, and automation. He demonstrates expertise in multiple service-based secure architectures utilizing multiple application and enterprise solution sets, e.g., Data Driven, Microservices, Cloud, etc. Dr. James Peake is an American politician and former lieutenant general who served as the sixth Secretary of Veterans Affairs from 2007 to 2009. In 2004, he retired from a 38-year United States Army career, having served as the 40th Surgeon General of the United States Army. After retiring from the Army, Peake served as Executive Vice President and Chief Operating Officer of Project Hope,[4][5] a non-profit international health foundation operating in more than 30 countries. While at Project HOPE, he helped to orchestrate the use of civilian volunteers aboard the Navy Hospital Ship Mercy as it responded to the tsunami disaster in Indonesia and also as part of the Hurricane Katrina response aboard the Hospital Ship Comfort. Just before he was nominated Secretary of Veterans Affairs, Peake served as Chief Medical Officer and Chief Executive Officer for QTC, one of the largest private providers of government-outsourced occupational health and disability examination services in the nation. 

BONUS: Why More Code Doesn't Mean Better Software — And Where AI Actually Helps Your SDLC Most teams are adopting AI to write code faster. But what if code generation isn't your bottleneck? Mooly Beeri has spent 25 years diagnosing where software organizations actually underperform — from Microsoft to Philips to automotive — and his message is clear: measure before you automate, and tie every AI investment to a business KPI. The Pattern Debugger's Origin Story "I've been identifying patterns way before AI was doing that. One of my first jobs was Microsoft, and I got the opportunity to work in engineering excellence. Every single simple improvement would make the lives of so many people better and the code better and the products better."   Mooly's career started at Microsoft in engineering excellence, where he discovered his passion for finding process areas that need improvement. From there he built the first software centre of excellence for Philips, spawned it into a separate business, and has been doing the same process excellence work across healthcare, telecom, and automotive ever since. His framework: understand where you're bleeding quality, revenue, or budget — then intervene there, not everywhere. Improvement Doesn't Mean Progress "There are too many efforts to improve too many things that don't really matter. The ability to tie a specific improvement to what actually means progress for a business — that, for me, is one critical component that's missing in many transformations."   Mooly's core insight applies directly to AI adoption: everyone has an improvement plan, but few can answer "how does this improvement improve business performance?" If you ask that one additional question, you can probably cancel half your improvement projects — the ones that make people feel good but don't move the needle on time to market, quality, or cost. The Code Generation Trap "It's like saying a book author is more productive because they write more words. The unit of work is not the number of lines of code they produce. The unit of work is a piece of code that works, that is tested, that is fully reliable, that meets a customer expectation, and eventually generates revenue."   Data from Faros AI shows individual developer PRs went up 98% with AI tools — but organizational delivery actually dropped 1.5%. More code, same or worse outcomes. Mooly explains why: most organizations invest in code generation not because it's the most effective thing to improve, but because it's the easiest step to automate. There are 35 steps in the SDLC. Picking code generation gives you a 1-in-35 chance of striking gold. As the saying goes: hope is not a strategy. Where AI Actually Works in the SDLC "The best usages would be in areas of the SDLC where there is a lot of data that needs processing and needs some detection of patterns — where AI is really, really good."   The most successful AI applications Mooly has seen with clients:   Defect root cause analysis — training AI agents on thousands of Jira bugs to find patterns humans can't see. In one healthcare client, AI analysis revealed that "false positive" bugs were actually compromised requirements — the dev team was closing real deviations as unimportant because they didn't have time to fix them Code review enhancement — AI scans incoming defects and generates a live, evolving checklist so reviewers spend their limited time checking for the most probable problems Test generation — unit, component, and functional test creation where AI can leverage existing test patterns and requirement data Requirements review — correlating requirements against strategic objectives, OKRs, and historical defect patterns to find contradictions before coding begins The Thinking Process You Can't Automate "The developers going through the process of converting requirements into code — it's actually a thinking process. It creates a lot of discussions with the product managers, a lot of back and forth, which help refine the requirement. This entire exchange is gone out the window when you have AI generate the code in 5 minutes."   When AI generates code instantly from requirements, it eliminates the human feedback loop that catches contradictions and incomplete specifications. The FDA has recognized this: every AI-assisted step in medical device software must be guardrailed by human activity. If you generate code quickly but still need a human review, the speed gain disappears. The value of coding was never just the code — it was the thinking. Map Every Investment to a Business KPI "If your uncle ran a bicycle repair shop and you said, let's advertise in the local newspaper, the first question he'd ask is: how many new customers will we get? The business logic hasn't evolved so much. If you want to do something — how will this impact your revenue, your customer retention, or your cost of producing goods? If you can't answer these things, don't invest."   Mooly's advice is deceptively simple: before adopting any AI tool in your SDLC, ask yourself which of three business outcomes it will improve — faster time to market, higher quality (fewer customer issues), or better margins (lower execution cost). If you can't draw a direct line from the AI investment to one of those outcomes, you're doing improvement theatre. About Mooly Beeri Mooly Beeri is CEO and co-founder of BetterSoftware, a consulting firm with over 25 years helping companies across healthcare, telecom, and automotive transform how they build software. His work focuses on diagnosing where software organizations underperform and designing targeted interventions — not blanket transformations.   You can link with Mooly Beeri on LinkedIn.

This Open Source Startup Podcast episode has our co-hosts Robby and Tim in conversation with Zohar Einy the Co-Founder of agentic SDLC platform Port.They have a few open source projects including ocean which allows third-party systems to integrate with their developer portal.Port is positioning itself as the infrastructure layer for the agentic era, evolving the traditional internal developer portal into what its founders describe as a “system of record for agents.” The company believes the future belongs not to vertical point solutions, but to flexible platforms that organizations control themselves, enabling anyone, from developers to non-technical employees, to become builders. Rooted in the founders' experience of overwhelming developer workflows and ticket volumes, Port aims to centralize engineering context while making both humans and AI agents more self-sufficient. Their hybrid approach combines openness and commercial software, with public roadmaps, community contributions, and open-source integrations helping customers extend the platform while maintaining governance and control.The conversation also explored how AI is reshaping engineering organizations. Port is focused on creating the infrastructure around agents rather than building the agents themselves, providing visibility, permissions, governance, and a unified “context lake” for agent activity. As companies deploy increasing numbers of coding, security, SRE, and product agents, leaders need a control plane to understand what agents are doing and ensure they operate safely. The team is already seeing customers use Port to automate large portions of engineering support workflows, and they believe enterprises are adopting AI-driven workflows as quickly as, or faster than, mid-market companies. Internally, this pace of change requires constant adaptation, particularly across go-to-market teams, where education and flexibility have become more important than rigid playbooks.

AI coding tools promised to make development faster — and they delivered. But here's the problem nobody talks about enough: when you speed up coding, you don't eliminate the bottleneck in the SDLC. You just move it. And for most teams, it lands squarely in QA. In this episode, Joe sits down with Vilhelm von Ehrenheim, Co-founder and Chief AI Officer of QA.tech, to dig into how agentic AI is reshaping software testing from the ground up. Vilhelm brings serious ML credibility, he helped build Motherbrain, one of the earliest production LLM systems in venture capital, and he's now applying that experience to one of the hardest problems in software delivery: testing at AI development velocity. You'll learn how QA.tech's behavioral knowledge graph gives AI agents the context they need to actually understand your application, why validating user intent beats checking element identifiers every time, how autonomous agents can review PRs, reproduce bugs from Slack messages, and generate targeted tests without a single line of test code ,and what the tester's role actually looks like when agents do the heavy lifting. If you're wondering whether your QA practice can survive the pace of AI-driven development, this one's required listening.

I'm excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World's Fair! We'll streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However we did not hold back with this interview - we asked all the burning questions about uptime and Copilot that we know you have in your minds. Lets go!For almost two decades, GitHub has been the home of software, where both open source and closed flow, through commits, pull requests, reviews, actions, etc.This ecosystem flourished as open-source maintainers and contributors would continue shipping code for the benefit of the community. However as coding agents began to ship mass quantities of code - growing 1400% in 2026, it marked a new era that was both extremely exciting and challenging for GitHub.While these agents help more people ship more projects, they also significantly increase the floor of how much code is shipped, how often it is shipped, how many people commit code, and basically orders of magnitude multiples in every dimension of GitHub infrastructure:Now GitHub inevitably experiences more pressure on their infrastructure which was originally designed around human developers moving at human speed. This has resulted in a very publicly notable uptime story:So it begs the question of whether current systems around code can absorb what AI produces. Can CI/CD keep up when every idea becomes a build? Can open source maintainers survive floods of AI-generated slop contributions? Can GitHub preserve the human social contract of software while becoming the operating layer for agents?Which brings us to the perfect person to answer these questions: GitHub COO Kyle Daigle. In this episode, he joins swyx to unpack what happens when AI doesn't just autocomplete code, but starts changing how companies operate, how open source works, how pull requests get reviewed, and how GitHub itself has to scale. We go deep on GitHub's internal AI workflows: micro-skills, WorkIQ, MCP, Slack, Teams, email, Copilot workflows, the new Copilot desktop app, CLI, cloud agents, and how Kyle uses agents to look backwards across company context before deciding what to do next. Kyle also reflects on GitHub's history building webhooks, APIs, Actions, npm, Dependabot, and Semmle, why the AI era is breaking GitHub in new ways, how Actions became a general-purpose compute layer, and what Copilot becomes after code completion.Full Video PodWe discuss:* Kyle's expanded role across GitHub* How AI got Kyle coding again after years in leadership* Why GitHub rolls out AI through existing workflows instead of forcing new tools* WorkIQ, MCP, Slack, Teams, email, and GitHub as company context* Why massive “mega-skills” are giving way to small, atomic micro-skills* How AI changes summarization, communications, marketing, and analyst work* Why former developers in leadership may have a unique advantage in the AI era* Kyle's “15 agents on Saturday” workflow* How Kyle built an AI-generated executive presentation for CRO/CFO teams* Why AI changes the chief of staff role without removing the human work* GitHub Actions, webhooks, arbitrary code execution, and secure agent compute* The npm acquisition, supply-chain security, 2FA, and token invalidation* Slop forks, vendoring, and whether AI agents change dependency management* What pull requests become when most PRs come from agents* Prompt requests, vouching, AI review, and trust in open source* What counts as a “developer” when AI lowers the barrier to building* GitHub Spark, low-code, and why GitHub refuses to hide the code* 14x commit growth, Actions load, databases, monorepos, and availability* Copilot's evolution from completion to CLI, desktop app, cloud agents, and SDK* Context, memory, rules, and making GitHub “act like Kyle wants it to act”* Ambient AI, OpenClaw, enterprise security, and the new operating system for agents* What swyx should ask Satya Nadella about Microsoft's AI futureKyle Daigle* LinkedIn: https://www.linkedin.com/in/kyledaigle* X: https://x.com/kdaigleTimestamps00:00:00 Introduction00:03:36 Why AI Got Kyle Coding Again00:07:04 Running GitHub with AI: WorkIQ, MCP, Slack, Teams, and Skills00:15:39 The Golden Age for Former Developers in Leadership00:17:31 15 Agents on Saturday and AI-Generated Executive Work00:20:20 How AI Changes the Chief of Staff Role00:21:45 GitHub's History: Actions, npm, Webhooks, and Open Source00:28:45 Slop Forks, Vendoring, and AI Dependency Management00:33:57 Pull Requests, Prompt Requests, and Trust in Agent-Generated Code00:41:21 GitHub Stars, 200M+ Developers, and the New AI Builder Wave00:45:15 GitHub Spark, Low-Code, and Why GitHub Still Shows the Code00:47:38 GitHub's Hardest Era: 14x Growth, Reliability, and Scale00:59:21 Actions as the Compute Layer for CI/CD and Automation01:02:04 The State and Future of GitHub Copilot01:08:24 Ambient AI, Background Agents, and the Future of the SDLC01:13:09 OpenClaw, Enterprise Security, and the New OS for Agents01:18:03 Build Announcements, WorkIQ, FoundryIQ, and Microsoft Context01:21:41 What Should swyx Ask Satya?TranscriptIntroduction: Kyle Daigle's Expanded Role at GitHub and MicrosoftSwyx [00:00:00]: We're here with Kyle Daigle, COO of GitHub. Welcome.Kyle [00:00:07]: Hey, thanks for having me.Swyx [00:00:08]: You're not just CEO of GitHub. People know you as that. You have a new role.Kyle [00:00:11]: So I have an expanded role now. I've been working at GitHub for thirteen years and doing all things developer. Joined as a developer myself. And now, I'm also responsible as the CMO of Developer for Microsoft. And so all the kind of learnings and passion for developers and how we work with them and how we communicate and how we bring our products to market, we're also bringing that expertise to the broader Microsoft ecosystem and helping every developer that uses a Microsoft product or would like to have a sort of similar experience that they've had with GitHub over the years. So it's a different role in some ways, but it's also just building on the experience that I've had at GitHub of just sort of tell the truth, be authentic, show people how to use it and then let the products speak for themselves. Now just doing that with, all of Microsoft.Swyx [00:01:09]: We'll be releasing this in conjunction with Build. You got lots of stuff planned, and we can sort of touch on that whenever it's appropriate. I think one of the interesting things is I rarely meet a COO who's also a CMO. I think you're a very outward facing and you're very confident publicly. That's rare. Do you actually view yourself as COO? What's What is your thing?From GitHub Developer to COO/CMO: Building the Platform and Operating GitHubKyle [00:01:33]: I think for me, it's been funny. The titles have always been, a— have always felt a little strange to me. I joined GitHub as a developer? I wrote so much of theSwyx [00:01:46]: Let's bring that up. You wrote the back ends?Kyle [00:01:48]: I was going through, I was going through, some old photos, when folks were talking about how things were being built or how there was a build GitHub. I built, webhooks and worked with teams building the API, built the platform layer. Anything that integrated with GitHub, up until really twenty eighteen, I built or ran the engineering teams. And that's kind of where my the beginning of my passion always was helping people build things, deliver them to, their customers. And so being a developer, building for developers was always super unique. In a— I think as my role expanded, it became my ability to talk to not just developers, but also enterprise customers or business leaders and have this translation layer. And then through all those years, GitHub has always operated pretty uniquely. Post-pandemic, working remotely was not as novel as it was when GitHub started in two thousand and eight. But all that expertise of running remote teams, doing it well, became this sort of bigger role, ultimately turning into the COO role of how do we operate GitHub in the way that GitHub's always operated after the Microsoft acquisition. And kind of so on from there. So like for me, I think the— I've, I still code. I love coding but the problem has always been, people. It's a much harder problem to both support our own employees, a harder problem to communicate to developers and enterprise buyers what we're building why it matters, ‘cause those are two very different messages. And so getting to work in the mix of COO, CMO, also just being a dev, I think is what's kept me at GitHub for so long.AI Workflows for Leadership: Commits, Retrospectives, and ContextSwyx [00:03:40]: Apparently, you have— your commits have gone up. What's this? What's going on?Kyle [00:03:45]: Rui's called me out pretty aggressively. So I think— as you can imagine, right, you can see my normal era of being a dev In the twenty thirteen, twenty fourteen era, and then moving into management, and then ultimately the COO role. I think what you see there is me, really getting back to coding thanks to AI. I— similar to, attaching problems between how to market and how to operate a business and how to code, I find, building agents and workflows that are connecting very disparate problems to be what's driving this. So that's, some of it's writing software. A lot of it is, connecting a ton of a different data sources to, help me out. But that is completely me really diving in on the AI side in trying out our tools, trying out everyone's tools, But building for me, building for the non-technical leader, though I'm technical and how we're, able to use these tools more than just the simple, call and response that I think a lot of the non-technical, your employers, you have to get— you have to use AI, and so everyone uses, ChatGPT or Copilot or Claude or whatever. To really get into, how is this going to help me out, it— I find that it's not the I need to write a blog post, I need to those simple examples. Helping people find the workflows of, “Okay, I need you to go through all the PRs today. I need you to go through everything that we've posted online. I need you to go through what we did the last three months. Go through all of my Obsidian notes for any mentions of this then go through my transcripts at work.” We use, Teams, so, using WorkIQ, go call that MCP server, grab all the transcripts, go through all the Slack, and then build me out the plan of, what this week's messaging actually was. That's something that was, impossible because for me, I find AI in a what most of this launch here is actually, less building forward. It's actually, a recursive loop backwards. I'm always looking at what had happened first. Go back through the week and tell me what we did, what worked, what didn't work? And then tell me in the next three or four days-What would you tweak based on this sort of like looking backwards and then looking ahead a little bit? I find that to be so much more valuable, especially for like non-technical, because that retrospection is actually LLMs are very good at that. Like finding all the patterns, pulling them out, and then applying that retrospection to just a couple of days or just like a short period of time. Is all a bunch of apps that I've built and launched a bunch of, internal tools. I use the new, GitHub Copilot app, the desktop app with workflows. Every time I crack open my laptop, it's running workflows for me. It's just a ton of different stuff and of course, it all ends up on, it all ends up on GitHub.Swyx [00:06:47]: Of course. That's where, that's where, stuff is hosted. Man, there's so much to ask you. I was going to leave the how do you run a company with AI thing at the end. I have to ask one— double click one thing. You said, you are looking back at the week. You're, you're understanding what happens. When you say we That's three thousand people. How?Rolling Out AI Internally: Skills, CLIs, and Company ContextKyle [00:07:09]: I think when we started rolling out AI internally beyond engineering, right? One of the things that I was really, passionate about is like we have to do this in a way where no one has to change how they work. I don't want to have to teach you a tool. I don't want to have to teach you something new. And so for us, we tried out a few tools. Most of them don't work because I got to get you on board? I got to teach you how to use it. What we've actually ended up doing is we've built like a set of skills internally. We have we each have our set of skills, and we've just been distributing even to the non-technical folks, the CLI. And then effectively, we're just giving it access to like read about everything that we're writing. So that's for us, that's usually GitHub, Teams, Email, and Slack. So Teams for, video chat, generally speaking.Swyx [00:08:03]: Teams and Slack?Kyle [00:08:04]: so we use Teams for video communication, but we don't use it for chat. W-we— GitHub for a long history, right? We're alwaysSwyx [00:08:13]: Also SlackKyle [00:08:14]: Talking about ChatOps and like everything is built into Slack. Like every command, every flow.Swyx [00:08:18]: So even though you have been acquired for I don't know, eight years nowKyle [00:08:22]: we stillSwyx [00:08:23]: You still use Slack?Kyle [00:08:23]: it's a purpose-built tool for us, and I think the reality is that moving off of it would be so bluntly expensive? Simply because all the tooling is, baked in with that paradigm. And they both have their pros and cons but they don't work the same way at all. We still use a bunch of different tools Because it's the purpose-built tools that We need. And thenSwyx [00:08:47]: Well, the same doesn't go for the rest of Microsoft, presumably.Kyle [00:08:50]: like the like various teams like operateSwyx [00:08:53]: They make their own decisionsKyle [00:08:54]: Various ways. I think it just matters what you're trying to what you're trying to do. But we do we do work across kind of every tool that we use, and then by giving everyone access to all of that context and the new WorkIQ MCP server, which is quite cool if you do live in the M365 like world. I can ask it all these backwards-facing questions, and it's incredibly important for our teams that are working remotely. There's a lot of stuff you miss when you're not in an office, and we are spread out all over the world. So most of that is looking back. And then we post, we post either auto-automatically into GitHub issues or discussions, these sorts of like findings or like our industry reports. Like what's happening this morning, today, yesterday. A little automation gets run. We'll use the app. We might use GitHub Actions like with, our agentic workflows just to go do that run, and then we push it into GitHub, and w-we keep having a conversation. So usually for us, it's about that sort of like looking back, looking forward on the non-technical side. And then of course for a lot of those folks, it's also building an app, pushing it to GitHub pages or pushing it somewhere to host it et cetera. But it's just like enabling everyone with that power of it's going to take me a week to figure this out. Instead, we're going “Okay I built a skill. Let's put it into a repo. We'll all share that skill together, and then we'll use the CLI or now the app-” “just to run it.”Micro Skills vs. Mega Skills: How GitHub Uses AI at WorkSwyx [00:10:26]: All right. I think, I think we're going straight into like the team management and productivity thing. I think a lot of people are getting various levels of LLM psychosis. How do you manage the bloat of skills? Like everyone Has their thing, and they're Like trying to promote it to the rest of their peers in their org, right? And obviously, whoever becomes a skill influencer internally becomes like an AI leader, right? Of sorts. I assume you have those.Kyle [00:10:50]: like I think we haveSwyx [00:10:52]: And I assume it's a mess a Yeah.Kyle [00:10:54]: there's like I— like I think the reality is there's two pieces. Like first is I think that we're ending the era of these like massive, beautiful, perfect skills that are just like not any of those things. ‘cause for a while, right every tweet every day is like go download the skills, the perfectly managed thing to do this entire workflow. And I think that like what we've found and what— I was just with my team, this week, and we were talking about the skill side, and we're really talking about these like incredibly micro skills that are just doing one thing for us very well Versus a skill that's going to do I said, that full report. That doesn't really exist on our side anymore. It's usually how do— like a single skill that's going to identify the most important marketing information given any MCP server. Like this is the most important thing. Less about stitch a bunch of tools together and have it produce this mega output because then weeks go by, months go by, things change, and you want to tweakSwyx [00:11:58]: It's brittleKyle [00:11:58]: Your mega skill and you're screwed? You can't do that. And so now we're really just talking about the Legos we're using and just letting the instruction book be something we're all putting together. Whereas I think a lot of AI skills for a while have been that mega instruction book style.Swyx [00:12:15]: I've, thought a lot about Postel's law. I don't know if that's a term that is, means things to folks. It's the idea that you should be liberal in what you accept and strict in what you output, right? And I think that's like a good framing principle for skills. This is my skills, obviously on GitHub. I feel like everyone should have like how like some repos In GitHub are special repos? I feel like we should sort of reify the slash skills and everyone like give it some kind of special presentation. Anyway, so, yeah, this is one of those like download Download anything, transcribe anything, and then you can string together the atomic skills that do one thing well Into like some kind of orchestration skill that calls other skills. I assume, does that match?Kyle [00:12:56]: I like I think so. I think that theSwyx [00:13:00]: Summarize anything.Kyle [00:13:01]: Like I think the- For me, summarizing something for I do communications and PR and analyst relations and marketing and customer activities, and so my summarize everything is very different for each one of those like Contexts. What ‘Cause if I'm summarizing something for an analyst, that's a very different thing than, probably how I'm going to summarize something for like a customer meeting or an engagement. So that's I think like the difference when we're talking about the like the tools I might use on Saturday or the skills I might use on a Saturday when it's just for Kyle. Yeah, those are kind of like they have an atomic actual tool underneath or maybe skill, and then Kyle cares about X. But I think when we're talking about work and enabling the the marketers, communicators there, it's the atomic, this is what good summarization is, and then this is what I care about as for marketing for communications For whatever. And that I think is like the interesting matrix problem when we go from like a developer set of concerns to all kinds of different professions, is that what that word means to me is different than it means to you is different than it means to the analyst or the salesperson, and that's where I think the matrix mess is that we're starting to like still starting to find. It's about these mega skills but they're all just slight permutations, but those permutations are really important. It's the difference between someone reading this and going “Did AI make this?” what Or “This makes total sense, and I would expect this when I'm giving a briefing to Gartner,” or like whatever else.Swyx [00:14:37]: I think the beauty of it maybe is that you don't have to be that careful about what goes in there. It doesn't have to exactly fit as long as it like roughly is contained in there. I used to complain about plugin hell, basically. Like when you have a framework and then you have a hundred things that you need to integrate, everyone does like the GitHub used to be bloated full of these things. And now we don't need them anymore ‘cause now you just use skills.Former Developers in Leadership: AI as a Creation MultiplierKyle [00:15:00]: And like I think the most magical thing is the just that like I can just also crack it open. Like Like yes, I could go like change the how the plugin is coded, or like I could go do that now with AI, but I think there's just something more magical about getting a response back and being “That's not right,” and then you just crack the skill open, you just type English words and it's different. That building block is just, I think very unique. Once I get everyone to kind of understand how to best how to best make those changes to get the most power out of them.Swyx [00:15:36]: Is there a— you have a your peer group that Of people like you. Is there a common framing for Something I'm feeling is, which is true, is that is this a golden age for former developers who are now in leadership? Because you can wield the tools, you would know the right words, you're maybe not too close to the details. Doesn't matter. But like you're more effective than someone who doesn't come from that background.Kyle [00:15:59]: I think that like the secret has always been your ability to identify patterns and solve problems, and I think that for folks that like myself that don't code day to day anymore, that has made me successful as a developer, made me successful as a COO and now CMO. And so now that I have access to get and write code, I'm now applying that sort of like pattern finding and problem solving, and I know enough still about how to then go and say, “Oh, I want to make an app, but I don't want to break into jail or create something that's not going to be able to work or to be deployed scale or whatever.” that ability to apply all that additional business knowledge and still code I think is what makes that so interesting to me. Slightly different than I think some of the other like technical leaders that became business leaders and now are going back to their apps and updating them. Good for them? But I think the more, much more interesting thing is, well, now I have this whole new set of expertise over ten plus years. Why not take that and use that as a developer with these AI tools? So I definitely think that makes me more powerful, but I think that's true for like every dev as well. Most of the dev friends I still have also have some other underlying skill and passion. There's really talented, very kind of linear computer science software devs, absolutely. I just find that the folks that came from a different career, went to school for something else, went off and did this random thing, and then became a software dev, or were a dev, did a random thing, came back. Learning that extra set of information, learning those extra skills, and now having the power of an AI where I can crank up fifteen agents on Saturday while my kids are doing lacrosse, That's like really powerful. And I think it gets me back to that feeling of like creation, and it's very hard to replicate that in most other senses? That first time you build an app and you click it and you show someone that's magical. And so being able to do that not just in code, but across all kinds of different assets that's, that's huge. We were doing we're doing our every year we do our revenue planning. We talk about okay, what is it going to look like for next year? And of course as you imagine, there's, slideshows everywhere talking about what are we going to talk about, what's the narrative, et cetera. And so as you said I'm “Okay, well, I could probably just like build something to build this and then that way I don't have to go build the whole spreadsheet or I have to pass it to my team.” So we went through this process, and I got all the information and used the skills I mentioned. I built like a little app just to make it so I could look at some of the information in a SQLite database, more easily. And I ultimately built this entire presentation without touching any of it and I was “Okay, I'm just going to present this to our CRO, the CFO, their teams,” without mentioning I'd built it with AI. I like built a skill to make it look very much not AI driven. Just not pretty.AI-Generated Presentations, Human Taste, and the Changing Chief of Staff RoleSwyx [00:19:03]: Like a design. Yeah.Kyle [00:19:03]: Not pretty. But just like very clearly not AI. Kind of like don't do anything interesting.Swyx [00:19:08]: That's, yeah, that is valuable.Kyle [00:19:08]: Just go Exactly. We did the whole thing through. It used my notes from Obsidian, it used all the context I mentioned before, the plans, and Never came up once that it was AI generated.Swyx [00:19:20]: It didn't matter.Kyle [00:19:20]: Never once. D It didn't matter. And so now I takeSwyx [00:19:23]: This is a toolKyle [00:19:23]: I can take that tool and go, “Look, I don't want you to go build slideshows.” They're just helping us share information with each other. If this thing can do it With a little bit of crafting from you and then we can look at it together, awesome. There's no value in all that extra work. I think that the ability to, make it look humanly bad and and build a little app to, manipulate the data I think is part of, that upside for devs that are now in leadership roles. Because, the thing that I feel like I said before, this that's all a people, that's all a people problem. I know if you've used a coworker or not to build a slide deck, unless you spent a bunch of time to not do it.Swyx [00:20:07]: I know, but like it was so, I think there's a certain charm to just being blatantly AI. ‘Cause I think that you're well, you're just honest about There may be mistakes here that I cannot vouch for. So how much value is there? But anyway I think, actually the real question I want to ask is, there's a— You were a chief of staff To Thomas. And in the pre-AI world, the that job would've been a chief of staff job of like Can you prep me these slides and all that? And now you do it yourself.Kyle [00:20:35]: I still, I still have a chief of staff. Because, the difference is it's sort of the discussion every time we have some sort of technology evolution is it's not that the jobs the roles don't all go away, they just change? And so yeah, I don't have someone spending all their time building out slides for me and presentations ‘cause I don't need that anymore. But now I need that person that is able to go and find all the different connections between humans in those discussions to help me find out, okay, I should be meeting with this group and this team, and they have an opportunity, and I'm going to be in San Francisco today, I'm going to be in Seattle tomorrow. Those sorts of human connection aspects are still incredibly valuable and has always been a big part of that chief of staff role. But now just like chiefs of staff are not opening up, letters to process, they're doing emails. What It's the same thing. And now they're, they're not building out as many of these presentations because they have the the ability to have a AI take it on for, and share that with me and great. Let's keep moving ‘cause it's allowing us to go faster and make better decisions more quickly.Swyx [00:21:45]: Awesome. Well, so we can dive into more sort of, Productivity insights as you go. I did want to do a little bit of a brief history of colleague and hub. Because, we started here. And then you also involved the NPM acquisition. I did, I do want to touch upon that. And then more recently, I just want to bring up to present day where we're having uptime issues Which transparently we've already Addressed publicly, but we'll, we'll discuss in the pod. Did I miss anything? Like what, any other major highlights? Obviously, it's, it's a lot of years to cover.A Brief History of GitHub: Webhooks, Actions, Acquisitions, and Platform EvolutionKyle [00:22:15]: No the I think one of one highlight was right before the acquisition closed in twenty eighteen, I got to launch the first version of ActionsSwyx [00:22:27]: OhKyle [00:22:27]: At GitHub Universe. So it was OSwyx [00:22:29]: They're that young?Kyle [00:22:30]: It was October of twenty eighteen, I think. Yeah. Yeah.Swyx [00:22:33]: Gee, Jesus.Kyle [00:22:34]: I got to I was the engineering leader on that project and got to launch that. And then, yeah, we did acquisitions of NPM you said, Semmle, Dependabot Pul Panda a whole bunch of things. That was a bigSwyx [00:22:47]: Pul Panda.Kyle [00:22:48]: Abi is doing well.Swyx [00:22:51]: DX. Holy crap.Kyle [00:22:52]: Did well on DX. I and like that was a that was the big shift, after the acquisition. I had to join the sort of business side.Swyx [00:23:00]: So I need to hit you on some of these things ‘cause you were there. Right? And how often do I get to talk to someone who was there? But yeah, Actions. Is that the number one source of security issues on GitHub?Kyle [00:23:11]: Oh, sh I think that the number one source of, security issues is probably like all, the literal code in everyone's like underlying repositories. I would say back further than that is, if you remember I had to show in this graph was this is, I'm, didn't say this before, this is ultimately webhooks.Swyx [00:23:30]: You yeah.Kyle [00:23:31]: Like circa whatever it was.Swyx [00:23:32]: It says Hookshot in there.Kyle [00:23:32]: I forget. Yeah. Yeah, Hookshot's in there. And so like back then, it says GitHub Services. Do you see, it says Hookshot FE for front end, and then it says GitHub Services. GitHub Services back in the old days, right? You we had a repository that was Ruby code, and you could write any Ruby code in there, and then we would execute that On your behalf As a service, and then that way if an if you were trying to integrate with something, it didn't we would run it for you.Swyx [00:23:57]: And of course no containers ‘causeKyle [00:23:58]: No, ‘cause it wasSwyx [00:23:59]: Well, no containersKyle [00:24:00]: Twenty fourteen. And so there was some isolation obviously, but it was mostly the separations on the server level. That's like an example as long as the very old version of Pages, which ran on its own containerization infrastructure, not on Actions.Swyx [00:24:15]: Which like all-time great product.Kyle [00:24:16]: Pages powers the internet at this point to some degree. Those were places where like clearly there were no like issues like to my knowledge. But it was those things where I'm looking at and going “Okay, well we can't be running arbitrary Ruby code,” like on everyone's behalf. Then containerizing all of that up intoUh into actions now where yeah the containerization, is r-really good. The pinning most folks aren't pinning it the like to a particularSwyx [00:24:48]: ImagesKyle [00:24:48]: Sha, et cetera like their workflows, and so that's a big that's a big place Of pain for folks if they're just doing similar to any dependency management, just V1 or newest or latest, I think. But, that journey from that day to “Okay, we're just going to run all this arbitrary code, and, it'll basically be okay,” to now, no, we have, really good containerization. We have a new, underlying, ag-agent, containerization, service. It's like we're using it under the hood. It's through Azure. They recently announced it. The Azure, Dev Compute, but it's, very fast, very fast compute to be able to, spin up your own cloud agents, or whatnot. We're using it under the hood for some parts of the new,Swyx [00:25:36]: Microsoft Dev Box?Kyle [00:25:37]: No. Dev Compute, yeah.Swyx [00:25:41]: Hmm. Not finding it just yet.Kyle [00:25:44]: Oh, it's, it's in there somewhere.Swyx [00:25:46]: All right. Well, we'll cut that out.Kyle [00:25:47]: Sorry. But with, Dev Compute, you can, run, really fast, spin up really, small VMs really quickly, so you're doing a tool callSwyx [00:25:58]: Same conceptKyle [00:25:58]: Just do it containerize exact-exactly. So we're using that so definitely moving that direction to protect us from every every piece of code that we're ultimately running.Swyx [00:26:07]: look, that grows into the full SDLC? Code hosting was just the start and and then it's grown beyond that. Let's talk about NPM may-maybe ‘cause I think that's also, a very major point in the industry. I do think, it was looking for a home. It was, kind of struggling as a business, right? I don't know, I don't know how you would characterize that whole acquisition and how itNPM, Package Security, and Keeping the Internet RunningKyle [00:26:33]: like when we were talking to the team, I think the big thing for the both of us was to find a way to keep NPM, which was basically powering the internet then and way more so now to some degree running. Keep it going keep continuing to scale. It was having scaling problems, if I recall, back at that time. They were doing some rewrites. ItSwyx [00:27:00]: that's cute compared to now.Kyle [00:27:01]: Well, that's the thing is like when I'm talking to folks now, there's there's so many more underlying uses of NPM than there were back when we had them join in with GitHub. But that was ultimately the goal. It was really okay, we used to have pages. We have, the world's code. Let's make sure that we can keep NPM running well for the world. And we put a bunch of time and investment into fixing some of the underlying backend, changes, some of which we talked about some of the manifest work, et cetera. And then now, really trying to bring the the security posture of NPM up to speed. But, it is a unique challenge in that every move that we make to make it more secure will break a lot of people. And security is paramount. And also, we take it very seriously. We're, the any time that we have a problem with GitHub or we make a change that makes us more secure but hurts, there's, a snow day for developers or a really bad fire that they have to go put out. And so we've, have changed the 2FA policies. We've changed the way the tokens work. When we find tokens that have been exposed or potentially, exposed, we invalidate them, andSwyx [00:28:22]: I love that feature in GitHub. Yeah, it's greatKyle [00:28:23]: That creates issues, but, the but that's the thing is we're trying to push the community, forward without necessarily, doing something that is going to break the contract that's been for 15 years or close to it or some amount of years on NPM.Slop Forks, Vendoring, and the Future of Open Source Supply ChainsSwyx [00:28:43]: I think the— So now we're talking about, open source and publishing. And I think there's something here with what people are calling slop forks, which, I think Malta from Vercel is doing. And, part of me thinks, well, the way to get past any vulnerabilities, we just, let's just get rid of the concept of NPM. And we only publish source code. And anytime you want to import it you have your coding agent look at it and then adapt whatever subset you're going to use into your vendor it. But, the AI vendor it. Is that realistic? I don't know. Is it— Will that solve all our security issues? I don't know.Kyle [00:29:24]: I don't think it'll solve I so Mitchell was just talking Mitchell Hashimoto Was just talking about this today, and I think that I-in some ways, it's all all things, old or new again? Yeah, absolutely vendoring everything. Like I do I do remember twenty thirteen, twenty fourteen.Swyx [00:29:42]: This is Yeah. Let's, we must return toKyle [00:29:43]: That's what is We were vendoring everything. We were having actual discussions around, or at least I remember we were “Should we take this full thing?” “Why is this so big? We only need this one file.” And so I do think there's something true there where having either taking only what you need or the dependencies just getting incredibly small over time, I think will help to some degree, but it's not going to solve the fundamental problem, I don't think, because the vulnerabilities in an agent looking at them, there's time and time again, there's a million different ways in which we can convince an agent that this thing is, secure or not and pull it in. Or we can do static code analysis or runtime testing to say whether the code works or not. That is, I think, the step that needs to continue to be, invested in. The question is just on, how much scope. Should it be this enormous project that I'm pulling down, or should it be this piece? Either most companies are running some amount of security checking on the on the packages that they're bringing in or vendoring. That I think won't change. That's like what advanced security does to some degree, Socket does some degree. Like everyone is doing a piece of that. How we each do that like especially when we're talking to enterprise customers, is just like very different. No there's no one wants one single way to do it. And I think that's always been GitHub's, unique position in the world. I talk a lot to maintainers, I talk a lot to folks about this. It's we're— we rarely start like a process and a practice and like push it onto the community. We usually wait for the sort of like RFC process socially or literally, everyone agreeing, and then we'll cement something in. Because otherwise we'reMaintainers, RFCs, Vouching, and the Social Layer of TrustSwyx [00:31:35]: That fits your role in the ecosystem, yeahKyle [00:31:36]: We're GitHub. Yeah, we don't want to shape the whole thing. We want it to be figured out. But like how do you balance that like sort of Role in the industry to keep everything as secure as is possible and make sure that you're you're not going to be compromised as a human, ‘cause that's usually how it all happens. And Not not create a process or lock us into a flow that you're not going to or like Mitchell's not going to or other open source projects aren't going to like. That's always been a tricky balance for us, and I think that's something that we haven't talked about enough is we're not going to be able to fix everything for everyone in a way that everyone is going to like. So tell, help us, tell us what is working. When Mitchell was talking about, the Upvote, the upSwyx [00:32:22]: I was going to bring up his thing. Yeah.Kyle [00:32:23]: I forget what it Yeah. When he's talking to us, I was chatting with him and talking to him about this and I put it on Twitter and we talked to, also over DM, was “We're going to keep working.” but I think the important thing is I do actually want to hear what isn't working for you. And as, be as specific and clear for your project as is possible. And to every piece of credit over the many years that we've known each other through the industry, he's always done that and I appreciate that ‘cause there are places that we need to fix up, and we hear from him, and we'll fix up just like we do all other kinds of maintainers. But that that process between making those types of improvements and being more secure and like creating, I forget what he calls it's not the proof process, not the claims process. Do what I'm talking about? He has that he his projects have a way for you to kind of like,Swyx [00:33:13]: VouchKyle [00:33:13]: Vouch. Thank you. Yeah. He has like the vouch system for saying, “Hey, you should accept my PRs.” That's beenSwyx [00:33:20]: I just built this into GitHub. I don't know.Kyle [00:33:22]: Well, see, but that's the thing is that you say that and like he and his community really likes this and then I'll go talk to other maintainers and other maintainers, globally, and they're “No, this doesn't work for me.” And that is the tension, but also the kind of beauty of GitHub, depending on which way you look at it is we want to help maintainers, so we create all these tools to let you have more control over how much you take in from AI and PRs. But you can also use this. What You can go use this project, and if it takes off and becomes the kind of mostly standard, then yeah, we probably wouldn't enforce it but we would add it in because that's the flow that we tend to do?Swyx [00:34:02]: I hear a lot of people don't know the history of the pull request. And like like that's how, that's something that GitHub standardized basically.Kyle [00:34:08]: Yeah. It was a very messy process Like beforehand, and now the we have the benefit of it being the process? And now we have to go and Figure out the next best process or what adaptations change, or what does a pull request look like when eighty percent of your PRs are just coming from your agents and not From other devs?Swyx [00:34:31]: Do you like the prompt request idea from Peter?Kyle [00:34:34]: like I think that for each like each idea I think has its merits. I'm not, I'm not avoiding saying anything good or bad, but I feel like I've seen a version of we have that we have entire Thomas' store. Take all the assets of what you've built and put that in. I think that's got great ideas. There's all these various permutations of the PR flow, but I think the reason why there's not a single answer is ultimately we're trying to codify trust. We're trying to say “Okay, if Sean reviews this I'm going to trust it because you're Sean or you're the senior dev or you're the whatever.” And right now, when we are working in a flow where an agent writes code and another agent reviews code and then Kyle goes and looks at it the trust is kind of diffuse. And most of the tools that we're talking about are talking more about verification flows. We have more assets to look at, so I can probably say whether this is a good PR or not. But that still doesn't solve, I think, the human problem of I'm looking at a PR and I want to know if I can trust it. And we're still, we still tend to use human signals for that? Mitchell approving it or Kyle approving it or whatever. And so I think that's, I think that's why most of these options haven't really solved it is because, it's a social problem ultimately. It's a it's a human problem to review it and agree. Or you fully trust the tool and you're imbuing that tool with full trust Which I think in some cases that absolutely exists.AI-Generated PRs, Trust, and the Waymo AnalogySwyx [00:36:08]: And so like in the same way that there will be a tipping point in society when we don't allow humans to drive anymore Because machines are measurably better than Than humans. I'm looking for that tipping point, right? Like Mythos is ridiculously expensive. Someday we'll have Mythos on a desktop. I don't know. Will, does that change the equation?Kyle [00:36:30]: I think it's more I took a Waymo here, and I was on my phone and not looking around at all. There are other, self-driving, vehicles that I would not trust while, staring at the road. And I think that trust is something that isSwyx [00:36:48]: Is this a Zoox thing? What is itKyle [00:36:50]: I think that is both. I think that is both. LikeSwyx [00:36:53]: There's Zoox in this robo taxi. That's it. It'sKyle [00:36:56]: Well, depending on what level Of self-driving. But, my point is sort of that I think part of that is I strongly believe that's, a mixture of verifiable proof. Like how many accidents, how much data, and so on, and the human aspect of how I feel when I'm in this car, what it tells me, et cetera. And so that's why I think some of the like Some of these some of our AI tools tend to, imbue me with more of that feeling of trust, even if the data says this is 100% accurate. I feel like it takes more time for us to go, “Should I trust this or not?” And that's in the soft sense of, startups with high agency, weekend projects, and open source. And then there's enterprises and regulated industries and everything else, and that is an even harder problem to go solve because even when it is fully verified, not only do you have to have trust from the humans on the team, you probably have to have trust from multinational,Swyx [00:37:55]: Oh my GodKyle [00:37:55]: Multi governments around the world and regulating agencies. And so that's where I feel like until we tip over to your point on the sort of like human EQ side of it. I feel okay this feels okay I've been proven enough. Then the ball will start to roll a lot faster, where we'll end up getting to the “Okay, we can trust this,” and feel good about it in the Most difficult of cases.Reputation, Sponsors, Stars, and Bot Activity on GitHubSwyx [00:38:18]: If human trust is the thing that matters, I feel like GitHub as the developer social network could maybe do more there. Like vouchers are one system But, we have star counts, and then we have Contributor rights, and that's it. And I feel like there should be more in that space. I don't know if there's any other design decisions there.Kyle [00:38:37]: I think that one of the places that we don't really expose right now in this sort of way is, some degree of like hard trust and support, which would like for me is like sponsors is a good example of that.Swyx [00:38:49]: Ah.Kyle [00:38:49]: It like costs you something. To prove that I believe in your project and I trust you To some degree or I want to support you at the very least.Swyx [00:38:56]: Solve payments for open source. Why not?Kyle [00:38:58]: I think that I think that like as we keep moving forward, right, there's more and more projects where I'm, adding more and more dollars into sponsors personally because I want to like support them, but I also like know of I've probably never met them in person, but, I know of enough of their work that I want to support them. I think the thing that I don't love about stars or commit counts or anything else is ultimately, even with all of the various, abuse and de-spamming and deduplication work that we do or anti-abuse work that we do, these are all, not active social signals. They're passive ones that are ultimately gamifiable. And you may trust me, but another open source maintainer may not. And on what heuristic should you be, trusting me? That I think, is kind of where some of our thinking is right now. What signal from me is most important to you? You— If you can define that potentially, honestly in an agentic workflow that's what we see some of these open source projects do, where you have GitHub actions, and then you have like an agentic workflow that's calling AI, and you're setting these rules. Like if Kyle has submitted and gotten accepted PRs across any given project and has a social handle tied to his account in GitHub, and that social account's older than a certain amount. Really complex measures that matter to you ‘cause most open source projects have that heuristic built into their heads, if not written down in the contributing guidelines. You could take that and then go apply that and then just say, “Oh, we're not going to accept this PR.” Building something that is, I think, malleable to everyone's needs, is a little bit better, rather than going “Hmm, this account's too young.” Because what happens? The attackers just go and go and create a multitude of accounts, and they wait Until it ages up. Needs to have a certain amount of stars. That's how star inflation happens. Need to have a certain amount of reposSwyx [00:40:46]: Oh my God. YeahKyle [00:40:47]: With PRs. They all just create repos and submit PRs to each other, and then they come in and do something nefarious. And so, it's hard. It's hard to find the measure. So I think we're, we're looking more at how can we provide you tools so you can kind of choose what's best for you. And of course, we'll give you some standards. But the trust vector, gets down to I don't know, some version of like human digital ID like everyone's been talking about. Like how do I prove that it's meSwyx [00:41:13]: Give me your eyeballsKyle [00:41:14]: On the internet. Give me your eyeballs. Exactly.Swyx [00:41:18]: The I got to keep moving on Topics, but obviously I can go all day on this stuff because, I've been involved in GitHub and open source My entire professional career. Stars. Very superficial. Everyone knows it. But I think time to one hundred thousand stars is the fastest I've ever seen. Like people just reached that in I don't know, months. And then like at the same time I don't trust it right? Like how many of these are real or bot or like whatever. I don't know how to ask this but like what can we do about it? LikeKyle [00:41:49]: JustSwyx [00:41:49]: Is stars broken? Is stars fine?Kyle [00:41:51]: I think that there's kind of two, there's like two pieces. Obviously we're constantly like trying to find ways in which like your users are producing spam, which would, I would include like be like only doing star gamification. When we find them, we pluck ‘em out and we,Swyx [00:42:08]: But it's like a Whac-A-MoleKyle [00:42:10]: It's a hundred percent like a Whac-A-MoleSwyx [00:42:11]: There's no wayKyle [00:42:11]: Now, powered by AI to be helpful. But I think more so what I'm seeing is, a lot of the like fastest time to X tends to be because we're now inviting so many more people into like software development on GitHub That like the zeitgeist is just swarming? And it'sSwyx [00:42:32]: It's not just developers anymoreKyle [00:42:33]: And it's not you and I. Like like however you want to say like what a developer is it's not just folks who have been coding for a very long time. It's folks that have maybe started coding or only joined in since the AI era. And nowSwyx [00:42:44]: what's the latest Octoverse number? I know eighty million was my lastRem- member that a number of developers on GitHubKyle [00:42:50]: Oh, we're over 200 million now.Swyx [00:42:53]: Okay. Well, so you see?Kyle [00:42:55]: Like over 200 million developers now.Swyx [00:42:56]: But it's not developers, right? It's, it's people with a GitHub account.What Counts as a Developer in the AI Era?Kyle [00:43:00]: So, so this is, this is the biggest debate that I would say, everyone loves to have at GitHub at this point. From my perspective, right, I think that there's, there's clearly a difference between, professional enterprise developer and then developers. But I think that I think that the idea that we should be I don't know, splitting hairs or segmenting developers in the early era of software development is, not worth our not worth the time. SoSwyx [00:43:29]: When you get into gatekeepingKyle [00:43:31]: 100%Swyx [00:43:31]: What is a developer?Kyle [00:43:31]: 100%. ‘Cause I wasn't a developer when I started writing code? I was going toSwyx [00:43:36]: Oh, no. I made— I cloned a thing, seven years before I learned to code. And then I and then I wrote about my learning to code journey, and people Just called me a fraud ‘cause I had a GitHub account. And I'm “Well, no, I just use GitHub, but I don't know-” “I didn't know what I was doing.”Kyle [00:43:49]: I I remember that. I remember those sets of posts, and like that's, that's b******t. So I fight very clearly on the line of, if you create code, if you have an idea and you create it into some way of, I'm, I'm going to run it and use the app right now, you may still use AI in that moment, but that's okay. At some point you're going to do the next thing. You're going to create a big— You're going to have to learn about this database. You're going to fix a bug, whatever. We're all on some same journey, and those people are also hearing about the great new agent skill package or a new CLI tool or a new whatever. And those projects are going up because you want to be a part of this moment, just like I wanted to be a part of the Ruby community when Ruby was popping off when I started becoming a developer, and now I can just click the star button. And so I think that yes, there's clearly some amount of like spamming and game gamification that we're working against, but I really think we're just seeing this whole new cohort of folks that are moving from technology to technology because they're not working on a 20-year-old software application. They're working on a side app that they built on the weekend for their friends or for their new idea or whatever. And that's how you see these enormous charts going up and to the right with With stars.Swyx [00:44:59]: I think something that's remarkable is the persistence or, that GitHub extends to those folks. Usually when I see platforms go into a new audience, they usually have to, have like a second platform with a different name that wraps the main platform. But somehow GitHub has been able to sort of persist and extend, and it's friendly and whatever? So it's, it's nice.Spark, Low-Code, and Always Showing the CodeKyle [00:45:19]: I that's partially why I think as we've tried to move into I don't know, more like low-code-y things. We so we started working on Spark as like a way to, build an app and run it. I think that the reality is that we anytime we try to, kind of put even a veneer on top of it without when we put a veneer on top of something, we still always show you the code. That's kind of like a tenant. We're never going to, hide the code from you ever, because whatSwyx [00:45:52]: Why would you?Kyle [00:45:52]: That's, yeah, that's the whole point? However, I think that what we learned with things like Spark is that really the value of Spark for most devs is, easy runtime. And you may have a runtime or a host that you're going to use for that or you just build something and run it but, the package of making that even more simple isn't really needed for folks that are trying to build software and not just trying to build, an app, which is, slightly different, a slightly different goal. So I want to get you in, I want to get you comfortable. I think the best thing for me as, someone that did not traditionally come into software dev way back, I want anyone to be able to breach that chasm and not be in the I don't know, I feel like we're, we're still in an era of, STEM. I've got a 12-year-old and an eight-year-old, and it's “We got to get ‘em into STEM,”? Over and over. And I like I do, I do the things that good parents do. I was “Oh, you want to do coding?” “Yes, I want to do coding.” Do coding classes. But now they're just not afraid of doing software. And that's, I think, the thing that's honestly kept me at GitHub for so long. Anyone should be able to go and build a thing, just like I can go change a light switch in my house. I'm not going to go into the breaker box ‘cause I'll probably kill myself? But, I can go change that light switch. Everyone should be able to go and say, “This fricking app doesn't do what I want. I want it to work like this.” And that I think, is what's kind of kept us all connected with GitHub through the years and some and during the easiest of times or in the hard times because of that opportunity of, we're the home for all developers, and we want everyone to be able to have that feeling that we've had of, had an idea, I created it and holy s**t here it is.Swyx [00:47:37]: Here it is. All right, I'm going to try to do more spicy questions.GitHub's Hardest Scaling Moment: Growth, Agents, and UptimeKyle [00:47:42]: Great.Swyx [00:47:42]: Is it an easy time now or a hard time?Kyle [00:47:45]: Oh at GitHub? It's a hard time. Like, it's a hard time and also, I was just with my team and I said, “This is also, the best and most exciting time that I think I can remember at GitHub.” BecauseSwyx [00:47:57]: Best of times, worst of times. It's never oneKyle [00:47:59]: ‘cause we've we were talking about Octoverse reports and, usually we do an Octoverse report once a year, and we look at the numbers, and we say, “Oh my goodness.” I was at Universe in October saying, “This was the fastest year of growth that we've ever had,” right? And now we're doing more in a month than we did in a year last year.Swyx [00:48:20]: You're talking about PRs.Kyle [00:48:21]: Commits.Swyx [00:48:21]: Commits, yeah.Kyle [00:48:22]: PRs. Kind of like you name it by roughly every measure that we're looking at, there's some amount of sort of growth that is much bigger, and that is breaking our system in new ways, not old ways. Like webhooks were always notoriously, unreliable over the years?Swyx [00:48:38]: Whose fault is that?Kyle [00:48:39]: not anymore mine, but for a period of time, I'm sure you could pull up a tweet that was “It was me. I'm sorry.” but, now, that got rewritten at a scale level that is still working and is not having problems today. Now what we're finding isn't just the isn't the-The simple stuff that folks are on the sometimes on Twitter or on the internet are “Hey, why is this like this?” Sure. There's absolutely silly problems that we shouldn't exist. But now we're talking about, unique, novel permission problems that happen only at a scale across all different objects or whatever, that now we have to go rewrite this underlying system. And so it's, there are problems that yeah, caught us off guard, which I think I said. Like the growth is astronomical, but also we're making such material progress in that I'm excited once we're once we've kind of like reimagined the underlying foundation layer, or pieces of it at least, what's going to be possible when it's not just all of us and all the new people that are being developers and all of their agents and all the tools like working together. Because that'll still happen in that in that GitHub tool, that GitHub community. But it's a it's a hard day anytime we can't give you what you're looking for. We have the same problem internally. We operate through github. Com. Of course, we have backups when things go down and whatnot for our own operations but we feel it too. If it's not working it's not working for us, and that's kind of like the promise of dogfooding for GitHub. It's always been true. We're using the same tool you're using. We're not using a super secret version. We and so we also need it to be great for us for our customers of course for open source. And now an exponential growth of agents, Doing it too.Swyx [00:50:32]: I wanted to load for audio listeners who maybe haven't seen your tweets, whatever. So one billion commits in twenty-five. Now it's two hundred and seventy-five million per week on pace for fourteen billion this year, if growth remains linear. Is that still the pace? I don't know. It's been aKyle [00:50:48]: it's, it's speedingSwyx [00:50:50]: Roughly.Kyle [00:50:50]: It's still speeding up.Swyx [00:50:51]: It's, it's April, so yeah.Kyle [00:50:51]: Exactly. This was in April.Swyx [00:50:53]: All right. So basically you have fourteen x growth, right? Year on year on year. And I think that's a scaling issue. I think, I'm going to like try to really steel man this thing. People have experienced fourteen x growth. They haven't had your downtime. And that's like— C-can we go dig into that? Why? Like what's the— what broke? What are we doing to fix it? Like just anything for the community to reassure them.Why GitHub Reliability Is Breaking in New WaysKyle [00:51:18]: so there's a Like I was saying, there's a couple different places that we've seen the growth issues. Some of the growth issues, which is why we're t— I was talking about pushing hard on more CPUs is in actions in particular. More tools, more agents, more PRs mean more builds, more builds mean more CPUs. And so we are expanding through not just our data center, but obviously we were talking about moving to Azure and moving to, adding an additional cloud compute because we simply need more CPUs. Not as much GPUs. We definitely need GPUs too, but now CPUs are becoming a factor.Swyx [00:51:53]: It's very CPU heavy.Kyle [00:51:54]: Underneath the hood when it comes to some of the underlying services, we've been breaking up over the years our database infrastructure, so that way we have, more cognitive separation between our the various services. The place that we continue to have pain is in, permissioning. And so right now m-many of our permissioning layers sit into a database that we like internally call MySQL One, and old Hubbers will know what I'm talking about. And so we've been pulling things out of MySQL One for many years, because like and we use we use Vitess and we use other technologies to shard and we do it as one bigSwyx [00:52:31]: Famous thing, PlanetScale was born from this andKyle [00:52:32]: A hundred percent. Sam Old Hubber and friend. And so finding these opportunities to like break this out and then do that globally. The other thing that I think is interesting and both a unique opportunity and tricky is we also run everything I just talked about in a black box container with GitHub Enterprise Server for people that work on-prem. So we take everything I just said, and we also do it on-prem, and we also do all of that and we do it in a data residence setup for customers that need to have their data in a single location. Each of these has the unique characteristic around how we're sort of storing that data in MySQL or in a permissioning setup. That's where some of these outages have oc-occurred, where you're seeing it more like across the board rather than just like the one pieceSwyx [00:53:17]: Filling the databaseKyle [00:53:17]: Isn't quite working. Exactly. And so part of it is that. I think there's been some other places where agents are much more or more projects appear to be moving towards monorepo versus we were going the other direction for many years in the industry. Repos were smaller, but there were more of them, and now we're seeing the opposite. Repos are bigger, and there's, not fewer of them per se ‘cause there's new growth, but, we're just seeing many more big repos. Big repos, big monorepos have always had, a unique performance problem. Because each one, is slightly different if, particularly if the underlying blobs are incredibly big Inside the repos. And so we've done a ton of work that you pro— like most people haven't probably experienced, unless you're in this case of the monorepo. But that Git, infrastructure layer improvement does help the overall, system because, many of the improvements that make monorepos work better make all repo infrastructure work better. And so, I could kind of keep going down the line where it's another thing where we're moving out of, We're changing how we do j I'll just say job queuing for lack of a better, explanation changing the underlying technologies there.Swyx [00:54:32]: I spent two years being a job queuing guy, so.Kyle [00:54:34]: And so it's kind of a little bit of a little bit of piece by piece, and it's mostly because as we were— as it was built, we built everything in a way that assumed, I guess in some ways that the size of the pipe of work was going to remain the same. There's just going to be more people coming through each of those pipes. But instead now in places whereA git push was, generally a certain size for example, is now, no longer true.Swyx [00:55:03]: Oh, yeah.Kyle [00:55:03]: OrSwyx [00:55:05]: I push a thousandKyle [00:55:06]: On the average. 100%Swyx [00:55:06]: A thousand line commits like dailyKyle [00:55:07]: Same thing with PRs. Like PRs same thing. And like we've talked about optimizing that and making changes where, and there were technology choices that did not work there? And it got slow, and it didn't It was not fast. It did not do what the users wanted. And so we've been reeling that all out and going “Okay, that's just not right. Let's stop putting good money after bad and do it the do it the right way or the right way now.” So there's It's a it's a lot of things, not quite when I've experienced scale at GitHub historically, it's almost always two options that we've used. We go vertical scaling, particularly with databases, right? And we go horizontal scaling. Oh, we just have more people using this service. Great. We're going to add more servers, and we rack them in our data center, or we use it in a cloud. And now we're sort of in a like diagonal, where like vertical doesn't really work anymore. Horizontal isn't work either because we're all We all have some CPU or GPU constraints in the world now, and now we have to go in and like crack open services that have been running for 10 or 15 years and go, “Okay, the rules of this service have legitimately changed, and now we have to rewrite them.” None of this is an excuse. This is like we're We have to do the work. We have to make it better.Swyx [00:56:22]: actually as an infra guy, I'm “This is like one of the most fascinating scaling challenges I've ever seen.”Kyle [00:56:26]: That's that's, that's the thing that's the thing that it's hard for Like when we weren't talking about it publicly, and I was like I came out, and I was “Hey, I just want to explain what's going on.” Part of it comes from a very old GitHub ethos, which is it's our it's our uptime. It's down. W What I know you're a developer, so you're, you're inclined to want to understand more what's going on. But at the same time us going “Hey, this service didn't, perform the way we expected, and now we have to go change it,” we weren't We're not trying to hide anything from you i

Modern work can be frustrating and chaotic—if you don't have the right tools. From context engineering to multimodal search, go behind the scenes and hear how Dropbox engineers are building AI that actually understands you, so you can focus on the work that matters most. If you're new to Working Smarter, we've travelled from the F1 track to the bottom of a lake, and heard real stories from chefs, doctors, lawyers, and founders about how AI is helping them do more of what they love about their jobs. But in our third season, we're talking to the people behind the tools—the engineers and product leaders building helpful, time-saving AI features into the Dropbox experience you already know and trust. You'll hear all about their work on agents, inference, security, and, of course, how the people building AI use AI themselves. ~ ~ ~  Working Smarter is brought to you by Dropbox. Find, organize, and share your work—all in one place—with context-aware AI from Dropbox. You can listen to more episodes of Working Smarter on Apple Podcasts, Spotify, YouTube, Amazon Music, or wherever you get your podcasts. To read more stories and past interviews, visit workingsmarter.ai This show would not be possible without the talented team at Cosmic Standard: producer Ben Montoya, sound engineer Aja Simpson, technical director Jacob Winik, and executive producer Eliza Smith. Special thanks to our illustrator Fanny Luor, marketing consultant Meggan Ellingboe, and editorial support from Catie Keck.  Our theme song was composed by Doug Stuart.  Working Smarter is hosted by Matthew Braga. Thanks for listening!

Josh chats with Sal Kimmich about the current state of everything, and what we can expect next. Sal has some incredible insight into what we can expect to see due to the current wave of security bugs and incidents. There are some new features we will need in both our hardware and software to ward off the state of things. Since those features are years away, what we need in the short term is shoring up our SDLC programs. Sal has some really good medical examples and analogies for this one. It's a huge problem but not insurmountable. The show notes and blog post for this episode can be found at https://opensourcesecurity.io/2026/2026-06-verification-sal-kimmich/

Dwayne McDaniel, developer advocate at GitGuardian.com, joins host Priyanka Raghavan to talk about the engineering challenges of secrets management. They explore what "secrets" really are in modern systems—far beyond passwords—including API keys, tokens, certificates, and machine identities, and how "secret sprawl" emerges across the SDLC. Drawing on reports from GitGuardian and Verizon, they discuss the growing scale of secret leaks and why credential abuse and phishing remain dominant attack vectors. They examine common leak points—from code repos and logs to CI/CD pipelines, containers, and SaaS integrations—and how cloud, DevOps, and AI tooling are amplifying risks. Priyanka quizzes Dwayne about recent supply chain attacks from pyPi and trivy ecosystems, highlighting recurring root causes like poor access control, long-lived credentials, and weak security hygiene. Finally, they consider detection, response, and modern solutions—short-lived credentials, secret scanning, and identity-based approaches like OWASP NHIR and SPIFFE/SPIRE—ending with practical advice for engineers to reduce blast radius and design for secure secret lifecycle management.

We showcase recordings from this year's RSAC. At RSAC Conference 2026, Scott Clinton, Co-Chair and co-founder of the OWASP GenAI Security Project, shares insights from the project's latest research, including new landscape guides and evolving approaches to securing generative and agentic AI systems. The conversation explores critical gaps in GenAI data security, the rise of AI-assisted development, and the immense growth of the OWASP community and sponsor ecosystem. Looking ahead, he outlines the most urgent risks and priorities shaping AI and agentic security in 2026. Then Merritt Maxim discusses how AI is affecting Identity and Access Management. Expect to hear this topic a lot throughout 2026, especially as the industry tries to figure out what's different or special about securing agent identities. We close with a chat with Janet Worthington about the impact of agents on the SDLC and how orgs are updating their controls to deal with code generated by humans and LLMs alike. Segment Resources: https://genai.owasp.org https://genai.owasp.org/resources/ https://www.scworld.com/podcast-episode/3905-keeping-up-with-the-owasp-genai-project-scott-clinton-asw-381 This segment is sponsored by The OWASP GenAI Security Project. Visit https://securityweekly.com/owasp to learn more about them! Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw-384