DevOps Paradox

#350: The bottleneck used to be writing the code. Now it is feeding the agent enough context to write the right code. That is Patrick Debois' argument, and given that Patrick coined the term DevOps, it is worth paying attention when he says the discipline is shifting again. The model does not matter. The IDE does not matter. What matters is whether your team can capture the way you actually work and hand it to an agent that does not know any of it. The promise was that AI would let us ship without writing specs. The reality is the opposite. If you want decent output, you need richer specs, more docs, and a way to feed the agent what is unique about your team and your codebase. Viktor admits he stopped writing specs himself. He talks to the agent until he is satisfied, then says write it down. The work did not go away. It moved. A second agent that validates your work tends to take the original spec too seriously and miss what is not there. The interesting validation is not whether the code matches the spec. It is whether the spec matches reality. Patrick's response is harness engineering -- combining verifier agents with deterministic tooling like linters and tests, and mining conversation logs for the moments a user says this is wrong so the missing context can be saved and reused. Memory, hooks, skills, registries -- all just delivery mechanisms for the same underlying thing. Patrick's number one piece of advice if you are starting today is brutal in its simplicity. When the agent does the wrong thing, write it down in your AGENTS.md or claude.md. Do not just re-prompt and move on. Build the context file. That is the new job. Code moved to context. Context, eventually, moves to knowledge -- the way your organization actually works, captured somewhere an agent can use it. Whoever owns that layer wins. The model does not. Patrick's contact information: LinkedIn: https://www.linkedin.com/in/patrickdebois/ X: https://x.com/patrickdebois YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#336: The workplace is on the verge of a transformation as significant as the Industrial Revolution. Just as Bring Your Own Device policies emerged after the iPhone disrupted corporate mobile standards, we are now entering an era where employees may arrive with their own AI teams in tow. The question is no longer whether AI will change hiring and employment - it is how quickly companies will adapt before being left behind by competitors who embrace this shift. Current AI productivity gains remain largely individual rather than organizational. Writing code twice as fast means nothing if the deployment pipeline stays the same speed. But within five to ten years, entire industries face disruption - from primary care physicians to transportation to knowledge work. Companies clinging to restrictive AI policies today risk driving away top talent who have already integrated these tools into their workflows. The intellectual property implications alone - who owns an AI stack trained on company processes when an employee leaves - will require entirely new frameworks for employment law. Darin and Viktor explore these scenarios through the lens of a hypothetical job interview where a candidate brings their own team of AI agents. The conversation surfaces uncomfortable questions about compensation models, corporate governance, and whether we are witnessing the emergence of a new kind of talent that blends human expertise with digital capabilities. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#334: The debate over whether AI saves developers time misses a fundamental truth: coding was never the hardest part of software development. Writing code is mechanical work - the real challenges have always been understanding problems, designing solutions, communicating with stakeholders, and navigating organizational complexity. AI is now forcing a reckoning with this reality, pushing developers at every level to reconsider what skills actually matter. The traditional separation between architects who design and developers who implement is breaking down. AI enables a return to something like pair programming, where the person thinking through problems can now work alongside a fast executor without the old bottleneck of slow human typing. This shift means developers need stronger communication skills - the ability to explain technical decisions to non-technical stakeholders and translate business requirements into technical direction. For juniors, the opportunity is unprecedented: you can upskill faster than ever in the history of software, but only if you balance building things with actually understanding how they work. Darin and Viktor explore what this means for developers at every career stage, from juniors who should focus on fundamentals and end-to-end understanding, to seniors who are becoming more like editors and supervisors of AI-generated work. The developers who will thrive are those who combine real experience with a willingness to embrace change - and that combination has always been the winning formula. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#332: AI adoption in enterprise software development is accelerating, but operations teams are lagging behind. While application developers embrace AI tools at a rapid pace, those on the ops side remain skeptical—citing concerns about determinism, control, and a general resistance to change. This mirrors previous technology waves like containers, cloud, and Kubernetes, where certain groups initially pushed back before eventually adapting. The prediction for 2026: AI will not see widespread adoption in operations despite its growing presence elsewhere in the software lifecycle. The bigger challenge facing organizations is not just adopting AI but transforming entire processes to take advantage of it. Improving just one piece of the software delivery pipeline—like development speed—only creates bottlenecks elsewhere. Companies cannot hand developers AI tools while keeping everything else the same and expect transformational results. The future points toward a world where experts bring their own AI agents to companies: personal toolsets trained on their experience and best practices that integrate with organizational systems. Perhaps the most provocative insight centers on the value of writing code itself. The argument: writing code is the easiest and least valuable part of software development. The real cognitive load comes from thinking through requirements, architecture, and design. Developers who simply translate instructions to code without deeper engagement may find themselves in real danger as AI continues to advance. Darin and Viktor explore these predictions and more as they look ahead to what 2026 might bring for DevOps, platform engineering, and the evolving role of developers. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#330: In this short episode, Darin and Viktor reflect on the holiday season. YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#328: The build versus buy decision isn't as binary as most companies think. Every technology choice involves elements of both - you might use Linux (buy) but still configure and customize it extensively (build). The real question isn't whether to build or buy, but finding the right balance between the two approaches based on your company's resources, size, and unique requirements. Companies often fall into the trap of thinking their processes are so unique that existing solutions won't work, leading to unnecessary custom development. This "not invented here" syndrome is particularly common in large enterprises that mistake their size for complexity. In reality, most businesses face challenges that have already been solved by others. The key is recognizing when you truly need a custom solution versus when you can adapt existing tools. The decision becomes more nuanced when considering factors like maintenance costs, compliance requirements, and long-term sustainability. Building internally requires ongoing resources for updates, security patches, and knowledge retention within your team. Meanwhile, buying from vendors shifts much of this burden but introduces dependencies and integration challenges. The conversation features insights from Alex Gusev from Uploadcare, along with perspectives from hosts Darin and Viktor on navigating these complex technology decisions. Alex's contact information: X: https://x.com/alxgsv LinkedIn: https://www.linkedin.com/in/alxgsv/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/

#326: Microservices architecture has evolved far beyond simple distributed systems, but most development teams are still rebuilding the same foundational patterns over and over again. Mark Fussell, co-founder of Dapr and Diagrid, explains how his team at Microsoft identified this repetitive reinvention problem and created a solution that abstracts away the complexity of service discovery, messaging, state management, and security while providing true cloud portability. Dapr emerged from Microsoft's Azure incubations team with a clear mission: stop forcing developers to rebuild distributed systems patterns from scratch. The runtime provides standardized APIs for common microservices needs while allowing teams to swap underlying infrastructure components without changing application code. Whether using Kafka, RabbitMQ, Redis, or cloud-native messaging services, developers write against consistent APIs while platform teams maintain control over infrastructure choices. The conversation covers Dapr's journey from Microsoft internal project to CNCF graduated status, the technical decisions behind its multi-language approach, and how it integrates with existing frameworks like Spring Boot and .NET. Mark also discusses Diagrid's platform play around durable workflows and the emerging role of Dapr in AI agent development. Darin and Viktor explore the practical adoption challenges, the balance between developer productivity and platform engineering concerns, and why experienced developers tend to embrace abstraction layers more readily than those building their first distributed systems. Mark's contact information: X: https://x.com/mfussell LinkedIn: https://www.linkedin.com/in/mfussell/ YouTube channel: https://youtube.com/devopsparadox Review the podcast on Apple Podcasts: https://www.devopsparadox.com/review-podcast/ Slack: https://www.devopsparadox.com/slack/ Connect with us at: https://www.devopsparadox.com/contact/