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/

#349: Every platform you already own is about to have AI baked into it. Not next year. This year. That is Ben Wilcox's blunt prediction, and Ben is the CTO and CISO at ProArch, so when he says shadow AI is going to make shadow IT look quaint, it is worth slowing down to figure out what that actually means. The data leaves your stack through tools you already paid for, through features the vendor shipped without asking, through copilot agents nobody filed a ticket for.
Here is the uncomfortable part. This is not a new problem. It is the exact same retroactive-security failure pattern that broke DevSecOps, just with higher stakes and a faster clock. A pen test done six months ago is already obsolete because the app added AI in the meantime. Models get deprecated on seven-month windows while frameworks still get years of support. The whole "we will deal with it at the end" approach that worked badly for cloud and worked worse for containers is going to be catastrophic for AI.
The fix is older than the problem. Landing zones. Well-architected frameworks. A storage account that already has the right policy. An API gateway already in front of the API. The developer should not be picking from twenty checkboxes to figure out which combination is secure -- that decision should already be made before the ticket lands. Stop forcing developers onto the security team. Stop running security reviews while the head developer sweats through his shirt right before release. Build the foundation up front and let the developer deploy into it.
Then the harder question. The leaders making these calls today are the same engineers who lived through every prior cycle of this exact pain. Why are they letting another generation eat it again? Viktor's answer is one line: "It's my time now, baby." Ben does not disagree. PE pressure, VC timelines, race-to-market everything -- the budget exists, the tools exist, the patterns exist. What is missing is the will to invest two weeks up front so the last two months do not turn into panic. Ben's practical advice for any leader dipping a toe in: do not do it alone, inventory everything, talk to sales and finance and the developers, and assume the conversation you are having today will be obsolete in six months.
 
Ben's contact information:
LinkedIn: https://www.linkedin.com/in/ben-wilcox/
 
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/

Something flipped this year. Chatbots were a toy. Useful sometimes, but a toy. Agents are not. Agents take actions, hold credentials, write code, move Kanban cards, and run on cron schedules. The window between "this is interesting" and "this is existential" has closed faster than cloud, faster than Kubernetes, faster than any prior shift.
Viktor's read is blunt. One person can now build a bigger business than most mid-size companies have ever managed. That is not hyperbole -- that is a description of what is already happening with a handful of solo-built projects shipping in weeks what used to take a hundred-person org years. The thesis: panic. Not because the sky is falling, but because larger companies cannot turn around overnight, and the gap between the people who get this and the people who are still scheduling meetings about scheduling meetings is widening every week.
The conversation walks through what each big provider is actually doing. AWS is not pretending to compete on models -- they want the inference revenue. Microsoft is lost in Copilot button-stuffing. Google is quietly winning on three layers at once: TPUs, models, and inference infrastructure. Anthropic is on the path to becoming the next defining IPO, while OpenAI looks like a place to take money out of, not put more in. The Linux Foundation's new Agentic AI foundation got Anthropic's MCP, Block's Goose, and OpenAI's AGENTS.md spec. Viktor's reaction: those are heavy hitters donating not very much.
Then it gets practical. Vendor-provided agents are like hiring a genius engineer who knows nothing about your company. Public skills are mostly nonsense -- if it is in public training data, the model already knows it; what is missing is everything specific to you, which is exactly what no public skill can provide. OWASP just published an Agentic AI Top 10 and most of it is least-privilege rebranded for agents. The cost story is also not what the marketing says: a 00 monthly subscription will not last a day for anyone working full-time with agents. There is a true story in here about a leaked token that turned a 00 monthly spend into 5,000 in two days.
The hardest part of the episode is the part nobody likes hearing. If your output stays the same in 2026, you are in trouble. If you multiply your output, you are fine. Companies have always wanted to do more than they could afford to do. Now they can. The middle is where careers used to live. The middle is where the cuts are going.
 
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/

