DevOps Paradox

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

#351: Entry-level tech jobs are down 67% since 2022. Junior developer roles are down 40 to 50%. The instinct is to blame AI and call it unprecedented, but the layoffs are not the new part. The boom-bust cycle has happened before -- dot-com to dot-bomb, the 2020 hiring spree to the 2022 correction, now this. The new part is that the thing replacing the bottom of the ladder is not a cheaper human in another country. It is an agent that takes instruction and ships code overnight.
Here is the uncomfortable reframe. A junior developer is told what to do, does not change the architecture, does not make decisions, and produces better work the more detail you give them. Replace the word junior with agent and the description does not change. That is the whole problem. The traditional path from junior to senior assumed five years of grunt work would teach you the things grunt work teaches. The grunt work has a new owner now, and nobody knows what the new on-ramp looks like.
Seniors are not safe either. If you have spent 30 years writing pretty code and you have already started rejecting the idea that an agent can do it better, history is not on your side. The same people who refused to embrace cloud and containers are the people who will refuse this -- and the SSH-key-maker on the team that took a week to provision a key is not pivoting to AI either. Two types of employees. The ones you can replace in five minutes and the ones whose departure feels like a loss. Only one type thrives in this cycle.
So what actually works? Capacity to learn over experience. Specific knowledge over generic knowledge -- if every developer on the internet can do what you do, the model trained on the internet can too. The job is becoming managing a team of agents the way a manager manages people: figure out what should be done, how, and when, then check on the team and work with individuals. The hiring test that still works after all these years is the one where the candidate switches to the browser and Googles. That is the person who can adapt. That is the person who survives this market.
 
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/

#350: The bottleneck used to be writing the code. Now it is feeding the agent enough context to write the right code. That is Patrick Debois' argument, and given that Patrick coined the term DevOps, it is worth paying attention when he says the discipline is shifting again. The model does not matter. The IDE does not matter. What matters is whether your team can capture the way you actually work and hand it to an agent that does not know any of it.
The promise was that AI would let us ship without writing specs. The reality is the opposite. If you want decent output, you need richer specs, more docs, and a way to feed the agent what is unique about your team and your codebase. Viktor admits he stopped writing specs himself. He talks to the agent until he is satisfied, then says write it down. The work did not go away. It moved.
A second agent that validates your work tends to take the original spec too seriously and miss what is not there. The interesting validation is not whether the code matches the spec. It is whether the spec matches reality. Patrick's response is harness engineering -- combining verifier agents with deterministic tooling like linters and tests, and mining conversation logs for the moments a user says this is wrong so the missing context can be saved and reused. Memory, hooks, skills, registries -- all just delivery mechanisms for the same underlying thing.
Patrick's number one piece of advice if you are starting today is brutal in its simplicity. When the agent does the wrong thing, write it down in your AGENTS.md or claude.md. Do not just re-prompt and move on. Build the context file. That is the new job. Code moved to context. Context, eventually, moves to knowledge -- the way your organization actually works, captured somewhere an agent can use it. Whoever owns that layer wins. The model does not.
 
Patrick's contact information:
LinkedIn: https://www.linkedin.com/in/patrickdebois/
X: https://x.com/patrickdebois
 
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/