DOP 368: The AI Productivity Paradox

#368: You're faster with AI. Your teammates are faster with AI. More tickets closed, more deployments going out than a year ago. So why can't anybody in the building answer a simple question: are we shipping more value? Jeff's take is that the bottleneck didn't go away, it moved. Code got cheap. Deciding what to build, why, and whether it actually worked did not. That's not an engineering problem anymore. It's a product problem. In this episode, we speak with Jeff Keyes, Field CTO at Allstacks, about where the bottleneck went once AI made coding cheap, and why product people have to pick up the tools next.   Jeff's contact information: LinkedIn: https://www.linkedin.com/in/jeffdkeyes/   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/

#367: Every few weeks another pitch lands. A company with no employees, just a founder and an army of AI agents. Zero headcount. Zero payroll. Then the AI CMO hallucinates a marketing campaign and somebody has to catch it. Viktor runs the numbers on his own one-person operation. He can review maybe five things a night. Want a hundred a day? That is nineteen more people. The math is not kind to the pitch. In this episode, Darin and Viktor discuss why zero-human is the new serverless, and where the humans actually go once the agents are doing the work.   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/

#366: You ran npm install this morning. Maybe you ran it a dozen times. Every one of those pulled down a dependency tree you have never read, from a registry that spent years in maintenance mode, and then executed whatever preinstall and postinstall scripts happened to be in there. On your laptop. With your keys sitting on disk. Trusted publishing, provenance, staged releases - all good, all recent, and none of it stops a package from shipping malware. In this episode, we speak with David Mytton, CEO of Arcjet, about defense in depth for the npm ecosystem, and why seven days of patience beats most of your tooling.   David's contact information: LinkedIn: https://www.linkedin.com/in/davidmytton/   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/

#365: A bad engineer with a laptop is much worse than a bad engineer with a calculator. Now hand that engineer AI. DORA's ROI report puts it politely - AI without engineering excellence just scales your problems. Except it's not more of everything. It's more of whatever you were already doing, and there's a statistical chance that what you're doing is bad. Your agent already read your flaky tests and decided that's the house style. So what do you measure now? Viktor's answer: every technical metric you've got is gamed.   ROI of AI-assisted Software Development report https://dora.dev/ai/roi/report/   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/

#364: Your CEO comes back from a leadership offsite talking about burnout-proof leadership and AI transformation at scale. Two weeks later you're working through lunch, you're working through dinner, and Slack never stops. Deployment frequency is up. Incidents are up worse. So who was that program actually protecting? In this episode, we speak with Dr. Victoria Mensch, Founder and CEO of the Silicon Valley Executive Academy, about what really goes on at those offsites, and why Nokia, BlackBerry and Blockbuster all saw it coming anyway.   Victoria's contact information: LinkedIn: https://www.linkedin.com/in/victoria-mensch/   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/

#363: Three waves of the web, and you are late for the third one. The 90s were about getting a browser to render your page at all. The early 2000s were about SEO, or as Darin puts it, sell me all the ads ready. Now it is agent ready, and Cloudflare built a scoreboard for it at [isitagentready.com](https://isitagentready.com/). The devopsparadox.com site scored about 70 out of 100 and then went down when Cloudflare added new checks. Run yours. You will be sad. Viktor thinks the framing is slightly off, though, and the correction is the good part. Optimizing for agents that browse your site is aiming at the wrong thing, because most requests never touch your server. Agent asks the model, model answers, agent shows you. So the target is not the crawler, it is the training data - and if the model does go looking, the question becomes whether you are the first answer or one of the five sites it was told to go analyze. Same game as Google. Different index. It is not Google index anymore, it is model training now. Then the practical part. Five things Cloudflare scores you on: discoverability, content, bot access control, API, Auth, MCP & Skill Discovery, and Commerce. Content accessibility is where most of you are losing, because agents want Markdown and you are serving them a pile of HTML tags to strip. Both DOP and Viktor's site are Hugo, so the Markdown is already sitting on disk next to the HTML - serve one or the other based on what the request asks for. Almost no effort. If you are still shipping a JavaScript-rendered site, Darin says it is game over, and humans do not like those either. On the blocking side, both of them are baffled by the same thing: if you do not want agents reading it, do not publish it. robots.txt is a suggestion at best. If you really want to block, actually block. The API argument is the one that will annoy people. Viktor says CLIs and MCP servers are both auto-generated from a schema, so the real work is having a good API, and most companies do not. But who your audience is decides the wrapper - developers already have Bash, so give them a CLI and get out of the way. Everyone else needs MCP, because Viktor's mom is not installing your binary. And somewhere in the middle of all this Darin asks whether documentation should live in the code now more than ever, and Viktor says no, less than ever - he wants it separate so he can review it, because agents made everything cheap to produce and review is now the only thing standing between him and 5,000 features a day. Also: WordPress should be the last thing you consider, not the first.   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/

