#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. The Gateway API now has an inference extension in beta -- model routing baked directly into the Kubernetes networking layer. And here's the thing Whitney pointed out that should make everyone pause: you can't even run inference workloads in containers. They can escape. You need micro VMs. So the container orchestrator is orchestrating things that aren't containers.

The platform engineering conversation shifted too. The bottleneck isn't technology anymore -- it's culture. Getting teams to work together differently. And if your company can't trust its own employees to make decisions, good luck trusting agents. Viktor's take on the determinism objection was blunt: agents aren't deterministic, but neither are you. You just think you are.

One thread that kept surfacing: agents as first-class platform users. Not agents doing agent things -- agents as the users your platform serves. Viktor sees it in real time -- pull requests created by agents, reviewed by his Claude, responses written by the submitter's agent. Humans aren't even in the conversation anymore.

The new CNCF sandbox projects tell the story too. LLM-D, KAI Scheduler, Higress (AI-native gateway). And then Velero -- the Kubernetes backup tool that everyone assumed was already CNCF -- finally donated by Broadcom. Which raises a fair question: is CNCF becoming a dumping ground for projects companies don't want to maintain? Probably some of both.

Viktor compared the current state to the first five years of Kubernetes -- everyone focused on low-level components, trying to figure out how to combine 57 different tools. The next wave will be higher-level platforms that bundle all of it. And somewhere underneath it all, the mainframe keeps running. Viktor's bet: it'll outlive AI.

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

#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 object. Fine when another service is calling it. But a model? All those extra fields are context you're paying for, and they make the model hallucinate. Matt says you need something between the model and all those backend services -- an orchestration layer that takes one request and handles the mess underneath. That's where GraphQL comes in.

He draws a parallel that'll land immediately if you've been in this space a while. APIs right now are pets -- handwritten, named, carefully managed. But AI-generated code is about to produce way more microservices, which means way more APIs. They're going to become cattle. And just like containers needed Kubernetes, APIs are going to need declarative infrastructure to manage them at scale.

The conversation takes an interesting turn when Darin pushes back on the idea that developers are becoming architects. His take: we're becoming product managers. Matt says both. Viktor throws in code reviewers. Matt's own story backs it up -- he codes more as CEO than he did as CTO, because AI handles the parts he never had time to learn. He doesn't know modern React. Doesn't need to.

One more thing that should make any tech company uncomfortable: if AI agents are how customers find you now, what happens to your docs-page-driven acquisition funnel? Apollo's already made the shift -- their first audience for documentation is the models, not the humans.

Matt's contact information:

LinkedIn: https://www.linkedin.com/in/debergalis/

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/

#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 Slack thread, somebody's head -- but it's not where anyone would think to look for it.

The running system itself is the most accurate documentation any company has. Your Kubernetes cluster tells you how many pods are running right now. Git tells you how many you wished you had. Those aren't the same thing, and pretending Git is the source of truth is a comfortable lie most teams tell themselves daily.

RAG won't save this. Not the way most people imagine it -- point an agent at your docs and let it answer questions. That fails for the same reason Google's old enterprise search appliance failed. What could work is a continuous process that watches every information source, extracts what matters, and updates a central location intelligently. We have the pieces for this. Nobody's built it yet.

The practical path forward: audit what you have before building anything new. Instrument your documentation the way you instrument applications -- find out what people search for and can't find. Design for retrieval, not storage. Build feedback loops. And stop treating documentation as a project with an end date. The companies that treat this as a strategic advantage instead of a chore are the ones that will actually make AI work for them.

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/