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,...
info_outlineDevOps Paradox
#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...
info_outlineDevOps Paradox
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...
info_outlineDevOps Paradox
#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...
info_outlineDevOps Paradox
#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...
info_outlineDevOps Paradox
#345: Vibe coding works fine until your project gets complicated. That's the gap Amit Patel and his team at AWS built Kiro to fill. The tool launched with about six people in mid-2024, hit GA around October 2025, and the team still fits in a single room -- maybe a seven-pizza team by Darin's math. The core idea is spec-driven development, but not the kind where business analysts disappear for five years and come back with a document nobody needs anymore. Amit's version: you tell the agent what you want in a chat prompt, it writes the spec for you, and you iterate on it. Twenty minutes of back...
info_outlineDevOps Paradox
#344: Kubernetes is boring now. That's the whole point. KubeCon EU 2026 in Amsterdam -- likely the biggest KubeCon ever at more than 13,000 attendees -- made one thing extremely clear: the container orchestrator is done being interesting on its own. Every keynote, every new sandbox project, every vendor announcement pointed the same direction. AI. Inference. Agents. NVIDIA donated a DRA driver for GPUs to CNCF. Google open-sourced their cluster autoscaler and shipped a DRA driver for TPUs. Red Hat brought LLM-D for disaggregated inference. NVIDIA contributed the KAI Scheduler for AI workloads....
info_outlineDevOps Paradox
#343: Here's the thing about your company's APIs -- they were built for your own engineers to use inside your own software. Nobody designed them to be the front door. But that's exactly what's happening. Matt DeBergalis, CEO of Apollo GraphQL, makes a pretty compelling case that AI agents are turning internal APIs into the actual interface between companies and customers. Not the website. The APIs themselves. And most of them aren't ready for that. At all. Think about what happens when you point a model at a typical REST API. GitHub's API returns hundreds of fields for a single repository...
info_outlineDevOps Paradox
#342: Most companies have plenty of documentation. The problem is almost none of it is findable, current, or true. Between what's documented, what's actually true, and what people actually do, there are gaps wide enough to kill any AI initiative before it starts. Viktor makes a distinction that reframes the whole problem: there are two types of documentation. Why something was done -- that's eternal. How something works -- that's outdated the moment someone changes a config and forgets to update the wiki. The information about that change probably exists somewhere -- in a Zoom recording, a...
info_outlineDevOps Paradox
#341: Nobody's arguing about whether you need feature flags in 2026. That debate ended years ago. But the code flowing through those flags? That's a different story. AI is writing more of it than ever, review times are climbing, and delivery throughput has actually declined. Trevor Stuart, co-founder of Split.io and now running Feature Management & Experimentation at Harness, calls it the six-lane highway ending in a two-lane bridge. The bottleneck didn't disappear. It moved. Coding got faster, but everything downstream -- reviews, security scans, delivery pipelines -- stayed the same...
info_outline#340: The smartest ops people are often the most likely to resist new technology -- and they're not wrong. If you don't change anything, nothing breaks, and nobody blames you. That's a completely rational choice. It's also the one that guarantees you fall behind. Bare metal to VMs, VMs to cloud, cloud to Kubernetes -- every time, the teams that played it safe ended up scrambling to catch up two years later. The safe bet isn't safe. It just feels that way.
It gets worse when you look at where the tools come from. Kubernetes? Built by developers. Terraform? Developers. Containers? Developers. The tools ops teams depend on were made by a different tribe. So the pushback isn't really about whether the tech is ready or whether the risk is too high. It's about identity. 'Not my people' is a harder objection to overcome than 'not ready yet,' because no amount of documentation or proof-of-concepts answers it.
And about proof -- everyone wants it before they'll move. But the proof already exists. It's the tool someone on your team has been running in shadow IT for a year without any official support. If it survived that long on its own, that's stronger evidence than any pilot program. That's your roadmap. And the way in is small chunks, not grand plans. Move one service. Learn something. Adjust. Repeat.
AI in ops follows the exact same pattern. A tool that gets you 50% of the way there for free means you can focus your expertise on the other 50%. That's a win. But the people waiting for AI to be perfect before they'll touch it? They're making the same mistake as the teams that waited for perfect proof before migrating to the cloud. Different decade, same trap.
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: