The transformative role of artificial intelligence in the software development life cycle (SDLC) is thoroughly explored in this interview with Rob Zuber, an expert in CI/CD and development platforms, focusing on the concept of autonomous reliability.
Zuber discusses the challenges of maintaining code quality and establishing trust when AI agents accelerate code creation. The talk delves into the hurdles of moving AI-generated prototypes to production, the evolution of CI/CD pipelines toward greater autonomy and micro-builds, and the shifting responsibilities of platform teams toward becoming process engineers.
The conversation looks at the impact of AI on current practices such as Agile and DevOps, and noting that while core software construction principles persist, the economic and practical realities of rapid, AI-driven development require a revisiting of traditional processes.
The remarks have been edited for clarity and length.
Q: One of the things we’ve been hearing a lot about is the, it’s called, I guess, the AI SDLC, where people are just trying to automate everything throughout the lifecycle. A subset of that would be autonomous reliability. I would love to hear how you define it, how you explain it, and why you think it’s important.
Rob Zuber: Accelerating software creation without accelerating slow, human-led processes achieves little and often lowers software quality. Autonomous reliability addresses this in two ways: first, by ensuring quality, which is the traditional role of CI, and second, by giving direct feedback to AI agents as they build code. This feedback loop tells agents whether their code will pass tests, which must be known as good and sufficient for the outcome. If AI writes tests at the pace of code, you risk losing trust in the tests themselves, as they may simply return true without evaluating quality. Autonomous reliability builds in better quality assessment and feedback loops to go beyond the basic CI green checkmark.
Q: Is trust still a big issue? I know things have evolved and are moving very quickly, and these AI agents could learn super fast. I think there’s more trust now in the use of these agents, but when AI first came out, people questioned having AI create code and AI check and validate it.
Rob Zuber: Everything is improving, and we get good results with less guidance, similar to a maturing human engineer. However, improved work quality doesn’t guarantee ultimate confidence; senior engineers still write code that breaks in production. While models rapidly deliver better outcomes, they still have input variability and do not guarantee the absence of issues. The evolution involves giving feedback directly to the agent so it can iterate without human involvement, which is essential for production confidence. Many early adopters are using harness engineering—the 2026 equivalent of test-driven development—to ensure a good outcome. Trust is increasing because we are learning how to use a non-deterministic tool in a way that consistently produces a deterministic outcome.
Q: We hear a lot about people saying, “this works fine as we pilot it,” but the problems begin once you try to move into production. What are some of those issues that people are finding as they try to move into production with their AI?
Rob Zuber: The problems stem from how and who is using the AI. AI makes prototyping easy, but these projects often lack the deep understanding of scaling and system issues necessary for production. Production requires handling security, secrets, authentication, and scaling from a single user to millions. These are not downfalls of AI, but rather a reflection of the user’s experience. An experienced engineer can guide the AI effectively. A novice can build a prototype but will need an expert to guide the LLM to a better outcome based on knowledge of how large systems must work. LLMs need both initial guidance and continuous feedback. This feedback includes deterministic evaluation of software quality for autonomous validation, and also prompting the LLM to act as an editor—an “adversarial approach”—to evaluate its own work against organizational principles for security and reliability.
Q: How is AI changing how we think about pipelines, and what the evolution looks like as things move towards more autonomy?
Rob Zuber: Two factors are driving change. First, validation is being pushed left—earlier and faster—using micro builds to deliver targeted feedback and corrections to the agent sooner. This acceleration ensures high confidence before code enters the main CI/CD pipeline. Second, the platform team’s role is evolving into “process engineering,” investing in the “factory”—the automation, tooling, and guardrails that build the software—rather than the software itself. Platform teams enable LLMs and CI/CD to work together autonomously. The product engineering team describes the desired outcome, which then flows through this guided process, eliminating the need for human intervention in tuning the LLM.
Q: I wanted to ask about delivery and deployment. After all the checks and tests pass, is the deployment now also autonomous, or is there a stop sign at the last gate for human review?
Rob Zuber: Deployment is autonomous. Tools like automated deployments, managed rollouts, and feature flags—which manage risk—are seeing increased use. The continuous deployment process manages rollouts by assessing errors and making autonomous decisions to continue or roll back. Manual gates are becoming starkly inefficient due to the rapid arrival rate of AI-generated changes, which creates significant overhead. The new challenge is managing the arrival rate problem … if changes are created faster than controlled rollouts can process them, the queue of changes grows unboundedly. While the current focus is ensuring quality to reach a deployable state faster, future tooling will need to manage aggressive merging and merge conflicts caused by the volume of simultaneous changes.
Q: I’ve heard people say that AI is making Agile irrelevant, or even dead. Do you see any impact on what we’ve historically called DevOps or CI/CD? Are these becoming legacy terms, or are we just automating the same processes?
Rob Zuber: Terms like harness engineering are often just new names for old concepts, such as TDD combined with AI. Autonomous validation and reliability are crucial because without the right tooling to move through the process, the upfront acceleration provided by AI is pointless. The original intent of the Agile manifesto—functioning code in customers’ hands—is effectively back because the economics of building software have fundamentally changed. The ease of building code now means we can bypass the high-overhead, capital-A Agile processes—such as excessive meetings, planning poker, and perfect user stories—that became the antithesis of the original guiding principles.
Q: If you look at the automotive industry, when they brought in robots, the assembly line process didn’t change. Is it the same with software? Are the processes still the same to get from the idea to the delivery of a product?
Rob Zuber: I think that overall the goals and the principles are the same, but again, some of the things that became critical to the process are there to defend against the cost of writing code. We spend more time talking and writing the perfect store user story. We estimate how long something is going to take when, honestly, the process of planning poker might take longer than building the thing at this point, and so I think at some point the economics shift so much that the underpinnings of the process need to be called into question. The best example I’ve come up with, which is a little bit of a stretch, but if you take the car example for one second, yes, the factory added robots, but that was once we were in the factory and the flow looked about the same. But when people were hand-building cars, did we follow the exact same process? Because software engineering has been like a design pursuit during the course of construction, which was the thing that always kept it from being mass manufacturing … we were never building the same thing twice.
But if you look at software before we just had AI to build everything, even at that point, a lot of software development was stringing together a bunch of pre-constructed components, like third-party services and open source software. We’re building different consumer applications or business applications, but we’re combining a lot of the same pieces. And so that’s the part that is really high leverage and automatable, and then once we unleash AI, you could take the final step, which is now I can rapidly produce anything that I needed to glue those things together. If you look at the early stages of manufacturing, with a bunch of people standing along a conveyor belt turning bolts, and now we have a robot that turns the bolts, but it’s still going down the conveyor belt. We’re shifting from bespoke craft software construction into the very first conveyor belt, and so that shift feels more like analogous..
