DevOps Paradox

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

#356: Fleet management means one thing to a DevOps engineer and something completely different to Tomas Kovacovsky. To Viktor it is a CD problem - a fleet of Kubernetes clusters he would rather not babysit. To Tomas it is hundreds of physical robots rolling around a warehouse, picking orders, dodging each other, and working very hard not to lose their connectivity.
Tomas is the CTO of Brightpick, where the robots are not the kind you yell at for bumping into a chair. They are three-meter-tall autonomous pickers - some telescoping up to six - that find their way using lidar, recognize items with neural networks, and make their own decisions the second the network drops. Here is the part that will feel oddly familiar: everything you already do to ship software shows up again in the physical world. Canary rollouts. Rollbacks to the last good config. Prometheus scraping every robot, Grafana for the fleet. Logs, metrics, traces. Split brain, when a robot and the server disagree about what just happened. Even a flaky robot - one that feels off with no error to point at - gets diagnosed the same way you would hunt a flaky test: compare it against the rest of the population and find the outlier. A warehouse full of robots, running like a distributed system.
The stack is what you would guess and also not. C++ on the robots for speed, Python on the backend, Kubernetes on an edge server inside the warehouse because latency matters down to the millisecond, and Git as the source of truth - the on-site servers check for differences and update themselves. GitOps, for robots.
Then it gets bigger. The optimal pick speed, Tomas says, is infinity - right up until you try to pick an egg. The real bottleneck was never the picking, it was the traveling, so Brightpick moves the picking into the aisles instead of hauling totes back to a station. He also drops a prediction worth chewing on: the intelligence arrives before the dexterity. Machines will think their way around a warehouse long before they can fish for keys in a bag the way your hand does without looking. And the jobs question everyone braces for - the robot guys walking in, are you fearful for your job in 20 minutes - turns out the picker positions were mostly empty to begin with. Hundreds of thousands of them, unfilled.
The takeaway for anyone writing software is the one Tomas lands at the end. The craft is getting eaten. What is left, and what actually matters, is whether you can connect the work to the product.
 
Tomas' contact information:
LinkedIn: https://www.linkedin.com/in/tomas-kovacovsky-46411280/
 
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/

#355: Picture your engineering team a year from now. A coding agent doing the coding. A testing agent on tests. A security agent on security. An infrastructure agent on infrastructure. All of them wired into GitHub and Jira, all of them working right alongside the humans. Not science fiction either - Atlassian and GitHub are already shipping these features.
So out come the stats everyone loves to quote. AI code introduces 1.7 times more issues. Half of it ships with security holes. Code duplication is through the roof. AI-assisted PRs take four to five times longer to review. The response to most of it: so what? If you have a way to detect the issue and feed it back, that is just the SDLC doing its job. Couldn't care less if it is 1.7x or 50x more issues - what matters is what is left at the end, per feature shipped. Security holes? You have scanners. Detect, fix, ship. The only real problem is when you skip the detection or sit on the fix for months, and that has nothing to do with AI.
Here is the one stat that actually sticks: PR reviews backing up. Speed up coding and leave everything downstream at human speed, and you have not sped up delivery - you have just moved the pile from Jira tickets to pull requests. The review pipeline was built for human speed, and now it is the bottleneck. The blunt fix: stop letting AI write 10,000-line PRs, work in smaller chunks, and accept that the job is about to get mentally harder. Delegate the tedious work and what is left is the demanding work - architecture, taste, is this even the feature we should ship. The silly stuff, does every function have a comment, is it camel case, goes to the machine. Spend your time there and you are wasting your talent.
Offshoring never worked when the only goal was cheaper - chase the cheapest engineers, then chase even cheaper ones, and you end up dragging the work back in house. Same trap with AI. Offshore to Opus, then Sonnet, then Haiku, then Llama on a laptop. If cheaper is your primary motivation, you are doing it wrong. The win is qualitative, not the price tag. Where does it land? Three people per product, end to end - frontend, backend, database, deployments. Augmented at every stage, not autonomous. A human still pushes the final button to prod, the way you never let a Jenkins pipeline deploy straight to production without a check. Full autonomy is coming the way self-driving cars came: not in a year, not everywhere at once, and not by flipping it on at 4pm on a Friday. Even when the technology is ready, you are not. And if you think none of this touches your job, there is a story here about a textile factory built in the eighties that ran on five people. Knowledge work is next. The only exception is a monopoly, and you probably do not have one.
 
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/

#354: How do you build a consent system for someone who is dead? How do you clone a voice so it cannot be turned into a deep fake? Miles Spencer built a company around those exact questions. Reflekta.ai lets you talk to a reflection of someone who has passed. His own father reads a bedtime story to his granddaughter every night and talks it through until she falls asleep, eight years after he died.
Is this just deep fake with better branding? What happens when the AI goes off the rails and asks grandpa for the three numbers on the back of a credit card? Miles has an answer for each one, and most of them land on the same line: you built it, you paid for it, it never leaves your four walls. Nothing gets scraped. There are only two public reflections on the entire platform. The voice of his dad came from a ten-second voicemail found on a relative's phone five years after he was gone, and last month that voice had 9,000 conversations.
More than half the stories on Reflekta are from people who are still alive. ALS and Alzheimer's patients getting it all down while they still can. Founders who want their values to outlast them. And that last group is where it gets interesting for anyone who runs a company. New hires talk to the founder during onboarding. Ask a question about the business and the founder answers. SOPs, handbooks, the whole thing, in the voice of the person who built it.
Miles calls the framework SoulTech, starting from the emotional weight of the product instead of bolting ethics on at the end. Agree with the premise or not, the stack underneath is less exotic than it sounds: multi-cloud, RAG, three voice vendors swapped by time of day, 110 days from idea to launch. Darin's verdict by the end is honest. The dead-relative part is still not his jam. But the founder who never leaves the building, the one who onboards every new hire forever? That one he gets.
 
Miles' contact information: 
LinkedIn: https://www.linkedin.com/in/milesspencer/
 
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/