#347: Andrei Kvapil has been around Kubernetes since the early days. Contributor to Cilium, Kubevirt, and a handful of other projects you probably use without realizing it. He is also the maintainer of Cozystack, a CNCF sandbox project, and the CEO of Aenix, the company behind it.
The thesis: Kubernetes should be boring. Not exciting, not cutting-edge, not the thing everyone argues about. Boring like the Linux kernel is boring. Something that sits underneath everything and nobody needs to think about. Viktor takes it one step further and says it should be invisible -- developers should never need to know Kubernetes exists, any more than they need to know what kernel their laptop is running.
Cozystack is Andrei's answer to a specific problem. ISPs, banks, finops shops, anyone in Europe who cannot or will not put their data in AWS -- they all want to offer managed databases, managed Kubernetes, object storage, the whole stack. Building that from scratch is hard. Running OpenStack requires a dedicated team that does nothing but tune networking. Cozystack bundles the pieces (Kubevirt, CloudNative Postgres, Cilium, etc) into one product with an aggregation API layer on top of Kubernetes itself. Helm becomes the extension language. The platform becomes a product.
Then the conversation takes a turn. Andrei is the CEO of a bootstrapped company and he says flatly that without AI the company would not exist. Claude Code is moving Kanban cards. Clients send files generated by their AI agent and Aenix feeds those files to their AI agent to generate the response. Andrei's only wish is for this middle step -- him -- to stop existing. Let the agents talk to each other and call him when something actually matters.
There is a hiring question in here too. If the next generation of engineers starts their career with AI on the first commit, do they ever build the mental model that lets them guide the agent when it goes wrong? Andrei thinks you still need deep understanding for anything serious. Viktor agrees. Speed versus quality is still a choice, and juniors who skip the "write it three times until it stops being garbage" phase are going to feel that gap eventually.
 
Andrei's contact information:
LinkedIn: https://www.linkedin.com/in/kvaps/
 
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/

#346: Drive-by PRs, AI slop, maintainers burning out -- the open source world is having a meltdown and everyone wants to blame the robots. Viktor isn't buying it.
The real problem started long before AI. Contributing to most open source projects has always depended on tribal knowledge and obscure docs nobody reads. AI didn't break that. It exposed it. When contributions were trickling in, you could get away with onboarding people via vibes. Now that contributions are a firehose, you can't.
Viktor's take cuts in a direction that will annoy a lot of maintainers: your primary job is empowering contributors, not gatekeeping. And if a 20,000-line PR is drowning you, the answer isn't to block everybody. The answer is to change the whole review cycle -- because yesterday you were complaining about not enough contributions and today you're complaining about too many. That's a great problem to have. Solve it.
Here's the part that will upset people. Viktor reframes what a developer's job actually is. If you think your role is typing on a keyboard, you're going to be disappointed. Your role is becoming a product manager. Asking the agent did you look at this, are you sure, what about that. Your job is no more. You just didn't receive the memo.
There's also a thread running through the episode about auditing. Can you actually assess the health of an open source dependency you depend on? Viktor dares Darin to audit Kubernetes. Or curl. Or anything. Humans can't do it at all. AI can -- imperfectly, but better than nothing. Which means the old enterprise model (pay Red Hat, they'll handle it) starts to wobble when the value of someone else handling it drops because the tools can handle it for you.
And there's a prediction. Right now when you ask AI to build something, it picks libraries based on training data. But what happens when the agent actually goes shopping -- analyzing projects, reading docs, deciding which dependencies to pull in? That changes the open source landscape in a way nobody is ready for.
The episode ends somewhere quieter. Contributors, human or AI, should be cherished and trained over time. The hostility toward AI contributions is coming from maintainers who forgot that investing in new contributors is the job. The tools will make a mess. Then they will make less of a mess. Eventually we will be arguing about whether the feature should exist at all -- not whether the code compiles.
 
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/