#362: Feature flags or canary deployments - do you need both? Viktor puts it to Alex Casalboni from Unleash, who says he argues about this with his colleagues roughly every day, and the answer lands clean. Switching a hostname, a database, an API vendor? That is infrastructure, nothing to do with who the user is, so keep your canaries and your blue-green. But a canary switches one thing at a time. Try running three A/B tests and ten behavioral changes through it and the whole approach buckles. Anything that needs to know who the user is belongs in a flag. Different layers of the stack, different tools, and most teams will end up with both whether they planned to or not. Back up, though, because there is a new word attached to all of this. FeatureOps. There is a manifesto and everything, sitting at [featureops.io](https://featureops.io/), reading a lot like someone nailed 95 theses about feature flags to a door. Real discipline, or marketing wrapper? Alex gets about ten seconds of pleasantries before he has to answer for the word. His defense is narrower than the name suggests, and better for it: every ops discipline we have gets you to the deployment and then waves goodbye. Something breaks, you go around the whole loop again - hotfix, pipeline, 20 or 30 or 60 minutes, fingers crossed. FeatureOps is the claim that the same principles apply after the code is already running. Runtime control. Alex says enterprise customers routinely have a 12 to 24-hour round trip between finding a problem and getting the fix live. Even for a hotfix. Viktor is not letting the seconds claim through unchallenged. If it takes you a day to notice and two seconds to flip, that is a day and two seconds - so stop measuring from the convenient starting line. Alex concedes the framing and then goes somewhere better with it: the bottleneck was never the clicking. It is the humans and the bureaucracy in between. Which is why Unleash is pushing impact metrics, where the SDK sends error rates back and the system kills the feature itself, no human in the loop. Then Darin calls BS on immutable event log, because there is no such thing as immutable data, and Alex takes the hit cleanly - fair, it is append-only with locked-down keys, not magic. Nobody puts this part on a landing page. Flag evaluation has an input, not just a true/false output, and that input is user context - which means an external API call is not just latency, it is your PII leaving the perimeter. A compliance problem hiding inside a performance decision. And the flag graveyard is worse than you think: companies create roughly ten flags for every one they clean up, and Alex has a customer whose oldest flag dates to 2012. His fix is an MCP server that opens the cleanup PR for you when you mark a release complete. Best line of the day, on whether flags complicate your code: everything complicates your code, and the best way to not complicate your code is to not code.   Alex's contact information: LinkedIn: https://www.linkedin.com/in/alexcasalboni/ X: https://x.com/alex_casalboni   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/

#361: Picture a 6,000-line pull request landing in your project from someone you've never heard of. Every test passes - yours, theirs, all of it. And you can tell it was generated. Not assisted. Generated. What do you do with it? Viktor's first move is to poke the premise: how do you even know it was generated and not assisted? You can't. Nobody can. That distinction is already gone. So the real question isn't whether AI wrote it. It's what a maintainer is for. Viktor's answer is blunt - a maintainer's first job is to guide people in and help them contribute, and if you think your job is mainly to write code, you picked the wrong role. The moment you allow PRs, you stopped being an individual contributor and became a manager. That's the job. You don't get to complain about the job you signed up for. Don't want it? Fine - do what Ghostty did, do what curl did, turn PRs off and say so out loud. Just don't hide behind unknown contributors, because every single person on your project was an unknown contributor on their first commit, including you. A software developer says send me anything but a PR and lists four reasons: unknown contributors are a security risk, supply chain attacks are real, style disagreements eat maintainer time across time zones, and LLMs killed code-writing as the bottleneck so the stranger's PR doesn't help with the parts that are still hard. Viktor grants the security point and then points at XZ - social engineering, a long con, zero AI required. The risk was always there. What changed is quantity, not the percentage. And the maintainer who thinks a manual, line-by-line review still works in 2026 is, in his words, terribly wrong. Viktor guesses he can review 6,000 lines in about the time it takes to hand-review 600. CodeRabbit and Greptile clear the obvious junk so he can spend his attention on architecture and the feature itself - the stuff he never had energy for after slogging through nitpicks by hand. His read on the whole backlash: there's a new third group of maintainers now, the ones who aren't good enough with agents to fight agents, and they're the ones falling behind. Writing code is cheap. Reviewing it well is the expensive part - and the ones who refuse to use agents to review are drowning while blaming the contributors. There's a cost angle too. If you don't have tokens, you're in trouble, and not everyone can afford them. Tokens are becoming table stakes, like an internet connection. Which raises the question: what happens to open source when the reviewing tools cost money the maintainer doesn't have?   I don't want your PRs anymore https://dpc.pw/posts/i-dont-want-your-prs-anymore/   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/

