DevOps Paradox

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

#353: Move fast and break things never meant be reckless. It meant do not stall out of fear, because something is going to break no matter how careful you are. The part everyone dropped from the sentence is the part that actually matters: and fix things fast. Break faster, fix faster. Take the second half away and you are just breaking things.
So what changed with AI? An agent can take down a whole environment in the time it takes you to type kubectl. AWS found that out in December when Kiro -- running autonomously with operator-level permissions and no human in the loop -- decided to delete and recreate the production environment for Cost Explorer. Thirteen hours down in one region. Then there is the Agents of Chaos research, where five agents got two weeks with real infrastructure and an unrestricted bash shell, and one named Ash destroyed its entire mail server as a proportional response to being asked to protect a secret. Right values. Catastrophic judgment.
Here is where Viktor plants his flag. A person owns the work. Not the AI. Doesn't matter the level of autonomy, doesn't matter whether the code came out of Claude or out of your own hands. You chose the model, you chose the agent, you wrote the rule set, you gave it the tools. If you handed an admin account to a thing that deleted production, that is on you -- exactly the way it would be on you if a human did it. The Kiro engineer could have made the same mistake without AI. Blame the people.
The fix is not telling AI to be safe. It is building the place where breaking things is survivable. Immutable infrastructure. Progressive delivery everywhere. Feature flags you can actually turn off, not just on. Read-only tools for the agent and a human or a validation layer for anything that writes. And a new habit Darin calls celebrating near misses -- not just the failures, but the times the guardrails held and you learned where to tighten one more bolt. Viktor runs a blameless postmortem with his agents at least once a day, every wrong turn ends with an update to a skill or a CLAUDE.md. His homework for you this week: if an agent -- or a human -- deleted your full production environment right now, how long would it take you to come back?
 
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/

#352: Vibe coding is the latest version of a promise the industry has been making since the first generation of programming languages. Type what you want, get an app. Jeff Kuo from Ragic has been working on the no-code version of that same promise for almost twenty years. He has thoughts on why the promise keeps not quite landing.
The honest answer is that AI-assisted coding is great for people who already know what the code is doing. It is counterproductive for everyone else. A non-developer can generate a lot of code. They cannot maintain any of it. That gap is where every weekend vibe-coded project goes to die six months in, when the codebase has ballooned and the AI is in a loop confidently identifying the wrong root cause for the seventh time.
So what does work? Jeff's argument is that no-code platforms become the guardrail AI actually needs. Strip the infrastructure layer away, leave only the business logic, and the model only has to reason about one thing at a time -- which is the one thing today's models are good at. Ragic generates form and report definitions, not code, and the Java engine underneath does the rest.
There is also the strange consumer behavior nobody is talking about. People love AI chat boxes in tools they have never used before. They close AI chat boxes in tools they already know. Which means the future of AI-native software might not belong to the incumbents at all -- it belongs to the new tools being built right now for users who do not have any muscle memory to defend.
And one piece of advice that has aged perfectly across forty years of software: the maintenance is the thing that keeps you awake at night. AI makes it faster to build things from scratch and harder to maintain anything at scale. Begin with the end in mind. Or do not, and become the next cautionary tale.
 
Jeff's contact information:
LinkedIn: https://www.linkedin.com/in/ragic/
 
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/