DevOps Paradox

#356: Fleet management means one thing to a DevOps engineer and something completely different to Tomas Kovacovsky. To Viktor it is a CD problem - a fleet of Kubernetes clusters he would rather not babysit. To Tomas it is hundreds of physical robots rolling around a warehouse, picking orders, dodging each other, and working very hard not to lose their connectivity. Tomas is the CTO of Brightpick, where the robots are not the kind you yell at for bumping into a chair. They are three-meter-tall autonomous pickers - some telescoping up to six - that find their way using lidar, recognize items with neural networks, and make their own decisions the second the network drops. Here is the part that will feel oddly familiar: everything you already do to ship software shows up again in the physical world. Canary rollouts. Rollbacks to the last good config. Prometheus scraping every robot, Grafana for the fleet. Logs, metrics, traces. Split brain, when a robot and the server disagree about what just happened. Even a flaky robot - one that feels off with no error to point at - gets diagnosed the same way you would hunt a flaky test: compare it against the rest of the population and find the outlier. A warehouse full of robots, running like a distributed system. The stack is what you would guess and also not. C++ on the robots for speed, Python on the backend, Kubernetes on an edge server inside the warehouse because latency matters down to the millisecond, and Git as the source of truth - the on-site servers check for differences and update themselves. GitOps, for robots. Then it gets bigger. The optimal pick speed, Tomas says, is infinity - right up until you try to pick an egg. The real bottleneck was never the picking, it was the traveling, so Brightpick moves the picking into the aisles instead of hauling totes back to a station. He also drops a prediction worth chewing on: the intelligence arrives before the dexterity. Machines will think their way around a warehouse long before they can fish for keys in a bag the way your hand does without looking. And the jobs question everyone braces for - the robot guys walking in, are you fearful for your job in 20 minutes - turns out the picker positions were mostly empty to begin with. Hundreds of thousands of them, unfilled. The takeaway for anyone writing software is the one Tomas lands at the end. The craft is getting eaten. What is left, and what actually matters, is whether you can connect the work to the product. Tomas' contact information: LinkedIn: https://www.linkedin.com/in/tomas-kovacovsky-46411280/ 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/

#354: How do you build a consent system for someone who is dead? How do you clone a voice so it cannot be turned into a deep fake? Miles Spencer built a company around those exact questions. Reflekta.ai lets you talk to a reflection of someone who has passed. His own father reads a bedtime story to his granddaughter every night and talks it through until she falls asleep, eight years after he died. Is this just deep fake with better branding? What happens when the AI goes off the rails and asks grandpa for the three numbers on the back of a credit card? Miles has an answer for each one, and most of them land on the same line: you built it, you paid for it, it never leaves your four walls. Nothing gets scraped. There are only two public reflections on the entire platform. The voice of his dad came from a ten-second voicemail found on a relative's phone five years after he was gone, and last month that voice had 9,000 conversations. More than half the stories on Reflekta are from people who are still alive. ALS and Alzheimer's patients getting it all down while they still can. Founders who want their values to outlast them. And that last group is where it gets interesting for anyone who runs a company. New hires talk to the founder during onboarding. Ask a question about the business and the founder answers. SOPs, handbooks, the whole thing, in the voice of the person who built it. Miles calls the framework SoulTech, starting from the emotional weight of the product instead of bolting ethics on at the end. Agree with the premise or not, the stack underneath is less exotic than it sounds: multi-cloud, RAG, three voice vendors swapped by time of day, 110 days from idea to launch. Darin's verdict by the end is honest. The dead-relative part is still not his jam. But the founder who never leaves the building, the one who onboards every new hire forever? That one he gets. Miles' contact information: LinkedIn: https://www.linkedin.com/in/milesspencer/ 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/

#352: Vibe coding is the latest version of a promise the industry has been making since the first generation of programming languages. Type what you want, get an app. Jeff Kuo from Ragic has been working on the no-code version of that same promise for almost twenty years. He has thoughts on why the promise keeps not quite landing. The honest answer is that AI-assisted coding is great for people who already know what the code is doing. It is counterproductive for everyone else. A non-developer can generate a lot of code. They cannot maintain any of it. That gap is where every weekend vibe-coded project goes to die six months in, when the codebase has ballooned and the AI is in a loop confidently identifying the wrong root cause for the seventh time. So what does work? Jeff's argument is that no-code platforms become the guardrail AI actually needs. Strip the infrastructure layer away, leave only the business logic, and the model only has to reason about one thing at a time -- which is the one thing today's models are good at. Ragic generates form and report definitions, not code, and the Java engine underneath does the rest. There is also the strange consumer behavior nobody is talking about. People love AI chat boxes in tools they have never used before. They close AI chat boxes in tools they already know. Which means the future of AI-native software might not belong to the incumbents at all -- it belongs to the new tools being built right now for users who do not have any muscle memory to defend. And one piece of advice that has aged perfectly across forty years of software: the maintenance is the thing that keeps you awake at night. AI makes it faster to build things from scratch and harder to maintain anything at scale. Begin with the end in mind. Or do not, and become the next cautionary tale. Jeff's contact information: LinkedIn: https://www.linkedin.com/in/ragic/ 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/

#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/