# DevOps Paradox - Complete Content

> Comprehensive single-file archive of all DevOps Paradox content including episodes, guests, and livestreams. For sectioned content, see the individual llms.txt files.

## All Episodes

- [DOP 366: How to Prevent npm Supply Chain Attacks](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md) | September 2, 2026 | Guest: David Mytton (Arcjet)
- [DOP 365: What the DORA AI ROI Report Really Says](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md) | August 26, 2026
- [DOP 364: How to Avoid Burnout as a Leader](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md) | August 19, 2026 | Guest: Victoria Mensch (Silicon Valley Executive Academy)
- [DOP 363: Is Your Website Agent-Ready?](/episodes/is-your-website-agent-ready-363/index.md) | August 12, 2026
- [DOP 362: Feature Flags vs Canary Deployments](/episodes/feature-flags-vs-canary-deployments-362/index.md) | August 5, 2026 | Guest: Alex Casalboni (Unleash)
- [DOP 361: When Code Got Cheap, Reviewing Got Expensive](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md) | July 29, 2026
- [DOP 360: What Is an AI SRE?](/episodes/what-is-an-ai-sre-360/index.md) | July 22, 2026 | Guest: Birol Yildiz (ilert)
- [DOP 359: Demos in the Age of AI Agents](/episodes/demos-in-the-age-of-ai-agents-359/index.md) | July 15, 2026
- [DOP 358: Just-in-Time Access for AI Agents](/episodes/just-in-time-access-for-ai-agents-358/index.md) | July 8, 2026 | Guest: Ofir Stein (Apono)
- [DOP 357: What Is Spec-Driven Development?](/episodes/what-is-spec-driven-development-357/index.md) | July 1, 2026
- [DOP 356: Warehouse Robots Are a Distributed System](/episodes/warehouse-robots-are-a-distributed-system-356/index.md) | June 24, 2026 | Guest: Tomas Kovacovsky (Brightpick)
- [DOP 355: Why AI Coding Slows Down Code Review](/episodes/why-ai-coding-slows-down-code-review-355/index.md) | June 17, 2026
- [DOP 354: Your Dead Founder Trains New Hires](/episodes/your-dead-founder-trains-new-hires-354/index.md) | June 10, 2026 | Guest: Miles Spencer (Reflekta.ai)
- [DOP 353: A Person Owns It Not the AI](/episodes/a-person-owns-it-not-the-ai-353/index.md) | June 3, 2026
- [DOP 352: No-Code Is the Guardrail Vibe Coding Needs](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md) | May 27, 2026 | Guest: Jeff Kuo (KlotRagicho)
- [DOP 351: The Developer Job Market in the Age of AI](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md) | May 20, 2026
- [DOP 350: Context Is the New Bottleneck, Not Code](/episodes/context-is-the-new-bottleneck-not-code-350/index.md) | May 13, 2026 | Guest: Patrick Debois (Tessl)
- [DOP 349: Shadow AI Is Going to Be a Thousand Times Worse Than Shadow IT](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md) | May 6, 2026 | Guest: Ben Wilcox (ProArch)
- [DOP 348: Now It's Time to Panic](/episodes/now-it-s-time-to-panic-348/index.md) | April 29, 2026
- [DOP 347: Cozystack Turns Bare Metal Into a Managed Services Platform](/episodes/cozystack-turns-bare-metal-into-a-managed-services-platform-347/index.md) | April 22, 2026 | Guest: Andrei Kvapil (Aenix)
- [DOP 346: Fighting AI in Your Project Is a Terrible Mistake](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md) | April 15, 2026
- [DOP 345: From Chat Prompt to Working Software with Kiro](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md) | April 8, 2026 | Guest: Amit Patel (AWS)
- [DOP 344: KubeCon EU 2026 Review](/episodes/kubecon-eu-2026-review-344/index.md) | April 1, 2026 | Guest: Whitney Lee
- [DOP 343: Your APIs Were Never Built to Be the Front Door](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md) | March 25, 2026 | Guest: Matt DeBergalis (Apollo GraphQL)
- [DOP 342: Your Company Documentation Is Useless for AI](/episodes/your-company-documentation-is-useless-for-ai-342/index.md) | March 18, 2026
- [DOP 341: AI Widened the Highway but Nobody Rebuilt the Bridge](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md) | March 11, 2026 | Guest: Trevor Stuart (Harness)
- [DOP 340: Why Operations Teams Resist Every Technology Wave](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md) | March 4, 2026
- [DOP 339: DNS Is Old Tech (And That's Why It Still Runs the Internet)](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md) | February 25, 2026 | Guest: Anthony Eden (DNSimple)
- [DOP 338: The Assembly Line Problem: Why Adding AI to One Step Breaks Everything](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md) | February 18, 2026
- [DOP 337: Nanoseconds Matter - InfluxDB and the Future of Real-Time Data](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md) | February 11, 2026 | Guest: Evan Kaplan (InfluxData)
- [DOP 336: Why Top Talent Won't Work for You Anymore](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md) | February 4, 2026
- [DOP 335: Stop Building Dashboards and Start Getting Answers With Coroot](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md) | January 28, 2026 | Guest: Peter Zaitsev (Coroot)
- [DOP 334: If Code Is the Easy Part, What Should Developers Actually Be Doing?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md) | January 21, 2026
- [DOP 333: The Hidden Problems Behind Every Data Pipeline](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md) | January 14, 2026 | Guest: Pete Hunt (Dagster)
- [DOP 332: 2026 - The Year of Discovery](/episodes/2026-the-year-of-discovery-332/index.md) | January 7, 2026
- [DOP 331: Looking Back on Our 2025 Predictions](/episodes/looking-back-on-our-2025-predictions-331/index.md) | December 31, 2025
- [DOP 330: Merry Christmas (You Should Probably Be Doing Something Else)](/episodes/merry-christmas-you-should-probably-be-doing-something-else-330/index.md) | December 24, 2025
- [DOP 329: Vibe Coding and The Technical Debt Time Bomb](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md) | December 17, 2025
- [DOP 328: The Real Cost of Build Versus Buy Decisions](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md) | December 10, 2025 | Guest: Alex Gusev (Uploadcare)
- [DOP 327: When AI Tools Go Rogue](/episodes/when-ai-tools-go-rogue-327/index.md) | December 3, 2025
- [DOP 326: Stop Reinventing The Wheel - Use Dapr Instead](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md) | November 26, 2025 | Guest: Mark Fussell (Diagrid)
- [DOP 325: KubeCon North America 2025 Review](/episodes/kubecon-north-america-2025-review-325/index.md) | November 19, 2025 | Guest: Whitney Lee
- [DOP 324: Kubernetes Resource Right-Sizing and Scaling with Zesty](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md) | November 12, 2025 | Guest: Omer Hamerman (Zesty.co)
- [DOP 323: The Security Nightmare of Vibe Coding](/episodes/the-security-nightmare-of-vibe-coding-323/index.md) | November 5, 2025
- [DOP 322: How to Build Apps That Never Go Down Even When Servers Die](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md) | October 29, 2025 | Guest: Mathias Buus Madsen (Holepunch)
- [DOP 321: Model Context Protocol for Standardizing AI Tool Integration](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md) | October 22, 2025
- [DOP 320: Why Dashboards Alone Are Not Enough for Incident Response](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md) | October 15, 2025 | Guest: Jim Hirschauer (Xurrent)
- [DOP 319: AI-Powered Infrastructure: Beyond Hype to Reality](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md) | October 8, 2025
- [DOP 318: WireMock and the Changing Landscape of API Development Tools](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md) | October 1, 2025 | Guest: Tom Akehurst (WireMock)
- [DOP 317: The Human Cost of AI Automation in DevOps](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md) | September 24, 2025
- [DOP 316: Bringing Back the Original Internet Vision Using Tailscale](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md) | September 17, 2025 | Guest: Avery Pennarun (Tailscale)
- [DOP 315: Why Good Developers Spend More Time Designing Than Coding](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md) | September 10, 2025
- [DOP 314: Building Your Speaking Career From Meetups to Main Stage](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md) | September 3, 2025 | Guest: Geoffrey Huck
- [DOP 313: Harnessing AI for Smarter Development](/episodes/harnessing-ai-for-smarter-development-313/index.md) | August 27, 2025
- [DOP 312: Transitioning from VMWare to KubeVirt](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md) | August 20, 2025 | Guest: Kevin Jackson (Trilio)
- [DOP 311: Harnessing AI for Accelerated Project Development](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md) | August 13, 2025
- [DOP 310: The Misconceptions and Realities of DevOps, Agile, and Leadership](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md) | August 6, 2025 | Guest: Tim Beattie (Stellafai)
- [DOP 309: Using AI Agents in Daily Development Tasks](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md) | July 30, 2025
- [DOP 308: The Truth of CI/CD](/episodes/the-truth-of-ci-cd-308/index.md) | July 23, 2025 | Guest: Ricardo Castro
- [DOP 307: Kubernetes in 2025](/episodes/kubernetes-in-2025-307/index.md) | July 16, 2025
- [DOP 306: Understanding GraphQL's Role in Modern APIs](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md) | July 9, 2025 | Guest: Sophia Willows
- [DOP 305: The Episode I Thought I Would Never Record](/episodes/the-episode-i-thought-i-would-never-record-305/index.md) | June 18, 2025
- [DOP 304: Strategies for Successful Talent Retention](/episodes/strategies-for-successful-talent-retention-304/index.md) | February 26, 2025
- [DOP 303: How To Develop a CLI in 2025](/episodes/how-to-develop-a-cli-in-2025-303/index.md) | February 19, 2025 | Guest: Wesley Beary (Anchor)
- [DOP 302: Using AI To Help With Your Programming Tasks](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md) | February 12, 2025
- [DOP 301: Exploring OpenRewrite and the Future of Code Modernization](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md) | February 5, 2025 | Guest: Jonathan Schneider (Moderne)
- [DOP 300: How To Become an AI Native Engineer in 2025](/episodes/how-to-become-an-ai-native-engineer-in-2025-300/index.md) | January 29, 2025 | Guest: Patrick Debois (Tessl)
- [DOP 299: Managing Your AI Workloads With KitOps](/episodes/managing-your-ai-workloads-with-kitops-299/index.md) | January 22, 2025 | Guest: Gorkem Ercan (Jozu)
- [DOP 298: Tools Versus Culture](/episodes/tools-versus-culture-298/index.md) | January 15, 2025
- [DOP 297: Streamline Access Control Using Cerbos](/episodes/streamline-access-control-using-cerbos-297/index.md) | January 8, 2025 | Guest: Alex Olivier (Cerbos)
- [DOP 296: 2025 - The Year of Not Yet](/episodes/2025-the-year-of-not-yet-296/index.md) | January 1, 2025
- [DOP 295: If You Are Listening to This, Go Back to Bed](/episodes/if-you-are-listening-to-this-go-back-to-bed-295/index.md) | December 25, 2024
- [DOP 294: Looking Back on Our 2024 Predictions](/episodes/looking-back-on-our-2024-predictions-294/index.md) | December 18, 2024
- [DOP 293: Attracting and Retaining Talent in a Changing Tech World](/episodes/attracting-and-retaining-talent-in-a-changing-tech-world-293/index.md) | December 11, 2024 | Guest: Michael Zuercher (Primastic)
- [DOP 292: No Project Is Truly Open Source](/episodes/no-project-is-truly-open-source-292/index.md) | December 4, 2024
- [DOP 291: The Future of Software Development in an AI-Driven World](/episodes/the-future-of-software-development-in-an-ai-driven-world-291/index.md) | November 27, 2024 | Guest: Derek Ferguson (Fitch)
- [DOP 290: KubeCon North America 2024 Review](/episodes/kubecon-north-america-2024-review-290/index.md) | November 20, 2024 | Guest: Whitney Lee
- [DOP 289: When to Build Your Own vs. Using Off-the-Shelf](/episodes/when-to-build-your-own-vs-using-off-the-shelf-289/index.md) | November 13, 2024 | Guest: Hugo Santos
- [DOP 288: The Laws of Software Evolution](/episodes/the-laws-of-software-evolution-288/index.md) | November 6, 2024
- [DOP 287: Automating Dependency Updates with Renovate](/episodes/automating-dependency-updates-with-renovate-287/index.md) | October 30, 2024 | Guest: Rhys Arkins (Mend)
- [DOP 286: The Hidden Costs of Free Services](/episodes/the-hidden-costs-of-free-services-286/index.md) | October 23, 2024
- [DOP 285: Navigating the Challenges of Legacy Software in Modern Enterprises](/episodes/navigating-the-challenges-of-legacy-software-in-modern-enterprises-285/index.md) | October 16, 2024 | Guest: Neil Millard
- [DOP 284: From Scratch Isn't Really From Scratch](/episodes/from-scratch-isn-t-really-from-scratch-284/index.md) | October 9, 2024
- [DOP 283: OpenTelemetry Meets Mobile](/episodes/opentelemetry-meets-mobile-283/index.md) | October 2, 2024 | Guest: Austin Emmons (Embrace)
- [DOP 282: How To Measure Software Complexity](/episodes/how-to-measure-software-complexity-282/index.md) | September 25, 2024
- [DOP 281: The Impossibility of Competing with Tech Giants](/episodes/the-impossibility-of-competing-with-tech-giants-281/index.md) | September 18, 2024 | Guest: Bret Fisher | Guest: Nirmal Mehta
- [DOP 280: Understanding the Importance of Policy as Code for Cloud-Native Success](/episodes/understanding-the-importance-of-policy-as-code-for-cloud-native-success-280/index.md) | September 11, 2024
- [DOP 279: Exploring Grafana Alloy](/episodes/exploring-grafana-alloy-279/index.md) | September 4, 2024 | Guest: Paschalis Tsilias (Grafana Labs)
- [DOP 278: GUI versus Command Line in Development](/episodes/gui-versus-command-line-in-development-278/index.md) | August 28, 2024
- [DOP 277: Making Security Tooling Easy for Developers](/episodes/making-security-tooling-easy-for-developers-277/index.md) | August 21, 2024 | Guest: Luke Hinds (Stacklok)
- [DOP 276: Why APIs Matter More Than Ever](/episodes/why-apis-matter-more-than-ever-276/index.md) | August 14, 2024
- [DOP 275: Managing Modern Infrastructure with GitOps](/episodes/managing-modern-infrastructure-with-gitops-275/index.md) | August 7, 2024 | Guest: Christian Hernandez (Akuity)
- [DOP 274: What Is the XY Problem?](/episodes/what-is-the-xy-problem-274/index.md) | July 31, 2024
- [DOP 273: Adapting Three Tier Architecture for Platform Engineering](/episodes/adapting-three-tier-architecture-for-platform-engineering-273/index.md) | July 24, 2024 | Guest: Daniel Bryant (InfoQ)
- [DOP 272: How To Become a Speaker at Conferences](/episodes/how-to-become-a-speaker-at-conferences-272/index.md) | July 17, 2024
- [DOP 271: Solving Real Problems in Platform Engineering](/episodes/solving-real-problems-in-platform-engineering-271/index.md) | July 10, 2024 | Guest: Puja Abbassi (Giant Swarm)
- [DOP 270: Why Should a Developer Consider Using Devbox from Jetify?](/episodes/why-should-a-developer-consider-using-devbox-from-jetify-270/index.md) | July 3, 2024
- [DOP 269: Using Human Centered Computing in Platform Engineering](/episodes/using-human-centered-computing-in-platform-engineering-269/index.md) | June 26, 2024 | Guest: Katharina Sick
- [DOP 268: What Is Kubernetes Used For?](/episodes/what-is-kubernetes-used-for-268/index.md) | June 19, 2024
- [DOP 267: To Fork or Not To Fork](/episodes/to-fork-or-not-to-fork-267/index.md) | June 12, 2024 | Guest: Charles-Edouard Brétéché (Nirmata)
- [DOP 266: The Evolution of Data Structure Languages](/episodes/the-evolution-of-data-structure-languages-266/index.md) | June 5, 2024
- [DOP 265: The Impact of Kubernetes and GitOps on the Tech Landscape](/episodes/the-impact-of-kubernetes-and-gitops-on-the-tech-landscape-265/index.md) | May 29, 2024 | Guest: John Dietz (Kubefirst)
- [DOP 264: Navigating the Changing Landscape of Open Source](/episodes/navigating-the-changing-landscape-of-open-source-264/index.md) | May 22, 2024
- [DOP 263: Navigating the Complex Path to Becoming a DevOps Architect](/episodes/navigating-the-complex-path-to-becoming-a-devops-architect-263/index.md) | May 15, 2024 | Guest: Ádám Szücs-Mátyás
- [DOP 262: Rethinking Project Success The Iterative Way](/episodes/rethinking-project-success-the-iterative-way-262/index.md) | May 8, 2024
- [DOP 261: Visionary Views on Internal Developer Platforms and Portals with Port](/episodes/visionary-views-on-internal-developer-platforms-and-portals-with-port-261/index.md) | May 1, 2024 | Guest: Zohar Einy (port)
- [DOP 260: Artificial Intelligence Will NOT Replace You. Devs Using AI Will.](/episodes/artificial-intelligence-will-not-replace-you-devs-using-ai-will-260/index.md) | April 24, 2024
- [DOP 259: Reimagining The Terminal Experience with Wave Terminal](/episodes/reimagining-the-terminal-experience-with-wave-terminal-259/index.md) | April 17, 2024 | Guest: Mike Sawka (Wave Terminal)
- [DOP 258: Reflections on Startup Infrastructure Choices](/episodes/reflections-on-startup-infrastructure-choices-258/index.md) | April 10, 2024
- [DOP 257: Scaling at Adobe: Kubernetes, Global Networking, and Platform Innovation](/episodes/scaling-at-adobe-kubernetes-global-networking-and-platform-innovation-257/index.md) | April 3, 2024 | Guest: Joseph Sandoval (Adobe)
- [DOP 256: KubeCon EU 2024 Review](/episodes/kubecon-eu-2024-review-256/index.md) | March 27, 2024 | Guest: Whitney Lee
- [DOP 255: What Is Developer Observability?](/episodes/what-is-developer-observability-255/index.md) | March 20, 2024 | Guest: Liran Haimovitch (Rookout)
- [DOP 254: What Is Infrastructure As Code in DevOps?](/episodes/what-is-infrastructure-as-code-in-devops-254/index.md) | March 13, 2024
- [DOP 253: Deconstructing The Platform Engineering Maturity Model](/episodes/deconstructing-the-platform-engineering-maturity-model-253/index.md) | March 6, 2024 | Guest: Abby Bangser (Syntasso)
- [DOP 252: How To Upgrade Kubernetes](/episodes/how-to-upgrade-kubernetes-252/index.md) | February 28, 2024
- [DOP 251: Demystifying Modern Message Brokers with Memphis.dev](/episodes/demystifying-modern-message-brokers-with-memphis-dev-251/index.md) | February 21, 2024 | Guest: Valera Bronshtein (Memphis.dev)
- [DOP 250: From Godfather of DevOps to Godfather of AI](/episodes/from-godfather-of-devops-to-godfather-of-ai-250/index.md) | February 14, 2024 | Guest: Patrick Debois (Tessl)
- [DOP 249: How To Choose Between Open Source and Commercial Software](/episodes/how-to-choose-between-open-source-and-commercial-software-249/index.md) | February 7, 2024 | Guest: Hadi Chami (LEAD Technologies, Inc)
- [DOP 248: How To Use ChatGPT for DevOps](/episodes/how-to-use-chatgpt-for-devops-248/index.md) | January 31, 2024
- [DOP 247: Navigating the Nuances of Developer Relations](/episodes/navigating-the-nuances-of-developer-relations-247/index.md) | January 24, 2024 | Guest: Lian Li
- [DOP 246: How To Become a DevOps Architect in 2024](/episodes/how-to-become-a-devops-architect-in-2024-246/index.md) | January 17, 2024
- [DOP 245: Building Your Best Team Ever](/episodes/building-your-best-team-ever-245/index.md) | January 10, 2024 | Guest: David Burkus
- [DOP 244: What Every DevOps Should Learn in 2024](/episodes/what-every-devops-should-learn-in-2024-244/index.md) | January 3, 2024
- [DOP 243: Looking Back on Our 2023 Predictions](/episodes/looking-back-on-our-2023-predictions-243/index.md) | December 27, 2023
- [DOP 242: Take a Break. That’s the Message.](/episodes/take-a-break-thats-the-message-242/index.md) | December 20, 2023
- [DOP 241: From Restaurant Server to KubeCon Keynote in Under 4 Years](/episodes/from-restaurant-server-to-kubecon-keynote-in-under-4-years-241/index.md) | December 13, 2023 | Guest: Whitney Lee
- [DOP 240: Supercharging Developer Workflows with Simplified Platform Engineering](/episodes/supercharging-developer-workflows-with-simplified-platform-engineering-240/index.md) | December 6, 2023 | Guest: Mauricio Salatino (Diagrid)
- [DOP 239: What's in Your From Line? A Conversation With Chainguard](/episodes/whats-in-your-from-line-a-conversation-with-chainguard-239/index.md) | November 29, 2023 | Guest: Matt Moore (Chainguard) | Guest: Ville Aikas (Chainguard)
- [DOP 238: Unlocking the Potential of Modern Architectures Using Service Mesh](/episodes/unlocking-the-potential-of-modern-architectures-using-service-mesh-238/index.md) | November 22, 2023 | Guest: Marino Wijay (Solo.io)
- [DOP 237: KubeCon North America 2023 Review](/episodes/kubecon-north-america-2023-review-237/index.md) | November 15, 2023 | Guest: Whitney Lee
- [DOP 236: Efficient Cloud Cost Optimizations with Profisea Labs](/episodes/efficient-cloud-cost-optimizations-with-profisea-labs-236/index.md) | November 8, 2023 | Guest: Anton Grishko (Profisea Labs)
- [DOP 235: Diving Into Platform Engineering Trends With Humanitec](/episodes/diving-into-platform-engineering-trends-with-humanitec-235/index.md) | November 1, 2023 | Guest: Kaspar von Grünberg (Humanitec)
- [DOP 234: Better Bare Metal Infrastructure Management With RackN](/episodes/better-bare-metal-infrastructure-management-with-rackn-234/index.md) | October 25, 2023 | Guest: Rob Hirschfeld (RackN)
- [DOP 233: Upskill Your Knowledge Using Wilco](/episodes/upskill-your-knowledge-using-wilco-233/index.md) | October 18, 2023 | Guest: On Freund (Wilco)
- [DOP 232: Real-Time Application Security Using Arnica](/episodes/real-time-application-security-using-arnica-232/index.md) | October 11, 2023 | Guest: Nir Valtman (Arnica)
- [DOP 231: Automating API Development With Hasura](/episodes/automating-api-development-with-hasura-231/index.md) | October 4, 2023 | Guest: Tanmai Gopal (Hasura)
- [DOP 230: Simplifying End-to-End Encryption With Smallstep](/episodes/simplifying-end-to-end-encryption-with-smallstep-230/index.md) | September 27, 2023 | Guest: Mike Malone (Smallstep)
- [DOP 229: The Evolution of Installing Applications into Kubernetes](/episodes/the-evolution-of-installing-applications-into-kubernetes-229/index.md) | September 20, 2023
- [DOP 228: The Customer Is the True North Star](/episodes/the-customer-is-the-true-north-star-228/index.md) | September 13, 2023 | Guest: Paul Stovell (Octopus)
- [DOP 227: Layoff-Proofing Your Career](/episodes/layoff-proofing-your-career-227/index.md) | September 6, 2023 | Guest: Dagna Bieda (theMindfulDev.com)
- [DOP 226: When Cloud Services Let Us Down](/episodes/when-cloud-services-let-us-down-226/index.md) | August 30, 2023
- [DOP 225: The Rise of Kubernetes: From Google to Global Phenomenon](/episodes/the-rise-of-kubernetes-from-google-to-global-phenomenon-225/index.md) | August 23, 2023 | Guest: Craig Box (Armo)
- [DOP 224: Are Developer Bootcamps Worth It?](/episodes/are-developer-bootcamps-worth-it-224/index.md) | August 16, 2023 | Guest: Lane Wagner (Boot.dev)
- [DOP 223: Vendors and Communities Working Together in Open Source](/episodes/vendors-and-communities-working-together-in-open-source-223/index.md) | August 9, 2023 | Guest: Dotan Horovits (Logz.io)
- [DOP 222: Finding Performance Bottlenecks With Ddosify](/episodes/finding-performance-bottlenecks-with-ddosify-222/index.md) | August 2, 2023 | Guest: Kursat Aktas (Ddosify) | Guest: Fatih Baltaci (Ddosify)
- [DOP 221: Treat Security Like a Bug With Seemplicity](/episodes/treat-security-like-a-bug-with-seemplicity-221/index.md) | July 26, 2023 | Guest: Ravid Circus (Seemplicity)
- [DOP 220: What Are the Top Challenges for Implementing DevOps?](/episodes/what-are-the-top-challenges-for-implementing-devops-220/index.md) | July 19, 2023
- [DOP 219: What Is NoSQL?](/episodes/what-is-nosql-219/index.md) | July 12, 2023 | Guest: Matthew Groves (Couchbase)
- [DOP 218: Continuous Testing With BlazeMeter](/episodes/continuous-testing-with-blazemeter-218/index.md) | July 5, 2023 | Guest: Bharath Vantari (Perforce Software)
- [DOP 217: Learning eBPF With Liz Rice](/episodes/learning-ebpf-with-liz-rice-217/index.md) | June 28, 2023 | Guest: Liz Rice (Isovalent)
- [DOP 216: Simplify Microservice Development With Signadot](/episodes/simplify-microservice-development-with-signadot-216/index.md) | June 21, 2023 | Guest: Arjun Iyer (Signadot)
- [DOP 215: Reviewing Thoughtworks Technology Radar Volume 28](/episodes/reviewing-thoughtworks-technology-radar-volume-28-215/index.md) | June 14, 2023
- [DOP 214: Taking SQL to the Next Level With Materialize](/episodes/taking-sql-to-the-next-level-with-materialize-214/index.md) | June 7, 2023 | Guest: Arjun Narayan (Materialize)
- [DOP 213: Unlocking the Secrets to a Successful Product Launch](/episodes/unlocking-the-secrets-to-a-successful-product-launch-213/index.md) | May 31, 2023 | Guest: Mav Turner (Tricentis)
- [DOP 212: Build and Release SaaS Pricing Changes Faster With Stigg](/episodes/build-and-release-saas-pricing-changes-faster-with-stigg-212/index.md) | May 24, 2023 | Guest: Anton Zagrebelny (Stigg)
- [DOP 211: Learning To Code in the Age of AI](/episodes/learning-to-code-in-the-age-of-ai-211/index.md) | May 17, 2023 | Guest: Jim Douglas (Armory)
- [DOP 210: Mastering Database Scalability with PlanetScale](/episodes/mastering-database-scalability-with-planetscale-210/index.md) | May 10, 2023 | Guest: Sam Lambert (PlanetScale)
- [DOP 209: Move From Multicloud to Polycloud With Macrometa](/episodes/move-from-multicloud-to-polycloud-with-macrometa-209/index.md) | May 3, 2023 | Guest: Chetan Venkatesh (Macrometa)
- [DOP 208: KubeCon EU 2023 Review](/episodes/kubecon-eu-2023-review-208/index.md) | April 26, 2023 | Guest: Whitney Lee | Guest: Engin Diri
- [DOP 207: What Did It Take To Bring SQreamDB to SaaS?](/episodes/what-did-it-take-to-bring-sqreamdb-to-saas-207/index.md) | April 19, 2023 | Guest: Yaniv Leven (SQream)
- [DOP 206: Open Source Supply Chain Security With Pyrsia](/episodes/open-source-supply-chain-security-with-pyrsia-206/index.md) | April 12, 2023 | Guest: Stephen Chin (JFrog)
- [DOP 205: Thoughts on Digital Twins and Custom Silicon](/episodes/thoughts-on-digital-twins-and-custom-silicon-205/index.md) | April 5, 2023
- [DOP 204: Transform Data From Managed to Actionable With Rivery](/episodes/transform-data-from-managed-to-actionable-with-rivery-204/index.md) | March 29, 2023 | Guest: Itamar Ben Hemo (Rivery)
- [DOP 203: Dealing With Flaky Tests and Broken Builds With Aviator](/episodes/dealing-with-flaky-tests-and-broken-builds-with-aviator-203/index.md) | March 22, 2023 | Guest: Ankit Jain (Aviator)
- [DOP 202: Go From Docker Compose to Kubernetes Using Shipyard](/episodes/go-from-docker-compose-to-kubernetes-using-shipyard-202/index.md) | March 15, 2023 | Guest: Benjie De Groot (Shipyard)
- [DOP 201: Getting to the Root Cause With Zebrium](/episodes/getting-to-the-root-cause-with-zebrium-201/index.md) | March 8, 2023 | Guest: Ajay Singh (Zebrium)
- [DOP 200: From Digital Twins to Management – A Conversation With Patrick Debois](/episodes/from-digital-twins-to-management-a-conversation-with-patrick-debois-200/index.md) | March 1, 2023 | Guest: Patrick Debois (Tessl)
- [DOP 199: Test Your Distributed Applications Using Helios](/episodes/test-your-distributed-applications-using-helios-199/index.md) | February 22, 2023 | Guest: Ran Nozik (Helios)
- [DOP 198: Securing Your Runtime With Spyderbat](/episodes/securing-your-runtime-with-spyderbat-198/index.md) | February 15, 2023 | Guest: Brian Smith (Spyderbat)
- [DOP 197: Is Your Job Stuck 20 Years in the Past?](/episodes/is-your-job-stuck-20-years-in-the-past-197/index.md) | February 8, 2023
- [DOP 196: Simplifying Performance Optimization Using Granulate](/episodes/simplifying-performance-optimization-using-granulate-196/index.md) | February 1, 2023 | Guest: Noam Salinger (Granulate)
- [DOP 195: Why Do Companies Not Replace Legacy Systems?](/episodes/why-do-companies-not-replace-legacy-systems-195/index.md) | January 25, 2023 | Guest: Robert Cooke (3forge)
- [DOP 194: How To Write Test Cases for Microservices](/episodes/how-to-write-test-cases-for-microservices-194/index.md) | January 18, 2023 | Guest: Darko Fabijan (Semaphore)
- [DOP 193: Automatic AI-Powered Database Tuning Using OtterTune](/episodes/automatic-ai-powered-database-tuning-using-ottertune-193/index.md) | January 11, 2023 | Guest: Andy Pavlo (OtterTune)
- [DOP 192: What Every DevOps Should Learn in 2023](/episodes/what-every-devops-should-learn-in-2023-192/index.md) | January 4, 2023
- [DOP 191: Looking Back on Our 2022 Predictions](/episodes/looking-back-on-our-2022-predictions-191/index.md) | December 28, 2022
- [DOP 190: Have You Started Your Shopping Yet?](/episodes/have-you-started-your-shopping-yet-190/index.md) | December 21, 2022
- [DOP 189: Code Anywhere on Any Device With Gitpod](/episodes/code-anywhere-on-any-device-with-gitpod-189/index.md) | December 14, 2022 | Guest: Chris Weichel (Gitpod)
- [DOP 188: Foster a Culture of Resilience With Steadybit](/episodes/foster-a-culture-of-resilience-with-steadybit-188/index.md) | December 7, 2022 | Guest: Benjamin Wilms (Steadybit)
- [DOP 187: Simplify Testing With Testcontainers](/episodes/simplify-testing-with-testcontainers-187/index.md) | November 30, 2022 | Guest: Sergei Egorov (AtomicJar)
- [DOP 186: Easily Get Your Code to the Cloud With Amnic](/episodes/easily-get-your-code-to-the-cloud-with-amnic-186/index.md) | November 23, 2022 | Guest: Ankit Bhati (Amnic)
- [DOP 185: What Is Cost Optimization in AWS?](/episodes/what-is-cost-optimization-in-aws-185/index.md) | November 16, 2022 | Guest: Ganesh The Awesome (GlobalDots)
- [DOP 184: How To Reduce Cloud Costs Using Tenacity](/episodes/how-to-reduce-cloud-costs-using-tenacity-184/index.md) | November 9, 2022 | Guest: Jason Yaeger (Tenacity Cloud)
- [DOP 183: Viktor’s Review of KubeCon 2022 Detroit](/episodes/viktors-review-of-kubecon-2022-detroit-183/index.md) | November 2, 2022
- [DOP 182: Why You Should Start a Side Project](/episodes/why-you-should-start-a-side-project-182/index.md) | October 26, 2022 | Guest: Ryan Kulp (Fork Equity)
- [DOP 181: Monitoring Kubernetes With Kubevious](/episodes/monitoring-kubernetes-with-kubevious-181/index.md) | October 19, 2022 | Guest: Ruben Hakopian (Kubevious)
- [DOP 180: What is AIOps?](/episodes/what-is-aiops-180/index.md) | October 12, 2022 | Guest: Richard Whitehead (Moogsoft)
- [DOP 179: What Are Service Level Objectives?](/episodes/what-are-service-level-objectives-179/index.md) | October 5, 2022 | Guest: Brian Singer (Nobl9)
- [DOP 178: Kubernetes Observability Using eBPF](/episodes/kubernetes-observability-using-ebpf-178/index.md) | September 28, 2022 | Guest: Shahar Azulay (groundcover)
- [DOP 177: How To Modernize Legacy Applications](/episodes/how-to-modernize-legacy-applications-177/index.md) | September 21, 2022 | Guest: Bob Quillin (vFunction)
- [DOP 176: Critical Skills That Every Engineer Should Master](/episodes/critical-skills-that-every-engineer-should-master-176/index.md) | September 14, 2022 | Guest: Sashank Purighalla (BOS Framework)
- [DOP 175: Applying DevOps Principles to Low-Code and No-Code Applications](/episodes/applying-devops-principles-to-low-code-and-no-code-applications-175/index.md) | September 7, 2022 | Guest: Gil Hoffer (Salto)
- [DOP 174: Security Concerns in Low-Code and No-Code Applications](/episodes/security-concerns-in-low-code-and-no-code-applications-174/index.md) | August 31, 2022 | Guest: Alon Jackson (Astrix Security)
- [DOP 173: Drag and Drop Deployments for Kubernetes With Harpoon](/episodes/drag-and-drop-deployments-for-kubernetes-with-harpoon-173/index.md) | August 24, 2022 | Guest: Dominic Holt (Harpoon)
- [DOP 172: Dynamically Manage Cloud Costs With Zesty](/episodes/dynamically-manage-cloud-costs-with-zesty-172/index.md) | August 17, 2022 | Guest: Maxim Melamedov (Zesty)
- [DOP 171: How Many Hours Do You Code per Day?](/episodes/how-many-hours-do-you-code-per-day-171/index.md) | August 10, 2022 | Guest: Mason McLead (Software)
- [DOP 170: Running Containers at the Edge](/episodes/running-containers-at-the-edge-170/index.md) | August 3, 2022 | Guest: Dan Bartholomew (Section)
- [DOP 169: How To Reduce Cloud Development Complexity](/episodes/how-to-reduce-cloud-development-complexity-169/index.md) | July 27, 2022 | Guest: Aaron Torres (Klotho) | Guest: Ala Shiban (Klotho)
- [DOP 168: Should You Use Docker Desktop in 2022?](/episodes/should-you-use-docker-desktop-in-2022-168/index.md) | July 20, 2022
- [DOP 167: How To Secure Kubernetes](/episodes/how-to-secure-kubernetes-167/index.md) | July 13, 2022 | Guest: Lachlan Evenson (Azure)
- [DOP 166: Are in Person Events Dead?](/episodes/are-in-person-events-dead-166/index.md) | July 6, 2022
- [DOP 165: Looking Back at KubeCon EU 2022](/episodes/looking-back-at-kubecon-eu-2022-165/index.md) | June 29, 2022
- [DOP 164: How To Monitor and Debug Microservices](/episodes/how-to-monitor-and-debug-microservices-164/index.md) | June 22, 2022 | Guest: Aviad Mor (Lumigo)
- [DOP 163: What Is Kubecost?](/episodes/what-is-kubecost-163/index.md) | June 15, 2022 | Guest: Webb Brown (Kubecost)
- [DOP 162: Performance Testing With k6](/episodes/performance-testing-with-k6-162/index.md) | June 8, 2022 | Guest: Nicole van der Hoeven (k6)
- [DOP 161: Why Incidents Are Slowing Down Companies](/episodes/why-incidents-are-slowing-down-companies-161/index.md) | June 1, 2022 | Guest: Matt Davis (Blameless) | Guest: Jake Englund (Blameless)
- [DOP 160: I’m New to CI/CD. Where Do I Start?](/episodes/im-new-to-ci-cd-where-do-i-start-160/index.md) | May 25, 2022
- [DOP 159: When to Use Kubernetes](/episodes/when-to-use-kubernetes-159/index.md) | May 18, 2022
- [DOP 158: Powering Zero Trust With OpenZiti](/episodes/powering-zero-trust-with-openziti-158/index.md) | May 11, 2022 | Guest: Mike Guthrie (NetFoundry)
- [DOP 157: How to Create a Startup](/episodes/how-to-create-a-startup-157/index.md) | May 4, 2022 | Guest: Aharale Batonia
- [DOP 156: Validate Your API Specifications With Cherrybomb](/episodes/validate-your-api-specifications-with-cherrybomb-156/index.md) | April 27, 2022 | Guest: Guy Levinger (BLST Security)
- [DOP 155: The Difference Between Projects and Products](/episodes/the-difference-between-projects-and-products-155/index.md) | April 20, 2022
- [DOP 154: Reducing Developer Friction](/episodes/reducing-developer-friction-154/index.md) | April 13, 2022
- [DOP 153: Eliminate Cloud Chaos With Firefly](/episodes/eliminate-cloud-chaos-with-firefly-153/index.md) | April 6, 2022 | Guest: Eran Bibi (Firefly)
- [DOP 152: An Internal Developer Platform Story](/episodes/an-internal-developer-platform-story-152/index.md) | March 30, 2022 | Guest: Diogo Correia (Pipedrive) | Guest: Ragnar Paide (Pipedrive)
- [DOP 151: What Is OpenTelemetry?](/episodes/what-is-opentelemetry-151/index.md) | March 23, 2022 | Guest: Ramon Guiu (Timescale)
- [DOP 150: Diagrams As Code](/episodes/diagrams-as-code-150/index.md) | March 16, 2022 | Guest: Patrick Debois (Tessl)
- [DOP 149: What Is FinOps?](/episodes/what-is-finops-149/index.md) | March 9, 2022 | Guest: Roi Ravhon (Finout)
- [DOP 148: Is Kubernetes Ready to Run Databases?](/episodes/is-kubernetes-ready-to-run-databases-148/index.md) | March 2, 2022 | Guest: Nicolas Vermandé (Ondat)
- [DOP 147: Should You Use a Recruiter When Looking for a Job?](/episodes/should-you-use-a-recruiter-when-looking-for-a-job-147/index.md) | February 23, 2022 | Guest: Erin Lovern (Grove Talent Group)
- [DOP 146: Context Means Everything in Security](/episodes/context-means-everything-in-security-146/index.md) | February 16, 2022 | Guest: Dean Agron (Oxeye)
- [DOP 145: What Does a DevOps Engineer Do?](/episodes/what-does-a-devops-engineer-do-145/index.md) | February 9, 2022
- [DOP 144: Is Open Source Sustainable?](/episodes/is-open-source-sustainable-144/index.md) | February 2, 2022
- [DOP 143: How to Get Started With CI/CD](/episodes/how-to-get-started-with-ci-cd-143/index.md) | January 26, 2022
- [DOP 142: Do We Need Coding for DevOps?](/episodes/do-we-need-coding-for-devops-142/index.md) | January 19, 2022
- [DOP 141: Five Reasons to Leave Your Job](/episodes/five-reasons-to-leave-your-job-141/index.md) | January 12, 2022
- [DOP 140: What Every DevOps Should Learn in 2022](/episodes/what-every-devops-should-learn-in-2022-140/index.md) | January 5, 2022
- [DOP 139: Is Markdown Good for Documentation?](/episodes/is-markdown-good-for-documentation-139/index.md) | December 29, 2021
- [DOP 138: Great Expectations](/episodes/great-expectations-138/index.md) | December 22, 2021
- [DOP 137: Shifting Infrastructure Management Left](/episodes/shifting-infrastructure-management-left-137/index.md) | December 15, 2021
- [DOP 136: Teaching Kubernetes to a New Team Member](/episodes/teaching-kubernetes-to-a-new-team-member-136/index.md) | December 8, 2021
- [DOP 135: Migrate Everything to Kubernetes](/episodes/migrate-everything-to-kubernetes-135/index.md) | December 1, 2021
- [DOP 134: The True Cost of Open Source](/episodes/the-true-cost-of-open-source-134/index.md) | November 24, 2021
- [DOP 133: APIs Are Everything](/episodes/apis-are-everything-133/index.md) | November 17, 2021 | Guest: Joyce Lin (Postman)
- [DOP 132: How to Manage a Remote Team](/episodes/how-to-manage-a-remote-team-132/index.md) | November 10, 2021 | Guest: David Burkus
- [DOP 131: The Cloud Skills Shortage Is Worse Than You Think](/episodes/the-cloud-skills-shortage-is-worse-than-you-think-131/index.md) | November 3, 2021 | Guest: Rosemary Wang
- [DOP 130: Signs of High Work in Progress](/episodes/signs-of-high-work-in-progress-130/index.md) | October 27, 2021
- [DOP 129: How to Develop Microservices](/episodes/how-to-develop-microservices-129/index.md) | October 20, 2021
- [DOP 128: Securing Your Environments With a Universal Secrets Manager](/episodes/securing-your-environments-with-a-universal-secrets-manager-128/index.md) | October 13, 2021 | Guest: Brian Vallelunga (Doppler)
- [DOP 127: Software Development vs Software Delivery](/episodes/software-development-vs-software-delivery-127/index.md) | October 6, 2021
- [DOP 126: What Is Bare Metal in Cloud Computing?](/episodes/what-is-bare-metal-in-cloud-computing-126/index.md) | September 29, 2021 | Guest: Ian McClarty (phoenixNAP)
- [DOP 125: What Is the Low Code Movement?](/episodes/what-is-the-low-code-movement-125/index.md) | September 22, 2021 | Guest: Mike Fitzmaurice (WEBCON)
- [DOP 124: Fake Data Rules the World](/episodes/fake-data-rules-the-world-124/index.md) | September 15, 2021 | Guest: Adam Kamor (Tonic.ai)
- [DOP 123: Simplifying Microservice Development](/episodes/simplifying-microservice-development-123/index.md) | September 8, 2021
- [DOP 122: What Are the Costs of a Digital Transformation?](/episodes/what-are-the-costs-of-a-digital-transformation-122/index.md) | September 1, 2021 | Guest: Randy Abernethy (RX-M)
- [DOP 121: Infrastructure As Code Meets Day Two](/episodes/infrastructure-as-code-meets-day-two-121/index.md) | August 25, 2021 | Guest: Tim Davis
- [DOP 120: Stop Using the D Word](/episodes/stop-using-the-d-word-120/index.md) | August 18, 2021
- [DOP 119: Developer Advocacy or Engineering?](/episodes/developer-advocacy-or-engineering-119/index.md) | August 11, 2021 | Guest: Anaïs Urlichs (Civo)
- [DOP 118: We Need More Silos, Not Less](/episodes/we-need-more-silos-not-less-118/index.md) | August 4, 2021
- [DOP 117: Understanding Why Gates Exist in Business](/episodes/understanding-why-gates-exist-in-business-117/index.md) | July 28, 2021
- [DOP 116: Why You Should Choose Boring Technology](/episodes/why-you-should-choose-boring-technology-116/index.md) | July 21, 2021
- [DOP 115: How Far Are You From No Touch Production?](/episodes/how-far-are-you-from-no-touch-production-115/index.md) | July 14, 2021
- [DOP 114: Solving Multitenancy Problems In Kubernetes](/episodes/solving-multitenancy-problems-in-kubernetes-114/index.md) | July 7, 2021
- [DOP 113: Are Specifications Still Relevant?](/episodes/are-specifications-still-relevant-113/index.md) | June 30, 2021 | Guest: Luca Ingianni
- [DOP 112: Essential Infrastructure as Code](/episodes/essential-infrastructure-as-code-112/index.md) | June 23, 2021 | Guest: Rosemary Wang
- [DOP 111: What Are Software Supply Chain Attacks?](/episodes/what-are-software-supply-chain-attacks-111/index.md) | June 16, 2021
- [DOP 110: The Problems With Microservices](/episodes/the-problems-with-microservices-110/index.md) | June 9, 2021
- [DOP 109: How to Test Microservices](/episodes/how-to-test-microservices-109/index.md) | June 2, 2021
- [DOP 108: Why Do We Want to Use Microservices?](/episodes/why-do-we-want-to-use-microservices-108/index.md) | May 19, 2021
- [DOP 107: Getting Into the Flow With Value Streams](/episodes/getting-into-the-flow-with-value-streams-107/index.md) | May 12, 2021 | Guest: Steve Pereira (Visible)
- [DOP 106: The Difference Between SRE and DevOps](/episodes/the-difference-between-sre-and-devops-106/index.md) | May 5, 2021
- [DOP 105: Does History Repeat Itself?](/episodes/does-history-repeat-itself-105/index.md) | April 28, 2021
- [DOP 104: Technical Debt Is a Business Decision](/episodes/technical-debt-is-a-business-decision-104/index.md) | April 21, 2021 | Guest: Dan Burns (Testifi)
- [DOP 103: Knative in Action](/episodes/knative-in-action-103/index.md) | April 14, 2021 | Guest: Jacques Chester (VMware)
- [DOP 102: Getting Started With Open Policy Agent](/episodes/getting-started-with-open-policy-agent-102/index.md) | April 7, 2021
- [DOP 101: What to Do When Technology Fails](/episodes/what-to-do-when-technology-fails-101/index.md) | March 31, 2021 | Guest: Nicolas Frankel (Hazelcast)
- [DOP 100: Course Correcting DevOps](/episodes/course-correcting-devops-100/index.md) | March 24, 2021 | Guest: Patrick Debois (Tessl)
- [DOP 99: Do DevOps Engineers Need to Know How to Code?](/episodes/do-devops-engineers-need-to-know-how-to-code-99/index.md) | March 17, 2021
- [DOP 98: Kubernetes Troubleshooting Simplified With Komodor](/episodes/kubernetes-troubleshooting-simplified-with-komodor-98/index.md) | March 10, 2021 | Guest: Itiel Shwartz (Komodor)
- [DOP 97: Processing Event Streams With Apache Kafka](/episodes/processing-event-streams-with-apache-kafka-97/index.md) | March 3, 2021 | Guest: Viktor Gamov (Confluent)
- [DOP 96: The Kubernetes API Is Becoming Omnipresent](/episodes/the-kubernetes-api-is-becoming-omnipresent-96/index.md) | February 24, 2021
- [DOP 95: Should Everything Be Automated?](/episodes/should-everything-be-automated-95/index.md) | February 17, 2021
- [DOP 94: Are Videos or Text Better for Learning?](/episodes/are-videos-or-text-better-for-learning-94/index.md) | February 10, 2021
- [DOP 93: Creating a Healthy Working Environment](/episodes/creating-a-healthy-working-environment-93/index.md) | February 3, 2021
- [DOP 92: Frontend vs Backend Development in 2021](/episodes/frontend-vs-backend-development-in-2021-92/index.md) | January 27, 2021 | Guest: Grady Saccullo (Cycle)
- [DOP 91: It's Past Time to Abandon Docker Compose](/episodes/its-past-time-to-abandon-docker-compose-91/index.md) | January 20, 2021 | Guest: Tobias Ericsson
- [DOP 90: Event Driven Continuous Delivery With Keptn](/episodes/event-driven-continuous-delivery-with-keptn-90/index.md) | January 13, 2021 | Guest: Andi Grabner
- [DOP 89: 2021 - the Year of the Irrelevant](/episodes/2021-the-year-of-the-irrelevant-89/index.md) | January 6, 2021
- [DOP 88: DevOps in 2020 - Year in Review](/episodes/devops-in-2020-year-in-review-88/index.md) | December 30, 2020
- [DOP 87: God Bless Us Everyone](/episodes/god-bless-us-everyone-87/index.md) | December 23, 2020
- [DOP 86: Your Internal Developer Platform Sucks](/episodes/your-internal-developer-platform-sucks-86/index.md) | December 16, 2020 | Guest: Alan Barr (Veterans United Home Loans)
- [DOP 85: The Hidden Costs of DevOps](/episodes/the-hidden-costs-of-devops-85/index.md) | December 9, 2020 | Guest: Yuval Oren (PineWise)
- [DOP 84: Mattermost Saves a 30 Year Old D&D Campaign](/episodes/mattermost-saves-a-30-year-old-d-d-campaign-84/index.md) | December 2, 2020 | Guest: PJ Hagerty (Mattermost)
- [DOP 83: Using Spring to Develop Cloud Native Applications](/episodes/using-spring-to-develop-cloud-native-applications-83/index.md) | November 25, 2020 | Guest: Thomas Vitale
- [DOP 82: Where You Live Shouldn't Define Your Pay](/episodes/where-you-live-shouldnt-define-your-pay-82/index.md) | November 18, 2020 | Guest: Olaf Molenveld (Vamp.io)
- [DOP 81: Making Email Provider Integration Simple With Nylas](/episodes/making-email-provider-integration-simple-with-nylas-81/index.md) | November 11, 2020 | Guest: Christine Spang (Nylas)
- [DOP 80: What Should I Outsource to a Managed Solution?](/episodes/what-should-i-outsource-to-a-managed-solution-80/index.md) | November 4, 2020
- [DOP 79: Are You Doing CI, CD or None of the Above?](/episodes/are-you-doing-ci-cd-or-none-of-the-above-79/index.md) | October 28, 2020 | Guest: Ant Weiss (Otomato)
- [DOP 78: A Day in the Life of a SRE](/episodes/a-day-in-the-life-of-a-sre-78/index.md) | October 21, 2020 | Guest: Adam Hawkins (Skillshare)
- [DOP 77: NOC as a Service with Xiteit](/episodes/noc-as-a-service-with-xiteit-77/index.md) | October 14, 2020 | Guest: Avi Shalisman | Guest: Asaf Matyas
- [DOP 76: How to be a Cloud Engineer with Pulumi](/episodes/how-to-be-a-cloud-engineer-with-pulumi-76/index.md) | October 7, 2020 | Guest: Joe Duffy (Pulumi)
- [DOP 75: What is Code?](/episodes/what-is-code-75/index.md) | September 30, 2020
- [DOP 74: Using GitOps in Your DevOps Workflow](/episodes/using-gitops-in-your-devops-workflow-74/index.md) | September 23, 2020
- [DOP 73: Logging with Loki](/episodes/logging-with-loki-73/index.md) | September 16, 2020
- [DOP 72: Mastering Kubernetes with Gigi Sayfan](/episodes/mastering-kubernetes-with-gigi-sayfan-72/index.md) | September 9, 2020 | Guest: Gigi Sayfan
- [DOP 71: Observability in the Cloud with CloudWize](/episodes/observability-in-the-cloud-with-cloudwize-71/index.md) | September 2, 2020 | Guest: Yotam Atad (Cloudwize.IO) | Guest: Chen Goldberg (Cloudwize.IO)
- [DOP 70: High Availability Does Not Mean 100% Availability](/episodes/high-availability-does-not-mean-100-availability-70/index.md) | August 26, 2020
- [DOP 69: Is Containers as a Service Serverless?](/episodes/is-containers-as-a-service-serverless-69/index.md) | August 19, 2020
- [DOP 68: Is Docker Back?](/episodes/is-docker-back-68/index.md) | August 12, 2020
- [DOP 67: Orchestrating Chaos on Kubernetes using LitmusChaos](/episodes/orchestrating-chaos-on-kubernetes-using-litmuschaos-67/index.md) | August 5, 2020 | Guest: Umasankar Mukkara (MayaData)
- [DOP 66: AWS Lambda vs. Google Cloud Functions vs. Azure Functions for 2020](/episodes/aws-lambda-vs-google-cloud-functions-vs-azure-functions-for-2020-66/index.md) | July 29, 2020
- [GCP Podcast - Serverless Made Easy with Nimbella](/episodes/serverless-made-easy-with-nimbella-65/index.md) | July 22, 2020 | Guest: Rodric Rabbah (Nimbella)
- [DOP 64: Do We Really Want To Use Serverless?](/episodes/do-we-really-want-to-use-serverless-64/index.md) | July 15, 2020
- [DOP 63: Serverless 101](/episodes/serverless-101-63/index.md) | July 8, 2020
- [DOP 62: Kubernetes Is Dead, Long Live Serverless](/episodes/kubernetes-is-dead-long-live-serverless-62/index.md) | July 1, 2020 | Guest: Ádám Sándor (Container Solutions)
- [DOP 61: How To Use PowerfulSeal To Create Chaos In Your Kubernetes Clusters](/episodes/how-to-use-powerfulseal-to-create-chaos-in-your-kubernetes-clusters-61/index.md) | June 24, 2020 | Guest: Mikolaj Pawlikowski (Bloomberg LP)
- [DOP 60: Jenkins X: Why Good Is Better Than Best](/episodes/jenkins-x-why-good-is-better-than-best-60/index.md) | June 17, 2020
- [DOP 59: Why It Is Silly Not To Use Kubernetes If You’re Moving To The Cloud Today](/episodes/why-it-is-silly-not-to-use-kubernetes-if-youre-moving-to-the-cloud-today-59/index.md) | June 10, 2020
- [DOP 58: Innovation And The Sunk Cost Fallacy](/episodes/innovation-and-the-sunk-cost-fallacy-58/index.md) | June 3, 2020 | Guest: Nirmal Mehta
- [DOP 57: Join An Open Source Foundation And Get Free Stickers!](/episodes/join-an-open-source-foundation-and-get-free-stickers-57/index.md) | May 27, 2020 | Guest: Tracy Miranda
- [DOP 56: What Happens When You Just Don't Have The Time To Learn?](/episodes/what-happens-when-you-just-dont-have-the-time-to-learn-56/index.md) | May 20, 2020 | Guest: Joost van der Griendt
- [DOP 55: How To Setup And Operate Multiple Kubernetes Clusters At A Global Scale](/episodes/how-to-setup-and-operate-multiple-kubernetes-clusters-at-a-global-scale-55/index.md) | May 13, 2020 | Guest: Carlos Sanchez (Adobe)
- [DOP 54: Achieving Continuous Verification Using Chaos Engineering](/episodes/achieving-continuous-verification-using-chaos-engineering-54/index.md) | May 6, 2020 | Guest: Russ Miles (ChaosIQ.io) | Guest: Sylvain Hellegouarch (ChaosIQ.io)
- [DOP 53: Should You Maintain Your Systems Or Let Them Rot On The Vine?](/episodes/should-you-maintain-your-systems-or-let-them-rot-on-the-vine-53/index.md) | April 29, 2020
- [DOP 52: A Step By Step Guide To Trashing Other Vendor's Products](/episodes/a-step-by-step-guide-to-trashing-other-vendors-products-52/index.md) | April 22, 2020
- [DOP 51: Is Shifting Left All It Is Cracked Up To Be?](/episodes/is-shifting-left-all-it-is-cracked-up-to-be-51/index.md) | April 15, 2020 | Guest: Ádám Sándor (Container Solutions)
- [DOP 50: DevOps In The Time Of Mandated Remote Work](/episodes/devops-in-the-time-of-mandated-remote-work-50/index.md) | April 8, 2020 | Guest: Patrick Debois (Tessl)
- [DOP 49: How Are You Adapting To Remote Work?](/episodes/how-are-you-adapting-to-remote-work-49/index.md) | April 1, 2020
- [BONUS: What Are The Challenges To Doing Continuous Delivery In Kubernetes?](/episodes/what-are-the-challenges-to-doing-continuous-delivery-in-kubernetes-bonus/index.md) | March 27, 2020 | Guest: James Rawlings | Guest: James Strachan
- [DOP 48: Regulations Aren't An Excuse For Not Doing The Right Thing](/episodes/regulations-arent-an-excuse-for-not-doing-the-right-thing-48/index.md) | March 25, 2020 | Guest: Tigran Mnatsakanyan | Guest: Roger Day
- [BONUS: Continue Building Your Kubernetes Skills Using Remote Learning During The COVID-19 Crisis](/episodes/continue-building-your-kubernetes-skills-using-remote-learning-during-the-covid-19-crisis-bonus/index.md) | March 23, 2020 | Guest: Mislav Stipetic (Magic Sandbox, The Kubernetes training platform)
- [DOP 47: Technology Isn't the Problem. You Are The Problem.](/episodes/technology-isnt-the-problem-you-are-the-problem-47/index.md) | March 18, 2020
- [DOP 46: Making Containers Great Again - A Conversation With Phil Estes](/episodes/making-containers-great-again-a-conversation-with-phil-estes-46/index.md) | March 11, 2020 | Guest: Phil Estes (IBM)
- [DOP 45: (Almost) No One Cares Enough About Kubernetes To Learn It](/episodes/almost-no-one-cares-enough-about-kubernetes-to-learn-it-45/index.md) | March 4, 2020
- [DOP 44: Is It Possible To Make On Premise Great Again?](/episodes/is-it-possible-to-make-on-premise-great-again-44/index.md) | February 26, 2020
- [DOP 43: There Is No Such Thing As Continuous Testing](/episodes/there-is-no-such-thing-as-continuous-testing-43/index.md) | February 19, 2020
- [DOP 42: Is Your CTO Always Going To Be Your CTO?](/episodes/is-your-cto-always-going-to-be-your-cto-42/index.md) | February 12, 2020
- [DOP 41: Input Questions And UIs Are Evil](/episodes/input-questions-and-uis-are-evil-41/index.md) | February 5, 2020
- [DOP 40: Continuous Reliability: How To Avoid The Biggest Mistakes Developers Make](/episodes/continuous-reliability-how-to-avoid-the-biggest-mistakes-developers-make-40/index.md) | January 29, 2020 | Guest: Eric Mizell (OverOps)
- [DOP 39: One API To Rule Them All](/episodes/one-api-to-rule-them-all-39/index.md) | January 22, 2020
- [DOP 38: How Important Are You To Your Company?](/episodes/how-important-are-you-to-your-company-38/index.md) | January 15, 2020
- [DOP 37: 50 Shades of Canary Deployments](/episodes/50-shades-of-canary-deployments-37/index.md) | January 8, 2020
- [DOP 36: 4 predictions for DevOps in 2020](/episodes/4-predictions-for-devops-in-2020-36/index.md) | January 1, 2020
- [DOP 35: Looking Back at 2019](/episodes/looking-back-at-2019-35/index.md) | December 25, 2019
- [DOP 34: To All The Dockers I've Loved Before](/episodes/to-all-the-dockers-ive-loved-before-34/index.md) | December 18, 2019
- [DOP 33: What Happens When There Are Tektonic Shifts In Technology](/episodes/what-happens-when-there-are-tektonic-shifts-in-technology-33/index.md) | December 11, 2019
- [DOP 32: Which Managed Kubernetes Service Sucks The Least - The Prelude](/episodes/which-managed-kubernetes-service-sucks-the-least-the-prelude-32/index.md) | December 4, 2019
- [DOP 31: Do Shared Services Teams Break The DevOps Rules?](/episodes/do-shared-services-teams-break-the-devops-rules-31/index.md) | November 27, 2019
- [BONUS: Viktor's KubeCon 2019 Review](/episodes/viktors-kubecon-2019-review-dop-bonus/index.md) | November 25, 2019
- [DOP 30: Site Reliability Engineering Traps To Avoid](/episodes/site-reliability-engineering-traps-to-avoid-30/index.md) | November 20, 2019 | Guest: Matt Turner (Ziglu)
- [DOP 29: Elasticsearch: Is It A Database Or A Datastore?](/episodes/elasticsearch-is-it-a-database-or-a-datastore-29/index.md) | November 13, 2019 | Guest: Philipp Krenn (Elastic)
- [DOP 28: Is Service Mesh Your New Best Friend?](/episodes/is-service-mesh-your-new-best-friend-28/index.md) | November 6, 2019 | Guest: Peter Jausovec (Oracle)
- [DOP 27: What Would Burt Gummer Do?](/episodes/what-would-burt-gummer-do-27/index.md) | October 30, 2019
- [DOP 26: The Architect Role In Your Company Is Completely Useless](/episodes/the-architect-role-in-your-company-is-completely-useless-26/index.md) | October 23, 2019
- [DOP 25: Tips for Conference Attendees Who Want Learn a New Skill](/episodes/tips-for-conference-attendees-who-want-learn-a-new-skill-25/index.md) | October 16, 2019
- [DOP 24: Deployment Strategy Myths Enterprises Actually Believe](/episodes/deployment-strategy-myths-enterprises-actually-believe-24/index.md) | October 9, 2019
- [DOP 23: Do Feature Flags Even Matter?](/episodes/do-feature-flags-even-matter-23/index.md) | October 2, 2019 | Guest: Erez Rusovsky (Rollout.io)
- [DOP 22: The Reasons That Motivate Us To Work, Learn, And Write](/episodes/the-reasons-that-motivate-us-to-work-learn-and-write-22/index.md) | September 25, 2019
- [DOP 21: Time Management Secrets Every Software Engineer Needs Now](/episodes/time-management-secrets-every-software-engineer-needs-now-21/index.md) | September 18, 2019
- [DOP 20: Configuration Management Mistakes Enterprises Make...And How To Avoid Them](/episodes/configuration-management-mistakes-enterprises-make-and-how-to-avoid-them-20/index.md) | September 11, 2019 | Guest: John Laffey (Puppet)
- [DOP 19: Are You A Hacker Or Developer?](/episodes/are-you-a-hacker-or-developer-19/index.md) | September 4, 2019
- [DOP 18: How To Avoid Issue Tracking Mistakes Teams Make](/episodes/how-to-avoid-issue-tracking-mistakes-teams-make-18/index.md) | August 28, 2019
- [DOP 17: The Learning Styles Of The Rich and Famous](/episodes/the-learning-styles-of-the-rich-and-famous-17/index.md) | August 21, 2019
- [DOP 16: Don't Let Someone Automate You Out Of Your Job](/episodes/dont-let-someone-automate-you-out-of-your-job-16/index.md) | August 14, 2019
- [DOP 15: Silos Are For Farmers, Not Enterprises](/episodes/silos-are-for-farmers-not-enterprises-15/index.md) | August 7, 2019
- [DOP 14: Creating Happy Customers Through GitOps](/episodes/creating-happy-customers-through-gitops-14/index.md) | July 31, 2019
- [DOP 13: What Tricks Does Viktor Have Up His Sleeve?](/episodes/what-tricks-does-viktor-have-up-his-sleeve-13/index.md) | July 24, 2019
- [DOP 12: Why Understanding English Is Important For Developers](/episodes/why-understanding-english-is-important-for-developers-12/index.md) | July 17, 2019
- [DOP 11: Is Serverless The New Wild West?](/episodes/is-serverless-the-new-wild-west-11/index.md) | July 10, 2019
- [DOP 10: Why Open Source is important to your business](/episodes/why-open-source-is-important-to-your-business-10/index.md) | July 3, 2019
- [DOP 9: What Is The Maturity Level Of Your Continuous Deployment?](/episodes/what-is-the-maturity-level-of-your-continuous-deployment-9/index.md) | June 26, 2019
- [DOP 8: How To Escape The Continuous Delivery Rat Race](/episodes/how-to-escape-the-continuous-delivery-rat-race-8/index.md) | June 19, 2019
- [DOP 7: Continuous Integration Tips for Engineers Who Want Sleep Through The Night](/episodes/continuous-integration-tips-for-engineers-who-want-sleep-through-the-night-7/index.md) | June 12, 2019
- [DOP 6: Five Career Tips Every Successful DevOps Professional Needs To Know](/episodes/five-career-tips-every-successful-devops-professional-needs-to-know-6/index.md) | June 5, 2019
- [DOP 5: Do We Still Need Configuration Management?](/episodes/do-we-still-need-configuration-management-5/index.md) | May 15, 2019
- [DOP 4: Current Trends In DevOps](/episodes/current-trends-in-devops-4/index.md) | May 8, 2019
- [DOP 3: How Jenkins X Simplifies Kubernetes](/episodes/how-jenkins-x-simplifies-kubernetes-3/index.md) | May 2, 2019
- [DOP 2: Why Is Everyone So Crazy About Kubernetes?](/episodes/why-is-everyone-so-crazy-about-kubernetes-2/index.md) | May 2, 2019
- [DOP 1: What Is DevOps?](/episodes/what-is-devops-1/index.md) | May 2, 2019
- [DOP 0: Welcome](/episodes/welcome-0/index.md) | May 1, 2019



## Frequently Asked Questions

### [Why is running npm install a security risk?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-why-is-running-npm-install-a-security-risk)

Running npm install executes arbitrary code on your machine before and after a package is put in place. David Mytton of Arcjet explains on DevOps Paradox episode 366 that npm supports pre-install and post-install hooks, so a package author can run whatever they like on a developer laptop, in a CI pipeline, or in production. He describes the hooks as a convenience from an era when the registry was treated as a trusted community resource. Configuration options exist to disable them, but they are not the default.

### [How long should an npm dependency cooldown period be?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-how-long-should-an-npm-dependency-cooldown-period-be)

Seven days is the cooldown David Mytton uses at Arcjet, he says on DevOps Paradox episode 366. Most of the recent npm compromises were live for only a couple of hours before being caught, so a seven-day wait catches the majority of them while keeping you current enough that a genuine security update is not badly delayed. Arcjet enforces it through Renovate, which lists the dependencies still inside the window separately and allows a deliberate bypass when an urgent fix lands.

### [What is the difference between npm install and npm ci?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-what-is-the-difference-between-npm-install-and-npm-ci)

npm ci installs from an existing lock file, so the same versions are installed every time, while npm install resolves versions afresh. David Mytton explains on DevOps Paradox episode 366 that npm install also adds a new package with a version range rather than a pinned version by default, which is how a compromised release deeper in the dependency tree gets pulled in automatically. He sets npm configuration to pin dependencies on all of his own projects.

### [Does npm trusted publishing stop supply chain attacks?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-does-npm-trusted-publishing-stop-supply-chain-attacks)

Trusted publishing closes one attack path and leaves the larger one open, David Mytton argues on DevOps Paradox episode 366. It replaces long-lived publishing tokens with short-lived OIDC credentials issued to a build workflow and ties a released package back to the provenance of its build, and npm's newer staged releases can require a second person to approve a publish. None of that inspects what is inside the package, so a release containing malware remains an entirely separate problem.

### [How do you isolate a development environment from compromised npm packages?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-how-do-you-isolate-a-development-environment-from-compromised-npm-packages)

Run dependency installs inside a container or a virtual machine so that nothing reaches the host. David Mytton says on DevOps Paradox episode 366 that Arcjet used dev containers and then moved to lightweight virtual machines on macOS, because the team runs several work trees in parallel for AI agents and a VM offers a stronger isolation guarantee. Malware in the dependency tree then has no access to keys on disk, password manager contents, or browser cookies, and the environment can simply be deleted.

### [How would you know if a compromised npm package ran on your laptop?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-how-would-you-know-if-a-compromised-npm-package-ran-on-your-laptop)

Usually you would not, David Mytton acknowledges on DevOps Paradox episode 366, because a post-install script can exfiltrate credentials and then delete itself. Arcjet runs endpoint management and scanning tools that watch for known indicators of compromise, and Mytton suggests a canary token left on disk that raises an alert if anything reads it. Without something along those lines, the first sign is often someone reaching your production environment or your sessions being logged out.

### [What is the DevOps Paradox podcast?](/episodes/how-to-prevent-npm-supply-chain-attacks-366/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 366 features David Mytton of Arcjet on npm supply chain attacks: why install hooks hand packages arbitrary code execution, what trusted publishing and staged releases do and do not fix, and why a seven-day dependency cooldown catches most compromises. Every episode page carries audio, video, and a full transcript.

### [What does the DORA report say about AI's return on investment?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-what-does-the-dora-report-say-about-ais-return-on-investment)

Darin Pope summarises the May 2026 DORA report on DevOps Paradox episode 365 in a single line: AI without engineering excellence just scales your problems. Productivity is not the issue. Organizations lacking mature platforms, clear workflows, and strong reviews amplify chaos when they switch AI on. The report also describes a J curve, with a dip in productivity across the first one to three months before output climbs.

### [Why does AI make a bad codebase worse?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-why-does-ai-make-a-bad-codebase-worse)

Viktor Farcic explains on DevOps Paradox episode 365 that an agent asked to add a feature does not invent an approach. It reads how you already do things and produces more of the same. Flaky tests beget more flaky tests. He adds a second problem on top: once the agent works out what you actually want, it does that job well, and what you wanted may have been wrong in the first place.

### [What should you measure before adopting AI?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-what-should-you-measure-before-adopting-ai)

Darin Pope lists the DORA baselines on DevOps Paradox episode 365: platform quality, CI/CD speed, code review SLAs, incident mean time to resolution, and deployment frequency. Viktor Farcic dismisses most technical metrics as gameable, lines of code above all, and argues the only measurement that survives contact with reality is money. His preferred version is the ratio of prospects converting to customers, tracked over a long period.

### [Should you send your team on AI training courses?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-should-you-send-your-team-on-ai-training-courses)

Darin Pope's advice on DevOps Paradox episode 365 is no. Give people the tools and access to your existing source code instead, and he reckons they will learn more in three days of that than in a three-day course. Viktor Farcic goes further: if AI is producing no benefit at your company, something in your system is broken, and the job is to find it rather than abandon the attempt.

### [What is agentic engineering?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-what-is-agentic-engineering)

Darin Pope explains on DevOps Paradox episode 365 that Andrej Karpathy, who coined the term vibe coding, later reframed the serious version as agentic engineering: design the system, specify the constraints, then use AI to accelerate something you have already reasoned through. Darin's observation is that the first two steps describe every project in history. Viktor Farcic adds that he now uses agents during the reasoning phase as well.

### [How do you review more code than you can read?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-how-do-you-review-more-code-than-you-can-read)

Viktor Farcic admits on DevOps Paradox episode 365 that he no longer understands his own hobby projects at the code level, only at the level of architecture. His response is to improve validation rather than slow production down. On a CLI project he has agents record video clips of each test case, so his morning review starts by watching those recordings and then choosing which parts to run by hand.

### [What is the DevOps Paradox podcast?](/episodes/what-the-dora-ai-roi-report-really-says-365/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 365 works through the DORA report on the return on investment of AI-assisted development, why AI amplifies whatever practices you already have, and what to measure before switching it on. Every episode page carries audio, video, and a full transcript.

### [Whose burnout does burnout-proof leadership actually protect?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-whose-burnout-does-burnout-proof-leadership-actually-protect)

Victoria Mensch tells DevOps Paradox episode 364 that she teaches it at the individual level, drawing on several cycles of burnout of her own before she recognized what they were. She grants that systemic conditions contribute, but focuses on separating what a person controls from what they do not. An individual contributor cannot set the team's workload; they can decide how they organize work, recharge, delegate, and stop equating hours with value.

### [Is leadership the same thing as being an executive?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-is-leadership-the-same-thing-as-being-an-executive)

Victoria Mensch argues on DevOps Paradox episode 364 that it is not. She describes leadership as self-leadership rather than a position on the hierarchy, so someone with nobody reporting to them still leads in their career and their work. Her immersion programs at SV Executive Academy do take executives, but also people from every level of an organization, mostly from traditional industries and larger companies outside Silicon Valley.

### [Should a company appoint a chief AI officer?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-should-a-company-appoint-a-chief-ai-officer)

Darin Pope pushes back on the title in DevOps Paradox episode 364, reading it as another silo in an already bloated organization. Viktor Farcic's objection differs: handing AI to a separate officer signals the CEO does not yet treat it as core business, the way banks once handed off software. Victoria Mensch answers that placement varies, some under HR and some under IT, and that the arrangements which work are the ones where the CEO takes ownership.

### [Why do most AI pilots never reach production?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-why-do-most-ai-pilots-never-reach-production)

Victoria Mensch's answer on DevOps Paradox episode 364 is that many were never meant to. Some pilots existed to find out what the technology could do, and treating those as failed products misreads them. Taking one to scale is a separate question that has to clear organizational, leadership and technology conditions, and those differ for a startup, a mid-size company, and a large firm in a heavily regulated industry.

### [Can a traditional company become a disruptor?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-can-a-traditional-company-become-a-disruptor)

Victoria Mensch's position on DevOps Paradox episode 364 is that it usually cannot, and does not need to. A startup is a temporary organization looking for a stable business model and has little to lose, while a large established company is built around something that already works. Her advice is adaptability rather than self-disruption: preserve the core business and innovate alongside it. Viktor Farcic notes that permanently catching up is a dangerous place to sit.

### [Are middle managers disappearing because of AI?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-are-middle-managers-disappearing-because-of-ai)

Victoria Mensch tells DevOps Paradox episode 364 that she does not see it, and that any such trend is slower than the headlines suggest. She has not yet seen a reasonably complex process run by AI with no human involved. What she does see is jobs being unbundled: some tasks within a role get automated, while the role itself, which exists to solve a problem, continues in a redefined form.

### [What is the DevOps Paradox podcast?](/episodes/how-to-avoid-burnout-as-a-leader-364/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 364, "How to Avoid Burnout as a Leader," brings in Dr. Victoria Mensch of SV Executive Academy to work through burnout, chief AI officer titles, and why innovation programs stall inside traditional enterprises. Every episode page carries the audio, the video, and a full transcript.

### [How do I make my website agent-ready for AI crawlers and assistants?](/episodes/is-your-website-agent-ready-363/index.md#faq-how-do-i-make-my-website-agent-ready-for-ai-crawlers-and-assistants)

Darin Pope breaks it into four parts on DevOps Paradox episode 363: discoverability through robots.txt and sitemaps, content accessibility, bot access control, and capabilities such as APIs and MCP servers. He points at Cloudflare's isitagentready.com as a way to score a site, noting devopsparadox.com sat around 70 out of 100. Getting structured data right with schema.org markup sits alongside all of that.

### [Should you serve Markdown instead of HTML to AI agents?](/episodes/is-your-website-agent-ready-363/index.md#faq-should-you-serve-markdown-instead-of-html-to-ai-agents)

Darin Pope's answer on DevOps Paradox episode 363 is to serve both, chosen by content negotiation: HTML when a browser asks for it, Markdown when the request carries text/markdown. That means fewer tokens to parse and no headers, image tags, or markup to strip out. Viktor Farcic adds that Markdown is genuinely more compact, since italics cost two characters and a heading costs one, where HTML costs more.

### [Should you block AI crawlers from your website?](/episodes/is-your-website-agent-ready-363/index.md#faq-should-you-block-ai-crawlers-from-your-website)

Viktor Farcic's position on DevOps Paradox episode 363 is that if you do not want to be found, you should not be public in the first place. Making the site private is simpler than fighting crawlers. Darin Pope adds that robots.txt was only ever a suggestion, so anyone serious about blocking has to do it at the firewall, with friction real enough that crawling stops being worth paying for.

### [Do you need an MCP server, or is a good API enough?](/episodes/is-your-website-agent-ready-363/index.md#faq-do-you-need-an-mcp-server-or-is-a-good-api-enough)

Viktor Farcic argues on DevOps Paradox episode 363 that it depends entirely on who your users are. Developers work through agents whose primary tool is a shell, so a CLI covers them. Everyone else needs an MCP server, because a non-technical user is never going to install a command line tool. His larger point is that both are generated from the API, which makes the API the real work.

### [Is being agent-ready just SEO again?](/episodes/is-your-website-agent-ready-363/index.md#faq-is-being-agent-ready-just-seo-again)

Viktor Farcic says on DevOps Paradox episode 363 that the optimisation framing carries over but the game does not. Where people once browsed for information, they now work through an intermediary that acts on their behalf. The two questions worth asking are whether your content is the first answer the model gives, and failing that, whether you are among the handful of sites it goes off to read.

### [Should documentation live in the code?](/episodes/is-your-website-agent-ready-363/index.md#faq-should-documentation-live-in-the-code)

Viktor Farcic says on DevOps Paradox episode 363 that he writes less documentation inside code now than he ever did before. Two years ago he wanted it next to the function so it stood a chance of being updated. Now that agents produce the first pass, he wants tests, code, and documentation kept separate so each can be reviewed on its own. Documentation gets the most of his review attention.

### [What is the DevOps Paradox podcast?](/episodes/is-your-website-agent-ready-363/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 363 works through what it takes to make a website agent-ready, from serving Markdown by content negotiation to deciding whether you need an MCP server or just a better API. Every episode page carries audio, video, and a full transcript.

### [When should you use feature flags instead of canary deployments?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-when-should-you-use-feature-flags-instead-of-canary-deployments)

Alex Casalboni of Unleash draws the line on DevOps Paradox episode 362 at whether the switch needs application-level knowledge. Swapping a database, an API vendor, or a hostname stays at the infrastructure level, where canary and blue-green deployments fit well. Anything depending on user context, or where you want three A/B tests and ten behaviours running at once, gets unmanageable as a canary. Teams commonly use both at different layers.

### [What is FeatureOps?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-what-is-featureops)

Alex Casalboni describes it on DevOps Paradox episode 362 as applying DevOps principles after the deployment rather than only up to it. Most tooling helps until code reaches production, and after that a problem means another hotfix and another pipeline run. FeatureOps is about runtime control: changing application behaviour in production in seconds to shrink the blast radius of an incident, instead of waiting on a release cycle.

### [Is it still a feature flag if changing it requires a redeploy?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-is-it-still-a-feature-flag-if-changing-it-requires-a-redeploy)

Alex Casalboni's answer on DevOps Paradox episode 362 is no, and he presents it as Unleash's opinionated position. If flipping the flag needs a full CI/CD run and a redeployment, what you have is closer to an environment variable read once at startup. He notes many enterprises live with a twelve to twenty-four hour round trip between spotting a problem and getting a hotfix into production.

### [How do you stop feature flags turning into technical debt?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-how-do-you-stop-feature-flags-turning-into-technical-debt)

Alex Casalboni cites research on DevOps Paradox episode 362 showing an order of magnitude gap between the number of flags companies create each year and the number they clean up. One customer's oldest flag dated from 2012. His advice is to put cleanup into the definition of done, and he describes wiring an MCP server into a GitHub workflow so marking a flag complete opens a cleanup pull request automatically.

### [Should feature flag evaluation happen over an API call?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-should-feature-flag-evaluation-happen-over-an-api-call)

Alex Casalboni argues against it on DevOps Paradox episode 362 for two reasons. A round trip rarely costs less than ten or twenty milliseconds, and rendering a single page may check ten flags. The second reason gets less attention: evaluating a flag needs user context, which can include personal data, so a remote call sends that outside your perimeter. Local evaluation keeps both the latency and the data at home.

### [Do you need to test every combination of your feature flags?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-do-you-need-to-test-every-combination-of-your-feature-flags)

Alex Casalboni says on DevOps Paradox episode 362 that combinatorially it looks impossible, but in practice it is not. Most flags never touch the same code path, and many only ever move from off to on before being removed. His suggestion is to start from the current production state and test the major branches from there, so ten flags means roughly five or six cases rather than a hundred.

### [What is the DevOps Paradox podcast?](/episodes/feature-flags-vs-canary-deployments-362/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 362 features Alex Casalboni of Unleash on FeatureOps, where feature flags fit alongside canary deployments, and how to keep flags from piling up as technical debt. Every episode page carries audio, video, and a full transcript.

### [Should open source maintainers accept AI-generated pull requests?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-should-open-source-maintainers-accept-ai-generated-pull-requests)

Viktor Farcic's position on DevOps Paradox episode 361 is yes. He argues a maintainer's first responsibility is to guide and help and bring people in to contribute, and that the moment you allow pull requests you have moved from individual contributor to manager. Maintainers who do not want that role should close pull requests outright and say so plainly, rather than blaming unknown contributors for a job they signed up for.

### [How long does it take to review a 6,000-line AI-generated pull request?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-how-long-does-it-take-to-review-a-6000-line-ai-generated-pull-request)

Viktor Farcic estimates on DevOps Paradox episode 361 that he can work through a 6,000-line pull request with Claude in roughly the time someone would spend manually reviewing 600 lines, about one tenth. His process runs CodeRabbit and Greptile first to clear obvious issues, then a second guided pass where he directs the AI toward specific concerns instead of letting it work from the pull request context alone.

### [Are unknown contributors a good reason to reject pull requests?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-are-unknown-contributors-a-good-reason-to-reject-pull-requests)

Viktor Farcic rejects that reasoning on DevOps Paradox episode 361, pointing out that unless you started a project yourself, everyone on it was an unknown contributor once, the maintainer included. He grants the security risk is real, then points at the XZ backdoor as social engineering that predated AI and needed none of it. What changed, he argues, is the quantity of pull requests, not the percentage that are malicious.

### [Is manual line-by-line code review still workable?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-is-manual-line-by-line-code-review-still-workable)

Viktor Farcic argues on DevOps Paradox episode 361 that a maintainer counting on a manual review process today is, in his words, terribly wrong. He describes a third group of maintainers who are not good enough with agents to fight agents, and says they are the ones falling behind. His own attention moves up a level, to architecture and to the feature itself, once tooling has cleared the nitpicks.

### [Can open source maintainers afford AI code review tools?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-can-open-source-maintainers-afford-ai-code-review-tools)

Darin Pope raises the cost problem on DevOps Paradox episode 361, noting that developers outside the United States generally have less cash flow, and that paid subscriptions or hardware to run open models both cost money a volunteer maintainer may not have. Viktor Farcic answers that a good deal is available free, citing Greptile and a free open source option from CodeRabbit, and predicts tokens will become as assumed as internet access.

### [What happens to an open source project that stops accepting pull requests?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-what-happens-to-an-open-source-project-that-stops-accepting-pull-requests)

Viktor Farcic's answer on DevOps Paradox episode 361 is that users leave. He says a rejected pull request, as opposed to one he is guided through and improves, leaves him two options: maintain his own fork, or rebuild the thing from scratch. Darin Pope pushes the case harder by asking what would happen if Kubernetes accepted contributions from only two people. Viktor's answer is an immediate switch to something else.

### [What is the DevOps Paradox podcast?](/episodes/when-code-got-cheap-reviewing-got-expensive-361/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 361, "When Code Got Cheap, Reviewing Got Expensive," works through why some open source maintainers are turning away AI-generated pull requests, and what that does to the economics of reviewing code. Every episode page carries the audio, the video, and a full transcript.

### [What is an AI SRE and what does it actually do?](/episodes/what-is-an-ai-sre-360/index.md#faq-what-is-an-ai-sre-and-what-does-it-actually-do)

Birol Yildiz of iLert describes it on DevOps Paradox episode 360 as an agent that runs the investigation an on-call engineer would run. It reads telemetry, recent changes, infrastructure health, CI/CD pipelines, and source code, then produces a root cause analysis with recommended actions. Instead of being paged to a blank alert, the engineer opens a completed investigation. Being able to verify its own fix is the part he says matters most.

### [How is an AI SRE different from AIOps or self-healing?](/episodes/what-is-an-ai-sre-360/index.md#faq-how-is-an-ai-sre-different-from-aiops-or-self-healing)

Viktor Farcic draws the line on DevOps Paradox episode 360: self-healing runs on predefined patterns, so a crashed pod gets restarted because somebody anticipated that case. Birol Yildiz adds that AIOps trained models on your own data and largely did not deliver what it promised. His approach trains nothing at all, using frontier foundation models inside a harness that supplies context and runs an investigation loop.

### [Should you feed your runbooks and wiki to an AI SRE?](/episodes/what-is-an-ai-sre-360/index.md#faq-should-you-feed-your-runbooks-and-wiki-to-an-ai-sre)

Birol Yildiz argues against it on DevOps Paradox episode 360, noting his product has no runbook integration at all. Pointing an agent at hundreds of stale runbooks and a Confluence wiki, in his view, causes more damage than it produces results. The most current documentation is the code and the telemetry. Viktor Farcic agrees the company knowledge is garbage, while suspecting you cannot reach the final destination without some of it.

### [How autonomous should an incident response agent be?](/episodes/what-is-an-ai-sre-360/index.md#faq-how-autonomous-should-an-incident-response-agent-be)

Birol Yildiz lays out four levels on DevOps Paradox episode 360: observe only, human in the loop, pre-approved classes of action where confidence is high, and full autonomy. He says no iLert customer runs fully autonomously in production, and his own team has reached level three only in staging. Trust is binary in his experience, so a single bad mistake strips an agent's write access entirely.

### [Who is accountable when an AI SRE makes an incident worse?](/episodes/what-is-an-ai-sre-360/index.md#faq-who-is-accountable-when-an-ai-sre-makes-an-incident-worse)

Birol Yildiz's answer on DevOps Paradox episode 360 is that it has to be a person, because an agent cannot carry accountability. He draws the parallel to coding agents: if the code is bad, blaming the model does not transfer the responsibility anywhere. To help people judge the output, iLert attaches a confidence level to each hypothesis and links every key finding back to the deployment or log line behind it.

### [Does your company need to be mature before adopting an AI SRE?](/episodes/what-is-an-ai-sre-360/index.md#faq-does-your-company-need-to-be-mature-before-adopting-an-ai-sre)

Birol Yildiz is direct about this on DevOps Paradox episode 360: if you have skipped the homework for fifteen or twenty years, there are things worth fixing before adopting AI in production. Some prospects have no observability at all and hope an agent lets them skip that step. Viktor Farcic's version is that the success of any AI adoption tracks closely with where a company already sits technologically.

### [What is the DevOps Paradox podcast?](/episodes/what-is-an-ai-sre-360/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 360 features Birol Yildiz of iLert on what an AI SRE actually does during an incident, how far teams should let one act on its own, and who carries the blame when it gets the diagnosis wrong. Every episode page carries audio, video, and a full transcript.

### [Are product demo videos still worth making?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-are-product-demo-videos-still-worth-making)

Viktor Farcic says on DevOps Paradox episode 359 that he rarely watches one and mostly runs demos himself. For an open source project he argues a good README, a quick start, and an agents.md file cover it. Darin Pope keeps a place for video but caps it tightly: five minutes for a technical viewer trying to solve one thing, ten at the outside, and only if it stays tight throughout.

### [What does making a product agent-friendly actually mean?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-what-does-making-a-product-agent-friendly-actually-mean)

Viktor Farcic's answer on DevOps Paradox episode 359 is that every level of a product should make life easier for agents, whether that means an MCP server, a CLI, skills, or simply not blocking your own site from them. He describes asking Claude to gather one cloud provider's pricing shortly before recording and getting back a Cloudflare block. Darin Pope adds clean markdown, llms.txt, and a published OpenAPI spec.

### [Do AI agents need different documentation than humans?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-do-ai-agents-need-different-documentation-than-humans)

Viktor Farcic argues on DevOps Paradox episode 359 that the rules are the same for both for now, and puts an equals sign between them. He rates agent-specific documentation as good rather than critical, since sifting through HTML costs more tokens but changes little he notices. What did change is speed: thin documentation was survivable when the work around it was measured in months.

### [Why do AI-assisted contributions to an open source project go badly?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-why-do-ai-assisted-contributions-to-an-open-source-project-go-badly)

Viktor Farcic turns that question back on maintainers in DevOps Paradox episode 359, asking whether the repository was made agent-ready or simply left to let an agent fantasize. A maintainer who works well with agents on their own project usually knows the right instructions but has never codified them for anyone else. Darin Pope adds that codifying them matters because the project outlives whoever maintains it today.

### [What should an internal demo show?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-what-should-an-internal-demo-show)

Viktor Farcic says on DevOps Paradox episode 359 that he no longer wants to see plans from anybody. Pitching a new feature means showing the feature working, and it does not have to be production ready or written the way he would write it. Darin Pope frames the payoff as a demo tailored to whoever is asking, so a stakeholder focused on accounts payable and one focused on HR see different things.

### [Is it too expensive to run an AI agent live during a customer meeting?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-is-it-too-expensive-to-run-an-ai-agent-live-during-a-customer-meeting)

Viktor Farcic's answer on DevOps Paradox episode 359 is no, and the comparison he reaches for is the salaries in the room. A single agent running continuously could not approach what one attendee costs a company over a year, so an hour of it is trivial against the meeting itself. For a prepared demo, with environment, skills and CLIs already set up, he rates Haiku as overpowered.

### [What is the DevOps Paradox podcast?](/episodes/demos-in-the-age-of-ai-agents-359/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 359, "Demos in the Age of AI Agents," works through what happens to vendor demos, open source onboarding, and internal stakeholder demos once the thing evaluating your product is an agent. Every episode page carries the audio, the video, and a full transcript.

### [How should just-in-time access work for AI agents?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-how-should-just-in-time-access-work-for-ai-agents)

Ofir Stein of Apono argues on DevOps Paradox episode 358 that access has to become dynamic in the way the rest of DevOps already is. A static policy that grants a role and then stops changing does not survive contact with agents. His model is guardrails defined in advance by people but evaluated at runtime against live attributes, such as whether the requester is on call and whether an incident is currently open.

### [Can AI agents be socially engineered?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-can-ai-agents-be-socially-engineered)

Ofir Stein describes an experiment on DevOps Paradox episode 358 in which his team ran a full AWS environment managed entirely by agents playing company roles, then opened a Discord channel inviting anyone to try tricking them. The finding was that however well those agents defended themselves, and he says they did it well, someone could always find a way through. Deterministic software was never exposed to this class of attack.

### [Is an AI agent a human identity or a machine identity?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-is-an-ai-agent-a-human-identity-or-a-machine-identity)

Ofir Stein says on DevOps Paradox episode 358 that customers argue both sides and that agents genuinely sit in between. They move at machine speed, which existing human access reviews cannot keep pace with, yet they are non-deterministic, which is precisely what human-style guardrails were built for. Darin Pope offers a rough test borrowed from pets versus cattle: if you gave your agent a name, treat it as human.

### [Why can't a human approve access requests for AI agents?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-why-cant-a-human-approve-access-requests-for-ai-agents)

Viktor Farcic presses this point on DevOps Paradox episode 358. If an agent performs thousands of operations a minute and each one needs its own decision, no person can sit inside that loop. What remains is blanket permissions, partial permissions that break because nobody knows in advance what is needed, or one AI evaluating another. Ofir Stein's answer is that the runtime decision has to be silicon, working from guardrails a human set earlier.

### [Do developers hate security?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-do-developers-hate-security)

Darin Pope's argument on DevOps Paradox episode 358 is that developers hate a bad security experience rather than security itself. Ofir Stein agrees from his own time leading an engineering group, when a SOC 2 audit stripped server access from his whole team for three months and the remedy was a workaround designed not to appear in the audit. He says CISOs increasingly treat the job as enabling the business.

### [What is the DevOps Paradox podcast?](/episodes/just-in-time-access-for-ai-agents-358/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 358 features Ofir Stein of Apono on just-in-time access, whether agents count as human or machine identities, and who approves a permission when the requester is running thousands of operations a minute. Every episode page carries audio, video, and a full transcript.

### [What is spec-driven development and how does it differ from vibe coding?](/episodes/what-is-spec-driven-development-357/index.md#faq-what-is-spec-driven-development-and-how-does-it-differ-from-vibe-coding)

Viktor Farcic's framing on DevOps Paradox episode 357 is that anyone working with AI already has a spec, because the alternative is asking for a random thing and seeing whether you like it. What actually varies is how detailed that spec is, and whether you write it all up front or discover it as you go. He argues the real question is waterfall versus agile applied to specifications.

### [Should you write a detailed spec before you start building?](/episodes/what-is-spec-driven-development-357/index.md#faq-should-you-write-a-detailed-spec-before-you-start-building)

Viktor Farcic pushes back on that on DevOps Paradox episode 357, because a design is only validated once it has been implemented. His alternative is building five throwaway MVPs, showing them to customers, picking one, and then asking Claude to generate the spec and diagrams from the winner. Teams take weeks or months to build a single MVP, he notes, and he can now build five in a day.

### [How much time should you spend planning before writing code?](/episodes/what-is-spec-driven-development-357/index.md#faq-how-much-time-should-you-spend-planning-before-writing-code)

Viktor Farcic puts the trade-off directly on DevOps Paradox episode 357: spend a week planning and finish a milestone in half a day, or spend an hour planning and finish in a day, leaving room to redo that milestone five times inside the same window. He picks redoing it five times. Over-specifying, he tells Darin Pope, mostly means lying to yourself about how much you knew up front.

### [Does spec-driven development work on legacy systems?](/episodes/what-is-spec-driven-development-357/index.md#faq-does-spec-driven-development-work-on-legacy-systems)

Viktor Farcic's answer on DevOps Paradox episode 357 is that a legacy system already has a complete specification, and it is the code itself, along with the observability and networking around it. Anything written thirty years ago is neither valid nor complete by now. Darin Pope's worry runs the other way: pointing agents at a legacy codebase runs straight into a context window nowhere near large enough to hold it.

### [Do you still need a spec framework now that Claude Code has plan mode?](/episodes/what-is-spec-driven-development-357/index.md#faq-do-you-still-need-a-spec-framework-now-that-claude-code-has-plan-mode)

Darin Pope raises this on DevOps Paradox episode 357, noting that the creator of Agent OS was able to strip away most of what that framework did once plan mode became good enough. Viktor Farcic's caveat is that plan mode operates at the level of one task inside one context. You still need higher-level milestones above it, and you have to write the outcome to a file before closing a session.

### [Should you review the code or the tests your AI agent writes?](/episodes/what-is-spec-driven-development-357/index.md#faq-should-you-review-the-code-or-the-tests-your-ai-agent-writes)

Viktor Farcic says on DevOps Paradox episode 357 that he now spends more time reviewing tests than code. His reasoning is that a test states the behaviour he expects, so reading the tests closely is a way of reviewing the implementation indirectly. He is careful to add that tests never capture everything, but past a certain level they tell you the code is doing what it was asked to do.

### [What is the DevOps Paradox podcast?](/episodes/what-is-spec-driven-development-357/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 357 works through spec-driven development, why building five throwaway MVPs can beat writing one detailed design, and how much planning is worth doing before an agent starts writing code. Every episode page carries audio, video, and a full transcript.

### [If AI speeds up writing code, why doesn't software delivery get faster?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-if-ai-speeds-up-writing-code-why-doesnt-software-delivery-get-faster)

Viktor Farcic argues on DevOps Paradox episode 355 that speeding up one stage of a pipeline moves the queue rather than shortening it. Where teams once piled up issues in Jira, they now pile up pull requests instead. He puts the choice starkly: making all ten steps ten percent faster beats doubling development speed while everything downstream runs at its old pace. Delivery to production is the only measure that counts.

### [Does AI-generated code introduce more bugs?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-does-ai-generated-code-introduce-more-bugs)

Darin Pope cites a figure of 1.7 times more issues than human-written code on DevOps Paradox episode 355. Viktor Farcic's response is that the multiple barely matters. If you have a mechanism to detect issues and feed them back, the number worth tracking is how many remain per feature shipped. His question about any such study is whether the issues surfaced in the pipeline or after weeks sitting in production.

### [Why do AI-assisted pull requests take longer to review?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-why-do-ai-assisted-pull-requests-take-longer-to-review)

Darin Pope cites figures of four to five times longer on DevOps Paradox episode 355. Viktor Farcic's diagnosis is size: the fact that an agent can write ten thousand lines does not mean they should arrive as one pull request. He argues any reviewer struggles with that volume regardless of what produced it, and that the work still needs splitting into smaller chunks.

### [What should a human review when AI writes the code?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-what-should-a-human-review-when-ai-writes-the-code)

Viktor Farcic separates silly from important on DevOps Paradox episode 355. Silly is whether every function carries a comment or whether names are camel case, which he calls a waste of your talent and hands to tooling. Important is whether the design holds up architecturally, and whether this is even the feature worth delivering. Freeing up time for the second question is, in his view, the actual gain.

### [Should you adopt AI to cut costs?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-should-you-adopt-ai-to-cut-costs)

Viktor Farcic says no on DevOps Paradox episode 355, comparing a hunt for cheaper AI to the hunt for cheaper offshore labour. Offshore to Opus, then Sonnet, then Haiku, then Llama on a laptop, and you land where companies chasing the cheapest engineers landed, dragging the work back in house. He points at Cursor's revenue per employee as a case where the win came from doing better with fewer people.

### [Will an agentic pipeline replace humans in the SDLC?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-will-an-agentic-pipeline-replace-humans-in-the-sdlc)

Viktor Farcic's answer on DevOps Paradox episode 355 is augmented rather than autonomous, at least for now. He compares it to self-driving cars, which did not appear everywhere a year after everyone predicted them, and warns that even once the technology is ready, you are not. Darin Pope's version keeps a person on the final push to production, the way nobody lets a Jenkins pipeline deploy straight to prod unchecked.

### [What is the DevOps Paradox podcast?](/episodes/why-ai-coding-slows-down-code-review-355/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 355, "Why AI Coding Slows Down Code Review," works through what happens when one stage of the delivery pipeline speeds up and the rest does not, and what reviewers should spend their attention on instead. Every episode page carries audio, video, and a full transcript.

### [How does no-code make AI-generated software more reliable?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-how-does-no-code-make-ai-generated-software-more-reliable)

Jeff Kuo argues on DevOps Paradox episode 352 that a no-code platform narrows what the model has to reason about. Generating a custom ERP through Ragic, the AI considers how inventory moves, how a sales order is structured and how cost is calculated, and never touches the infrastructure underneath. He describes current models as handling one layer well at a time, so removing layers works as a guardrail.

### [Is vibe coding a good idea for people who cannot code?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-is-vibe-coding-a-good-idea-for-people-who-cannot-code)

Jeff Kuo's answer on DevOps Paradox episode 352 is that AI-assisted coding suits professionals who understand the infrastructure underneath it. He calls it counterproductive for non-developers, who can generate far more code than they can maintain. From his own side projects he describes losing the structure once he stopped reading the output closely, then getting stuck in loops where the model repeatedly announces it has found the root cause.

### [Why does AI generate worse code for less popular tools?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-why-does-ai-generate-worse-code-for-less-popular-tools)

Viktor Farcic raises this on DevOps Paradox episode 352 using Nushell, where the generated results come out clearly inferior to Bash even though he prefers Nushell himself. He attributes the gap to how little source material exists. Jeff Kuo confirms Ragic hits the same wall and treats it as solvable: break the task into several prompts, simplify the tool descriptions, and rewrite documentation so models learn the product properly.

### [Should product documentation be written for AI or for humans first?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-should-product-documentation-be-written-for-ai-or-for-humans-first)

Darin Pope's position on DevOps Paradox episode 352 is AI first, web crawlers second, humans third, and he argues that writing for a model reads very differently from writing for a person. Jeff Kuo describes Ragic rewriting its documentation with all three audiences in mind, so models learn the product rather than merely knowing it exists. Viktor Farcic puts it more bluntly: humans will not be reading it much longer.

### [Will companies still need software developers?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-will-companies-still-need-software-developers)

Jeff Kuo tells DevOps Paradox episode 352 yes, but fewer, and expects reading code to become a more important skill than writing it. Viktor Farcic disagrees, predicting demand will hold or rise even as both reading and writing decline. His argument is that the critical skill becomes taste, which is built from experience: anyone can produce a design in Photoshop, and the result still shows who actually understands design.

### [What matters most when choosing between no-code, vibe coding and hand coding?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-what-matters-most-when-choosing-between-no-code-vibe-coding-and-hand-coding)

Jeff Kuo's answer on DevOps Paradox episode 352 is maintenance, and he says that advice has not changed in decades. Making things is no longer the constraint, because you can regenerate from scratch. The question is who maintains the result and how, since an AI-assisted codebase grows large very quickly and becomes painful past a certain size. Decide it while planning the project, not afterwards.

### [What is the DevOps Paradox podcast?](/episodes/no-code-is-the-guardrail-vibe-coding-needs-352/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 352, "No-Code Is the Guardrail Vibe Coding Needs," brings in Jeff Kuo of Ragic to argue that constraining AI to business logic beats letting it generate everything. Every episode page carries the audio, the video, and a full transcript.

### [How is AI changing the developer job market?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-how-is-ai-changing-the-developer-job-market)

Darin Pope frames DevOps Paradox episode 351 around two markets running at once: companies paying data scientists 750,000 dollars or more, while Amazon lays off 16,000 people and Block sheds several thousand more. Viktor Farcic reads it as a boom and bust cycle the industry has been through before, comparing it to the dot-com collapse. What is genuinely different this time, he says, is the speed and the width of the scope.

### [Why are junior developer roles disappearing?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-why-are-junior-developer-roles-disappearing)

Darin Pope cites figures on DevOps Paradox episode 351 putting entry-level tech positions down 67 percent since 2022 and junior developer roles down 40 to 50 percent. Viktor Farcic's explanation is uncomfortable: a junior is typically told what to do rather than deciding, and produces better work the more precisely they are instructed. Replace the word junior with agent, he argues, and the description does not change.

### [Are senior developers safer than juniors from AI?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-are-senior-developers-safer-than-juniors-from-ai)

Viktor Farcic is not convinced on DevOps Paradox episode 351. He argues history suggests seniors will be the ones rejecting the change, insisting no AI reviews code or connects to a machine as well as they can. His test runs on different lines: if your work rests on knowledge many people have, and models were trained on that public material, you are replaceable. Specific knowledge gets complemented rather than replaced.

### [What skills keep a developer employable?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-what-skills-keep-a-developer-employable)

Darin Pope's list on DevOps Paradox episode 351 is system design, orchestration, security and governance, domain expertise, communication, and judgment. He adds that a decade at one company without understanding what the business does is its own kind of risk. Viktor Farcic offers a blunter test for anyone with more than ten years behind them: if you have already changed what you do and how you do it several times, you are fine.

### [How should a developer start using AI coding tools?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-how-should-a-developer-start-using-ai-coding-tools)

Darin Pope's suggestion on DevOps Paradox episode 351 is to spend twenty dollars for a month, pick something non-trivial, and build it. Viktor Farcic adds the warning that matters: do not judge the tools by the results of the first week. He compares it to a first week with Java, which does not produce code serving a million concurrent users, and says giving up after a week is the actual mistake.

### [What should you look for when hiring a developer now?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-what-should-you-look-for-when-hiring-a-developer-now)

Viktor Farcic says on DevOps Paradox episode 351 that he has always valued capacity to learn over specific experience, and that this counts for more now rather than less. He tells the story of a junior hiring test where candidates worked on a company laptop that had a browser open alongside the editor. The candidate who switched to the browser and searched for an answer got the job.

### [What is the DevOps Paradox podcast?](/episodes/the-developer-job-market-in-the-age-of-ai-351/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 351, "The Developer Job Market in the Age of AI," works through why entry-level roles are vanishing, whether seniors are any safer, and which skills still hold value. Every episode page carries audio, video, and a full transcript.

### [Is context, rather than code generation, the bottleneck in software development?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-is-context-rather-than-code-generation-the-bottleneck-in-software-development)

Patrick Debois argues on DevOps Paradox episode 350 that it is. His reasoning is that daily users cannot do much about the model itself beyond flipping a switch when a new one lands, so the one lever left is the context handed to the agent. He notes the irony that the job was supposed to get easier, and instead teams need better specifications and more written documentation than before.

### [Should you treat prompts and context like code?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-should-you-treat-prompts-and-context-like-code)

Patrick Debois makes exactly that argument on DevOps Paradox episode 350. If the prompt is the new code, then it needs testing, improving, and keeping up to date the same way code does. He extends context well past specifications to include tickets, team guidelines, and descriptions of how work actually gets done, none of which a model can be trained on because they are specific to one environment.

### [Why doesn't a second AI agent catch the first one's mistakes?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-why-doesnt-a-second-ai-agent-catch-the-first-ones-mistakes)

Viktor Farcic raises this on DevOps Paradox episode 350: a separate reviewing agent tends to take the original context too seriously, inheriting its mistakes rather than finding them. What he wants is something that discovers what is missing, not something that confirms what is there. Patrick Debois answers that verification improves when you pair the reviewing agent with deterministic tooling such as linters and tests.

### [What should you do when your coding agent does the wrong thing?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-what-should-you-do-when-your-coding-agent-does-the-wrong-thing)

Patrick Debois's main advice on DevOps Paradox episode 350 is to write it down in your context file rather than re-prompting and throwing the correction away. He frames teaching the agent as the new job, and the reflex worth building. He also describes teams capturing this automatically, using hooks that trigger on confusion or mining conversation logs for the moments a user says something was wrong.

### [How should teams share AI context across projects?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-how-should-teams-share-ai-context-across-projects)

Patrick Debois explains on DevOps Paradox episode 350 that checking a context file into one repository works until a second team needs it, at which point copying and linking gets clunky. His answer is to treat context as a shared component: publish it as a package to a registry so it can be versioned, installed, tested, and owned. The platform team owns deployment guidance, security owns its requirements.

### [Should you run a coding agent in a sandbox?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-should-you-run-a-coding-agent-in-a-sandbox)

Patrick Debois's view on DevOps Paradox episode 350 is that it becomes necessary the moment you stop watching every turn, because if you are not there you cannot pull the brakes. He points out that skills and context files execute before you get to approve anything. He also flags a gap: there is no real equivalent of a web application firewall for context yet, so constraining the file system is the practical defence.

### [What is the DevOps Paradox podcast?](/episodes/context-is-the-new-bottleneck-not-code-350/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 350, "Context Is the New Bottleneck, Not Code," features Patrick Debois, who coined the term DevOps, on treating context as code, sharing it across teams, and sandboxing coding agents. Every episode page carries audio, video, and a full transcript.

### [Why is shadow AI a bigger problem than shadow IT was?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-why-is-shadow-ai-a-bigger-problem-than-shadow-it-was)

Ben Wilcox, CTO and CISO at ProArch, tells DevOps Paradox episode 349 that AI is arriving inside products an organization already runs, rather than as something staff go out and adopt on their own. His advice to security leaders is to assume any platform they own now has AI in it, then work out where the data goes as a result. Darin Pope's summary, which Ben agrees with, is that this makes shadow AI far worse.

### [Why does DevSecOps not work in practice?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-why-does-devsecops-not-work-in-practice)

Ben Wilcox argues on DevOps Paradox episode 349 that the failure is forcing developers onto the security team without good guardrails or planning ahead. He describes watching a lead developer sweat through a security review held just before an initial release, long after the decisions were locked in. Viktor Farcic adds that security stays reactive, telling teams what they did wrong instead of building the services that would make secure work the easy path.

### [How should teams handle AI models being deprecated?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-how-should-teams-handle-ai-models-being-deprecated)

Ben Wilcox says on DevOps Paradox episode 349 that almost nobody plans for it at the start of a project. Darin Pope compares it to upgrading a framework from version three to version four, only worse, because model behaviour is non-deterministic and nothing tells you what changed. Ben suggests choosing smaller models that shift less between releases, and running an ongoing test practice that checks whether familiar prompts still produce acceptable output.

### [What changes about penetration testing when an application uses AI?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-what-changes-about-penetration-testing-when-an-application-uses-ai)

Ben Wilcox explains on DevOps Paradox episode 349 that his teams have had to rebuild their approach. An application tested one way six months earlier comes back needing a different method entirely once AI is added, because the attack surface moves. They now have to account for the supply chain, how identities are handled, and how data flows through the system. His teams use AI to generate those test cases rather than writing them by hand.

### [Where should a CISO start with AI?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-where-should-a-ciso-start-with-ai)

Ben Wilcox's advice on DevOps Paradox episode 349 is to start with an inventory, and not to do it alone. He suggests going across the whole organization and talking to sales and finance rather than only developers, since commoditized tools get picked up everywhere. From there, look at how data is being used inside applications, think through what a failure would actually look like, and log enough to reconstruct it later.

### [Why do organizations misjudge what AI will cost?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-why-do-organizations-misjudge-what-ai-will-cost)

Ben Wilcox tells DevOps Paradox episode 349 that he sees projections missed in both directions. The uncomfortable version is a team budgeting eight thousand dollars a month and landing at fifteen. What follows is usually a reassessment of whether the value matches the spend. Where the capability is built into a product, companies tend to absorb the difference; where it is an internal tool, the conversation gets considerably harder.

### [What is the DevOps Paradox podcast?](/episodes/shadow-ai-is-going-to-be-a-thousand-times-worse-than-shadow-it-349/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 349 features Ben Wilcox, CTO and CISO at ProArch, on shadow AI, why security reviews keep arriving too late, and what changes about testing once an application has a model inside it. Every episode page carries audio, video, and a full transcript.

### [Why should companies panic about AI agents?](/episodes/now-it-s-time-to-panic-348/index.md#faq-why-should-companies-panic-about-ai-agents)

Viktor Farcic's argument on DevOps Paradox episode 348 is that things look fine right up until they are not, and by then it is too late for a company too large to turn around overnight. He tells companies to panic because whoever fails to get there first lands in trouble they cannot recover from, whether that arrives next week or next year. He points at the recent slide in security company stock prices.

### [Are vendor-provided AI agents worse than ones you build yourself?](/episodes/now-it-s-time-to-panic-348/index.md#faq-are-vendor-provided-ai-agents-worse-than-ones-you-build-yourself)

Viktor Farcic answers yes on DevOps Paradox episode 348, without qualification. He compares an off-the-shelf agent to hiring a brilliant engineer and telling them nothing about your company: they write flawless Rust while you use something else, and deploy to AWS while you run Azure. He allows that a vendor agent makes a reasonable starting point, so long as you then explain your business and your systems to it.

### [Should you use AI skills you download from the internet?](/episodes/now-it-s-time-to-panic-348/index.md#faq-should-you-use-ai-skills-you-download-from-the-internet)

Viktor Farcic calls that nonsense in most cases on DevOps Paradox episode 348. His reasoning is that models are already trained on essentially all public knowledge, including every skill sitting in a public repository, so a public skill cannot supply the thing actually missing: what your own company does privately. Darin Pope agrees in practice, describing how he adapts any skill he picks up rather than running it as written.

### [Do AI agents need least privilege?](/episodes/now-it-s-time-to-panic-348/index.md#faq-do-ai-agents-need-least-privilege)

Darin Pope reads through the OWASP Agentic AI Top 10 on DevOps Paradox episode 348 and concludes that least agency is least privilege under a new name. Viktor Farcic's starting point is to give an agent whatever you would give a person, and he dismisses hallucination as a reason not to, since people hallucinate as much or more. He separates granting broad shell access from exposing a few named tools.

### [What does heavy AI agent use actually cost per month?](/episodes/now-it-s-time-to-panic-348/index.md#faq-what-does-heavy-ai-agent-use-actually-cost-per-month)

Viktor Farcic tells DevOps Paradox episode 348 that the twenty or two hundred dollar subscription is not the real figure. Someone working full time with several agents in parallel would exhaust that inside a day, and he puts the realistic number closer to a thousand dollars a month. Darin Pope adds a cautionary case: a leaked token took one person's usual spend under 200 dollars to 85,000 in two days.

### [Which cloud provider is best positioned for AI?](/episodes/now-it-s-time-to-panic-348/index.md#faq-which-cloud-provider-is-best-positioned-for-ai)

Viktor Farcic picks Google on DevOps Paradox episode 348, calling it top on every level, with strong TPUs, models at the front of the field, and inference sold as part of Google Cloud. He reads AWS as declining to compete on models and monetizing inference instead, and thinks Microsoft has lost its way with Copilot. Darin Pope is surprised, having expected him to name Anthropic.

### [What is the DevOps Paradox podcast?](/episodes/now-it-s-time-to-panic-348/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 348, "Now It's Time to Panic," works through the shift from chatbots to agents, what least privilege means for an agent, and why Viktor thinks a company that waits to react will not recover. Every episode page carries the audio, the video, and a full transcript.

### [Should an open source project ban AI-generated contributions?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-should-an-open-source-project-ban-ai-generated-contributions)

Viktor Farcic calls that a terrible mistake on DevOps Paradox episode 346. His position is that a maintainer's primary role is empowering people to contribute, and that the barrier to entry has never been lower than it is now. Rather than fighting it, he argues for putting the guidance into the repository itself through an agents.md, skills and rule sets, replacing the tribal knowledge contributing has always depended on.

### [Can you tell whether a pull request was written by AI?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-can-you-tell-whether-a-pull-request-was-written-by-ai)

Viktor Farcic's answer on DevOps Paradox episode 346 is that you cannot. The only available signal is noticing that no human would have been willing to do it, which he rejects as a criterion. He redirects the question toward instructions instead: how good generated code turns out depends heavily on the guidance it was given, so a project supplying none has largely chosen its own results.

### [Is zero tolerance for bad AI contributions a sensible policy?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-is-zero-tolerance-for-bad-ai-contributions-a-sensible-policy)

Viktor Farcic reframes it on DevOps Paradox episode 346 by removing one word: zero tolerance for bad contributions. Whether a person, an agent, or his mother wrote it does not change whether it is bad. His harder question is what counts as bad, because a project that has not written that down is judging contributions on the maintainer's taste and asking contributors to guess it.

### [How should you audit the health of an open source dependency?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-how-should-you-audit-the-health-of-an-open-source-dependency)

Viktor Farcic argues on DevOps Paradox episode 346 that no human can do it honestly, daring Darin Pope to assess Kubernetes, or even curl, on his own. He narrows the question to context: what matters is the portion of a library your application actually uses and how it uses it, rather than the whole library. He adds that conventional audits cost so much they get treated as permanent once passed.

### [Is a 2,000 dollar a year sponsorship worth a maintainer's time?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-is-a-2000-dollar-a-year-sponsorship-worth-a-maintainers-time)

Darin Pope runs the numbers on DevOps Paradox episode 346 and reaches roughly 40 dollars a week, or 8 dollars a day, which he says does not justify the work. Viktor Farcic agrees it cannot be anyone's income, but values it as recognition on a project someone already works on out of passion. His reasoning is that money is real recognition, where a virtual sticker costs nothing.

### [What happens to companies selling enterprise versions of open source?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-what-happens-to-companies-selling-enterprise-versions-of-open-source)

Viktor Farcic lays out the squeeze on DevOps Paradox episode 346. That business rests on customers being able to do the work themselves at far greater cost than the license. As AI lowers the cost of doing it yourself, he sees three possible outcomes: prices fall to stay competitive, the products go away, or the vendor drastically increases what it adds on top, which hiring more people cannot pay for.

### [What is the DevOps Paradox podcast?](/episodes/fighting-ai-in-your-project-is-a-terrible-mistake-346/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 346, "Fighting AI in Your Project Is a Terrible Mistake," works through how curl and Ghostty responded to AI-assisted pull requests, what a dependency audit can honestly cover, and how funding models for maintainers hold up. Every episode page carries the audio, the video, and a full transcript.

### [What problem is Kiro trying to solve?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-what-problem-is-kiro-trying-to-solve)

Amit Patel explains on DevOps Paradox episode 345 that AWS engineers using the AI coding tools of 2024 got poor results on anything of medium or high complexity. Prompting back and forth lost fidelity across sessions, so what the agent built drifted from what the developer meant. Kiro's answer is spec-driven development, taking the specify-then-design-then-decompose approach AWS already used manually and moving it into the agent workflow.

### [Who writes the spec in spec-driven development?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-who-writes-the-spec-in-spec-driven-development)

Amit Patel's answer on DevOps Paradox episode 345 is that the agent writes it, not the user. You open with a prompt describing what you want, the agent produces a set of requirements, and you refine them by asking for specifics such as end-to-end encryption. He describes most specs taking around twenty minutes of back and forth, yielding a design and a task list, with working software typically two or three days later.

### [Does AI-written code eliminate product managers?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-does-ai-written-code-eliminate-product-managers)

Amit Patel argues on DevOps Paradox episode 345 that the roles remain but grow more fluid. He describes a product manager and an engineer settling an MCP feature in a half-hour conversation rather than three days of document writing, after which the product manager generated the spec with Kiro and demonstrated a prototype the next day. The value, he says, sits in defining what customers actually need.

### [What is left for humans once agents write the code?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-what-is-left-for-humans-once-agents-write-the-code)

Amit Patel describes it on DevOps Paradox episode 345 as bookends. At the front, somebody has to establish what the intent actually is. At the back, somebody has to verify that the code and the specification match that intent. Tooling keeps improving the middle, but he does not expect it to define intent for you, nor to fully validate that the intent was achieved.

### [Do junior developers still have a path in an AI-assisted industry?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-do-junior-developers-still-have-a-path-in-an-ai-assisted-industry)

Amit Patel says yes on DevOps Paradox episode 345, noting AWS continues taking interns and college hires at its usual rate. His example is a simple app that uploads files to S3: knowing to ask for bucket protection, encryption in transit, certificate exchange and KMS comes from experience. A model will generate every bit of that, but only when asked, and nobody asks without first knowing to.

### [How do you verify that AI-generated code is correct?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-how-do-you-verify-that-ai-generated-code-is-correct)

Amit Patel points on DevOps Paradox episode 345 to property-based testing, which Kiro launched shortly before Christmas. It rests on automated reasoning and math rather than enumerating unit tests, aiming to establish that the code does what was intended. He frames formal methods as growing more important precisely because generating code has become cheap while reaching genuinely high quality code has not.

### [What is the DevOps Paradox podcast?](/episodes/from-chat-prompt-to-working-software-with-kiro-345/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 345, "From Chat Prompt to Working Software with Kiro," is Darin Pope's conversation with Amit Patel of AWS about spec-driven development, verification when code is cheap, and where junior engineers fit. Every episode page carries the audio, the video, and a full transcript.

### [Are REST APIs the right interface for AI agents to use?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-are-rest-apis-the-right-interface-for-ai-agents-to-use)

Matt DeBergalis, CEO of Apollo GraphQL, argues on DevOps Paradox episode 343 that they were never built for it. REST APIs were designed for trusted engineers calling them as part of an internal implementation, where latency matters little and the caller discards whatever fields it does not need. He points at GitHub's REST API returning hundreds of fields for one repository object, all of which becomes context a model pays for.

### [Why does GraphQL suit AI agents better than REST?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-why-does-graphql-suit-ai-agents-better-than-rest)

Matt DeBergalis explains on DevOps Paradox episode 343 that GraphQL distils complexity into a short query and pushes the rest into infrastructure, the way a database engine hides a query planner. A model writes ten or twenty lines rather than a thousand lines of procedural code. It also avoids making the model orchestrate the three, four, or ten separate calls a resource-shaped REST API would otherwise require.

### [Should AI agents call APIs non-deterministically?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-should-ai-agents-call-apis-non-deterministically)

Matt DeBergalis argues on DevOps Paradox episode 343 that you want the non-determinism at the experience layer and precision underneath it. His example is a bank, where every customer asking about their account should get the same five recent transactions rather than sometimes ten, with no freelancing about how systems get combined. Viktor Farcic pushes back, asking why AI needs to be involved in the deterministic parts at all.

### [Will AI change how many APIs a company has?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-will-ai-change-how-many-apis-a-company-has)

Matt DeBergalis predicts on DevOps Paradox episode 343 that companies are about to own many more microservices and APIs, because asking an agent to write code works best when that code is structured as independent modules. He draws the parallel to containers, noting Kubernetes appeared because teams had two thousand of them rather than two, and expects APIs to become similarly ephemeral and to need orchestrating infrastructure.

### [What is agent experience and how does it differ from developer experience?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-what-is-agent-experience-and-how-does-it-differ-from-developer-experience)

Matt DeBergalis describes it on DevOps Paradox episode 343 as writing documentation and building products with the models as the first audience rather than people. At Apollo GraphQL that has meant making sure agents can interact with the product, and reworking how GraphQL reports errors on the assumption an agent rather than a human is reading the output. Humans still use it, so both audiences have to be served together.

### [What happens to companies whose documentation is the top of their funnel?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-what-happens-to-companies-whose-documentation-is-the-top-of-their-funnel)

Matt DeBergalis is blunt about this on DevOps Paradox episode 343: if your business model depends on human developers visiting your docs page to work something out, you have a problem. He compares the shift to what SEO once meant for many kinds of company, and argues it now cuts deeper, because whether a customer finds you at all depends on what a model says while they type.

### [What is the DevOps Paradox podcast?](/episodes/your-apis-were-never-built-to-be-the-front-door-343/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 343, "Your APIs Were Never Built to Be the Front Door," features Matt DeBergalis of Apollo GraphQL on why APIs designed for internal engineers do not survive contact with AI agents. Every episode page carries audio, video, and a full transcript.

### [Why is company documentation not useful for AI agents?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-why-is-company-documentation-not-useful-for-ai-agents)

Viktor Farcic argues on DevOps Paradox episode 342 that the information usually exists but sits in the wrong place: a stale wiki page, a Zoom transcript, a Slack thread nobody scrolls back to. He splits documentation into why something was done, which stays true more or less forever, and how something works, which he says he has never seen kept current outside of mainframes. AI inherits that problem rather than solving it.

### [Is Git the source of truth for your infrastructure?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-is-git-the-source-of-truth-for-your-infrastructure)

Viktor Farcic says no on DevOps Paradox episode 342. He argues the running system is the source of truth and that Git holds desired state, a replica rather than the original. If Git says four pods and the cluster is running five, the actual state is five. What the cluster cannot tell you is why five were wanted, and that motivation is the part genuinely worth writing down.

### [What should you actually write in code comments?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-what-should-you-actually-write-in-code-comments)

Viktor Farcic's rule on DevOps Paradox episode 342 is to document why, not what. He points out that a changed IP address is already visible in the config, so recording the new value adds nothing, while recording the reason for the change adds the one thing the system cannot show you on its own. He suggests the same approach for cloud resources, putting the motivation into labels on the instance.

### [Will RAG fix a company's documentation problem?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-will-rag-fix-a-companys-documentation-problem)

Darin Pope's position on DevOps Paradox episode 342 is that RAG is a tool rather than the answer. He cites Gartner projections that organizations will abandon 60 percent of AI projects unsupported by AI-ready data, and that roughly 30 percent of generative AI projects get dropped at proof of concept, often over poor data quality. Viktor Farcic adds that the same drag applies to people, not only to models.

### [How much context does an AI coding agent need?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-how-much-context-does-an-ai-coding-agent-need)

Viktor Farcic compares it on DevOps Paradox episode 342 to a new hire's first day. Telling someone to deploy a release and nothing else gets you nothing back, and handing them a Notion URL covering everything the company ever wrote is barely an improvement. The work is pointing at the relevant parts specifically. Expecting more from an AI agent than you would from a person, he argues, makes no sense.

### [How can you tell whether your documentation is good enough for AI?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-how-can-you-tell-whether-your-documentation-is-good-enough-for-ai)

Darin Pope closes DevOps Paradox episode 342 with a test: run a retrieval process over your existing documentation and ask whether the answer it returns beats the hallucination you would have got without it. If the grounded answer is worse, the documentation is the problem. He also suggests instrumenting documentation the way teams instrument applications, so the gaps between what people search for and what they find become visible.

### [What is the DevOps Paradox podcast?](/episodes/your-company-documentation-is-useless-for-ai-342/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 342, "Your Company Documentation Is Useless for AI," works through why internal documentation decays, why the running system is a better source of truth than a wiki, and what has to change before AI can use any of it. Every episode page carries audio, video, and a full transcript.

### [Why is AI-generated code not shipping any faster?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-why-is-ai-generated-code-not-shipping-any-faster)

Trevor Stuart brings the analogy on DevOps Paradox episode 341 of a six-lane highway ending in a two-lane bridge. Code volume exploded, but throughput went down, because more code means more security vulnerabilities and more review time. Viktor Farcic reads the bottleneck as adoption rather than any particular phase, describing teams putting a new shiny thing into an old ugly box and expecting the same processes to hold.

### [Are feature flags still worth adopting in 2026?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-are-feature-flags-still-worth-adopting-in-2026)

Trevor Stuart's answer on DevOps Paradox episode 341 is that most teams already have them, homegrown or from a vendor, and that they became table stakes in software delivery. He contrasts that with conference conversations ten years ago, where people still asked whether a feature flag was just a config file. The question he now hears is how to undo the technical debt all those flags created.

### [How are feature flags being used with AI?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-how-are-feature-flags-being-used-with-ai)

Trevor Stuart describes on DevOps Paradox episode 341 customers putting prompts, tokens and temperature settings into the JSON configuration attached to a flag treatment. That lets them run prompt tests against real traffic, turning one variant on for five percent of customers and a second variant on for another five. He expects AI configs and AI evals to become normal parts of the delivery pipeline.

### [Do teams actually remove old feature flags?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-do-teams-actually-remove-old-feature-flags)

Trevor Stuart admits on DevOps Paradox episode 341 that they do not, not as often as they should, and says he has hundreds awaiting removal in his own code. Viktor Farcic presses on why it is hard: deleting a disabled block is simple, but the surrounding code was written around the flag and needs refactoring. Trevor credits coding agents with finally making automated removal workable.

### [Can a team get experimentation wrong?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-can-a-team-get-experimentation-wrong)

Trevor Stuart's answer on DevOps Paradox episode 341 is that the failure is cultural rather than technical. Teams that run one experiment, watch it fail, and then ship whatever they had planned anyway have left the experimentation mindset entirely. Accepting failure is the hard part, because a failed experiment means admitting an idea did not work, and the value arrives across the next thirty.

### [Should you test in production?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-should-you-test-in-production)

Trevor Stuart argues yes on DevOps Paradox episode 341, because a pre-production environment never fully mimics production and some features only misbehave under real load. He offers a case where his own team cleared QA, skipped production testing, and shipped something broken. Viktor Farcic sharpens it: production is the only test that really matters, and everything earlier buys confidence to get there.

### [What is the DevOps Paradox podcast?](/episodes/ai-widened-the-highway-but-nobody-rebuilt-the-bridge-341/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 341, "AI Widened the Highway but Nobody Rebuilt the Bridge," brings in Trevor Stuart of Harness on why more generated code has not produced faster delivery, and what feature flags do with prompts. Every episode page carries the audio, the video, and a full transcript.

### [Why do operations teams resist new technology?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-why-do-operations-teams-resist-new-technology)

Viktor Farcic's explanation on DevOps Paradox episode 340 turns on whose people built the tool. Application developers readily adopt libraries written by other application developers, but the tooling handed to operations, Kubernetes included, was written by developers rather than by operators. He adds an incentive problem: refusing a change means nobody can ever prove it would have helped, so saying no carries no measurable blame.

### [Are operations teams more resistant to change than other teams?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-are-operations-teams-more-resistant-to-change-than-other-teams)

Viktor Farcic pushes back on that premise in DevOps Paradox episode 340. Every group has its own reason for saying no, and each treats its own reason as valid while dismissing everyone else's. Operations cite production, security cite risk, testers cite the human touch. He says the same applies to blame: it feels asymmetric from inside a team, but corporations distribute it fairly evenly.

### [How should a company approach a large technology migration?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-how-should-a-company-approach-a-large-technology-migration)

Viktor Farcic's answer on DevOps Paradox episode 340 is small chunks paired with a vision that can change. Grandiose plans get made because they sound better to shareholders than describing the single thing you intend to do this week. He insists on both halves: chunks without a vision are random, and a vision that never changes proves nobody applied what the chunks taught them.

### [What should companies do about shadow IT?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-what-should-companies-do-about-shadow-it)

Viktor Farcic proposes a rule on DevOps Paradox episode 340: adopt any shadow practice still running a year later. Persistence is the evidence, because the ones that were not worth it quietly disappear, so a surviving shadow tool is a roadmap item that already validated itself. He describes the practice as an illegal center of excellence. Darin Pope calls it appealing and chaotic in equal measure.

### [Where does AI genuinely help operations work today?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-where-does-ai-genuinely-help-operations-work-today)

Viktor Farcic's rule on DevOps Paradox episode 340 is that AI shines where a large volume of data sits in one place, or very few places, and somebody has to make sense of it. Darin Pope's example is log summarization, and he adds generating a Bash script that includes the input validation he would otherwise skip. Cases spanning many scattered sources get harder.

### [Could AI replace an operations engineer?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-could-ai-replace-an-operations-engineer)

Viktor Farcic says on DevOps Paradox episode 340 that nothing is close to that today. His framing is that AI enhances him rather than substituting for him: output that is only half right still helps, so long as reviewing and correcting it takes less time than doing the work himself. What he wants is the ratio shifting toward thinking and away from correcting.

### [What is the DevOps Paradox podcast?](/episodes/why-operations-teams-resist-every-technology-wave-340/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 340, "Why Operations Teams Resist Every Technology Wave," works through why operations teams reject tools their developers are keen on, how blame is actually distributed, and what shadow IT reveals about a roadmap. Every episode page carries the audio, the video, and a full transcript.

### [What does it take to run DNS for other people at scale?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-what-does-it-take-to-run-dns-for-other-people-at-scale)

Anthony Eden explains on DevOps Paradox episode 339 that small setups run unicast, with each machine answering on its own address. Growing past that means moving to anycast, distributing nodes worldwide for reliability, and then keeping every edge synchronized as records change. DNSimple runs fourteen edges against nine origin name servers, with anycast used internally too, so an edge reaches whichever origin is nearest.

### [What do people most often get wrong when setting up DNS?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-what-do-people-most-often-get-wrong-when-setting-up-dns)

Anthony Eden names two failures on DevOps Paradox episode 339. The first is leaving production DNS on a registrar never built to be DNS-first, putting a constant, business-critical dependency on infrastructure not designed to carry it. The second is security: registering under a shared login because the registrar has no multi-user access control, so the domain becomes unreachable the moment that person leaves the company.

### [Which DNS records do teams forget to configure?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-which-dns-records-do-teams-forget-to-configure)

Anthony Eden points on DevOps Paradox episode 339 at email deliverability: DMARC to declare a policy, SPF to authorize which senders may send, and DKIM to sign messages so recipients can confirm they are untampered. He also raises change management, where records get added by hand with no note of why, leaving zones nobody dares clean up. DNSimple added notes with history for exactly that.

### [How has AI search affected DNSimple's traffic?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-how-has-ai-search-affected-dnsimples-traffic)

Anthony Eden describes on DevOps Paradox episode 339 losing informational search traffic once Google placed AI summaries above the results, because the knowledge base articles explaining each DNS record type now get answered in place. Signups dipped after those tools appeared. What remains, though, is people genuinely interested in the product rather than bots following links, and he reports an uptick since.

### [Is vibe coding acceptable for operational systems?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-is-vibe-coding-acceptable-for-operational-systems)

Anthony Eden says no on DevOps Paradox episode 339, at least not yet. Running systems that have to stay up means his engineers need to understand what they are building, and he argues that understanding only comes from reading the generated code. He adds that humans wreck the comprehensibility of a system with hand-written code just as thoroughly, so his objection is about understanding rather than about AI.

### [How does a small company survive a hyperscaler entering its market?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-how-does-a-small-company-survive-a-hyperscaler-entering-its-market)

Anthony Eden was asked exactly that when AWS launched Route 53, and he tells DevOps Paradox episode 339 his answer has not changed. A hyperscaler is building one of hundreds of products, so the investment is finite and the result stays deliberately general, which leaves room for a focused provider to move faster. DNSimple runs on twenty people, around three quarters of them engineers, funded from profit.

### [What is the DevOps Paradox podcast?](/episodes/dns-is-old-tech-and-that-s-why-it-still-runs-the-internet-339/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 339, "DNS Is Old Tech (And That's Why It Still Runs the Internet)," brings in Anthony Eden of DNSimple on anycast, the records teams forget, and running an internet-critical service with twenty people. Every episode page carries the audio, the video, and a full transcript.

### [Why is AI-assisted development not delivering features any faster?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-why-is-ai-assisted-development-not-delivering-features-any-faster)

Viktor Farcic's answer on DevOps Paradox episode 338 is that somebody downstream is blocking, and that AI is incidental to the story. Any single phase of the software development lifecycle running faster than the rest relocates the bottleneck rather than removing it, exactly as moving from punch cards to Java did. Darin Pope adds that upstream teams are rarely told they could now be producing more.

### [What is the fastest possible software delivery pipeline?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-what-is-the-fastest-possible-software-delivery-pipeline)

Viktor Farcic's answer on DevOps Paradox episode 338 is one person carrying an idea all the way to users. He is not arguing for one person per project, only per feature or fix, with the system arranged so nobody waits on someone else to review, run tests, or deploy. He distinguishes wiring a light switch once from employing somebody to stand beside it. Darin Pope calls that a butler.

### [Why do teams always think the bottleneck is somewhere else?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-why-do-teams-always-think-the-bottleneck-is-somewhere-else)

Viktor Farcic observes on DevOps Paradox episode 338 that people only see bottlenecks to their right. A feature request simply arrives, and whether it took a day or seven years to reach you is invisible, so nothing upstream ever registers as slow. Developers blame testers, testers blame whoever deploys, and the people writing the requests blame developers. He calls the perception completely wrong and completely normal.

### [Why does AI help developers more than operations teams?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-why-does-ai-help-developers-more-than-operations-teams)

Viktor Farcic separates the two cases on DevOps Paradox episode 338 by asking where the context lives. A coding agent gets most of what it needs from the repository it was pointed at, and security scanning is much the same. Operations context is scattered across cloud accounts, cluster access, runbooks, company policy and whatever sits in an engineer's head, so the same tools take far more work to make useful.

### [Should a company optimize its whole delivery pipeline at once?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-should-a-company-optimize-its-whole-delivery-pipeline-at-once)

Viktor Farcic argues against it on DevOps Paradox episode 338. Nobody understands a large system in full, so nobody can predict how one change ripples, and companies attempting everything at once spend three years philosophizing. His alternative is to poke the system: optimize one step, watch what that surfaces, and let it show you where the next constraint sits. The failure is treating one optimization as the finish.

### [Who should own fixing a company's delivery pipeline?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-who-should-own-fixing-a-companys-delivery-pipeline)

Viktor Farcic says on DevOps Paradox episode 338 that centers of excellence fail because whoever leads one is placed at the same level as the heads of testing, development, operations and security. That turns the work into a fight for power, and it ends with a good idea nobody adopts. His view is that the role has to sit above those functions to change how they actually operate.

### [What is the DevOps Paradox podcast?](/episodes/the-assembly-line-problem-why-adding-ai-to-one-step-breaks-everything-338/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 338, "The Assembly Line Problem," works through why speeding up one step of the software development lifecycle moves a bottleneck instead of removing it, and why every team believes the blocker is another team. Every episode page carries the audio, the video, and a full transcript.

### [Why use a time series database instead of PostgreSQL or MySQL?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-why-use-a-time-series-database-instead-of-postgresql-or-mysql)

Evan Kaplan of InfluxData explains on DevOps Paradox episode 337 that general purpose databases do not optimize for the thing a time series workload already knows: its index is primarily time. Specializing lets you change ingest rate, write time, query speed and storage cost together, and skipping that means paying all of those prices. He compares using a relational database for the job to entering a minivan in a Formula 1 race.

### [How long should you keep time series data?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-how-long-should-you-keep-time-series-data)

Evan Kaplan tells Darin Pope on DevOps Paradox episode 337 that the retention period is whatever separates signal from noise for the problem being solved. The common pattern is collecting high resolution data for a short window, then downsampling and storing the result for a long one. Viktor Farcic adds that going finer than you need costs money and performance. Kaplan counters that you do not always know the needed period in advance.

### [Who does not need a time series database?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-who-does-not-need-a-time-series-database)

Evan Kaplan says on DevOps Paradox episode 337 that light instrumentation feeding a dashboard does not need one, and a general purpose database or an observability vendor will do. The people who do need one run operational workloads where something depends on the data rather than just a chart. His example is a customer collecting from ten million devices that has to act on readings in under fifteen milliseconds.

### [Why does physical AI need deterministic models rather than probabilistic ones?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-why-does-physical-ai-need-deterministic-models-rather-than-probabilistic-ones)

Evan Kaplan argues on DevOps Paradox episode 337 that probabilistic models work fine for language and digital data, but systems acting on the physical world need deterministic ones. His illustration is blunt: he does not want his robot running over his cat, or a self-driving car hitting a pedestrian. He also notes that the physical world offers effectively infinite data to collect, unlike the digital corpus that has largely been scraped already.

### [Why has InfluxDB kept a permissive open source license?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-why-has-influxdb-kept-a-permissive-open-source-license)

Evan Kaplan tells Viktor Farcic on DevOps Paradox episode 337 that InfluxData stayed on MIT and Apache while most competitors moved to restrictive secondary licenses, and that he would make the same choice starting over today. He describes the approach as open core, meaning not everything goes into the open source project. The company also has committers on Apache Arrow and Apache DataFusion rather than contributing only to its own code.

### [Why did AWS partner with InfluxData rather than fork it?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-why-did-aws-partner-with-influxdata-rather-than-fork-it)

Evan Kaplan says on DevOps Paradox episode 337 that Amazon both licenses and pays for InfluxDB and sells it as Timestream for InfluxDB. He reads the shift as Amazon having learned what maintaining its own forks of Elasticsearch and Redis actually costs, measured against the goal that matters more to it: getting workloads onto the platform. Data has gravity, so once it lands there the other services follow.

### [What is the DevOps Paradox podcast?](/episodes/nanoseconds-matter-influxdb-and-the-future-of-real-time-data-337/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 337 brings in Evan Kaplan of InfluxData to work through when a time series database earns its place, how long to keep the data, and why physical automation changes the requirements. Every episode page carries the audio, the video, and a full transcript.

### [What does bring your own agents to work mean?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-what-does-bring-your-own-agents-to-work-mean)

Darin Pope frames it on DevOps Paradox episode 336 as the next version of bring your own device: a candidate arrives already having their own AI agents, tuned to how they work, and treats using them as non-negotiable. He traces the device parallel from 2004, when the practice appeared, to around 2009, when the iPhone and Android made it normal and Intel built a standard way to allow it.

### [Why do companies not see productivity gains from AI yet?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-why-do-companies-not-see-productivity-gains-from-ai-yet)

Viktor Farcic argues on DevOps Paradox episode 336 that the gains are real for individuals and invisible at company level, because the bottleneck does not move. If you write code twice as fast but the pipeline that delivers it to production runs at the same speed, you are faster and the company is not. Until the whole process is on board, the constraint stays where it was.

### [Why does shadow IT keep being shadow IT?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-why-does-shadow-it-keep-being-shadow-it)

Viktor Farcic explains on DevOps Paradox episode 336 that shadow IT exists because individuals or teams are genuinely more productive working around the process. It stays shadow rather than becoming policy because the productivity gain is obvious at the individual level and not at the company level. Creating an EC2 instance faster than your infrastructure department can issue a VM does not get the application into production any sooner.

### [Who owns AI agents an employee tunes while working at a company?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-who-owns-ai-agents-an-employee-tunes-while-working-at-a-company)

Darin Pope and Viktor Farcic work through the problem on DevOps Paradox episode 336 without resolving it, noting neither is a lawyer. Farcic's analogy is a personal laptop: what you brought stays yours, but company software installed on it while you were there makes leaving with it complicated. Agents trained over years on one company's way of working sit in exactly that grey area.

### [Should candidates be allowed to use AI during a technical interview?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-should-candidates-be-allowed-to-use-ai-during-a-technical-interview)

Viktor Farcic says on DevOps Paradox episode 336 that he allowed candidates to use the internet when hiring roughly twenty years ago. Only one person did, and that person was hired. His reasoning is that knowing what to search for is itself a differentiator, and an experienced engineer finds a solution faster than an inexperienced one. He calls isolated problem-solving exams largely pointless.

### [Is AI the biggest shift in how people work?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-is-ai-the-biggest-shift-in-how-people-work)

Viktor Farcic tells Darin Pope on DevOps Paradox episode 336 that he can name two comparable moments in his own career: getting his first computer, and discovering the internet. He puts AI at a similar order of magnitude rather than a larger one. What he considers genuinely new is the breadth, since previous disruptions hit one industry at a time and this one arrives almost everywhere at once.

### [What is the DevOps Paradox podcast?](/episodes/why-top-talent-won-t-work-for-you-anymore-336/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 336 is a conversation between the two hosts about candidates bringing their own AI agents to a job, what that does to compensation and intellectual property, and why company AI policy is already affecting recruiting. Every episode page carries the audio, the video, and a full transcript.

### [How is Coroot different from Grafana?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-how-is-coroot-different-from-grafana)

Peter Zaitsev tells Viktor Farcic on DevOps Paradox episode 335 that the two are not direct competitors. Grafana is a set of Lego blocks that lets you build almost any visualization, provided you build it. Coroot is opinionated and works out of the box, telling you which things to look at rather than offering to show you anything. Plenty of people run both, pulling Coroot data into Grafana for custom views.

### [Why does Coroot use eBPF instead of application instrumentation?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-why-does-coroot-use-ebpf-instead-of-application-instrumentation)

Peter Zaitsev explains on DevOps Paradox episode 335 that OpenTelemetry requires configuring each application to emit traces, which is workable for new services and impractical for old or proprietary ones nobody maintains. An eBPF agent instruments every container and pod with no configuration, and it is far safer than the kernel modules that were the previous option. Coroot still consumes OpenTelemetry traces when an application already produces them.

### [Should root cause analysis be done by an LLM?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-should-root-cause-analysis-be-done-by-an-llm)

Peter Zaitsev draws a line on DevOps Paradox episode 335 between two stages. Mapping a system and tracing how errors propagate through it is systematic and deterministic, not something different models should have differing opinions about, so Coroot does that with mathematical precision. The LLM comes in afterwards, once the origin is known, to suggest what to do about a specific problem given full context.

### [Why did Coroot choose Apache 2.0 over AGPL or BSL?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-why-did-coroot-choose-apache-20-over-agpl-or-bsl)

Peter Zaitsev says on DevOps Paradox episode 335 that the goal is maximum adoption with no restrictions, including companies building Coroot into their own commercial offerings. He contrasts this with vendors who market themselves as open source forever, fail to make money, and then change the license. Several companies already ship the Coroot agent with their own interfaces, and some contribute fixes back.

### [Why do open source companies change their licenses?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-why-do-open-source-companies-change-their-licenses)

Peter Zaitsev attributes it on DevOps Paradox episode 335 to venture capital taken at a high valuation. Growth continues but not at the exponential rate the funding assumed, and the license change follows from that pressure. Coroot has raised only minimal angel funding, which he describes as giving the team the luxury of patience, and lets them choose on technical merit rather than chasing the current hype cycle.

### [What does it take to run Coroot?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-what-does-it-take-to-run-coroot)

Peter Zaitsev tells Darin Pope on DevOps Paradox episode 335 that a server with four gigabytes of memory handles roughly ten nodes carrying a decent number of pods, and that he would rather understate it than overpromise. Docker Compose installs the application and its ClickHouse dependency; a Helm chart on an existing Kubernetes cluster also instruments the nodes. There is a public demo for evaluating it without deploying anything.

### [What is the DevOps Paradox podcast?](/episodes/stop-building-dashboards-and-start-getting-answers-with-coroot-335/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 335 brings in Peter Zaitsev, co-founder of Coroot and founder of Percona, to discuss self-hosted observability, eBPF-based instrumentation, and why open core beats a license change later. Every episode page carries the audio, the video, and a full transcript.

### [Is writing code the hardest part of software development?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-is-writing-code-the-hardest-part-of-software-development)

Viktor Farcic argues on DevOps Paradox episode 334 that typing code is the easiest part and he does not understand the fuss about it. His comparison is the technical books he has written: once the subject is understood, the chapters planned and the scripts validated across operating systems, the actual writing was almost mechanical. Everything around the code, deciding what to build and why, is where the difficulty sits.

### [Why does AI make pair programming between an architect and a developer practical?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-why-does-ai-make-pair-programming-between-an-architect-and-a-developer-practical)

Viktor Farcic explains on DevOps Paradox episode 334 that the pairing was always desirable and never possible, because one architect serves ten, twenty or more people writing code. You cannot pair one to many. If the person producing code becomes much faster, the ratio changes and the architect can think about the next step while the current one is being built, then validate it in short iterations.

### [Should you still refactor code that AI wrote?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-should-you-still-refactor-code-that-ai-wrote)

Viktor Farcic questions the assumption on DevOps Paradox episode 334. Cleaning up code exists mostly so humans can navigate it, and that trade-off has two sides: avoiding repetition often means one central function carrying conditionals for a hundred callers, where most of the code serves nobody in particular. He suggests two hundred self-contained lines can be easier to understand than twenty lines spread across five libraries.

### [What skills do developers need to work effectively with AI?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-what-skills-do-developers-need-to-work-effectively-with-ai)

Viktor Farcic names two on DevOps Paradox episode 334. The first is accepting that the work changes rather than assuming you will do the same thing slightly differently, the same reset that moving from Java to Rust demands. The second is communication, which he says many engineers avoided the profession to escape. His test is whether you could explain what you are about to do to a technical CEO.

### [How do code reviews change when AI writes the code?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-how-do-code-reviews-change-when-ai-writes-the-code)

Viktor Farcic tells Darin Pope on DevOps Paradox episode 334 that it depends on who opened the pull request. Reviewing his own work, he wants the tool to find correlations he missed. Reviewing someone else's, the tool can approve code that is technically fine and heading the wrong way entirely: it confirms you have arrived in Paris without knowing the destination was London.

### [What should junior developers focus on now?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-what-should-junior-developers-focus-on-now)

Viktor Farcic advises on DevOps Paradox episode 334 that juniors balance building things with stopping to understand them, since neither theory nor practice alone gets you there. His concern is that the pressure to look productive every hour crowds out learning, at a moment when upskilling is faster than at any point in the history of software. His half-serious suggestion is joining a company that rejects AI and learning quietly.

### [What is the DevOps Paradox podcast?](/episodes/if-code-is-the-easy-part-what-should-developers-actually-be-doing-334/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 334 is a conversation between the two hosts about what developers do when writing code stops being the bottleneck, covering architecture, code review, communication, and advice by career stage. Every episode page carries the audio, the video, and a full transcript.

### [What problems do all data pipelines have in common?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-what-problems-do-all-data-pipelines-have-in-common)

Pete Hunt of Dagster reduces it to three on DevOps Paradox episode 333: "My data is late." The data does not look right by some definition. And "I'm getting weird errors and I don't know why." The industry names them data quality, observability and data downtime. He says the classes of problem are identical whether a company is testing rocket engines or delivering portable toilets, even though the data sets are nothing alike.

### [Why do data projects fail even when the pipeline works?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-why-do-data-projects-fail-even-when-the-pipeline-works)

Pete Hunt tells Viktor Farcic on DevOps Paradox episode 333 that a stakeholder makes an urgent request, the data team scrambles and builds a dashboard, and then nobody uses it. He treats this as an adoption problem rather than a technical one, closer to getting people to engage with a consumer app. Farcic recognises the same pattern in developer platforms built on assumptions about what developers need.

### [What is Dagster?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-what-is-dagster)

Pete Hunt describes Dagster on DevOps Paradox episode 333 as open source data orchestration, with a commercial product on top. His comparison is Kubernetes: you declare what you want and a reconciliation loop keeps the actual state matching it, except the domain is data rather than pods, so it checks that data is hitting its service level agreements and flowing through the pipes. The underlying structure is a directed acyclic graph of data assets.

### [Why did so many companies adopt microservices?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-why-did-so-many-companies-adopt-microservices)

Pete Hunt gives an incentives answer on DevOps Paradox episode 333: demonstrating large-scale distributed system architecture is written into promotion guidelines at big tech companies, so engineers build services. Vendors then fund tooling for the complexity that follows. His view is that "the day you introduce a new service should be a very sad day", where at most large companies it is a happy one, and that company tech blogs were content marketing rather than technical advice.

### [How do you catch a spam attack that started five minutes ago?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-how-do-you-catch-a-spam-attack-that-started-five-minutes-ago)

Pete Hunt explains on DevOps Paradox episode 333 that trained models lag, because an adversary adapts faster than labels arrive and retraining happens. For emerging threats his team broke posts into trigrams and skip-grams and watched for sudden jumps in usage, which could be a spam campaign or a celebrity news event. Human reviewers triaged the top movers, a quick rule stopped the bleeding, and those rules then generated labels feeding the models.

### [How should you measure an engineer's performance?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-how-should-you-measure-an-engineers-performance)

Pete Hunt argues on DevOps Paradox episode 333 that the closest thing to a universal measure is forecasting ability rather than output. A mid or late career engineer working in a well understood area should be able to give a date, or give a range and then narrow it. Expectations scale with level: new graduates are expected to be wildly wrong. He adds that tying the measure to compensation ruins it.

### [What is the DevOps Paradox podcast?](/episodes/the-hidden-problems-behind-every-data-pipeline-333/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 333 brings in Pete Hunt, an early member of the team behind React and now leading Dagster, to discuss data pipeline failures, why dashboards go unused, and the incentives that produced the microservices era. Every episode page carries the audio, the video, and a full transcript.

### [Will AI take over operations in 2026?](/episodes/2026-the-year-of-discovery-332/index.md#faq-will-ai-take-over-operations-in-2026)

Viktor Farcic predicts on DevOps Paradox episode 332 that it will not, even in fully supervised mode, and says he hopes to be wrong. His reasoning is that the roles have swapped. Operations led adoption of containers, virtual machines and cloud while application developers were indifferent; now application developers are adopting AI rapidly and operations is defending the status quo. He calls it a human problem rather than a technological one.

### [Why do companies see no return on investment from AI?](/episodes/2026-the-year-of-discovery-332/index.md#faq-why-do-companies-see-no-return-on-investment-from-ai)

Viktor Farcic uses an assembly line on DevOps Paradox episode 332: improving one station does not shorten the time to produce a car. Giving developers AI while approvals, testing, security and operations run at the old speed leaves the release date where it was. He points out this is the same pattern as Kubernetes and cloud adoption, arriving faster than before.

### [Can you feed your existing company documentation to AI?](/episodes/2026-the-year-of-discovery-332/index.md#faq-can-you-feed-your-existing-company-documentation-to-ai)

Viktor Farcic warns on DevOps Paradox episode 332 that it will be a disaster, because three different things exist: what is documented, what people actually do while quietly working around the documentation, and what the process should be now that the pace has changed. He compares it to companies that adopted two week sprints while keeping their annual waterfall release, except this time an individual cannot quietly ignore it.

### [Does GitOps still matter with AI-driven operations?](/episodes/2026-the-year-of-discovery-332/index.md#faq-does-gitops-still-matter-with-ai-driven-operations)

Viktor Farcic argues on DevOps Paradox episode 332 that it is needed right now precisely because confidence in AI for operations is close to zero, so a pull request, a human approval and a synchronised apply are the point. His concern is later: an agent that fixes an issue, writes a manifest, then waits minutes for asynchronous polling while checking whether the change landed, turns the process itself into the bottleneck.

### [Will developers bring their own AI agents to a new employer?](/episodes/2026-the-year-of-discovery-332/index.md#faq-will-developers-bring-their-own-ai-agents-to-a-new-employer)

Viktor Farcic says on DevOps Paradox episode 332 that he is certain of it, though he declines to date it. His analogy is hiring a director who brings their previous team along the following week, with the agents in that role. He points out Darin Pope is already partway there, since the prompts a person writes encode their own experience and way of working into a portable tool set.

### [What is the least valuable thing a developer does?](/episodes/2026-the-year-of-discovery-332/index.md#faq-what-is-the-least-valuable-thing-a-developer-does)

Viktor Farcic answers on DevOps Paradox episode 332 that it is writing code, and says people will hate him for it. His warning is direct: "you should be very worried if you are one of the people in a company that literally just receives instructions and translates them as-is to code". He describes his own workload shifting from one feature a week to thinking about several a day.

### [What is the DevOps Paradox podcast?](/episodes/2026-the-year-of-discovery-332/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 332 is the pair's annual predictions episode for 2026, covering AI in operations, developer experience metrics, GitOps, internal developer platforms, and where the bottleneck moves next. Every episode page carries the audio, the video, and a full transcript.

### [How did the DevOps Paradox 2025 predictions turn out?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-how-did-the-devops-paradox-2025-predictions-turn-out)

Darin Pope scores them on DevOps Paradox episode 331 as roughly a failure, which he notes is the annual tradition. Of four predictions made in episode 296, more license rug pulls largely did not happen, WebAssembly staying niche was correct, small company roll-up acquisitions were about half right, and AI becoming embedded in existing tools rather than bought separately was correct.

### [What did the hosts miss in their 2025 predictions?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-what-did-the-hosts-miss-in-their-2025-predictions)

Agentic AI, as both hosts concede on DevOps Paradox episode 331. Viktor Farcic points out the episode was recorded in November 2024, when the word agent was barely being used. He says his mistake was not about the models, which progressed roughly as he expected, but about what turned out to matter: giving models the ability to use tools.

### [Was Viktor Farcic skeptical about AI?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-was-viktor-farcic-skeptical-about-ai)

Yes, and he says so plainly on DevOps Paradox episode 331: "November last year, I was in denial about AI." He knew it was on a path to becoming useful and was certain he would not be using it constantly a year later. He now uses it for writing code, operating clusters, working in AWS, writing blog posts, and deciding what to watch.

### [Does it matter which foundation model you use?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-does-it-matter-which-foundation-model-you-use)

Viktor Farcic argues on DevOps Paradox episode 331 that for an existing user of a major model there is little reason to switch, since any lead lasts about a week. Darin Pope adds that the steep improvement curve has moved from the models to how they are used, pointing at the run of additions to Claude Code as where the interesting changes have been happening.

### [Are more open source license changes coming?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-are-more-open-source-license-changes-coming)

Viktor Farcic expects so on DevOps Paradox episode 331, and plans to repeat the prediction he got wrong. His reasoning is funding rather than ideology: companies that are neither hyperscalers nor built around AI are struggling to raise money, and desperate companies do desperate things. He also notes acquisitions in 2025 concentrated on very young AI companies rather than established ones.

### [How does the AI hype cycle compare to Kubernetes?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-how-does-the-ai-hype-cycle-compare-to-kubernetes)

Viktor Farcic draws the parallel directly on DevOps Paradox episode 331. Both went through a period of every month bringing something that appeared to change everything, followed by a slowdown. He places the industry about a year into agentic AI, still discovering what works, with the shift from discovery to making it work still ahead. That framing gave the following episode its title.

### [What is the DevOps Paradox podcast?](/episodes/looking-back-on-our-2025-predictions-331/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 331 is the pair's annual review of their own predictions, scoring what they got right about 2025 and admitting they did not see agentic AI coming. Every episode page carries the audio, the video, and a full transcript.

### [When is vibe coding a reasonable choice?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-when-is-vibe-coding-a-reasonable-choice)

Darin Pope splits the question into three levels on DevOps Paradox episode 329: personal tooling, internal applications, and anything public facing. Viktor Farcic accepts vibe coding for the first and wants a skilled engineer behind the other two. His comparison is cooking. Everybody should be able to cook, and a few hundred people eating every day is a different job that calls for a chef.

### [What happens when a vibe-coded application is handed to a real developer?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-what-happens-when-a-vibe-coded-application-is-handed-to-a-real-developer)

Viktor Farcic predicts on DevOps Paradox episode 329 that the developer will say the work was extremely valuable, though not for the reason its author expects. It communicates what the person actually wants better than any other explanation would have, and then it gets thrown away and rebuilt. He likens it to a wireframe mockup, which is used as reference and never becomes the finished site.

### [Does the DRY principle still matter when AI writes the code?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-does-the-dry-principle-still-matter-when-ai-writes-the-code)

Viktor Farcic questions it on DevOps Paradox episode 329. Avoiding repetition mattered because the same change in five places took five times as long; if that becomes a minute instead of ten seconds, the calculation changes. He notes he now cares much less about things like function naming conventions, and tells the agent not to repeat code without treating a failure to comply as a problem.

### [Is technical debt from vibe coding permanent?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-is-technical-debt-from-vibe-coding-permanent)

Viktor Farcic argues on DevOps Paradox episode 329 that refactoring is one of the easiest things to hand an agent, and much easier than getting it to implement the feature in the first place. Consolidating fifty thousand repeated lines used to be a month of work nobody would authorise; he puts it closer to half an hour. Darin Pope adds the obvious precondition: generate the missing tests first.

### [Can you pair program with an AI agent?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-can-you-pair-program-with-an-ai-agent)

Viktor Farcic says on DevOps Paradox episode 329 that working with one agent feels like the pair programming he used to enjoy, with the difference that he is no longer an equal partner but the one in charge. Adding a second human broke it. He was telling that person what to tell the agent, which put the three participants on different levels rather than pairing.

### [How is vibe coding different from low-code and no-code?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-how-is-vibe-coding-different-from-low-code-and-no-code)

Viktor Farcic treats them as the same progression on DevOps Paradox episode 329, with each step raising the ceiling before a non-engineer gets stuck. Expert help was always available at any of those stages and people did not ask for it then either. His addition is that an expert is more likely to be able to help with a vibe-coded application than with a no-code one.

### [What is the DevOps Paradox podcast?](/episodes/vibe-coding-and-the-technical-debt-time-bomb-329/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 329 is a conversation between the two hosts about where vibe coding belongs, what happens when a vibe-coded application reaches its limit, and whether AI changes the economics of technical debt. Every episode page carries the audio, the video, and a full transcript.

### [Is build versus buy really a choice between two options?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-is-build-versus-buy-really-a-choice-between-two-options)

Viktor Farcic rejects the framing on DevOps Paradox episode 328, challenging anyone to name a case of pure building or pure buying. Running Linux on your servers is buying, and you always install and configure something on top. The same is true of Kubernetes, managed or not. The real question is the ratio, and Alex Gusev of Uploadcare agrees that managing that balance is what running the business consists of.

### [What do companies underestimate when they decide to build?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-what-do-companies-underestimate-when-they-decide-to-build)

Alex Gusev tells Darin Pope on DevOps Paradox episode 328 that the path to shipping looks clear while maintenance stays invisible, particularly for anyone without experience running a self-built system. His example is a chief executive claiming to have rebuilt Jira in two weeks with AI and planning to drop the vendor. Viktor Farcic adds that if the objection is cost, dozens of open source alternatives already exist.

### [Does having thousands of engineers justify building your own tools?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-does-having-thousands-of-engineers-justify-building-your-own-tools)

Viktor Farcic calls headcount a fallacy on DevOps Paradox episode 328. A bank with fifty thousand people building something is not evidence that its problems are more unusual than those of a company with a thousand. He argues the opposite correlation is more common, pointing at AI labs that are small or medium sized by any measure while working on problems no existing solution covers.

### [Why does not-invented-here syndrome persist?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-why-does-not-invented-here-syndrome-persist)

Alex Gusev and Viktor Farcic give two reasons on DevOps Paradox episode 328. One is managers believing their company's processes are unique enough that no existing tool could support them, which Farcic mocks with the case of a team rebuilding a ticketing system to get Kanban boards. The other is simpler: people do not know the options exist. Gusev had not heard of Uploadcare until two years before becoming its CTO.

### [How do compliance requirements affect a build or buy decision?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-how-do-compliance-requirements-affect-a-build-or-buy-decision)

Alex Gusev explains on DevOps Paradox episode 328 that as a SOC 2 Type 2 certified company, Uploadcare has to select vendors at the same level of compliance, and that picking those vendors is part of his job. He notes GDPR and HIPAA can conflict directly, one requiring data be removed after a period and the other requiring it be retained, which means handling data differently by customer origin.

### [Does buying instead of building remove the maintenance burden?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-does-buying-instead-of-building-remove-the-maintenance-burden)

No, and Alex Gusev is blunt about it on DevOps Paradox episode 328: his whole working life is a maintenance nightmare. Integration libraries still need upgrading. He adds that building something obliges you to maintain not only the tool but the level of knowledge of it inside the company, and that a vendor's engineering culture matters as much as its certifications, since some deprecate an API with a week's notice.

### [What is the DevOps Paradox podcast?](/episodes/the-real-cost-of-build-versus-buy-decisions-328/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 328 brings in Alex Gusev, CTO of Uploadcare, to work through build versus buy: the maintenance costs teams forget, why headcount is a poor guide, and how compliance changes the arithmetic. Every episode page carries the audio, the video, and a full transcript.

### [Should you let an AI agent manage infrastructure unsupervised?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-should-you-let-an-ai-agent-manage-infrastructure-unsupervised)

Viktor Farcic says no on DevOps Paradox episode 327, for anything beyond trivial tasks, while allowing that this may change. His reasoning is personal and concrete: he has never had a single session with an agent where he did not say no at least once and redirect it. Until he reaches the point of approving everything, he cannot picture running one unsupervised.

### [Can the model underneath your agent change without you noticing?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-can-the-model-underneath-your-agent-change-without-you-noticing)

Viktor Farcic explains on DevOps Paradox episode 327 that APIs expose dated model versions, so pinning one gives you a fixed snapshot. He treats a model like any other dependency: you would not switch to a new version of a third-party API without testing it first. For supervised interactive work he does not pin, because he is checking every step anyway.

### [Why does AI cause problems in a company's infrastructure?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-why-does-ai-cause-problems-in-a-companys-infrastructure)

Viktor Farcic separates malice from ignorance on DevOps Paradox episode 327 and says the second is the real risk. A model knows how Kubernetes works. What it cannot know is how your company works, which policies apply, and what you never do. His analogy is a new hire deploying to Azure on day one at an AWS shop, not through bad intent but through having no way to know.

### [Should companies require developers to use AI?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-should-companies-require-developers-to-use-ai)

Viktor Farcic argues against mandating tools on DevOps Paradox episode 327, while accepting that the measurement changes. If the company genuinely became more efficient, the expected output rises for everyone, and how you reach it is your business. His parallels are editors and Kubernetes clients: if someone stays ahead using Vim rather than an IDE, that is fine, and the same standard applies either way.

### [What is a sleeper agent in AI?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-what-is-a-sleeper-agent-in-ai)

Viktor Farcic describes research he had read on DevOps Paradox episode 327 into agents carrying hidden behaviour that activates on a specific date, named after Cold War sleeper agents. His concern is the supply chain around it: a free agent that does something genuinely useful gets adopted and runs inside your own infrastructure, and nobody is going to audit it. Darin Pope calls agents the next level of malware.

### [What does SEO look like for LLM answers?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-what-does-seo-look-like-for-llm-answers)

Viktor Farcic predicts on DevOps Paradox episode 327 that this becomes a large segment of the industry. The old problem was reaching the first page of Google. The new one is being the answer an assistant gives, chosen from an unlimited pool of alternatives, and then getting the reader to visit anyway. He frames the requirement bluntly: the answer has to be helpful and insufficient at the same time.

### [What is the DevOps Paradox podcast?](/episodes/when-ai-tools-go-rogue-327/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 327 is a conversation between the two hosts about what happens when AI tooling misbehaves, covering supervision, pinned model versions, company-specific knowledge, and agents carrying hidden behaviour. Every episode page carries the audio, the video, and a full transcript.

### [What problem does Dapr solve?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-what-problem-does-dapr-solve)

Mark Fussell explains on DevOps Paradox episode 326 that his team watched hundreds of enterprises rebuild the same distributed systems patterns: discovering and calling other services, passing messages between them, coordinating across them, and plugging in storage or secret stores. Dapr codifies those patterns as APIs. Asked whether that is itself reinventing the wheel, he answers that it stops everyone reinventing their own: "this is buy a wheel, not build a wheel."

### [How does the Dapr component model work?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-how-does-the-dapr-component-model-work)

Mark Fussell describes it on DevOps Paradox episode 326 as separating the API your code calls from the infrastructure behind it. Publish and subscribe code written against the Dapr API keeps working when the broker underneath changes from one message broker to another. Installing the CLI locally runs Redis in a container for messaging, so the same code developed on a laptop deploys to a different broker in production by changing one component definition.

### [How is Dapr different from a service mesh like Istio?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-how-is-dapr-different-from-a-service-mesh-like-istio)

Mark Fussell tells Viktor Farcic on DevOps Paradox episode 326 that a service mesh operates on network traffic and containers, with no concept of application A and application B. Dapr gives each process a named application identity backed by a SPIFFE ID, so one application can call another by name and you can declare that only application one may talk to application two. He calls that a boundary a mesh cannot express.

### [Does Dapr duplicate Kubernetes secrets?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-does-dapr-duplicate-kubernetes-secrets)

Mark Fussell draws the line on DevOps Paradox episode 326 at infrastructure versus application. Most organisations keep secrets in a cloud vault rather than in Kubernetes so they can manage them centrally. The Dapr secrets API retrieves them into the application directly from whichever store, which Viktor Farcic summarises as skipping the step where an operator syncs the secret into Kubernetes and mounts it.

### [Why do AI agents need durable workflows?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-why-do-ai-agents-need-durable-workflows)

Mark Fussell argues on DevOps Paradox episode 326 that agentic systems are distributed applications with language models attached, and an agent running twenty steps is a state machine. If the machine crashes at step fifteen, you do not want it to lose its memory of what it had already done. He says most agent frameworks lack that durability, which is what Dapr's code-first workflow engine provides.

### [Why do developers underestimate what a distributed application runtime gives them?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-why-do-developers-underestimate-what-a-distributed-application-runtime-gives-them)

Mark Fussell puts it down to experience on DevOps Paradox episode 326: "if you haven't built a system from scratch all the way through before and then had to worry about the security, the resiliency, the observability, and dealing with the failures and all of that pain that it entails, you think it's an easy task when it's not in any way." He observes adoption usually starts with senior developers who have already been through it.

### [What is the DevOps Paradox podcast?](/episodes/stop-reinventing-the-wheel-use-dapr-instead-326/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 326 brings in Mark Fussell, co-founder of Dapr and Diagrid, to explain what the runtime abstracts away, how swapping infrastructure components works, and why durable workflows matter for agents. Every episode page carries the audio, the video, and a full transcript.

### [Why was ingress-nginx deprecated?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-why-was-ingress-nginx-deprecated)

Whitney Lee reports on DevOps Paradox episode 325 that the project had two maintainers, both volunteers, neither paid to work on it. She says a maintainer told her roughly 40 percent of Kubernetes clusters worldwide use it, and that there is no clear migration path. Viktor Farcic treats the announcement as acknowledging a reality that had existed for years rather than a sudden decision.

### [Are companies behind CNCF projects disappearing?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-are-companies-behind-cncf-projects-disappearing)

Viktor Farcic says on DevOps Paradox episode 325 that he cannot prove it with numbers, but his impression from the KubeCon Atlanta show floor is that exhibitors who are the company behind a CNCF project keep declining, while companies merely using those projects remain plentiful. His concern follows directly: those companies pay the maintainers, and projects without paid maintainers die slowly or quickly depending on the project.

### [Why has AI not been adopted in operations?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-why-has-ai-not-been-adopted-in-operations)

Viktor Farcic offers a blunt test on DevOps Paradox episode 325: put AI in your talk title at KubeCon and watch attendance drop. He argues vendors target developers instead, since there are between ten and thirty developers for every operations person, making ops a small market per seat. What changed, he adds, is that developers turned out to be buyers after years of buying nothing.

### [What were the themes at KubeCon North America 2025?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-what-were-the-themes-at-kubecon-north-america-2025)

Whitney Lee summarises Atlanta on DevOps Paradox episode 325 as settling into the boring parts of AI, operationalising it, with a healthy amount of platform engineering alongside. Keynotes covered AI conformance and safety rather than novelty, and a new Kubernetes working group is forming around AI conformance. She also heard far more about SPIFFE and SPIRE than usual, for automating workload identity for AI workloads.

### [Will AI innovation come from established companies or new ones?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-will-ai-innovation-come-from-established-companies-or-new-ones)

Viktor Farcic expects new ones on DevOps Paradox episode 325, because starting from scratch means no existing intellectual property to protect and, counterintuitively, more speed. He describes the trap facing an existing company as three bad choices: keep the current business and miss the wave, abandon revenue it cannot survive without, or split its people across both and build nothing substantial in either.

### [Will the CNCF still matter in ten years?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-will-the-cncf-still-matter-in-ten-years)

Darin Pope predicts on DevOps Paradox episode 325 that it will not exist by 2035. Viktor Farcic disagrees on the detail: it will exist, but resemble the Linux Foundation, still necessary and used by everyone without drawing tens of thousands to conferences. His point is that boring technology is fine, just poor ground for startups, since nobody launches new operating systems at a conference.

### [What is the DevOps Paradox podcast?](/episodes/kubecon-north-america-2025-review-325/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 325 is the pair's KubeCon North America review with Whitney Lee, covering the ingress-nginx deprecation, shrinking maintainer funding, and how AI showed up on the show floor. Every episode page carries the audio, the video, and a full transcript.

### [What is in-place pod resize in Kubernetes 1.33?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-what-is-in-place-pod-resize-in-kubernetes-133)

Omer Hamerman explains on DevOps Paradox episode 324 that it lets you change a pod's CPU or memory allocation on the fly without restarting it, a capability people had wanted for years and which reaches into how Linux namespaces work. It moved to beta in 1.33. The limits matter: you have to target individual pods rather than a deployment, and the node still needs spare capacity.

### [Can you actually know how much CPU and memory a workload needs?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-can-you-actually-know-how-much-cpu-and-memory-a-workload-needs)

Viktor Farcic says no on DevOps Paradox episode 324, calling the belief "a collective hallucination going on in our industry." You do not know on day one, day two, or three years later; at best an experienced engineer makes an approximate guess by language. Omer Hamerman agrees, noting his job exists to answer that question dynamically, and that asking users to specify something unknowable was a design mistake.

### [Do AI workloads break Kubernetes?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-do-ai-workloads-break-kubernetes)

Omer Hamerman argues on DevOps Paradox episode 324 that AI is another workload type rather than something unprecedented. It wants more CPU, preferably GPUs, more disk and more security layers, but Kubernetes has had ten years to become stable enough to carry it. Viktor Farcic points out the cost sits in the GPUs, outside Kubernetes, and that autoscaling is what keeps that bill from being permanent.

### [Should a startup run its own data center instead of the cloud?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-should-a-startup-run-its-own-data-center-instead-of-the-cloud)

Viktor Farcic argues against it on DevOps Paradox episode 324 on the grounds of uncertainty: companies do not yet know what they need, so leasing beats buying hardware for unknown requirements. He also objects to the usual comparison, which sets server cost against server cost while ignoring the people needed to run a data center. Omer Hamerman adds that hiring for it is its own problem.

### [Why can't you use the Kubernetes VPA and HPA together?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-why-cant-you-use-the-kubernetes-vpa-and-hpa-together)

Omer Hamerman explains on DevOps Paradox episode 324 that pointing both at the same metric on the same resource creates a negative feedback loop, which is why the vertical autoscaler carries an explicit warning. Kubernetes describes multidimensional autoscaling as a concept and leaves the implementation to others, the same pattern it follows elsewhere. He expects that combination to be the direction, helped by in-place resize removing the restart.

### [What is the most common mistake with Kubernetes right-sizing?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-what-is-the-most-common-mistake-with-kubernetes-right-sizing)

Omer Hamerman says on DevOps Paradox episode 324 that the most common mistake is simply not doing it, and not knowing the options exist. Most companies reach for horizontal scaling and distrust vertical scaling, sometimes for good reason. His summary of the whole conversation is deliberately unglamorous: "Don't overcomplicate, don't overthink. Sometimes the 80% you already have in place will do the job."

### [What is the DevOps Paradox podcast?](/episodes/kubernetes-resource-right-sizing-and-scaling-with-zesty-324/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 324 brings in Omer Hamerman of Zesty to discuss right-sizing Kubernetes workloads, the in-place resize feature, whether anyone can guess resource requests correctly, and what AI workloads change. Every episode page carries the audio, the video, and a full transcript.

### [Where does vibe coding work and where does it break down?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-where-does-vibe-coding-work-and-where-does-it-break-down)

Viktor Farcic draws the line on DevOps Paradox episode 323 at scope. Starting from scratch with a narrow goal works well: an HR tool for sorting candidates, or a site for a hobby. It breaks when a feature means writing a thousand lines that amount to a fraction of a percent of an existing codebase. He is describing unsupervised generation, which he distinguishes from the supervised back-and-forth most people now call vibe coding.

### [Can you let AI deploy to production unsupervised?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-can-you-let-ai-deploy-to-production-unsupervised)

Viktor Farcic is unambiguous on DevOps Paradox episode 323: "You cannot let AI just deploy to production unsupervised Because it has no idea what to do." His analogy is hiring the most brilliant graduate who ever lived and handing them production on day one. The problem is not capability. That person does not know whether you run on AWS or Azure, what your policies are, or where anything lives.

### [Is AI worse at security than a human developer?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-is-ai-worse-at-security-than-a-human-developer)

Viktor Farcic pushes back on that framing on DevOps Paradox episode 323. If the agent operates under the same permissions as a person and receives the same company-specific knowledge a new hire gets over a year, he asks why the outcome would differ. His point is that the failure being described is inexperience rather than artificial intelligence, and it applies equally to a person on their first day.

### [Would a non-developer build something safer without AI?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-would-a-non-developer-build-something-safer-without-ai)

Viktor Farcic argues on DevOps Paradox episode 323 that the same person with no-code tools, or with just enough self-taught JavaScript, reaches an equally bad outcome more slowly. The exposed credentials and the locally stored card numbers were possible before. He allows one difference in AI's favour: a model might warn the person that they are exposing a password, which no previous route would have done.

### [What should a company do with a vibe-coded app from a non-developer?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-what-should-a-company-do-with-a-vibe-coded-app-from-a-non-developer)

Viktor Farcic suggests on DevOps Paradox episode 323 that companies pass it through the controls they already run: security scanning, checks for exposed credentials, coding standards, code review. It will surface more issues than usual, which is still less work than starting from nothing. His question to the engineer is which they prefer, a working solution carrying extra security problems or a ticket describing something nobody can articulate.

### [What is missing before AI coding tools are safe at work?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-what-is-missing-before-ai-coding-tools-are-safe-at-work)

Viktor Farcic says on DevOps Paradox episode 323 that the tools are disconnected from everything else, closer to a hobby than part of the system. His comparison is Kubernetes: a company eventually stops letting everyone install their own and standardises on a platform with rules attached. Companies are currently assuming their existing policies do not apply to AI, and he cannot see why they would make that assumption.

### [What is the DevOps Paradox podcast?](/episodes/the-security-nightmare-of-vibe-coding-323/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 323 is a conversation between the two hosts about the security consequences of shipping vibe-coded applications, why the real gap is company knowledge rather than model capability, and how existing controls should apply. Every episode page carries the audio, the video, and a full transcript.

### [How is peer-to-peer different from a normal client-server application?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-how-is-peer-to-peer-different-from-a-normal-client-server-application)

Mathias Buus Madsen explains on DevOps Paradox episode 322 that conventional data flows are point to point: you call a specific endpoint and that entity gives you the data. Peer-to-peer inverts the trust model, so it does not matter who serves the data as long as you can verify it came from the right source. He can accept content from his worst enemy and check it cryptographically on his own machine.

### [Why does peer-to-peer matter beyond file sharing?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-why-does-peer-to-peer-matter-beyond-file-sharing)

Mathias Buus Madsen draws a parallel on DevOps Paradox episode 322 to encryption on the web. Fifteen or twenty years ago it was treated as an optional cost, weighed connection by connection. Nobody now asks whether traffic should be encrypted. He expects authenticating data at rest to follow the same path, and predicts that in twenty years the question will be why it was not always done.

### [Does peer-to-peer require users to donate their compute?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-does-peer-to-peer-require-users-to-donate-their-compute)

Mathias Buus Madsen says no on DevOps Paradox episode 322, pushing back on Viktor Farcic's framing. The resources a device already has for running an app far exceed what the network needs from it when that device joins. Users of BitTorrent were not thinking about reseeding; they wanted the content. He also notes that peer-to-peer needs no token or blockchain-style incentive to work.

### [What does deploying software mean when there are no servers?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-what-does-deploying-software-mean-when-there-are-no-servers)

Mathias Buus Madsen describes it on DevOps Paradox episode 322 as producing a cryptographic signature for the new version and handing it to a few peers, who pass it on from there. The internal process before that point is ordinary: test it, have other people test it, then sign. He points out he distributes updates to thousands of users from the laptop he is recording on.

### [How do you avoid losing data with no central database?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-how-do-you-avoid-losing-data-with-no-central-database)

Mathias Buus Madsen argues on DevOps Paradox episode 322 that small networks are the hard case, not large ones. Two peers is the weakest possible arrangement, since one going offline removes half the capacity, and every peer added makes it more resilient. That is the opposite of a centralised system, which struggles as users are added. Where guarantees are needed, you add peers that mirror the data.

### [What is hard about developing peer-to-peer applications?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-what-is-hard-about-developing-peer-to-peer-applications)

Mathias Buus Madsen names debugging on DevOps Paradox episode 322, since the software runs everywhere across versions and devices. He asked a Skype co-founder how they handled it and was told you go with the flow. Privacy compounds it: collecting centralised logs and statistics is unacceptable to the users such an application attracts, so his team logs locally and lets users choose to share.

### [What is the DevOps Paradox podcast?](/episodes/how-to-build-apps-that-never-go-down-even-when-servers-die-322/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 322 brings in Mathias Buus Madsen, creator of the Pear runtime, to explain how peer-to-peer changes where trust lives, what deployment and backup mean without servers, and why small networks are the difficult case. Every episode page carries the audio, the video, and a full transcript.

### [What is the Model Context Protocol?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-what-is-the-model-context-protocol)

Viktor Farcic describes MCP on DevOps Paradox episode 321 as a standard way for agents to accomplish what a model told them to do by talking to tools and APIs, calling it an API for agents. He separates the specification from the servers that implement it, the same way an API spec is separate from the service behind it. What a given server does behind that interface is unconstrained.

### [Why does an MCP tool description matter so much?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-why-does-an-mcp-tool-description-matter-so-much)

Viktor Farcic calls the description everything on DevOps Paradox episode 321. It is written in English and becomes part of the context sent to the model alongside your request, which is how the model learns the tool exists. It is a suggestion rather than a rule: nothing forces an agent to route Kubernetes work through a tool that offers to handle Kubernetes work.

### [Why do you need MCP when the model already knows the tools?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-why-do-you-need-mcp-when-the-model-already-knows-the-tools)

Viktor Farcic frames it on DevOps Paradox episode 321 as the difference between intent and context. Asking for an EC2 instance is intent. That your company always uses Crossplane is context the model does not have, so it will reach for CloudFormation or Terraform because that is what most documentation describes. An MCP server carries that organisational context into the request.

### [When should you not build an MCP server?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-when-should-you-not-build-an-mcp-server)

Viktor Farcic argues on DevOps Paradox episode 321 against mirroring a well-known tool one to one. Models already know the GitHub CLI and kubectl, and he says an agent statistically does better with the CLI than with an equivalent server. Servers earn their place when designed around intents rather than commands: finishing development, or deploying an application the way your company deploys applications.

### [What is still unsolved about running MCP servers remotely?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-what-is-still-unsolved-about-running-mcp-servers-remotely)

Viktor Farcic identifies permissions on DevOps Paradox episode 321. A server running beside the agent on your laptop inherits your permissions. One serving many people needs far broader permissions, and he does not think distinguishing and authenticating those users is solved. Transport compounds it: most servers spoke over standard input and output rather than HTTP, which makes running them behind normal Kubernetes networking awkward.

### [Why did MCP get adopted so quickly?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-why-did-mcp-get-adopted-so-quickly)

Viktor Farcic says on DevOps Paradox episode 321 he has never seen anything like it, with adoption across essentially every agent and vendor inside half a year: "Nothing ever propagated that fast." He argues the value is the agreement rather than the design. As with OpenTelemetry, a better protocol would still be worth less, because what matters is that your tools and everyone else's speak the same one.

### [What is the DevOps Paradox podcast?](/episodes/model-context-protocol-for-standardizing-ai-tool-integration-321/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 321 is a conversation between the two hosts explaining the Model Context Protocol: what a server actually adds, when writing one is a waste of effort, and what remains unsolved about running them remotely. Every episode page carries the audio, the video, and a full transcript.

### [Has incident management actually improved in twenty years?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-has-incident-management-actually-improved-in-twenty-years)

Jim Hirschauer says on DevOps Paradox episode 320 that the stories he hears from people in IT operations today match his own from fifteen to twenty years ago: war rooms, disconnects, and silos nobody has managed to break down. When he asks conference audiences whether the same incidents keep recurring, around three quarters of the room raises a hand. Viktor Farcic counters that the old problems were solved and the new ones are simply harder.

### [Why do the same incidents keep happening?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-why-do-the-same-incidents-keep-happening)

Jim Hirschauer explains on DevOps Paradox episode 320 that after service is restored and everyone celebrates, the team returns to an email queue and a backlog that grew during the war room. The postmortem identified real causes and follow-up work, and that work competes with catching up. He describes it as neglect driven by being overworked rather than by not knowing what to fix.

### [What are the four phases of incident management?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-what-are-the-four-phases-of-incident-management)

Jim Hirschauer breaks it down on DevOps Paradox episode 320 into pre-incident work such as runbooks, detection through observability and alerting, resolution, and post-incident follow-up. His argument is that the industry has spent years getting good at the two middle steps and neglected both bookends. Runbooks start sparse because development runs late, then go stale as the application changes.

### [Why are dashboards not enough for incident response?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-why-are-dashboards-not-enough-for-incident-response)

Viktor Farcic argues on DevOps Paradox episode 320 that a dashboard represents things you already knew could happen, so it fails precisely on the incident that has never occurred before. Jim Hirschauer describes hitting this himself: he had CPU, disk and memory charts he felt good about, and during a major incident realised he could not say what normal looked like without digging back through history.

### [Should you use static thresholds for alerting?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-should-you-use-static-thresholds-for-alerting)

Jim Hirschauer says on DevOps Paradox episode 320 that he dislikes static thresholds in most cases, with disk utilisation as the exception since filling up is genuinely predictable. He implemented dynamic thresholding instead, building bands of normal behaviour and alerting when something moves far enough outside. Crossing that line means pay attention rather than something is broken, and combinations of such signals carry more meaning than any one.

### [Why is it hard to keep executives informed during an incident?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-why-is-it-hard-to-keep-executives-informed-during-an-incident)

Viktor Farcic diagnoses it on DevOps Paradox episode 320 as a language problem. Tools are built for the person who buys them and speak only that role's language, so anyone else has no way to read what they show and comes to ask instead. He once wrote in an incident report that repeated requests for status were the reason resolution took so long.

### [What is the DevOps Paradox podcast?](/episodes/why-dashboards-alone-are-not-enough-for-incident-response-320/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 320 brings in Jim Hirschauer of Xurrent to discuss why incident management looks much as it did twenty years ago, which phases teams neglect, and why a wall of dashboards gives false confidence. Every episode page carries the audio, the video, and a full transcript.

### [What comes after general-purpose AI coding tools?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-what-comes-after-general-purpose-ai-coding-tools)

Viktor Farcic sketches three waves on DevOps Paradox episode 319. The first was fully generic assistants, equally capable at everything and nothing. The second added tools specialised toward software engineering while still handling anything. He expects the third to be narrower still: separate systems that are genuinely better at application development, at infrastructure, at databases, at security, eventually connected into a mesh.

### [What is missing from AI tools for infrastructure?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-what-is-missing-from-ai-tools-for-infrastructure)

Viktor Farcic argues on DevOps Paradox episode 319 that the gap is not public knowledge, which models already have and vendors keep improving. It is private company knowledge, and workflows between a human and an agent. Ask any current tool for a database and it hands you one, where a good consultant would spend a day at a whiteboard first, because you may not know what you need.

### [Is AI overhyped?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-is-ai-overhyped)

Viktor Farcic says on DevOps Paradox episode 319 that it is overhyped and underhyped simultaneously. Expectations are inflated by marketing that presents every weekly model release as changing everything, which he calls silly. At the same time he thinks people have not grasped how much is available to them today, so the understanding of what can actually be obtained lags well behind the promotion.

### [How many people are genuinely proficient with AI tools?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-how-many-people-are-genuinely-proficient-with-ai-tools)

Viktor Farcic puts the number close to zero on DevOps Paradox episode 319, and stresses he does not mean data scientists building models. He means users. Plenty of people describe themselves as proficient because they use an AI editor, but ask whether they understand prompt engineering, have worked with vector or graph databases, or have built their own agents, and the answer is usually no.

### [Do developers still need powerful laptops for AI work?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-do-developers-still-need-powerful-laptops-for-ai-work)

Viktor Farcic says no on DevOps Paradox episode 319 and argues the direction is back toward a dumb terminal accessing services elsewhere. Models make the case for him: what runs on ordinary hardware is fine for trivial tasks and poor at serious ones, compared with what runs as a service. Where the hardware question does return is at the company level, particularly for anyone training their own models.

### [What does an organisation's AI adoption path look like?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-what-does-an-organisations-ai-adoption-path-look-like)

Viktor Farcic lays out a sequence on DevOps Paradox episode 319: start with a public model, an agent and a few MCP servers, which takes you surprisingly far. Security then forces those servers off individual laptops onto shared infrastructure. Custom agents follow. The hard part arrives with them, since a shared agent needs broad permissions while still enforcing what each individual user is allowed to do.

### [What is the DevOps Paradox podcast?](/episodes/ai-powered-infrastructure-beyond-hype-to-reality-319/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 319 is a conversation between the two hosts about AI for infrastructure: what the marketing promises against what works today, the missing workflow layer, and the order in which companies actually adopt it. Every episode page carries the audio, the video, and a full transcript.

### [What does WireMock actually mock?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-what-does-wiremock-actually-mock)

Tom Akehurst clarifies on DevOps Paradox episode 318 that WireMock mocks networked APIs rather than objects. The core library is written in Java, but because the thing being mocked is a network interface, it works with any stack that speaks HTTP, whether REST or SOAP. The open source version can run as a standalone process configured over the network, so callers need not be Java developers.

### [Why mock at the network level instead of using mock objects?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-why-mock-at-the-network-level-instead-of-using-mock-objects)

Tom Akehurst points on DevOps Paradox episode 318 to an old rule among the originators of mock objects: do not mock types you do not own. HTTP clients are a particularly bad fit and produce brittle, misleading tests. Running your service almost exactly as it runs in production, with only the external endpoints redirected, catches configuration errors, serialiser problems and concurrency bugs that object mocking hides.

### [Is an LLM like a junior developer?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-is-an-llm-like-a-junior-developer)

Tom Akehurst rejects the analogy on DevOps Paradox episode 318. The key difference is accumulation: knowledge you give a junior developer builds up until they can work autonomously, while a model needs first-month-on-the-job supervision permanently. Viktor Farcic pushes back that this assumes only one of the two improves, and Akehurst concedes the trajectories differ, with the human fitting themselves to your specific domain.

### [How do you keep an OpenAPI specification accurate?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-how-do-you-keep-an-openapi-specification-accurate)

Tom Akehurst recommends a closed feedback loop on DevOps Paradox episode 318: sample real traffic to and from the API, validate it against the description, and alert people automatically when the two diverge. He expects agents to take the next step by opening pull requests with suggested fixes, turning documentation maintenance into reviewing those rather than someone trawling through the spec field by field.

### [Does AI make API design more consistent?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-does-ai-make-api-design-more-consistent)

Tom Akehurst argues on DevOps Paradox episode 318 that the homogenising effect is welcome here, since a model steers you toward whichever pagination or address structure is most common, which is what consumers already recognise. Viktor Farcic objects that public training data is not a quality signal, and that the most frequently used approach is not necessarily the right one, comparing it to a heavily upvoted but poor answer on a question site.

### [Does AI entrench established tools against new ones?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-does-ai-entrench-established-tools-against-new-ones)

Viktor Farcic draws the distinction on DevOps Paradox episode 318: a search engine still shows a second, third and fourth result, and some people scroll. Ask a model to do something and there is no long tail at all. Tom Akehurst concedes the risk, likening the default behaviour to a search engine's I'm Feeling Lucky button, and says investors he has spoken to rather like the advantage it gives incumbents.

### [What is the DevOps Paradox podcast?](/episodes/wiremock-and-the-changing-landscape-of-api-development-tools-318/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 318 brings in Tom Akehurst, creator of WireMock, to discuss network-level API mocking, keeping specifications honest, and what AI agents are doing to API design and to tool discovery. Every episode page carries the audio, the video, and a full transcript.

### [Why is AI's disruption different from previous technology shifts?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-why-is-ais-disruption-different-from-previous-technology-shifts)

Viktor Farcic argues on DevOps Paradox episode 317 that the difference is breadth rather than depth. His example is European cities blocked by taxi drivers when ride-hailing arrived, a hard change that hit one profession. He expects accountants, lawyers, doctors and others to face their version of that at roughly the same time, which governments and societies have no experience handling.

### [Are junior developer jobs disappearing first?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-are-junior-developer-jobs-disappearing-first)

Viktor Farcic says on DevOps Paradox episode 317 that it is already happening, pointing to record unemployment among recent graduates in the industry. His reasoning is structural: experienced people have always driven new features and architectures while less experienced people implemented them. When the thing implementing under supervision is an agent, the company needs fewer juniors rather than fewer seniors.

### [Why does domain knowledge matter more now?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-why-does-domain-knowledge-matter-more-now)

Viktor Farcic explains on DevOps Paradox episode 317 that whoever instructs an agent needs to know how the company and its industry work, not just how the tool works. A junior who is genuinely skilled with AI still does not know you are a healthcare company or why you do things a particular way. He treats that knowledge as always having been undervalued and now being decisive.

### [Will AI mean less human oversight or more?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-will-ai-mean-less-human-oversight-or-more)

Viktor Farcic predicts more on DevOps Paradox episode 317, because oversight becomes most of the work. Translating a request into instructions an agent can act on, then checking the result, replaces the doing. His comparison is the enterprise pattern of one architect deciding and everyone else implementing, and his expectation is that companies will need considerably more people in the deciding role.

### [Was being proud of writing code always misplaced?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-was-being-proud-of-writing-code-always-misplaced)

Viktor Farcic thinks so, and says on DevOps Paradox episode 317: "I think that it was always wrong to be proud to be a code monkey". His argument is that typing was never where the value sat. Knowing what to do, when, how and why was the value, and typing was simply work that had to be done. AI makes the distinction visible rather than creating it.

### [What happens to developers who refuse to use AI?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-what-happens-to-developers-who-refuse-to-use-ai)

Viktor Farcic's answer on DevOps Paradox episode 317 is that you had better work somewhere that shares your view, since otherwise colleagues become more productive and someone eventually asks why you are there. He accepts that artisanal work survives, comparing it to hand-assembled cars and Swiss watches, while noting those are a fraction of a percent of what gets produced.

### [What is the DevOps Paradox podcast?](/episodes/the-human-cost-of-ai-automation-in-devops-317/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 317 is a conversation between the two hosts about the human side of AI adoption: which roles are affected first, why domain knowledge becomes decisive, and what happens to people who opt out. Every episode page carries the audio, the video, and a full transcript.

### [Is Tailscale a VPN?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-is-tailscale-a-vpn)

Avery Pennarun calls that a great terrible way of putting it on DevOps Paradox episode 316, then separates two things sharing the name. The original VPN gave remote access to a private network you already had. What most people now mean is a service routing public traffic out through someone else's link, which he suggests is closer to a virtual public network. Tailscale is the first kind.

### [Why does Tailscale add a layer in the middle rather than on top?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-why-does-tailscale-add-a-layer-in-the-middle-rather-than-on-top)

Avery Pennarun explains on DevOps Paradox episode 316 that the early internet let any device reach any device directly, and address exhaustion, firewalls and network translation broke that. Devices now talk to the cloud rather than to each other, which he compares to terminals and a mainframe. Tailscale inserts one layer at the internet layer so connections work again, stripping away decades of workarounds built for a network that stopped working.

### [Why does Tailscale support every version it has ever released?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-why-does-tailscale-support-every-version-it-has-ever-released)

Avery Pennarun says on DevOps Paradox episode 316 that the promise dates from the company's founding, and covers roughly 89 builds per version across Linux distributions, phones, streaming boxes, routers, drones and embedded systems. His reasoning is operational: a device may sit powered off for three years and be switched on in an emergency, and requiring an update before it can reach the network defeats the point.

### [Why does software keep breaking underneath us?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-why-does-software-keep-breaking-underneath-us)

Avery Pennarun argues on DevOps Paradox episode 316 that the industry lost its way when "we started believing that it's better and easier to constantly shift the platform underneath us and then constantly run to keep up with the constantly shifting platform underneath us." He points at security as the excuse: you cannot skip a patch, the patch breaks things, and everything downstream must move. He asks what changes if fixes simply do not break things.

### [Does a smaller network change your security requirements?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-does-a-smaller-network-change-your-security-requirements)

Avery Pennarun makes the case on DevOps Paradox episode 316 with a database he built for a computer store as a teenager, which he describes as riddled with holes that did not matter because it was not on the internet. Exposure to billions of people means even a vanishingly small fraction of attackers is a real one. Restrict access to the ten people who need it and the calculation changes entirely.

### [Do you have to trust Tailscale itself?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-do-you-have-to-trust-tailscale-itself)

Avery Pennarun addresses this directly on DevOps Paradox episode 316. Each node generates its own key pair and the private key never leaves the device, so the company cannot decrypt traffic. The residual risk is being able to add a device to your network, which a feature called tailnet lock removes by requiring you to sign keys yourself. The clients are open source, and a self-hosted control plane exists.

### [What is the DevOps Paradox podcast?](/episodes/bringing-back-the-original-internet-vision-using-tailscale-316/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 316 brings in Avery Pennarun of Tailscale to discuss what a VPN originally meant, why direct device-to-device connectivity stopped working, and how far a small trust boundary goes toward solving security. Every episode page carries the audio, the video, and a full transcript.

### [Why does running a simple command in an AI agent cost tokens?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-why-does-running-a-simple-command-in-an-ai-agent-cost-tokens)

Viktor Farcic reframes the complaint on DevOps Paradox episode 315 after Darin Pope typed a directory listing into Claude Code and watched it think. Nobody lists files for its own sake; you do it to find where a function lives. Ask that instead. The tokens are well spent when the request describes what you are trying to accomplish rather than the mechanical step you would have taken yourself.

### [Should you let the agent run your tests?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-should-you-let-the-agent-run-your-tests)

Viktor Farcic argues yes on DevOps Paradox episode 315. You run tests because you changed code and something might fail, and if it does you will paste the output back anyway, spending the same tokens plus your own time. The agent wrote the code and the tests, so letting it run them and fix what it got wrong closes the loop. Nobody enjoys writing tests, which makes them an obvious candidate.

### [What does a CLAUDE.md file do?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-what-does-a-claudemd-file-do)

Viktor Farcic explains on DevOps Paradox episode 315 that initialising a project makes the agent walk the codebase and write down what matters, after which you add what it did not discover, such as always practising test-driven development. It then stops rediscovering the same facts each session. When Darin Pope objects to committing files to repositories he does not own, Farcic points at gitignore.

### [Do you need MCP servers to work with a coding agent?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-do-you-need-mcp-servers-to-work-with-a-coding-agent)

Viktor Farcic says mostly not on DevOps Paradox episode 315. He uses a memory server and a task server, and concedes the agent already has memory and already keeps a to-do list internally. Nothing about MCP is transformative if you already have command line tools for what you need, because the agent can reach those directly. They make things slightly better rather than possible.

### [Do developers actually want to write code?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-do-developers-actually-want-to-write-code)

Viktor Farcic says on DevOps Paradox episode 315, warning it makes people angry: "I think that good coders are not people who spend majority of their time writing code." He describes typing as a chore and design as the part he enjoys. His analogy is authorship, where the job is working out the story, the details and the flow rather than putting the words on the page.

### [Does working with AI agents mean going back to waterfall?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-does-working-with-ai-agents-mean-going-back-to-waterfall)

Viktor Farcic says the opposite on DevOps Paradox episode 315. He is several iterations into a project, having built something, decided it was wrong, and started over. Nobody produces a complete design before writing code, and anyone claiming otherwise is either lying or accepting failure later. What changes is speed: a week of iteration compresses into about two days, so design emerges faster.

### [What is the DevOps Paradox podcast?](/episodes/why-good-developers-spend-more-time-designing-than-coding-315/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 315 is a conversation between the two hosts about working with coding agents in practice, covering what to ask for, what to configure, and why the valuable part of development was never the typing. Every episode page carries the audio, the video, and a full transcript.

### [How do you get your first speaking slot?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-how-do-you-get-your-first-speaking-slot)

Geoffrey Huck recommends a Toastmasters club on DevOps Paradox episode 314, or failing that, asking a meetup organiser for two minutes to practise. Viktor Farcic adds a reason to prefer meetups in this industry: they are more numerous than Toastmasters clubs, you can help out until you find the courage, and the audience already cares about your subject rather than being a general mix of professions.

### [What does it mean when your conference talk is rejected?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-what-does-it-mean-when-your-conference-talk-is-rejected)

Geoffrey Huck reframes it on DevOps Paradox episode 314 as a rejection of the idea rather than the person. The organiser read an abstract and a title and judged that the audience would be less interested than in the other options available, at that moment and in that context. He treats the distinction as practical rather than consoling, since the response is to change the pitch.

### [How many slides should a conference talk have?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-how-many-slides-should-a-conference-talk-have)

Geoffrey Huck's answer on DevOps Paradox episode 314, after Darin Pope deliberately describes the worst possible deck, is to do the opposite of all of it: "You don't want people to look at your slides." The moment attention moves to the screen you have lost the room and may not get it back. A week later nobody remembers a slide, only three or four key ideas.

### [Does speaking often make you a better speaker?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-does-speaking-often-make-you-a-better-speaker)

Geoffrey Huck says on DevOps Paradox episode 314 that doing it is necessary and nowhere near sufficient, pointing at teachers who speak for hours daily for years and remain boring. Improvement requires stretching: if you stand behind the microphone in a flat voice, you can repeat that indefinitely without changing. His rule is to do the things that feel frightening, since fear marks the edge of your current range.

### [What should you do if you freeze on stage?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-what-should-you-do-if-you-freeze-on-stage)

Geoffrey Huck advises on DevOps Paradox episode 314 that you describe what is happening. Tell the audience you were afraid of forgetting your talk and that it has just happened, then ask whether anyone can remember what you said a minute ago. Everyone knows it is frightening, so nobody holds it against you, and narrating the moment slows your thinking down and builds a connection.

### [Can an introvert learn to start conversations at events?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-can-an-introvert-learn-to-start-conversations-at-events)

Geoffrey Huck describes it as a muscle on DevOps Paradox episode 314. Initiate three conversations in a row at one event: the first is very hard, the second hard, the third slightly hard, and then something shifts and you want to talk to everyone. He says the outgoing people he meets at networking events almost always tell him they consider themselves introverts who found that switch.

### [What is the DevOps Paradox podcast?](/episodes/building-your-speaking-career-from-meetups-to-main-stage-314/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 314 brings in Geoffrey Huck, a software engineer turned speaking coach, to cover getting a first slot, reading a rejection correctly, what slides are for, and how to keep improving. Every episode page carries the audio, the video, and a full transcript.

### [How do Cursor and Claude Code compare for refactoring work?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-how-do-cursor-and-claude-code-compare-for-refactoring-work)

Darin Pope ran the same questions through both on DevOps Paradox episode 313, against Jenkins plugins he helps maintain. Both found the significant problem immediately and both needed nudging toward the right fix. Claude Code surfaced a few extra items, which he attributes to the model behind it. Viktor Farcic points out Cursor's default setting picks the model for you and leans heavily toward the cheapest option.

### [Should you point an AI coding tool at your employer's code?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-should-you-point-an-ai-coding-tool-at-your-employers-code)

Darin Pope is emphatic on DevOps Paradox episode 313 that you get approval first, because the code leaves your machine. He does none of this against proprietary work. His suggestion for anyone wanting to learn without that constraint is open source, where a public repository has almost certainly been ingested already, so there is nothing left to leak and no compliance conversation to have.

### [Why write a detailed pull request description if AI generated the code?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-why-write-a-detailed-pull-request-description-if-ai-generated-the-code)

Viktor Farcic gives a second reason on DevOps Paradox episode 313 beyond helping the human reviewer. Start a fresh session weeks later with no memory of the work, point the agent at an issue in that pull request, and the description tells it exactly what was going on. He suggests generating those descriptions regardless of whether a person or an agent opened the request.

### [Do AI coding agents agree with you too easily?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-do-ai-coding-agents-agree-with-you-too-easily)

Viktor Farcic suggests a test on DevOps Paradox episode 313: tell the agent something obviously wrong, such as rewriting the whole plugin in a different language being a five minute job, and watch it agree that you are correct. Darin Pope had already noticed the pattern, describing how it thanked him for corrections it should have caught itself on a null check and a missing final.

### [Should you record AI findings as issues when working alone?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-should-you-record-ai-findings-as-issues-when-working-alone)

Viktor Farcic answers with a question on DevOps Paradox episode 313: without AI, having found six performance problems yourself, what would you do? Darin Pope concedes he would write them down somewhere, which makes the answer the same either way. The cost of not doing it landed immediately, when exiting the session lost the context and re-asking produced a different list.

### [What should you let a coding agent do without asking?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-what-should-you-let-a-coding-agent-do-without-asking)

Viktor Farcic's rule on DevOps Paradox episode 313 is to approve anything exploratory for the whole project, such as listing files or reading cluster state, and to review every change. Darin Pope found the interruption useful for a different reason: pausing on each edit gave him time to notice one he wanted to revisit, where a batch of five arriving at once would have hidden it.

### [What is the DevOps Paradox podcast?](/episodes/harnessing-ai-for-smarter-development-313/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 313 follows Darin Pope's first day with Cursor and Claude Code on real open source code, covering what each found, what needed correcting, and which habits carry over from working without them. Every episode page carries the audio, the video, and a full transcript.

### [Why could VMware raise prices so sharply after the acquisition?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-why-could-vmware-raise-prices-so-sharply-after-the-acquisition)

Viktor Farcic frames it on DevOps Paradox episode 312 as a question of switching cost rather than need. Some technologies are easy to replace, some are hard, and some represent years or decades of investment in something very specific. VMware sits in the last group. Kevin Jackson agrees that virtualisation is ingrained in how a generation of administrators works, which is exactly what gives the pricing power.

### [What is KubeVirt and where does it sit?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-what-is-kubevirt-and-where-does-it-sit)

Kevin Jackson describes it on DevOps Paradox episode 312 as a third platform that blurs the line between applications and hardware. VMware and OpenStack are the comparable pair at the infrastructure layer, with Kubernetes running above them. KubeVirt lets teams manage virtual machines through the same control plane and the same processes they already use for applications, rather than through a separate stack.

### [What is the first step in moving off VMware?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-what-is-the-first-step-in-moving-off-vmware)

Kevin Jackson says research on DevOps Paradox episode 312, and specifically understanding how the existing environment is used. If your infrastructure owners have no visibility into which applications run there, the effort is larger regardless of the destination. He warns against picking KubeVirt without engineers who already know Kubernetes, and suggests partners or commercially supported platforms for organisations unwilling to do that work.

### [Should KubeVirt be your first experience of Kubernetes?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-should-kubevirt-be-your-first-experience-of-kubernetes)

Kevin Jackson allows it on DevOps Paradox episode 312, calling KubeVirt a gateway to the wider ecosystem once teams see what else the platform can do. Viktor Farcic disagrees: almost every company already runs something modern that would be an easier first Kubernetes project. Jackson's counter is time, since a contract renewal does not leave room to explore Kubernetes at your leisure.

### [What do teams forget to plan for in a VMware migration?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-what-do-teams-forget-to-plan-for-in-a-vmware-migration)

Kevin Jackson points at the ecosystem on DevOps Paradox episode 312: monitoring, alerting and integrated services that worked out of the box will not simply carry over. He also names people, since engineers unwilling to retrain leave, taking years of company knowledge rather than platform knowledge. His counterpoint is that a migration is the rare opportunity to replace legacy tooling nobody could justify touching before.

### [Can you migrate off VMware without buying new hardware or taking downtime?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-can-you-migrate-off-vmware-without-buying-new-hardware-or-taking-downtime)

Kevin Jackson describes the approach on DevOps Paradox episode 312 as capacity management. Consolidate existing workloads onto fewer hypervisors, free up physical machines, build the new platform on those, test workloads there, then move more across and repeat, expanding the new cluster as the old one shrinks. Darin Pope compares it to a sliding puzzle with one empty square.

### [What is the DevOps Paradox podcast?](/episodes/transitioning-from-vmware-to-kubevirt-312/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 312 brings in Kevin Jackson, director of product management at Trilio, to discuss moving from VMware to KubeVirt or OpenStack, what the migration actually costs, and what teams overlook. Every episode page carries the audio, the video, and a full transcript.

### [What problem does Task Master solve?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-what-problem-does-task-master-solve)

Viktor Farcic explains on DevOps Paradox episode 311 that it turns a conversation about a feature into a detailed requirements document, then breaks that into tasks and subtasks with dependencies between them. The agent asks which to work on next and updates the record as each completes. He describes the result as a very detailed ongoing design document, and the one server he uses on every project.

### [Why does an agent's context window run out so quickly?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-why-does-an-agents-context-window-run-out-so-quickly)

Viktor Farcic says on DevOps Paradox episode 311 that he rarely gets past fifteen minutes of work, or half an hour at best, before the context starts compacting and information is lost. Models have no memory of their own. That is the constraint structured task tracking exists to work around, because a project of any size will exceed the window inside the first subtask.

### [What is a memory MCP server for?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-what-is-a-memory-mcp-server-for)

Viktor Farcic contrasts it with CLAUDE.md on DevOps Paradox episode 311: the file works, but is specific to one agent, so switching tools means translating it. A memory server is agent-agnostic, and he loads it as his first instruction in a session. It grows as he corrects behaviour, adding rules like practising test-driven development or preferring a particular test framework, since nobody can write all the rules up front.

### [Does AI change which programming language you should pick?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-does-ai-change-which-programming-language-you-should-pick)

Viktor Farcic says it changed his on DevOps Paradox episode 311. He abandoned a scripting language he considers far better than shell because models handle it poorly, and accepted shell instead since it works on the first attempt. His justification is that he is mostly reading rather than writing now, and everyone reads more languages competently than they can write quickly.

### [Is an AI coding subscription worth the money?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-is-an-ai-coding-subscription-worth-the-money)

Viktor Farcic sets a deliberately low bar on DevOps Paradox episode 311. Forget claims of being ten times faster; assume a person saves one or two days a month, which is a ten percent productivity change. At company level that already justifies the cost. Darin Pope works the same arithmetic per day and lands on roughly the price of lunch.

### [Why do people give up on AI coding tools after a day?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-why-do-people-give-up-on-ai-coding-tools-after-a-day)

Viktor Farcic hears this constantly on DevOps Paradox episode 311, with people reporting after a day or two that the tool is bad and they are slower. His explanation is unglamorous: "it takes time until you get used to any tool", as with any editor or language. His advice to anyone starting is to commit for at least a month before judging.

### [What is the DevOps Paradox podcast?](/episodes/harnessing-ai-for-accelerated-project-development-311/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 311 is a conversation between the two hosts about Viktor Farcic's working setup, covering which MCP servers earn their place, how to work around a context window, and what changes about language choice. Every episode page carries the audio, the video, and a full transcript.

### [Should DevOps be a job title?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-should-devops-be-a-job-title)

Tim Beattie answers no on DevOps Paradox episode 310. Agile and DevOps are philosophies meant to bring silos down, so a DevOps engineer or a DevOps team creates exactly the thing they were supposed to remove: a pocket where DevOps lives and where every question about it gets sent. He accepts coach as a title, and treats those roles on a job listing as a warning sign.

### [Why was there never a waterfall coach?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-why-was-there-never-a-waterfall-coach)

Tim Beattie points out on DevOps Paradox episode 310 that waterfall had its own bodies, certifications and tooling, but it is methodical and top down, closer to following a recipe. Agile and DevOps instead try to produce self-organising and self-correcting teams, which needs facilitation. Viktor Farcic adds that waterfall never contradicted how managers already managed anything else, so it required no conversion.

### [Should teams follow Agile frameworks exactly?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-should-teams-follow-agile-frameworks-exactly)

Tim Beattie describes frameworks on DevOps Paradox episode 310 as guardrails: worth following closely for a month or two with an immature team, because there is good thinking in them. The sign of a maturing team is when it starts asking why a retrospective waits two weeks, or why a finished feature waits for the end of a sprint. Viktor Farcic argues that following a method to the letter contradicts the point of it.

### [What is the definition of done?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-what-is-the-definition-of-done)

Viktor Farcic says on DevOps Paradox episode 310 that in years of asking teams, he never once heard the answer he wanted: running in production successfully. Tim Beattie goes further and adds being used and adopted. Farcic's criticism of Agile in practice is that teams declared victory at the last commit while forgetting deployment, operation and observation existed at all.

### [Is DevSecOps a useful term?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-is-devsecops-a-useful-term)

Both guests on DevOps Paradox episode 310 dismiss it. Tim Beattie wrote a post objecting to the escalating variants and took criticism for it, arguing the philosophy already covers everything between having users and those users getting value. Viktor Farcic is blunter: if security matters, security is part of the chain already, and naming it separately produces one more silo rather than one fewer.

### [Does a rigid process make safety-critical software safer?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-does-a-rigid-process-make-safety-critical-software-safer)

Tim Beattie reframes the question on DevOps Paradox episode 310. Looking at the disasters he has studied, the failure was a lack of safety at team and individual level: the people building the technology could see the problems and had no standing to challenge, say no, or ask for time. Top-down pressure and a rigid plan removed that, and the missing safety ended up in the product.

### [What is the DevOps Paradox podcast?](/episodes/the-misconceptions-and-realities-of-devops-agile-and-leadership-310/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 310 brings in Tim Beattie of Stellify, previously global head of product for Red Hat Open Innovation Labs, to argue about job titles, framework orthodoxy, what done means, and where safety actually comes from. Every episode page carries the audio, the video, and a full transcript.

### [What changed Viktor Farcic's mind about AI coding tools?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-what-changed-viktor-farcics-mind-about-ai-coding-tools)

He explains on DevOps Paradox episode 309 that it was not the claims of being ten times faster, which he calls something that never matched the real world. Working on an existing application with real constraints, he used to spend more time with AI than without. The moment it turned was reaching five or ten percent faster, which is the same bar he applies to adopting anything.

### [What is the difference between a model, an agent and an MCP server?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-what-is-the-difference-between-a-model-an-agent-and-an-mcp-server)

Viktor Farcic uses an anatomy analogy on DevOps Paradox episode 309. The model is the brain, holding information and answering questions. The agent is the arms and legs: it reads files, runs commands, fetches issues, and assembles the context it sends to the model. MCP is a protocol designed as an interface for agents to reach services, which he summarises as an API built for agents rather than people.

### [Does the agent matter as much as the model?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-does-the-agent-matter-as-much-as-the-model)

Viktor Farcic argues it does on DevOps Paradox episode 309, and offers his own experience as evidence: running the same model behind two different agents gave noticeably different quality. He also notes the economics differ. A tool billing tokens passes everything through, while a fixed subscription has every incentive to compact the context before sending it, which changes what the model sees.

### [Why can't you connect unlimited MCP servers to an agent?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-why-cant-you-connect-unlimited-mcp-servers-to-an-agent)

Viktor Farcic explains on DevOps Paradox episode 309 that every server's tools and descriptions load at startup and stay in memory, so agents start struggling somewhere between forty and a hundred tools. It is not a hard number, since it depends on how much each server contributes. Memory here is context, and he identifies context management as the underlying challenge rather than machine resources.

### [Should you use an MCP server when a command line tool already exists?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-should-you-use-an-mcp-server-when-a-command-line-tool-already-exists)

Viktor Farcic says no on DevOps Paradox episode 309, using the GitHub server as his example. Agents handle the GitHub CLI well, so when he approaches the tool limit that server is the first he removes. Where MCP earns its place is destinations with no convenient command line equivalent, where an agent would otherwise be reduced to assembling API calls from documentation.

### [Does AI make it easier to throw work away and start over?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-does-ai-make-it-easier-to-throw-work-away-and-start-over)

Viktor Farcic says yes, from experience on DevOps Paradox episode 309, describing his third restart on a project. A month of work is something almost nobody discards, but two or three days is. He adds a step that matters more than the deletion: have the agent document the current design, the conversations and the lessons learned first, then delete the code and begin again with that context.

### [What is the DevOps Paradox podcast?](/episodes/using-ai-agents-in-daily-development-tasks-309/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 309 is a conversation between the two hosts working through what changed in AI tooling over four months, covering models against agents against MCP servers, and why sunk cost is easier to walk away from now. Every episode page carries the audio, the video, and a full transcript.

### [Does having automation mean you are doing CI/CD?](/episodes/the-truth-of-ci-cd-308/index.md#faq-does-having-automation-mean-you-are-doing-cicd)

Ricardo Castro says no on DevOps Paradox episode 308, and that this is the core of his argument. Building and deploying in an automated way does not make it continuous integration. He accepts the converse, that CI does not scale without automation. Viktor Farcic extends the same reasoning to architecture: having multiple deployable applications does not make them microservices if releasing one requires changing another.

### [What is continuous integration actually?](/episodes/the-truth-of-ci-cd-308/index.md#faq-what-is-continuous-integration-actually)

Ricardo Castro defines it on DevOps Paradox episode 308 as integrating your work with the rest of the code base often, at least daily, keeping it in a releasable state. The reason is arithmetic: "you do this so often and so repeatedly that when you have integrations problems, they are small". Someone who disappears for a month and then merges is doing integration, but not continuously.

### [Can you do CI without CD?](/episodes/the-truth-of-ci-cd-308/index.md#faq-can-you-do-ci-without-cd)

Viktor Farcic argues on DevOps Paradox episode 308 that a team claiming CI without CD is probably not doing CI either. If you are afraid of what happens when you deploy, the outputs of your CI are not reliable. Ricardo Castro agrees and adds the missing ingredient is trust, in the testing and in the ability to roll back quickly if something goes wrong.

### [Where does CI end and CD begin?](/episodes/the-truth-of-ci-cd-308/index.md#faq-where-does-ci-end-and-cd-begin)

Darin Pope puts the boundary at the artifact on DevOps Paradox episode 308: the output of CI is a versioned artifact and the input to CD is that same artifact, with a repository in between. Ricardo Castro agrees while noting the line stays blurry, since producing an artifact does not make it shippable, and the testing that determines shippability happens after the build.

### [Can a deployment batch be too small?](/episodes/the-truth-of-ci-cd-308/index.md#faq-can-a-deployment-batch-be-too-small)

Ricardo Castro offers one caveat on DevOps Paradox episode 308: committing one or two lines to satisfy a daily target tends to surround them with defensive code and feature flags to guarantee nothing activates. Viktor Farcic treats the queueing problem Darin Pope raises as solved by deploying whatever is at the head of the main line, and thinks a pipeline iterating too quickly is a problem nobody has ever complained about.

### [Why should a company contribute to open source?](/episodes/the-truth-of-ci-cd-308/index.md#faq-why-should-a-company-contribute-to-open-source)

Viktor Farcic argues on DevOps Paradox episode 308 that companies should be selfish about it rather than framing it as the right thing to do. You fix the vulnerability because you need it fixed, and contributing is cheaper than abandoning the project over one missing feature. Ricardo Castro says that is already how most companies behave, and that giving back is the by-product everyone benefits from.

### [What is the DevOps Paradox podcast?](/episodes/the-truth-of-ci-cd-308/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 308 brings in Ricardo Castro to argue that automation is not continuous integration, work out where CI ends and CD begins, and question whether a team doing one without the other is doing either. Every episode page carries the audio, the video, and a full transcript.

### [Should developers be given direct access to Kubernetes?](/episodes/kubernetes-in-2025-307/index.md#faq-should-developers-be-given-direct-access-to-kubernetes)

Viktor Farcic is emphatic on DevOps Paradox episode 307: "Nobody should give developers Kubernetes as is". Handing over a kubeconfig makes their work harder rather than more productive. Kubernetes is the base you build a platform on, or the thing you skip in favour of a service that already did it. It took him years to master, and he does not expect everyone else to stop what they are doing and match that.

### [Do developers want managed Kubernetes?](/episodes/kubernetes-in-2025-307/index.md#faq-do-developers-want-managed-kubernetes)

Viktor Farcic argues on DevOps Paradox episode 307 that they want not to see Kubernetes at all, and that whether the cluster is managed makes no difference to them. His benchmark is the deployment experience Heroku set nearly two decades ago: supply the information that matters, get the result you expect. His analogy for the right outcome is the hypervisor, which most people neither see nor can name.

### [Is it cost optimization or resource optimization?](/episodes/kubernetes-in-2025-307/index.md#faq-is-it-cost-optimization-or-resource-optimization)

Viktor Farcic objects to the usual name on DevOps Paradox episode 307. What teams actually do is work out how much memory and CPU a workload needs and adjust to match, which is resource optimisation. Lower cost is a side effect and is not guaranteed, since the correct answer might be more. He acknowledges why the other name persists: nobody buys resource optimisation, and everybody buys cost reduction.

### [Why consolidate Kubernetes clusters?](/episodes/kubernetes-in-2025-307/index.md#faq-why-consolidate-kubernetes-clusters)

Viktor Farcic gives two reasons on DevOps Paradox episode 307. Each cluster needs its own control plane nodes, so a hundred clusters means hundreds of nodes running nothing of yours. Larger nodes in fewer clusters also let schedulers pack workloads more efficiently. He adds a cause for the sprawl: handing a team a fresh cluster feels safer than trusting isolation within an existing one, which is fear rather than design.

### [Is multi-cloud worth pursuing?](/episodes/kubernetes-in-2025-307/index.md#faq-is-multi-cloud-worth-pursuing)

Viktor Farcic expects that ambition to fade on DevOps Paradox episode 307, on the grounds that running across several providers is expensive on many levels and rarely justified as a design choice. He distinguishes it from hybrid, where on-premises plus cloud has real reasons: existing hardware, cloud for peak load, or one service a provider genuinely does better. Multi-cloud usually arrives through acquisition rather than intention.

### [What should AI actually do for operations?](/episodes/kubernetes-in-2025-307/index.md#faq-what-should-ai-actually-do-for-operations)

Viktor Farcic sets a higher bar than anomaly detection on DevOps Paradox episode 307. Asking what is wrong with your pods is useful but not the goal. He wants something that learns from what he did: having watched him restart a particular pod five times, it should handle the sixth and only call him when the outcome differs, the same expectation he would have of an intern.

### [What is the DevOps Paradox podcast?](/episodes/kubernetes-in-2025-307/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 307 works through a set of published Kubernetes predictions for 2025, agreeing with some and taking apart others on developer experience, cluster consolidation, multi-cloud and what to call resource optimisation. Every episode page carries the audio, the video, and a full transcript.

### [When is GraphQL the right choice?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-when-is-graphql-the-right-choice)

Sophia Willows makes the case on DevOps Paradox episode 306 for APIs shipped to external developers. At the start of such a project you cannot know which access patterns customers will invent, and curating response bodies in advance means guessing. You would have to define a schema and strong typing whatever technology you picked, and "GraphQL comes with all the stuff out of the box" rather than assembled from separate packages.

### [When should you not use GraphQL?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-when-should-you-not-use-graphql)

Sophia Willows says on DevOps Paradox episode 306 that her company deliberately does not use it between internal services, preferring REST and gRPC. Parsing query documents and running a heavy type system buys little when you own both ends and know exactly what each side needs. Avoiding request waterfalls also matters far less between services a millisecond apart than for a caller on the other side of the world.

### [What is the most common mistake with GraphQL?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-what-is-the-most-common-mistake-with-graphql)

Sophia Willows names mirroring your database schema one to one on DevOps Paradox episode 306, which several libraries make trivially easy and which she calls almost always an anti-pattern. Design around use cases instead. Rather than exposing a list of identifiers so consumers can check membership themselves, put a field on the type that answers the question, since consumers only pay for the fields they request.

### [Why does a specification matter more than flexibility?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-why-does-a-specification-matter-more-than-flexibility)

Sophia Willows argues on DevOps Paradox episode 306 that every REST API ends up a snowflake. People differ on status codes, on verbs, on whether the design is resource-oriented, and on what an error object contains. GraphQL removes whole categories of that argument: HTTP verbs do not exist in it, so nobody debates whether an operation should be a PUT or a POST, and errors are described by the specification.

### [How do GraphQL, REST and gRPC compare?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-how-do-graphql-rest-and-grpc-compare)

Darin Pope proposes a spectrum on DevOps Paradox episode 306 and Sophia Willows agrees with it: gRPC at one end optimising for performance, plain HTTP in the middle, and GraphQL at the other end optimising for consumer flexibility. The trade-off is that both ends carry real complexity, so the middle keeps working in either direction at the cost of being a compromise.

### [Is gRPC overused?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-is-grpc-overused)

Sophia Willows suggests so on DevOps Paradox episode 306, while noting gRPC has far fewer traps than GraphQL. It is more complicated than making HTTP requests between services and harder to debug, since a binary protocol does not appear as legibly in traces. Most systems reaching for it are not operating at a scale where they need that performance and would be fine with HTTP.

### [What is the DevOps Paradox podcast?](/episodes/understanding-graphql-s-role-in-modern-apis-306/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 306 brings in Sophia Willows of Rye to defend GraphQL against two sceptical hosts, marking out where it belongs, where it does not, and what people get wrong when adopting it. Every episode page carries the audio, the video, and a full transcript.

### [Should a new graduate work in an office or remotely?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-should-a-new-graduate-work-in-an-office-or-remotely)

Both hosts answer office without hesitation on DevOps Paradox episode 304, despite neither wanting to go themselves. Viktor Farcic's reasoning is that "learning from others is so much easier and faster when you are directly connected with people face to face". Darin Pope adds the condition that it only helps if colleagues are there too, since an office full of people on video calls offers nothing remote work does not.

### [Is return to office really about the office?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-is-return-to-office-really-about-the-office)

Viktor Farcic argues on DevOps Paradox episode 304 that the real subject is relocation. Technology jobs concentrated in a handful of cities, most people working there moved for the job rather than being from there, and the pandemic sent many of them home. The objection is rarely the commute. It is uprooting a spouse, a school and a house, which is why the answer is usually no.

### [What is a competitive salary at a fully remote company?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-what-is-a-competitive-salary-at-a-fully-remote-company)

Viktor Farcic poses the problem without solving it on DevOps Paradox episode 304. Is the rate for the role, or for the role in a particular city or country? A fully remote employer choosing between equally qualified candidates in expensive and cheap locations faces an equaliser, ending up above the local rate in some places and below it in others, and risking losing exactly the people it wanted to keep.

### [Why do niche skills command higher salaries?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-why-do-niche-skills-command-higher-salaries)

Viktor Farcic reduces it to pool size on DevOps Paradox episode 304. Millions of people can run things in containers, so that commands little. Fewer know Kubernetes, so the rate rises. Narrow further toward whatever is current and the pool shrinks again, which is why companies closest to the front of a wave must be prepared to pay the most for the smallest number of candidates.

### [Is a training budget still a retention perk?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-is-a-training-budget-still-a-retention-perk)

Viktor Farcic is sceptical on DevOps Paradox episode 304, noting the training is online now and nobody relocates for a week of it. He also points at shelf life: a certification once lasted most of a career, and now needs renewing every year or two even when the subject has not changed. He attributes that partly to genuine change and partly to renewal being profitable.

### [Should a company mandate the same office policy for everyone?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-should-a-company-mandate-the-same-office-policy-for-everyone)

Viktor Farcic calls blanket decisions in either direction the mistake on DevOps Paradox episode 304. Juniors should be in an office because that is the fastest way to learn. Teams whose work is brainstorming benefit from a room, which is why offsites exist. Execution work does not, and he argues he does more hours from home precisely because he can distribute them around the rest of his life.

### [What is the DevOps Paradox podcast?](/episodes/strategies-for-successful-talent-retention-304/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 304 is a conversation between the two hosts about retaining people, covering return to office as a relocation question, what competitive pay means without a location, and whether training budgets still matter. Every episode page carries the audio, the video, and a full transcript.

### [Why does distribution matter so much for a CLI?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-why-does-distribution-matter-so-much-for-a-cli)

Wesley Beary puts it high on the list on DevOps Paradox episode 303, drawing on having shipped a CLI in Ruby where users had to install a language runtime first. Viktor Farcic says installation instructions beginning with a package manager make him stop reading. Beary agrees the trouble compounds: fine for one tool, and a dependency nightmare as soon as two of them want different versions.

### [How do you test a terminal user interface?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-how-do-you-test-a-terminal-user-interface)

Wesley Beary found almost no examples with test coverage on DevOps Paradox episode 303, including in the framework's own repositories. The approach that worked was golden files, recording output and comparing future runs against it. Transient elements such as spinners produced race conditions and flaky tests, so his team now writes every frame like a flip book, accepting redundancy in exchange for consistency.

### [What should a CLI do when you are not signed in?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-what-should-a-cli-do-when-you-are-not-signed-in)

Wesley Beary argues on DevOps Paradox episode 303 that crashing and telling the user to do it right next time is the convention rather than good design. If the tool knows you are not authenticated and knows how to authenticate you, it should do that and then continue with the command you originally ran. The same applies to a missing argument, where it can offer a selection list instead.

### [How do you iterate cheaply on an API and its CLI?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-how-do-you-iterate-cheaply-on-an-api-and-its-cli)

Wesley Beary describes a spec-first approach on DevOps Paradox episode 303. Add the operation to the OpenAPI document, run a mock server generated from that spec, and build the CLI against the mock. Changing a few lines of YAML is far cheaper than changing an implementation and its tests. Once the contract is agreed, the CLI and the API can be built in parallel by different people.

### [Should a CLI do everything the web interface does?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-should-a-cli-do-everything-the-web-interface-does)

Wesley Beary says no on DevOps Paradox episode 303, describing an internal debate about account signup that ended with sending people to the browser, which handles federated login without inventing a novel flow. His rule is that there should always be a way to do something, but not necessarily the same way, and that a command can point you at the right URL rather than leaving you to hunt.

### [How do you get better at designing command line tools?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-how-do-you-get-better-at-designing-command-line-tools)

Wesley Beary recommends becoming a connoisseur on DevOps Paradox episode 303. Use other tools, work out what you like and what frustrates you, and form opinions about why. That matters because you rarely get many attempts at an interface, and because intuition alone does not survive a colleague proposing something worse. Having to explain why a pattern tastes bad is what turns preference into an argument.

### [What is the DevOps Paradox podcast?](/episodes/how-to-develop-a-cli-in-2025-303/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 303 brings in Wesley Beary of Anchor, previously of Heroku, to discuss building a command line tool: distribution, testing terminal interfaces, spec-first API design, and what a CLI should do rather than what CLIs usually do. Every episode page carries the audio, the video, and a full transcript.

### [Is objecting to AI coding assistance consistent?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-is-objecting-to-ai-coding-assistance-consistent)

Viktor Farcic argues it is not on DevOps Paradox episode 302. A search engine finds the closest match among indexed solutions, usually surfacing an answer from a question site, which may be wrong and which you may break your code by pasting. Swap the name and the description is identical. On that reading, refusing AI help while accepting search and Stack Overflow is holding two positions at once.

### [What is the real difference between AI help and searching the web?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-what-is-the-real-difference-between-ai-help-and-searching-the-web)

Viktor Farcic identifies privacy on DevOps Paradox episode 302. Asking a model about your code means a round trip, and there is no guarantee the code does not travel with the request, where nobody was pasting company secrets into a search box. He treats that as a question of which AI rather than whether: a provider you already trust, or a model you host yourself.

### [Will AI reduce the number of engineers companies need?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-will-ai-reduce-the-number-of-engineers-companies-need)

Viktor Farcic is sceptical on DevOps Paradox episode 302, pointing out the same prediction accompanied drag-and-drop tools, higher-level languages and the move to cloud, and each time hiring grew. The assumption misses that the goalposts move. What a company is expected to ship keeps expanding, not by choice but because competitors set the bar, so the work grows to match the productivity.

### [Should older or younger engineers be more worried about AI?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-should-older-or-younger-engineers-be-more-worried-about-ai)

Viktor Farcic says older, on DevOps Paradox episode 302, and includes himself. Experience carries value, but experienced people are statistically more likely to be defensive about a new trend. His comparison is language acquisition: small children learn faster partly because they have nothing to unlearn and no existing categories the new thing must be forced into.

### [Is adopting AI more urgent for individuals or companies?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-is-adopting-ai-more-urgent-for-individuals-or-companies)

Viktor Farcic separates the two on DevOps Paradox episode 302. For an individual it is not yet decisive, and nobody is out of the job market for skipping it this year. For a company the risk is different: by the time it changes your business, catching up may be impossible. His analogy is cloud, where you can start using AWS today but can no longer become it.

### [What combination makes an engineer most valuable?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-what-combination-makes-an-engineer-most-valuable)

Viktor Farcic's answer on DevOps Paradox episode 302: "If you can combine experience with curiosity, then we're talking." His point is that most people have one or the other. Experience often arrives alongside a loss of curiosity, and curiosity is most common in people who have not yet accumulated experience. He is careful to say either alone still has value; both together is the rare case.

### [What is the DevOps Paradox podcast?](/episodes/using-ai-to-help-with-your-programming-tasks-302/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 302 is a conversation between the two hosts about using AI while programming, covering whether the objections hold up, what privacy actually changes, and whether hiring predictions built on productivity gains have ever come true. Every episode page carries the audio, the video, and a full transcript.

### [What is OpenRewrite?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-what-is-openrewrite)

Jonathan Schneider describes it on DevOps Paradox episode 301 as large-scale automated refactoring. The main uses are application modernisation such as language and framework version upgrades, repairing security vulnerabilities, and fixing the kind of code quality issues a static analyser reports. The defining constraint is scope: anything you need to change not in one place but potentially across many repositories at once.

### [Why is an abstract syntax tree not enough for automated refactoring?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-why-is-an-abstract-syntax-tree-not-enough-for-automated-refactoring)

Jonathan Schneider explains on DevOps Paradox episode 301 that a syntax tree told him a method named info was being called, and could not tell him which logging library the field belonged to, since the signatures looked alike. That gap is why OpenRewrite drives the language compiler itself to resolve symbols, and keeps type information and original formatting in what the project calls a lossless semantic tree.

### [Why do mass pull requests get rejected?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-why-do-mass-pull-requests-get-rejected)

Jonathan Schneider reports a consistent figure on DevOps Paradox episode 301: pushing changes horizontally from a central team yields around 30 percent merge rates. He attributes it to how such requests feel, comparing them to unsolicited advice from a relative, where good content is beside the point. The fix is inverting it, giving the product team the same automation and letting them press the button.

### [Who should write migration recipes for a framework?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-who-should-write-migration-recipes-for-a-framework)

Jonathan Schneider argues on DevOps Paradox episode 301 that the framework authors should, since they have the most context on why a change was made and already write migration guides. He does not rely on goodwill for this. Large customers of the commercial entities behind major frameworks have put spending at risk to demand it, on the argument that whoever breaks you should fix you.

### [Should you upgrade dependencies frequently or in batches?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-should-you-upgrade-dependencies-frequently-or-in-batches)

Viktor Farcic argues for frequently on DevOps Paradox episode 301, and disputes that it is more work overall. Updating a single library to the next patch a thousand times beats updating a thousand libraries at once, because when something breaks you know where to look. He describes the alternative as deferring until the cost triples and then concluding the system will never be replaced.

### [Where does AI fit alongside rule-based refactoring?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-where-does-ai-fit-alongside-rule-based-refactoring)

Jonathan Schneider points out on DevOps Paradox episode 301 that several major vendors' code migration assistants are built on OpenRewrite underneath, because change at that scale cannot tolerate hallucination. He sees the two as complementary rather than competing: models accelerate writing new code, which produces more code needing maintenance, and the rule-based engine is what handles the maintenance end.

### [What is the DevOps Paradox podcast?](/episodes/exploring-openrewrite-and-the-future-of-code-modernization-301/index.md#faq-what-is-the-devops-paradox-podcast)

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 301 brings in Jonathan Schneider, creator of OpenRewrite and founder of Moderne, to explain automated refactoring at scale, why syntax trees fall short, and why the hardest part is social rather than technical. Every episode page carries the audio, the video, and a full transcript.


## All Guests

- [Aaron Torres](/guest/aaron-torres/index.md) | Cofounder & VP Engineering, Klotho
- [Abby Bangser](/guest/abby-bangser/index.md) | Principal Engineer, Syntasso
- [Adam Hawkins](/guest/adam-hawkins/index.md) | SRE, Skillshare
- [Adam Kamor](/guest/adam-kamor/index.md) | Co-Founder & Head Of Engineering, Tonic.ai
- [Ádám Sándor](/guest/adam-sandor/index.md) | Cloud Native Architect, Container Solutions
- [Ádám Szücs-Mátyás](/guest/adam-szucs-matyas/index.md)
- [Aharale Batonia](/guest/aharale-batonia/index.md) | Entrepreneur & Sales Specialist
- [Ajay Singh](/guest/ajay-singh/index.md) | CEO, Zebrium
- [Ala Shiban](/guest/ala-shiban/index.md) | Cofounder, Klotho
- [Alan Barr](/guest/alan-barr/index.md) | Platform Product Owner, Veterans United Home Loans
- [Alex Casalboni](/guest/alex-casalboni/index.md) | Developer Advocate, Unleash
- [Alex Gusev](/guest/alex-gusev/index.md) | CTO, Uploadcare
- [Alex Olivier](/guest/alex-olivier/index.md) | CPO & Co-Founder, Cerbos
- [Alon Jackson](/guest/alon-jackson/index.md) | Cofounder & CEO, Astrix Security
- [Amit Patel](/guest/amit-patel/index.md) | Director of Software Development for Developer Agents and Experiences, AWS
- [Anaïs Urlichs](/guest/anais-urlichs/index.md) | SRE, Civo
- [Andi Grabner](/guest/andi-grabner/index.md) | DevRel For The CNCF Sandbox Project Keptn
- [Andrei Kvapil](/guest/andrei-kvapil/index.md) | CEO & Founder, Aenix
- [Andy Pavlo](/guest/andy-pavlo/index.md) | Cofounder & CEO, OtterTune
- [Ankit Bhati](/guest/ankit-bhati/index.md) | Co-Founder & CEO, Amnic
- [Ankit Jain](/guest/ankit-jain/index.md) | Co-Founder & CEO, Aviator
- [Ant Weiss](/guest/ant-weiss/index.md) | CEO, Otomato
- [Anthony Eden](/guest/anthony-eden/index.md) | Cofounder & CEO, DNSimple
- [Anton Grishko](/guest/anton-grishko/index.md) | Chief Solutions Architect, Profisea Labs
- [Anton Zagrebelny](/guest/anton-zagrebelny/index.md) | Cofounder & CTO, Stigg
- [Arjun Iyer](/guest/arjun-iyer/index.md) | Co-Founder & CEO, Signadot
- [Arjun Narayan](/guest/arjun-narayan/index.md) | Co-Founder & CEO, Materialize
- [Asaf Matyas](/guest/asaf-matyas/index.md)
- [Austin Emmons](/guest/austin-emmons/index.md) | Lead iOS Engineer, Embrace
- [Avery Pennarun](/guest/avery-pennarun/index.md) | Co-Founder & CEO, Tailscale
- [Avi Shalisman](/guest/avi-shalisman/index.md)
- [Aviad Mor](/guest/aviad-mor/index.md) | CTO, Lumigo
- [Ben Wilcox](/guest/ben-wilcox/index.md) | CTO & CISO, ProArch
- [Benjamin Wilms](/guest/benjamin-wilms/index.md) | Co-Founder & CEO, Steadybit
- [Benjie De Groot](/guest/benjie-de-groot/index.md) | Cofounder, Shipyard
- [Bharath Vantari](/guest/bharath-vantari/index.md) | Principal Presales, Perforce Software
- [Birol Yildiz](/guest/birol-yildiz/index.md) | Co-Founder & CEO, ilert
- [Bob Quillin](/guest/bob-quillin/index.md) | Chief Ecosystem Officer, vFunction
- [Bret Fisher](/guest/bret-fisher/index.md)
- [Brian Singer](/guest/brian-singer/index.md) | Chief Product Officer, Nobl9
- [Brian Smith](/guest/brian-smith/index.md) | Co-Founder & CTO, Spyderbat
- [Brian Vallelunga](/guest/brian-vallelunga/index.md) | CEO, Doppler
- [Carlos Sanchez](/guest/carlos-sanchez/index.md) | Apache Member, OSS Contributor, & Engineer, Adobe
- [Charles-Edouard Brétéché](/guest/charles-edouard-breteche/index.md) | Senior Software Engineer, Nirmata
- [Chen Goldberg](/guest/chen-goldberg/index.md) | Co-Founder & CTO, Cloudwize.IO
- [Chetan Venkatesh](/guest/chetan-venkatesh/index.md) | CEO & Founder, Macrometa
- [Chris Weichel](/guest/chris-weichel/index.md) | CTO, Gitpod
- [Christian Hernandez](/guest/christian-hernandez/index.md) | Head Of Community, Akuity
- [Christine Spang](/guest/christine-spang/index.md) | CTO & Co-Founder, Nylas
- [Craig Box](/guest/craig-box/index.md) | VP Of Open Source & Community, Armo
- [Dagna Bieda](/guest/dagna-bieda/index.md) | Founder, theMindfulDev.com
- [Dan Bartholomew](/guest/dan-bartholomew/index.md) | CTO & Co-Founder, Section
- [Dan Burns](/guest/daniel-burns/index.md) | CEO & Co-Founder, Testifi
- [Daniel Bryant](/guest/daniel-bryant/index.md) | Independent Technical Consultant & News Manager, InfoQ
- [Darko Fabijan](/guest/darko-fabijan/index.md) | Cofounder, Semaphore
- [David Burkus](/guest/david-burkus/index.md) | Organizational Psychologist & Author
- [David Mytton](/guest/david-mytton/index.md) | Founder & CEO, Arcjet
- [Dean Agron](/guest/dean-agron/index.md) | CEO, Oxeye
- [Derek Ferguson](/guest/derek-ferguson/index.md) | Chief Software Officer, Fitch
- [Diogo Correia](/guest/diogo-correia/index.md) | Developer Experience Product Manager, Pipedrive
- [Dominic Holt](/guest/dominic-holt/index.md) | Founder & CEO, Harpoon
- [Dotan Horovits](/guest/dotan-horovits/index.md) | Principal Developer Advocate, Logz.io
- [Engin Diri](/guest/engin-diri/index.md)
- [Eran Bibi](/guest/eran-bibi/index.md) | Chief Product Officer, Firefly
- [Erez Rusovsky](/guest/erez-rusovsky/index.md) | Co-Founder, Rollout.io
- [Eric Mizell](/guest/eric-mizell/index.md) | VP Of Solution Engineering, OverOps
- [Erin Lovern](/guest/erin-lovern/index.md) | CEO, Grove Talent Group
- [Evan Kaplan](/guest/evan-kaplan/index.md) | CEO, InfluxData
- [Fatih Baltaci](/guest/fatih-baltaci/index.md) | Co-Founder, Ddosify
- [Ganesh The Awesome](/guest/ganesh-the-awesome/index.md) | Technical Sales Architect, GlobalDots
- [Geoffrey Huck](/guest/geoffrey-huck/index.md)
- [Gigi Sayfan](/guest/gigi-sayfan/index.md) | Author
- [Gil Hoffer](/guest/gil-hoffer/index.md) | CTO & Co-Founder, Salto
- [Gorkem Ercan](/guest/gorkem-ercan/index.md) | CTO, Jozu
- [Grady Saccullo](/guest/grady-saccullo/index.md) | Front End Developer, Cycle
- [Guy Levinger](/guest/guy-levinger/index.md) | CTO, BLST Security
- [Hadi Chami](/guest/hadi-chami/index.md) | Developer Advocate & Support Manager, LEAD Technologies, Inc
- [Hugo Santos](/guest/hugo-santos/index.md)
- [Ian McClarty](/guest/ian-mcclarty/index.md) | President, phoenixNAP
- [Itamar Ben Hemo](/guest/itamar-ben-hemo/index.md) | Co-Founder & CEO, Rivery
- [Itiel Shwartz](/guest/itiel-shwartz/index.md) | CTO & Co-Founder, Komodor
- [Jacques Chester](/guest/jacques-chester/index.md) | Engineer, VMware
- [Jake Englund](/guest/jake-englund/index.md) | Senior Site Reliability Engineer, Blameless
- [James Rawlings](/guest/james-rawlings/index.md)
- [James Strachan](/guest/james-strachan/index.md)
- [Jason Yaeger](/guest/jason-yaeger/index.md) | Co-Founder & CEO, Tenacity Cloud
- [Jeff Kuo](/guest/jeff-kuo/index.md) | CEO, KlotRagicho
- [Jim Douglas](/guest/jim-douglas/index.md) | CEO, Armory
- [Jim Hirschauer](/guest/jim-hirschauer/index.md) | Head Of Product Marketing, Xurrent
- [Joe Duffy](/guest/joe-duffy/index.md) | Founder & CEO, Pulumi
- [John Dietz](/guest/john-dietz/index.md) | CEO, Kubefirst
- [John Laffey](/guest/john-laffey/index.md) | Currently A Senior Sales Engineer, Puppet
- [Jonathan Schneider](/guest/jonathan-schneider/index.md) | Co-Founder & CEO, Moderne
- [Joost van der Griendt](/guest/joost-van-der-griendt/index.md)
- [Joseph Sandoval](/guest/joseph-sandoval/index.md) | Principal Product Manager, Platform Engineering, Adobe
- [Joyce Lin](/guest/joyce-lin/index.md) | Head Of Developer Relations, Postman
- [Kaspar von Grünberg](/guest/kaspar-von-grunberg/index.md) | Founder & CEO, Humanitec
- [Katharina Sick](/guest/katharina-sick/index.md)
- [Kevin Jackson](/guest/kevin-jackson/index.md) | Senior Director Of Product Management, Trilio
- [Kursat Aktas](/guest/kursat-aktas/index.md) | Co-Founder, Ddosify
- [Lachlan Evenson](/guest/lachlan-evenson/index.md) | Principal Program Manager On The Open Source Team, Azure
- [Lane Wagner](/guest/lane-wagner/index.md) | Founder, Boot.dev
- [Lian Li](/guest/lian-li/index.md)
- [Liran Haimovitch](/guest/liran-haimovitch/index.md) | Co-Founder & CTO, Rookout
- [Liz Rice](/guest/liz-rice/index.md) | Chief Open Source Officer, Isovalent
- [Luca Ingianni](/guest/luca-ingianni/index.md) | Freelance DevOps Consultant
- [Luke Hinds](/guest/luke-hinds/index.md) | CTO, Stacklok
- [Marino Wijay](/guest/marino-wijay/index.md) | Principal Developer Advocate, Solo.io
- [Mark Fussell](/guest/mark-fussell/index.md) | CEO, Diagrid
- [Mason McLead](/guest/mason-mclead/index.md) | CTO, Software
- [Mathias Buus Madsen](/guest/mathias-buus-madsen/index.md) | CEO, Holepunch
- [Matt Davis](/guest/matt-davis/index.md) | Senior Infrastructure Engineer, Blameless
- [Matt DeBergalis](/guest/matt-debergalis/index.md) | CEO and Co-Founder, Apollo GraphQL
- [Matt Moore](/guest/matt-moore/index.md) | Founder & CTO, Chainguard
- [Matt Turner](/guest/matt-turner/index.md) | Head Of Platform, Ziglu
- [Matthew Groves](/guest/matthew-groves/index.md) | Product Marketing Manager, Couchbase
- [Mauricio Salatino](/guest/mauricio-salatino/index.md) | Open Source Software Engineer, Diagrid
- [Mav Turner](/guest/mav-turner/index.md) | Chief Technology Officer Of DevOps, Tricentis
- [Maxim Melamedov](/guest/maxim-melamedov/index.md) | CEO, Zesty
- [Michael Zuercher](/guest/michael-zuercher/index.md) | Cofounder & CEO, Primastic
- [Mike Fitzmaurice](/guest/mike-fitzmaurice/index.md) | Chief Evangelist, WEBCON
- [Mike Guthrie](/guest/mike-guthrie/index.md) | Senior DevOps Engineer, NetFoundry
- [Mike Malone](/guest/mike-malone/index.md) | Founder & CEO, Smallstep
- [Mike Sawka](/guest/mike-sawka/index.md) | Founder & CEO, Wave Terminal
- [Mikolaj Pawlikowski](/guest/mikolaj-pawlikowski/index.md) | Software Engineer Project Lead, Bloomberg LP
- [Miles Spencer](/guest/miles-spencer/index.md) | Co-Founder & CEO, Reflekta.ai
- [Mislav Stipetic](/guest/mislav-stipetic/index.md) | CTO, Magic Sandbox, The Kubernetes training platform
- [Neil Millard](/guest/neil-millard/index.md) | Author
- [Nicolas Frankel](/guest/nicolas-frankel/index.md) | Developer Advocate, Hazelcast
- [Nicolas Vermandé](/guest/nicolas-vermande/index.md) | DevRel, Ondat
- [Nicole van der Hoeven](/guest/nicole-van-der-hoeven/index.md) | Developer Advocate, k6
- [Nir Valtman](/guest/nir-valtman/index.md) | CEO & Co-Founder, Arnica
- [Nirmal Mehta](/guest/nirmal-mehta/index.md) | DevOps Evangelist, Open Source Enthusiast, & Docker Captain
- [Noam Salinger](/guest/noam-salinger/index.md) | Director Of Product Management, Granulate
- [Ofir Stein](/guest/ofir-stein/index.md) | CTO & Co-Founder, Apono
- [Olaf Molenveld](/guest/olaf-molenveld/index.md) | CTO, Vamp.io
- [Omer Hamerman](/guest/omer-hamerman/index.md) | Infrastructure Architect, Zesty.co
- [On Freund](/guest/on-freund/index.md) | Co-Founder & CEO, Wilco
- [Paschalis Tsilias](/guest/paschalis-tsilias/index.md) | Software Engineer, Grafana Labs
- [Patrick Debois](/guest/patrick-debois/index.md) | AI Product Engineer, Tessl
- [Paul Stovell](/guest/paul-stovell/index.md) | Founder & CEO, Octopus
- [Pete Hunt](/guest/pete-hunt/index.md) | CEO, Dagster
- [Peter Jausovec](/guest/peter-jausovec/index.md) | Consulting Member Of Technical Staff, Oracle
- [Peter Zaitsev](/guest/peter-zaitsev/index.md) | Cofounder, Coroot
- [Phil Estes](/guest/phil-estes/index.md) | Distinguished Engineer & CTO, Container & Linux OS Architecture Strategy, IBM
- [Philipp Krenn](/guest/philipp-krenn/index.md) | Developer Advocate, Elastic
- [PJ Hagerty](/guest/pj-hagerty/index.md) | Senior Developer Advocate, Mattermost
- [Puja Abbassi](/guest/puja-abbassi/index.md) | VP Of Product, Giant Swarm
- [Ragnar Paide](/guest/ragnar-paide/index.md) | Senior DevOps Engineer, Pipedrive
- [Ramon Guiu](/guest/ramon-guiu/index.md) | VP Of Observability Products, Timescale
- [Ran Nozik](/guest/ran-nozik/index.md) | Co-Founder & CTO, Helios
- [Randy Abernethy](/guest/randy-abernethy/index.md) | Managing Partner, RX-M
- [Ravid Circus](/guest/ravid-circus/index.md) | Co-Founder & CPO, Seemplicity
- [Rhys Arkins](/guest/rhys-arkins/index.md) | Founder Of Renovate & VP Of Product, Mend
- [Ricardo Castro](/guest/ricardo-castro/index.md)
- [Richard Whitehead](/guest/richard-whitehead/index.md) | CTO, Moogsoft
- [Rob Hirschfeld](/guest/rob-hirschfeld/index.md) | Founder & CEO, RackN
- [Robert Cooke](/guest/robert-cooke/index.md) | Founder & Principal Architect, 3forge
- [Rodric Rabbah](/guest/rodric-rabbah/index.md) | Co-Founder & CTO, Nimbella
- [Roger Day](/guest/roger-day/index.md) | Developer With 15 Years Of Scala & Java Experience
- [Roi Ravhon](/guest/roi-ravhon/index.md) | CEO, Finout
- [Rosemary Wang](/guest/rosemary-wang/index.md) | Author
- [Ruben Hakopian](/guest/ruben-hakopian/index.md) | Founder & CEO, Kubevious
- [Russ Miles](/guest/russ-miles/index.md) | CEO, ChaosIQ.io
- [Ryan Kulp](/guest/ryan-kulp/index.md) | Cofounder, Fork Equity
- [Sam Lambert](/guest/sam-lambert/index.md) | CEO, PlanetScale
- [Sashank Purighalla](/guest/sashank-purighalla/index.md) | CEO & Founder, BOS Framework
- [Sergei Egorov](/guest/sergei-egorov/index.md) | Co-Founder & CEO, AtomicJar
- [Shahar Azulay](/guest/shahar-azulay/index.md) | CEO & Co-Founder, groundcover
- [Sophia Willows](/guest/sophia-willows/index.md)
- [Stephen Chin](/guest/stephen-chin/index.md) | VP Of Developer Relations, JFrog
- [Steve Pereira](/guest/steve-pereira/index.md) | Founder, Visible
- [Sylvain Hellegouarch](/guest/sylvain-hellegouarch/index.md) | Co-Founder & CTO, ChaosIQ.io
- [Tanmai Gopal](/guest/tanmai-gopal/index.md) | CEO & Co-Founder, Hasura
- [Thomas Vitale](/guest/thomas-vitale/index.md) | Author
- [Tigran Mnatsakanyan](/guest/tigran-mnatsakanyan/index.md) | Technology Consultant In London
- [Tim Beattie](/guest/tim-beattie/index.md) | CEO & Co-Founder, Stellafai
- [Tim Davis](/guest/tim-davis/index.md) | DevOps Advocate For Env0
- [Tobias Ericsson](/guest/tobias-ericsson/index.md)
- [Tom Akehurst](/guest/tom-akehurst/index.md) | Co-Founder, WireMock
- [Tomas Kovacovsky](/guest/tomas-kovacovsky/index.md) | CTO & Co-Founder, Brightpick
- [Tracy Miranda](/guest/tracy-miranda/index.md)
- [Trevor Stuart](/guest/trevor-stuart/index.md) | Senior Vice President & General Manager, Harness
- [Umasankar Mukkara](/guest/umasankar-mukkara/index.md) | Co-Founder & COO, MayaData
- [Valera Bronshtein](/guest/valera-bronshtein/index.md) | Director Of Infrastructure, Memphis.dev
- [Victoria Mensch](/guest/victoria-mensch/index.md) | Founder & CEO, Silicon Valley Executive Academy
- [Viktor Gamov](/guest/viktor-gamov/index.md) | Developer Advocate, Confluent
- [Ville Aikas](/guest/ville-aikas/index.md) | Founder, Chainguard
- [Webb Brown](/guest/webb-brown/index.md) | Co-Founder & CEO, Kubecost
- [Wesley Beary](/guest/wesley-beary/index.md) | Founding Engineer, Anchor
- [Whitney Lee](/guest/whitney-lee/index.md)
- [Yaniv Leven](/guest/yaniv-leven/index.md) | VP SaaS Product, SQream
- [Yotam Atad](/guest/yotam-atad/index.md) | Co-Founder & CEO, Cloudwize.IO
- [Yuval Oren](/guest/yuval-oren/index.md) | DevOps & DevSecOps Consultant, PineWise
- [Zohar Einy](/guest/zohar-einy/index.md) | CEO, port

## All Livestreams

- [What's New in Kubernetes 1.37](/livestreams/whats-new-in-kubernetes-137-2026-08-28/index.md) | August 28, 2026
- [GitHub Shipped a Security Checklist. Why Aren't They The Defaults?](/livestreams/github-shipped-a-security-checklist-why-arent-they-the-defaults-2026-07-10/index.md) | July 10, 2026
- [The AI That Ranks Your Dev Tools Has Never Used Any of Them](/livestreams/the-ai-that-ranks-your-dev-tools-has-never-used-any-of-them-2026-06-19/index.md) | June 19, 2026
- [ClickUp Will Pay You a Million Dollars. There Is a Catch.](/livestreams/clickup-will-pay-you-a-million-dollars-there-is-a-catch-2026-06-05/index.md) | June 5, 2026
- [The Bug Bounty Era Is Over](/livestreams/the-bug-bounty-era-is-over-2026-05-22/index.md) | May 22, 2026
- [The DORA Report Just Killed the AI Productivity Pitch](/livestreams/the-dora-report-just-killed-the-ai-productivity-pitch-2026-05-08/index.md) | May 8, 2026
- [Yet Another One](/livestreams/yet-another-one-2026-05-01/index.md) | May 1, 2026
- [Kubernetes 1.36 Shipped and the Logo Got More Press Than the Release](/livestreams/kubernetes-136-shipped-and-the-logo-got-more-press-than-the-release-2026-04-24/index.md) | April 24, 2026
- [The Security Advice Everyone Is Reissuing in 2026 Was Already True in 2000](/livestreams/the-security-advice-everyone-is-reissuing-in-2026-was-already-true-in-2000-2026-04-17/index.md) | April 17, 2026
- [Anthropic's Mythos Model Just Found a 27-Year-Old OpenBSD Bug Nobody Ever Noticed](/livestreams/anthropics-mythos-model-just-found-a-27-year-old-openbsd-bug-nobody-ever-noticed-2026-04-10/index.md) | April 10, 2026
- [GitHub Will Be Training on Your Code and You’re Already Opted In](/livestreams/github-will-be-training-on-your-code-and-youre-already-opted-in-2026-04-03/index.md) | April 3, 2026
- [Building Software Is Now Cheaper Than the Meeting to Discuss It](/livestreams/building-software-is-now-cheaper-than-the-meeting-to-discuss-it-2026-03-13/index.md) | March 13, 2026
- [The SDLC Is Dead and Context Is All That's Left](/livestreams/the-sdlc-is-dead-and-context-is-all-thats-left-2026-03-06/index.md) | March 6, 2026
- [Cloudflare Shrunk 2 Million Tokens to 1,000 but MCPs Still Have a Problem](/livestreams/cloudflare-shrunk-2-million-tokens-to-1000-but-mcps-still-have-a-problem-2026-02-20/index.md) | February 20, 2026
- [Your $14 App Is Now Someone's Weekend Project](/livestreams/your-dollar14-app-is-now-someones-weekend-project-2026-02-06/index.md) | February 6, 2026
- [The END of Open Source? Vibe Coding Is Killing Everything](/livestreams/the-end-of-open-source-vibe-coding-is-killing-everything-2026-01-30/index.md) | January 30, 2026
- [AI Is Writing All My Code Now](/livestreams/ai-is-writing-all-my-code-now-2026-01-23/index.md) | January 23, 2026
- [Anthropic Needs to Slow Down - Claude Code Is Moving Too Fast](/livestreams/anthropic-needs-to-slow-down-claude-code-is-moving-too-fast-2026-01-16/index.md) | January 16, 2026
- [RIP Open Source? How AI is Destroying Developer Business Models](/livestreams/rip-open-source-how-ai-is-destroying-developer-business-models-2026-01-09/index.md) | January 9, 2026
- [Why Every AI Tool is Suddenly Supporting Agent Skills](/livestreams/why-every-ai-tool-is-suddenly-supporting-agent-skills-2025-12-19/index.md) | December 19, 2025
- [Why VCs Are Throwing MILLIONS at Anything With 'AI' in the Name](/livestreams/why-vcs-are-throwing-millions-at-anything-with-ai-in-the-name-2025-12-12/index.md) | December 12, 2025
- [AWS Just Made DevOps Engineers Obsolete (Or Did They?)](/livestreams/aws-just-made-devops-engineers-obsolete-or-did-they-2025-12-05/index.md) | December 5, 2025
- [Ingress NGINX Retiring: What It Means for Your Infrastructure](/livestreams/ingress-nginx-retiring-what-it-means-for-your-infrastructure-2025-11-21/index.md) | November 21, 2025
- [This New AI Feature Just Saved Me 67% in Costs](/livestreams/this-new-ai-feature-just-saved-me-67-in-costs-2025-10-17/index.md) | October 17, 2025
- [90% of Developers Use AI? I Call BS](/livestreams/90-of-developers-use-ai-i-call-bs-2025-09-26/index.md) | September 26, 2025
- [AI Native Infrastructure Automation is HERE](/livestreams/ai-native-infrastructure-automation-is-here-2025-08-29/index.md) | August 29, 2025
- [Apple Hires Key Open Policy Agent Developers from Styra](/livestreams/apple-hires-key-open-policy-agent-developers-from-styra-2025-08-22/index.md) | August 22, 2025
- [Why AI Coding Tools Are Giving Everyone Headaches](/livestreams/why-ai-coding-tools-are-giving-everyone-headaches-2025-08-15/index.md) | August 15, 2025
- [Why Developers Are AI's Biggest Token Burners (It's Not Even Close)](/livestreams/why-developers-are-ais-biggest-token-burners-its-not-even-close-2025-08-08/index.md) | August 8, 2025
- [AI Writes 136-Line PRDs in Minutes - But Should You Trust It?](/livestreams/ai-writes-136-line-prds-in-minutes-but-should-you-trust-it-2025-08-01/index.md) | August 1, 2025
- [AWS EKS Now Supports 100,000 Nodes - AI is Eating Everything](/livestreams/aws-eks-now-supports-100000-nodes-ai-is-eating-everything-2025-07-18/index.md) | July 18, 2025
- [The AI Bubble: 18 Months to Crash or Unicorn Status?](/livestreams/the-ai-bubble-18-months-to-crash-or-unicorn-status-2025-07-11/index.md) | July 11, 2025
- [It’s All AI Now](/livestreams/its-all-ai-now-2025-06-27/index.md) | June 27, 2025
- [GitHub Copilot: The agent awakens](/livestreams/github-copilot-the-agent-awakens-2025-02-07/index.md) | February 7, 2025
- [First Look at Goose](/livestreams/first-look-at-goose-2025-01-31/index.md) | January 31, 2025
- [Hands On With Gitxray](/livestreams/hands-on-with-gitxray-2025-01-24/index.md) | January 24, 2025
- [Hands On With Windsurf Editor](/livestreams/hands-on-with-windsurf-editor-2025-01-17/index.md) | January 17, 2025
- [Installing and Configuring Ghostty](/livestreams/installing-and-configuring-ghostty-2025-01-10/index.md) | January 10, 2025
- [What’s New in Kubernetes 1.32](/livestreams/whats-new-in-kubernetes-132-2024-12-13/index.md) | December 13, 2024
- [One Last Look at KubeCon NA 2024](/livestreams/one-last-look-at-kubecon-na-2024-2024-11-22/index.md) | November 22, 2024
- [KubeConNA 2024 Countdown](/livestreams/kubeconna-2024-countdown-2024-11-08/index.md) | November 8, 2024
- [The 2024 DORA Report Arrives](/livestreams/the-2024-dora-report-arrives-2024-10-25/index.md) | October 25, 2024
- [GitHub Evolves Issues](/livestreams/github-evolves-issues-2024-10-11/index.md) | October 11, 2024
- [Hands-on with GitHub Copilot CLI](/livestreams/hands-on-with-github-copilot-cli-2024-09-27/index.md) | September 27, 2024
- [A Week of Little News](/livestreams/a-week-of-little-news-2024-09-13/index.md) | September 13, 2024
- [Catching Up After a Long Break](/livestreams/catching-up-after-a-long-break-2024-09-06/index.md) | September 6, 2024
- [HashiCorp State of Cloud Strategy Survey 2024](/livestreams/hashicorp-state-of-cloud-strategy-survey-2024-2024-06-28/index.md) | June 28, 2024
- [GitHub and JFrog Announce Partnership](/livestreams/github-and-jfrog-announce-partnership-2024-05-31/index.md) | May 31, 2024
- [How To Install and Use Devbox on macOS](/livestreams/how-to-install-and-use-devbox-on-macos-2024-05-24/index.md) | May 24, 2024
- [Kubernetes is turning 10!](/livestreams/kubernetes-is-turning-10-2024-05-10/index.md) | May 10, 2024
- [Spotify for Backstage](/livestreams/spotify-for-backstage-2024-05-03/index.md) | May 3, 2024
- [IBM To Buy HashiCorp](/livestreams/ibm-to-buy-hashicorp-2024-04-26/index.md) | April 26, 2024
- [What’s New in Kubernetes 1.30](/livestreams/whats-new-in-kubernetes-130-2024-04-19/index.md) | April 19, 2024
- [A New Open Source Foundation Emerges](/livestreams/a-new-open-source-foundation-emerges-2024-04-12/index.md) | April 12, 2024
- [Redis Adopts Dual Source-Available Licensing](/livestreams/redis-adopts-dual-source-available-licensing-2024-03-29/index.md) | March 29, 2024
- [GUAC Joins OpenSSF](/livestreams/guac-joins-openssf-2024-03-08/index.md) | March 8, 2024
- [The XY Problem](/livestreams/the-xy-problem-2024-03-01/index.md) | March 1, 2024
- [Crossplane Graduation Proposal](/livestreams/crossplane-graduation-proposal-2024-02-23/index.md) | February 23, 2024
- [So You Think You Know Git](/livestreams/so-you-think-you-know-git-2024-02-16/index.md) | February 16, 2024
- [A Week of Leaky Vessels](/livestreams/a-week-of-leaky-vessels-2024-02-02/index.md) | February 2, 2024
- [Amazon EKS now supports Kubernetes version 1.29](/livestreams/amazon-eks-now-supports-kubernetes-version-129-2024-01-26/index.md) | January 26, 2024
- [Hands On With Ollama](/livestreams/hands-on-with-ollama-2024-01-19/index.md) | January 19, 2024
- [Cisco Acquires Isovalent](/livestreams/cisco-acquires-isovalent-2024-01-05/index.md) | January 5, 2024
- [Docker Acquires AtomicJar, Maker of Testcontainers](/livestreams/docker-acquires-atomicjar-maker-of-testcontainers-2023-12-15/index.md) | December 15, 2023
- [The Frugal Architect](/livestreams/the-frugal-architect-2023-12-01/index.md) | December 1, 2023
- [Do Hackers Eat Turkey?](/livestreams/do-hackers-eat-turkey-2023-11-24/index.md) | November 24, 2023
- [The Next Generation of the Command Line](/livestreams/the-next-generation-of-the-command-line-2023-11-17/index.md) | November 17, 2023
- [No More Open Source Companies in Silicon Valley?](/livestreams/no-more-open-source-companies-in-silicon-valley-2023-10-27/index.md) | October 27, 2023
- [Cilium Graduates at the CNCF](/livestreams/cilium-graduates-at-the-cncf-2023-10-20/index.md) | October 20, 2023
- [How Safe Are GitHub Actions?](/livestreams/how-safe-are-github-actions-2023-09-08/index.md) | September 8, 2023
- [Why We Are Not Supporting OpenTF](/livestreams/why-we-are-not-supporting-opentf-2023-09-01/index.md) | September 1, 2023
- [OpenTF Announces Fork of Terraform](/livestreams/opentf-announces-fork-of-terraform-2023-08-25/index.md) | August 25, 2023
- [The Emergence of OpenTF](/livestreams/the-emergence-of-opentf-2023-08-18/index.md) | August 18, 2023
- [HashiCorp Adopts Business Source License](/livestreams/hashicorp-adopts-business-source-license-2023-08-11/index.md) | August 11, 2023
- [Breaking Free of Scrum Ceremonies](/livestreams/breaking-free-of-scrum-ceremonies-2023-08-04/index.md) | August 4, 2023
- [How Can We Trust GitHub Copilot?](/livestreams/how-can-we-trust-github-copilot-2023-07-28/index.md) | July 28, 2023
- [KubeVirt v1.0 has landed!](/livestreams/kubevirt-v10-has-landed-2023-07-21/index.md) | July 21, 2023
- [Stack Overflow 2023 Developer Survey](/livestreams/stack-overflow-2023-developer-survey-2023-06-16/index.md) | June 16, 2023
- [Happy Birthday to Amazon EKS](/livestreams/happy-birthday-to-amazon-eks-2023-06-09/index.md) | June 9, 2023
- [Cloud Dependencies Are Not the Problem. You Are.](/livestreams/cloud-dependencies-are-not-the-problem-you-are-2023-06-02/index.md) | June 2, 2023
- [Amazon EKS Now Supports 1.27](/livestreams/amazon-eks-now-supports-127-2023-05-26/index.md) | May 26, 2023
- [FOCUSing on FinOps](/livestreams/focusing-on-finops-2023-05-05/index.md) | May 5, 2023
- [AKS Long Term Support: Good or Bad?](/livestreams/aks-long-term-support-good-or-bad-2023-04-28/index.md) | April 28, 2023
- [Kubernetes 1.27 has arrived!](/livestreams/kubernetes-127-has-arrived-2023-04-14/index.md) | April 14, 2023
- [Autopilot Is Now GKE’s Default Mode of Operation](/livestreams/autopilot-is-now-gkes-default-mode-of-operation-2023-04-07/index.md) | April 7, 2023
- [Should AI Be Your Pair Programming Partner?](/livestreams/should-ai-be-your-pair-programming-partner-2023-03-31/index.md) | March 31, 2023
- [Using Tekton To Get to SLSA Level 2](/livestreams/using-tekton-to-get-to-slsa-level-2-2023-03-10/index.md) | March 10, 2023
- [Millions Wasted on Kubernetes Resources](/livestreams/millions-wasted-on-kubernetes-resources-2023-03-03/index.md) | March 3, 2023
- [Amazon EKS Now Supports Kubernetes Version 1.25](/livestreams/amazon-eks-now-supports-kubernetes-version-125-2023-02-24/index.md) | February 24, 2023
- [Chainguard Image Now Available for Kubectl](/livestreams/chainguard-image-now-available-for-kubectl-2023-02-10/index.md) | February 10, 2023
- [How Kubernetes Is Being Used at Chick-fil-A](/livestreams/how-kubernetes-is-being-used-at-chick-fil-a-2023-02-03/index.md) | February 3, 2023
- [Kubescape Accepted Into the CNCF](/livestreams/kubescape-accepted-into-the-cncf-2023-01-13/index.md) | January 13, 2023
- [Kured Donated to the CNCF](/livestreams/kured-donated-to-the-cncf-2023-01-06/index.md) | January 6, 2023
- [Single Node Clusters on Amazon EKS Anywhere](/livestreams/single-node-clusters-on-amazon-eks-anywhere-2022-12-23/index.md) | December 23, 2022
- [Track Leaked Secrets in Public GitHub Repositories](/livestreams/track-leaked-secrets-in-public-github-repositories-2022-12-16/index.md) | December 16, 2022
- [Argo and Flux Have Graduated](/livestreams/argo-and-flux-have-graduated-2022-12-09/index.md) | December 9, 2022
- [Finch Enters the Container Tooling War](/livestreams/finch-enters-the-container-tooling-war-2022-11-25/index.md) | November 25, 2022
- [Kubernetes the Much Harder Way](/livestreams/kubernetes-the-much-harder-way-2022-11-18/index.md) | November 18, 2022
- [The Rise of the Cloud IDEs](/livestreams/the-rise-of-the-cloud-ides-2022-11-11/index.md) | November 11, 2022
- [Twas the Week Before KubeCon](/livestreams/twas-the-week-before-kubecon-2022-10-21/index.md) | October 21, 2022
- [Getting Ready for KubeCon NA 2022](/livestreams/getting-ready-for-kubecon-na-2022-2022-10-14/index.md) | October 14, 2022
- [2022 Accelerate State of DevOps Report](/livestreams/2022-accelerate-state-of-devops-report-2022-10-07/index.md) | October 7, 2022
- [Vagrant Moving From Ruby To Go](/livestreams/vagrant-moving-from-ruby-to-go-2022-09-23/index.md) | September 23, 2022
- [Viktor Stuck in an Airport](/livestreams/viktor-stuck-in-an-airport-2022-09-16/index.md) | September 16, 2022
- [Hacktoberfest Is Coming](/livestreams/hacktoberfest-is-coming-2022-09-09/index.md) | September 9, 2022
- [Heroku Eliminates Free Tier](/livestreams/heroku-eliminates-free-tier-2022-08-26/index.md) | August 26, 2022
- [External Secrets Operator Accepted Into the CNCF Sandbox](/livestreams/external-secrets-operator-accepted-into-the-cncf-sandbox-2022-08-19/index.md) | August 19, 2022
- [You Probably Code Less Than an Hour a Day](/livestreams/you-probably-code-less-than-an-hour-a-day-2022-08-12/index.md) | August 12, 2022
- [GitLab and Dormant Projects](/livestreams/gitlab-and-dormant-projects-2022-08-05/index.md) | August 5, 2022
- [GitHub Projects Is GA](/livestreams/github-projects-is-ga-2022-07-29/index.md) | July 29, 2022
- [Kyverno Moves From Sandbox to Incubating](/livestreams/kyverno-moves-from-sandbox-to-incubating-2022-07-22/index.md) | July 22, 2022
- [GitOps Success Checklist](/livestreams/gitops-success-checklist-2022-07-08/index.md) | July 8, 2022
- [What Is Cloud Repatriation?](/livestreams/what-is-cloud-repatriation-2022-07-01/index.md) | July 1, 2022
- [Copilot vs CodeWhisperer](/livestreams/copilot-vs-codewhisperer-2022-06-24/index.md) | June 24, 2022
- [Grafana OnCall Is Now Open Source](/livestreams/grafana-oncall-is-now-open-source-2022-06-17/index.md) | June 17, 2022
- [Introducing Gitsign](/livestreams/introducing-gitsign-2022-06-10/index.md) | June 10, 2022
- [Chainguard announces Series A](/livestreams/chainguard-announces-series-a-2022-06-03/index.md) | June 3, 2022
- [Broadcom to Acquire VMware](/livestreams/broadcom-to-acquire-vmware-2022-05-27/index.md) | May 27, 2022
- [Taking a Second Look at Docker Desktop](/livestreams/taking-a-second-look-at-docker-desktop-2022-05-13/index.md) | May 13, 2022
- [Kubernetes 1.24 Ships!](/livestreams/kubernetes-124-ships-2022-05-06/index.md) | May 6, 2022
- [Istio Heads to the CNCF](/livestreams/istio-heads-to-the-cncf-2022-04-29/index.md) | April 29, 2022
- [Kubevirt Becomes a CNCF Incubating Project](/livestreams/kubevirt-becomes-a-cncf-incubating-project-2022-04-22/index.md) | April 22, 2022
- [Puppet Joins Forces With Perforce](/livestreams/puppet-joins-forces-with-perforce-2022-04-15/index.md) | April 15, 2022
- [The 23 Million Dollar Terminal](/livestreams/the-23-million-dollar-terminal-2022-04-08/index.md) | April 8, 2022
- [Create CI/CD Pipelines With Dagger](/livestreams/create-cicd-pipelines-with-dagger-2022-04-01/index.md) | April 1, 2022
- [GCP Price Increases](/livestreams/gcp-price-increases-2022-03-25/index.md) | March 25, 2022
- [Backstage Reaches 1.0 And Joins the CNCF Incubator](/livestreams/backstage-reaches-10-and-joins-the-cncf-incubator-2022-03-18/index.md) | March 18, 2022
- [Thoughts on Internal Developer Platforms](/livestreams/thoughts-on-internal-developer-platforms-2022-03-11/index.md) | March 11, 2022
- [Prebuild Comes to Codespaces](/livestreams/prebuild-comes-to-codespaces-2022-02-25/index.md) | February 25, 2022
- [Creating Diagrams with Mermaid](/livestreams/creating-diagrams-with-mermaid-2022-02-18/index.md) | February 18, 2022
- [High-Availability Control Plane Arrives on LKE](/livestreams/high-availability-control-plane-arrives-on-lke-2022-02-11/index.md) | February 11, 2022
- [Announcing OSM v1.0.0](/livestreams/announcing-osm-v100-2022-02-04/index.md) | February 4, 2022
- [A Documentary About Kubernetes Has Been Released](/livestreams/a-documentary-about-kubernetes-has-been-released-2022-01-28/index.md) | January 28, 2022
- [The Problem With Open Source](/livestreams/the-problem-with-open-source-2022-01-21/index.md) | January 21, 2022
- [How Did We Not Know About Task?](/livestreams/how-did-we-not-know-about-task-2022-01-07/index.md) | January 7, 2022
- [Tools, Tools, and More Tools](/livestreams/tools-tools-and-more-tools-2021-12-31/index.md) | December 31, 2021
- [The Giants of Open Source](/livestreams/the-giants-of-open-source-2021-12-17/index.md) | December 17, 2021
- [From HCL to HCP](/livestreams/from-hcl-to-hcp-2021-12-10/index.md) | December 10, 2021
- [What Happened at AWS re:Invent This Week?](/livestreams/what-happened-at-aws-reinvent-this-week-2021-12-03/index.md) | December 3, 2021
- [Getting Ready for AWS re:Invent](/livestreams/getting-ready-for-aws-reinvent-2021-11-26/index.md) | November 26, 2021
- [GitOps Finally Has an Official Definition](/livestreams/gitops-finally-has-an-official-definition-2021-11-19/index.md) | November 19, 2021
- [Move Over Rook. Here Comes Longhorn.](/livestreams/move-over-rook-here-comes-longhorn-2021-11-12/index.md) | November 12, 2021
- [Hashicorp Files for IPO](/livestreams/hashicorp-files-for-ipo-2021-11-05/index.md) | November 5, 2021
- [Everything New From GitHub Universe 2021](/livestreams/everything-new-from-github-universe-2021-2021-10-29/index.md) | October 29, 2021
- [Introducing Pulumi Registry](/livestreams/introducing-pulumi-registry-2021-10-22/index.md) | October 22, 2021
- [DigitalOcean and Linode Update Their Kubernetes Offerings](/livestreams/digitalocean-and-linode-update-their-kubernetes-offerings-2021-10-15/index.md) | October 15, 2021
- [Introducing VMware Tanzu Community Edition](/livestreams/introducing-vmware-tanzu-community-edition-2021-10-08/index.md) | October 8, 2021
- [VS Code in the Browser for Everyone](/livestreams/vs-code-in-the-browser-for-everyone-2021-10-01/index.md) | October 1, 2021
- [Let’s Encrypt Root Certificate Expires Sep 30](/livestreams/lets-encrypt-root-certificate-expires-sep-30-2021-09-24/index.md) | September 24, 2021
- [Do You Really Have Technical Debt?](/livestreams/do-you-really-have-technical-debt-2021-09-17/index.md) | September 17, 2021
- [EKS Anywhere or minikube?](/livestreams/eks-anywhere-or-minikube-2021-09-10/index.md) | September 10, 2021
- [Docker Wants Their Five Dollars](/livestreams/docker-wants-their-five-dollars-2021-09-03/index.md) | September 3, 2021
- [Are You Managing Your Cloud Budget or Is It Managing You?](/livestreams/are-you-managing-your-cloud-budget-or-is-it-managing-you-2021-08-27/index.md) | August 27, 2021
- [How Often Does Your Company Patch Their Systems?](/livestreams/how-often-does-your-company-patch-their-systems-2021-08-20/index.md) | August 20, 2021
- [Cloud-based Development for Everyone](/livestreams/cloud-based-development-for-everyone-2021-08-13/index.md) | August 13, 2021
- [Do You Trust the NSA to Help You Harden Your Kubernetes Cluster?](/livestreams/do-you-trust-the-nsa-to-help-you-harden-your-kubernetes-cluster-2021-08-06/index.md) | August 6, 2021
- [What’s New in Kubernetes 1.22](/livestreams/whats-new-in-kubernetes-122-2021-07-30/index.md) | July 30, 2021
- [API removals for Kubernetes v1.22](/livestreams/api-removals-for-kubernetes-v122-2021-07-16/index.md) | July 16, 2021
- [AWS Infinidash Is the Next Big Tech Breakthrough](/livestreams/aws-infinidash-is-the-next-big-tech-breakthrough-2021-07-09/index.md) | July 9, 2021
- [Is GitHub Copilot Going to Put Developers Out of a Job?](/livestreams/is-github-copilot-going-to-put-developers-out-of-a-job-2021-07-02/index.md) | July 2, 2021
- [Use a Container Registry for Binary Distribution?](/livestreams/use-a-container-registry-for-binary-distribution-2021-05-07/index.md) | May 7, 2021
- [Dependabot Preview Is Now Dependabot](/livestreams/dependabot-preview-is-now-dependabot-2021-04-30/index.md) | April 30, 2021
- [Mirantis Confirms the Future of Dockershim](/livestreams/mirantis-confirms-the-future-of-dockershim-2021-04-23/index.md) | April 23, 2021
- [AWS Announces the OpenSearch Project](/livestreams/aws-announces-the-opensearch-project-2021-04-16/index.md) | April 16, 2021
- [Kubernetes 1.21 Has Landed](/livestreams/kubernetes-121-has-landed-2021-04-09/index.md) | April 9, 2021
- [What's New in Kubernetes 1.21](/livestreams/whats-new-in-kubernetes-121-2021-04-02/index.md) | April 2, 2021
- [Will You Subscribe to K9sAlpha?](/livestreams/will-you-subscribe-to-k9salpha-2021-03-19/index.md) | March 19, 2021
- [Have You Tested Your Disaster Recovery Plan?](/livestreams/have-you-tested-your-disaster-recovery-plan-2021-03-12/index.md) | March 12, 2021
- [Okta Acquires Auth0](/livestreams/okta-acquires-auth0-2021-03-05/index.md) | March 5, 2021
- [Google Announces GKE Autopilot](/livestreams/google-announces-gke-autopilot-2021-02-26/index.md) | February 26, 2021
- [AWS EKS Now Supports 1.19 and OIDC](/livestreams/aws-eks-now-supports-119-and-oidc-2021-02-19/index.md) | February 19, 2021
- [Everything Should Be Event Based](/livestreams/everything-should-be-event-based-2021-02-12/index.md) | February 12, 2021
- [Docker Distribution Donated to the CNCF](/livestreams/docker-distribution-donated-to-the-cncf-2021-02-05/index.md) | February 5, 2021
- [Logz.io Jumps Into the Elastic Fray](/livestreams/logzio-jumps-into-the-elastic-fray-2021-01-29/index.md) | January 29, 2021
- [The AWS and Elastic Saga Continues](/livestreams/the-aws-and-elastic-saga-continues-2021-01-22/index.md) | January 22, 2021
- [Grafana Cloud Announces a Forever Free Plan](/livestreams/grafana-cloud-announces-a-forever-free-plan-2021-01-15/index.md) | January 15, 2021
- [The Rise of Sealed Secrets and PostItOps](/livestreams/the-rise-of-sealed-secrets-and-postitops-2021-01-08/index.md) | January 8, 2021
- [A Less Painful Way to Manage AWS ECS](/livestreams/a-less-painful-way-to-manage-aws-ecs-2021-01-01/index.md) | January 1, 2021
- [Christmas Presents from AWS and GCP](/livestreams/christmas-presents-from-aws-and-gcp-2020-12-18/index.md) | December 18, 2020
- [The Lifetime of Kubernetes](/livestreams/the-lifetime-of-kubernetes-2020-12-11/index.md) | December 11, 2020
- [Docker Goneski: The Pain Is Real](/livestreams/docker-goneski-the-pain-is-real-2020-12-04/index.md) | December 4, 2020
- [The Internet Breaks Whenever AWS Goes Down](/livestreams/the-internet-breaks-whenever-aws-goes-down-2020-11-27/index.md) | November 27, 2020
- [KubeCon North America 2020 Review](/livestreams/kubecon-north-america-2020-review-2020-11-20/index.md) | November 20, 2020
- [The Four Different Phases of Kubernetes](/livestreams/the-four-different-phases-of-kubernetes-2020-11-13/index.md) | November 13, 2020
- [AWS Takes on Docker Hub](/livestreams/aws-takes-on-docker-hub-2020-11-06/index.md) | November 6, 2020
- [Dockerpocalypse Is Upon Us](/livestreams/dockerpocalypse-is-upon-us-2020-10-30/index.md) | October 30, 2020
- [Swipe Left for Security!](/livestreams/swipe-left-for-security-2020-10-23/index.md) | October 23, 2020
- [HashiCorp announces Boundary and Waypoint](/livestreams/hashicorp-announces-boundary-and-waypoint-2020-10-16/index.md) | October 16, 2020
- [Third-party scan tools come to GitHub](/livestreams/third-party-scan-tools-come-to-github-2020-10-09/index.md) | October 9, 2020
- [The Dark Side of Hacktoberfest](/livestreams/the-dark-side-of-hacktoberfest-2020-10-02/index.md) | October 2, 2020
- [Azure Kubernetes Service lands on-prem](/livestreams/azure-kubernetes-service-lands-on-prem-2020-09-25/index.md) | September 25, 2020
- [Snowflake and JFrog Go Public](/livestreams/snowflake-and-jfrog-go-public-2020-09-18/index.md) | September 18, 2020
- [Codespaces is dead. Long live Codespaces!](/livestreams/codespaces-is-dead-long-live-codespaces-2020-09-11/index.md) | September 11, 2020
- [Do we need another container registry?](/livestreams/do-we-need-another-container-registry-2020-09-04/index.md) | September 4, 2020
- [Kubernetes 1.19 has arrived](/livestreams/kubernetes-119-has-arrived-2020-08-28/index.md) | August 28, 2020
- [What's new in Kubernetes 1.19?](/livestreams/whats-new-in-kubernetes-119-2020-08-21/index.md) | August 21, 2020
- [Docker's new container image retention policy announced](/livestreams/dockers-new-container-image-retention-policy-announced-2020-08-14/index.md) | August 14, 2020
- [Microsoft enters the service mesh business...sort of](/livestreams/microsoft-enters-the-service-mesh-business-sort-of-2020-08-07/index.md) | August 7, 2020
- [Manage your Kubernetes costs with Kubecost](/livestreams/manage-your-kubernetes-costs-with-kubecost-2020-07-31/index.md) | July 31, 2020
- [The reason why AWS Copilot is special](/livestreams/the-reason-why-aws-copilot-is-special-2020-07-24/index.md) | July 24, 2020
- [Should you move your VMware workload to Google Cloud?](/livestreams/should-you-move-your-vmware-workload-to-google-cloud-2020-07-17/index.md) | July 17, 2020
- [Happy Hour / AMA for 10Jul2020](/livestreams/livestream-2020-07-10/index.md) | July 10, 2020