loader from loading.io

DOP 349: Shadow AI Is Going to Be a Thousand Times Worse Than Shadow IT

DevOps Paradox

Release Date: 05/06/2026

DOP 350: Context Is the New Bottleneck, Not Code show art DOP 350: Context Is the New Bottleneck, Not Code

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_outline
DOP 349: Shadow AI Is Going to Be a Thousand Times Worse Than Shadow IT show art DOP 349: Shadow AI Is Going to Be a Thousand Times Worse Than Shadow IT

DevOps 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_outline
DOP 348: Now It's Time to Panic show art DOP 348: Now It's Time to Panic

DevOps 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_outline
DOP 347: Cozystack Turns Bare Metal Into a Managed Services Platform show art DOP 347: Cozystack Turns Bare Metal Into a Managed Services Platform

DevOps 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_outline
DOP 346: Fighting AI in Your Project Is a Terrible Mistake show art DOP 346: Fighting AI in Your Project Is a Terrible Mistake

DevOps 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_outline
DOP 345: From Chat Prompt to Working Software with Kiro show art DOP 345: From Chat Prompt to Working Software with Kiro

DevOps 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_outline
DOP 344: KubeCon EU 2026 Review show art DOP 344: KubeCon EU 2026 Review

DevOps 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_outline
DOP 343: Your APIs Were Never Built to Be the Front Door show art DOP 343: Your APIs Were Never Built to Be the Front Door

DevOps 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_outline
DOP 342: Your Company Documentation Is Useless for AI show art DOP 342: Your Company Documentation Is Useless for AI

DevOps 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_outline
DOP 341: AI Widened the Highway but Nobody Rebuilt the Bridge show art DOP 341: AI Widened the Highway but Nobody Rebuilt the Bridge

DevOps 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
 
More Episodes

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