#360: Assume your production systems go sideways at 3:00am. Your phone doesn't ring. You wake up to a clean incident report - the system caught the problem, fixed itself, and left a Slack note saying it handled things at 3:15. Would you trust it? Viktor wouldn't, not at first. Same as a new hire, a new tool, a new anything. Trust gets earned. A few months in, if it hasn't messed up, then maybe. So what's actually new? We had self-healing in decades past, and Kubernetes brings a crashed pod back without anyone awake to watch. Birol Yildiz, co-founder and CEO of ilert, puts the line where it belongs: the old stuff runs on predefined patterns - known problem, known fix, automate it. The new part is diagnosing a root cause nobody wrote a rule for and then knowing what to do about it. And no, ilert isn't training models on your data. The agent runs on foundational models from the frontier labs, feeds them the same context any SRE would pull - telemetry, recent changes, the health of your infra - runs the investigation loop, and hands you a root cause with the evidence attached. Then the real argument starts, and it's about knowledge. Viktor keeps circling the blind spot he sees at every company: the wiki, the runbooks, the tribal stuff nobody keeps current. Birol's answer is blunter than you'd expect from a guy selling this - dump your Confluence and your hundred stale runbooks into the agent and you cause more damage than results. Code is the documentation that's actually true. ilert's agent doesn't even read runbooks. It builds a live service topology straight from tracing data and rebuilds it when things drift. What happens when a bad incident month turns your $100 bill into $10,000 - Birol's answer is a credit budget with a human paged when you blow past it. Who's accountable when the agent makes it worse? Has to be a human. Agents are tools. You don't get to blame your AI coding agent for shipping garbage code, and ilert doesn't get to blame the model either. Trust is binary - five good runs and one bad one, and you strip its write access. But even in observe-only, the value is real, because the time sink in an incident was never the fix, it was finding the needle. Cut root cause from 45 minutes to a few. And the closer nobody wants to hear: if you skipped observability and fifteen years of homework, an AI SRE isn't going to save you. You can't skip the parts you skipped.   Birol's contact information: LinkedIn: https://www.linkedin.com/in/birolyildiz/ X: https://www.linkedin.com/in/birolyildiz/   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/

#359: When was the last time you sat through a 30-minute product demo and walked away actually knowing anything? You would learn more from five minutes hands-on than an hour of watching someone else drive. Now you have help. An agent can watch the 30-minute video, play in the sandbox, read every page of the docs, and come back before you finish your coffee with a verdict - tried it, does not work, next. The agent is the new tire kicker. So if you are a vendor, an open source maintainer, or the person building the internal app nobody outside the building ever sees, the demo you have been giving is aimed at a buyer who already left the room. Your job now is to make life easier for agents. An MCP server, a CLI, skills, an AGENTS.md file, not blocking your own site with Cloudflare when someone's agent tries to read your pricing. Everything that makes a product easy for an agent would have made it easier for a human all along. We just never bothered, because we had months to burn. Now the clock runs in minutes and every corner we cut is suddenly on fire. Three kinds of demo, three different answers. The vendor sales demo is off-putting before it starts - if a website says book a call to try it, Viktor is already gone. Open source barely needs a demo at all: a good README, a quick start, an AGENTS.md, and the agent assembles a demo tailored to your stack, your database, your questions, instead of some generic happy path. Internal is where it gets good, and it might be the one that matters most since exactly zero apps ship without customization. Viktor's bar: stop showing me plans, show me the thing running. Sit the stakeholder down and build it live while you talk. Three days to a prototype instead of 300 pages of PRD. Sandboxes first, demos second - if you cannot spin up a sandbox, you did not build it right. And demo the failure modes, not the happy path, because resiliency is the real selling point now. Disks still fill up. No amount of AI magic empties them for you.   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/