Skip to content
Sign in
Artwork for DevOps Paradox
Technology

DevOps Paradox

Darin Pope & Viktor Farcic

What is DevOps? We will attempt to answer this and many more questions.

Play
Open in
  • 33 episodes
  • weekly
  • Avg 48 min
  • English

Support the show

Goes straight to the publisher. podnod takes nothing.

Episodes 33

NewestOldestLongest
All20Unplayed20In progress0Played0
Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.
  • #376
    Yesterday · 41 min

    DOP 376: Secrets Management for AI Agents

    #376: How many secrets can your coding agent reach right now? You gave it a token so it could get work done. It might have passed that token to every agent it spun up. Somewhere along the way, you stopped reading the permission prompts and started clicking allow. At the same time, hardcoding secrets in our code is still the most common answer for how secrets are managed. Developers get paid to close tickets, not to lower risk, and the agents just copy whatever they find in the repo. In this episode, we speak with Dwayne McDaniel, Principal Developer Advocate at GitGuardian, about managing secrets when agents are the ones using them, and why the better answer might be no secrets at all. Dwayne's contact information: LinkedIn: https://www.linkedin.com/in/dwaynemcdaniel/ 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/

  • #375
    November 4 · 49 min

    DOP 375: AI Writes the Code. Who Understands It?

    #375: An agent can crank out 200 or 300 lines of code a minute. You can maybe review 40. So who's actually supposed to understand what just got merged? Maybe nobody ever did. Did you really read every line of every PR before AI showed up? Or did you just have the time? Now the junior has an agent, the senior is buried in review, and the job looks a lot more like management than coding. In this episode, Darin and Viktor talk about who's supposed to understand the code once AI writes it, and why that's now the senior engineer's job. 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/

  • #374
    October 28 · 56 min

    DOP 374: Does AI Make Companies More Productive?

    #374: Your company is paying for the AI licenses, and now there's a number attached. Two to three times the output, every day, or else. Can you hit it? If they're counting lines of code, sure. But you aren't the company. If everyone on the team gets faster on their own and the handoffs between them stay exactly the same, does anything ship sooner? Most AI today is single player. Your company probably isn't. In this episode, we speak with Tomasz Tunguz, founder of Theory Ventures, about why faster individuals don't add up to a faster company, and what that changes for startups and the people funding them. Tomasz's contact information: LinkedIn: https://www.linkedin.com/in/tomasztunguz/ X: https://x.com/ttunguz 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/

  • #373
    October 21 · 45 min

    DOP 373: Are Layoffs Really Because of AI?

    #373: A company lays off 4,000 people the same day it posts record revenue, and the stock jumps. Is that really because of AI? Or just a really good press release? Layoffs used to mean a company was bleeding cash. Now they show up next to record quarters, and AI gets the credit. Doesn't matter much if you're the one who got rapidly reallocated. You still need a job. In this episode, Darin and Viktor talk about AI as the current layoff scapegoat and what to do when you end up on the wrong side of it. 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/

  • #372
    October 14 · 49 min

    DOP 372: Using AI Every Day Doesn't Make You Good at It

    #372: Your company bought everyone a ChatGPT or Claude license. Problem solved, right? A few people never touch it. Most use it like a drive-through window -- type a question, grab the answer, leave. And the ones using it all day for emails assume that makes them good at it. But think about it. Your kid had to pass a written test before driving the car. Your team got the keys and a login. In this episode, we speak with Chris Daigle, founder and CEO of ChiefAIOfficer.com, about what actually turns daily AI use into real skill. Chris's contact information: LinkedIn: https://www.linkedin.com/in/doctordaigle/ 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/

  • #371
    October 7 · 30 min

    DOP 371: Should You Vibe Code Your Own CRM?

    #371: You've got an idea, two friends, and a coding agent. Why would you pay for a CRM when you can vibe code one this weekend? Day one, it looks great. You love it. Then day 30 shows up. Somebody else needs access, a new feature breaks an old one, and you're asking yourself where this thing is even hosted. Pretty soon you're spending more time maintaining your CRM than running your business. In this episode, we speak with Eddie Cliff, VP and GM of SMB and Growth Products at Salesforce, about when to build and when to buy. Eddie's contact information: LinkedIn: https://www.linkedin.com/in/eddiecliff/ X: https://x.com/eddiecliff 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/

  • #370
    September 30 · 1 hr 1 min

    DOP 370: Will AI Replace QA Testers?

    #370: Will AI replace QA testers? Three years ago, manual testers were told to learn automation or find another job. Now the automation engineers are hearing the same thing about AI. Same speech, new audience. Here's the thing. Nobody can test everything. Somebody still has to decide what quality means for your product and which workflows can't break, and your team is shipping ten times the code it used to. The conveyor belt got faster. You still have two eyes. In this episode, we speak with Shubha Govil, Chief Product Officer at Sauce Labs, about why the testing roles stay but the work doesn't. Shubha's contact information: LinkedIn: https://www.linkedin.com/in/shubhagovil/ 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/

  • #369
    September 23 · 48 min

    DOP 369: Vibe Coding Without the Slop

    #369: Vibe coding is great until it isn't, and the until part usually shows up fast. Ten different ways to calculate sales tax. An agent that switches programming languages in the middle of a request. One team on NodeJS, another on Python, and nobody with a rule about either. So who's supposed to stop that? Turns out that's a job now. Somebody has to tell the agents what they can and can't do, encode it, and then prove it held. In this episode, we speak with Dan Fernandez, Vice President of Product for Developer Services at Salesforce, about harness engineering, what actually counts as slop, and why Heroku isn't dead. Disclosure: Salesforce paid for Darin's travel and hotel to attend Dreamforce 2026. They did not review, approve, or influence this episode. The questions, the opinions, and the editing are ours. Dan's contact information: LinkedIn: https://www.linkedin.com/in/danfernandez/ 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/

  • #368
    September 16 · 53 min

    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
    September 9 · 40 min

    DOP 367: Zero-Human Companies Still Need Humans

    #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
    September 2 · 52 min

    DOP 366: How to Prevent npm Supply Chain Attacks

    #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
    August 26 · 48 min

    DOP 365: What the DORA AI ROI Report Really Says

    #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
    August 19 · 48 min

    DOP 364: How to Avoid Burnout as a Leader

    #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
    August 12 · 44 min

    DOP 363: Is Your Website Agent-Ready?

    #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
    August 5 · 48 min

    DOP 362: Feature Flags vs Canary Deployments

    #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
    July 29 · 41 min

    DOP 361: When Code Got Cheap, Reviewing Got Expensive

    #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
    July 22 · 54 min

    DOP 360: What Is an AI SRE?

    #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
    July 15 · 42 min

    DOP 359: Demos in the Age of AI Agents

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

  • #358
    July 8 · 50 min

    DOP 358: Just-in-Time Access for AI Agents

    #358: Production is on fire. You need access to one table you have never touched. So you file an access request, then phone the desk to say you filed it, then Slack them to say you phoned, then walk over to say you Slacked. Twenty-five minutes later the incident has resolved itself and the customer has already left. That is the setup, and Ofir Stein has lived the other side of it. He is the CTO and co-founder of Apono, and before that he was an engineering leader who felt the same pain every day - not because he hated security, but because he hated being blocked. There is a difference, and the whole conversation turns on it. Put productivity on one side, security risk on the other, and access management in the middle. Tighten one and you starve the other. Nobody wants to be slower and nobody wants to be breached, so the honest answer is there is no clean answer. Then AI agents show up and break the last assumption standing. Software used to be deterministic - your computer could not decide to do something other than what it was told. LLMs can. They can be socially engineered the way people are. Ofir's team built a full AWS environment run by AI agents, opened a Discord channel, and invited anyone to try to trick them. People could. That is the new attack surface, and it moves at machine speed - far too fast for the access reviews and approval chains built for humans. The guardrails everyone is now scrambling to build for agents should have been there for humans all along. Access is the one thing in your stack that never went dynamic. Servers scale up and down, pipelines rebuild everything, and then access is a static policy someone set two weeks ago when security sat with your manager and guessed what you would need. That is the opposite of how the rest of DevOps works. Ofir's argument is that access should change with context - who you are, whether you are on call, whether there is an open incident - evaluated in real time. For a human that is a faster request. For an AI agent, the decision has to live inside the loop, made by silicon, because no person can approve thousands of operations a minute. If access is per-operation and every operation is already a specific API call, what is left to scope? If the business context changes by the minute, how do you write guardrails in advance? And once the human is out of the loop, are you not just left with one AI deciding what another AI is allowed to do? Ofir does not pretend that part is solved. What he is sure of is the direction: the doors at the mall open when you walk up and close when you leave, and you never think about them. That is where access is headed - and there is a lot of road between here and there. Ofir's contact information: LinkedIn: https://www.linkedin.com/in/ofir-stein/ 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/

  • #357
    July 1 · 57 min

    DOP 357: What Is Spec-Driven Development?

    #357: Type a prompt, get code, fix the hallucinations, type another prompt. That is vibe coding, and it is a fine place to start. It is a terrible place to stay. So what comes next - and is spec-driven development actually it, or just waterfall wearing a new hat? Here is the reframe that runs the whole conversation: everybody already works from a spec. Even the person who swears they are winging it has a spec in their head - which language, where it runs, what it does. The real question was never specs or no specs. It is whether you write them like waterfall, one giant document before anyone touches code, or like agile, just enough to start and the rest discovered as you go. A design is only validated when you implement it - everything before that is an educated guess. So instead of spending a month on one detailed design, build five throwaway MVPs in a day. Fully operational. Frontend, backend, running in a cluster, connected to a database. Show them to customers. Pick the one that works. Then have the agent write the spec from the winning code, and throw the code away. The spec is the output, not the input. A PowerPoint took you a month and told the customer nothing. A working thing they can touch tells you everything. Viktor and Darin push on where this breaks. Over-specifying gives you a false sense of security - you are lying to yourself that you know everything up front, and you do not. Legacy systems? The code is the only complete spec - any document written thirty years ago is fiction. Performance? Measure it in production and be lightning-fast to react. Greenfield, CRUD, clear API contracts - those genuinely want a spec first. The part nobody on the org chart wants to hear: this does not delete the business analyst or the developer. It collapses the roles. The code monkey who pulls a Jira ticket, does the work, pushes it - that job is turning into tech lead, architect, product manager, all at once. Plan mode writes the spec with you, not for you. You write it to a file because you cannot review what you cannot see. And you review the tests harder than the code, because the tests are the spec made executable. Specs were always supposed to be living documents. Now there is finally no excuse. 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/

Showing 1–20 of 33 episodes