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

#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 width. Viktor points out this is the exact same pattern from the early agile days: his team shipped every two weeks, but testing still took six months. Different era, same structural problem.
Feature flags are part of the fix, but not the way most people use them. Teams are now stuffing prompts, token limits, and temperature settings inside feature flag configurations and running A/B tests on AI agents in production. That's a long way from changing button colors on a marketing page, which is where experimentation started 15 years ago.
The culture problem is harder than the tooling problem. Trevor has watched teams run one experiment, see it fail, and quit experimenting entirely. The fear of admitting failure kills more experimentation programs than bad data ever will. Meanwhile, the companies getting real results -- a fast food chain generating millions from kiosk experiments, a global bank driving hundreds of millions in customer acquisition -- are the ones treating experimentation as a permanent operating model, not a one-off project.
The conversation also covers Trevor's path from co-founding Split to running it inside Harness post-acquisition. He stayed -- which doesn't happen as often as you'd think. Harness runs what he calls a 'startup within a startup' model, and he breaks down what that actually looks like from the inside, what was hardest to let go of, and why finding your 'why' matters more than any exit.
 
Trevor's contact information:
LinkedIn: https://www.linkedin.com/in/trevorbstuart/
 
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/

#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:
https://www.devopsparadox.com/contact/

#339: DNS has been around since the 1980s. Nobody's writing blog posts about how it changed their life. But every single thing on the internet depends on it -- including all those AI tools everyone's excited about.
Anthony Eden has been in the DNS business since the late nineties, when he was CTO of one of the first seven domain registrars after the .com deregulation. In 2010 he started DNSimple, and he did it without a dime of venture capital. Sixteen years later, his 20-person team runs a global DNS infrastructure with 14 edge nodes and 9 origin servers spread across multiple continents.
The conversation covers the mistakes companies make with their domains -- running production DNS on a registrar that was never built for it, sharing logins with no access control, zero documentation on why records exist. Anthony breaks down how DNS actually works at scale (unicast vs anycast, the onion layers of resolvers), why your email deliverability problems are probably a DNS problem, and what the www vs no-www debate looks like in 2026.
On AI tools, Anthony's take is practical. They're giving his engineers more time to think about problems instead of typing out solutions. But he's not buying the vibe coding hype -- when you run critical internet infrastructure, everyone on the team needs to understand the systems they're building. And for AI startups hoping to cash out? Most will fail. The twist you put on somebody else's model won't be a moat. It'll just become a feature for something bigger.
 
Anthony's contact information:
X: https://x.com/aeden
Bluesky: https://bsky.app/profile/anthonyeden.bsky.social
LinkedIn: https://www.linkedin.com/in/aeden/
 
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/

#338: Every company adding AI coding tools runs into the same wall. Developers produce more code, but features don't ship any faster. The bottleneck just slides downstream -- to QA, to security, to legal, to whoever comes next in the pipeline. And the team that got faster? They don't even realize the people upstream could be feeding them more work.
Viktor's take: the fastest possible setup is one person carrying a feature from idea to production. Not one person doing everything alone -- a system designed so nobody waits. Tests run in CI. Deployments happen through Argo CD. Security scanning is automated. There's a real difference between wiring up a light switch and hiring a butler to flip it for you.
None of this is new. The same thing happened with punch cards, client-server, cloud, Kubernetes. One group adopts the new thing, everyone else says it doesn't apply to them, and the market eventually forces their hand. Meanwhile, every team in every company says they'd love to change if only the rest of the organization would get on board. Every team says this. So who's actually blocked?
 
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/