The evolving 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 development. The talk discusses the obstacles to moving AI-generated prototypes to production, the evolution of CI/CD pipelines toward greater autonomy and smaller architectures, and the evolving responsibilities of platform teams in becoming process engineers.
The discussion looks at the impact of AI on current processes such as Agile and DevOps, and notes that although the main principles of software development continue, the economic realities and the realities of rapid development, driven by AI require a review of traditional processes.
Words are edited for clarity and length.
Q: One of the things that we’ve been hearing a lot about, it’s called, I think, the AI SDLC, where people are trying to automate everything throughout the lifecycle. A subset of that would be independent credibility. I’d love to hear how you define it, how you define it, and why you think it’s important.
Rob Zuber: Speeding up software development without speeding up slow, human-led processes accomplishes little and often reduces software quality. Automated reliability addresses this in two ways: first, by ensuring quality, which is the traditional role of CI, and second, by providing direct feedback to AI agents as they build code. This feedback loop tells agents whether their code will pass the test, which should be known as a good and sufficient result. If AI writes tests at the speed of code, you risk losing trust in the tests themselves, as they may return to reality without quality checks. Automated reliability builds on better quality tests and feedback loops to exceed the basic CI green test mark.
Q: Is trust still a big problem? I know that things have already evolved and are moving very quickly, and these AI agents can learn very quickly. I think there is more trust now in the use of these agents, but when AI first came out, people doubted that AI created the code and AI tested and verified it.
Rob Zuber: Everything is improving, and we get good results with a little guidance, like a senior engineer. However, improved work quality does not guarantee complete confidence; senior engineers are still writing code that breaks in production. Although the models quickly deliver better results, they still have input variations and do not guarantee the absence of problems. Evolution involves giving feedback directly to the agent so that it can iterate without human involvement, which is essential for reliable production. Many early adopters use wire engineering—the 2026 equivalent of test-driven development—to ensure a positive outcome. Confidence increases because we learn to use an indeterminate tool in a way that always produces a deterministic result.
Q: We hear a lot from people saying, “this is working fine while we’re testing it,” but the problems start when you try to move it to production. What are some of those problems that people are experiencing as they try to move to productivity with their AI?
Rob Zuber: Problems range from How again WHO using AI. AI makes prototyping easier, but these projects often lack a deep understanding of the scaling and system issues needed for production. Productivity requires managing security, privacy, authentication, and scaling from one user to millions. This is not a downgrade of the AI, but rather a reflection of the user experience. An experienced developer can guide the AI effectively. A novice can create a prototype but will need an expert to guide the LLM to a better result based on the knowledge of how large systems must work. LLMs require both initial guidance and ongoing feedback. This response includes a prescriptive assessment of the quality of the automated authentication software, and encourages the LLM to act as a programmer—the “adversarial method”—to evaluate its work against the organization’s security and reliability principles.
Q: How is AI changing the way we think about pipelines, and what the environment looks like as things move towards more autonomy?
Rob Zuber: There are two factors that cause change. First, validation is pushed to the left—early and fast—using minimal architecture to deliver targeted feedback and corrections to the agent quickly. This acceleration ensures high confidence before the code enters the main CI/CD pipeline. Second, the field team’s role is evolving into “process engineering,” investing in the “industry”—the automation, tooling, and instrumentation that make up the software—rather than the software itself. Field teams enable LLMs and CI/CDs to work together automatically. A team of product engineers defines the desired outcome, which then flows into this guided process, eliminating the need for human intervention in LLM preparation.
Question: I wanted to ask about delivery and usage. After all the checks and tests have passed, is the shipment now independent, or is there a stop sign at the final gate for human review?
Rob Zuber: Shipping is independent. Tools like automated deployment, managed releases, and feature flags—which manage vulnerability—are seeing increased use. A continuous deployment process manages releases by checking for errors and making independent decisions to continue or roll back. Manual gates are becoming increasingly inefficient due to the rapid arrival rate of AI-generated changes, which creates significant overhead. A new challenge is to manage the arrival rate problem … if changes are created faster than the controlled release can process them, the queue of changes grows indefinitely. While the current focus is on quality assurance to reach a ready-to-use state, a future tool will need to control aggressive integration and integration conflicts caused by the volume of changes at the same time.
Q: I’ve heard people say that AI is making Agile useless, or even dead. Do you see an impact on what we’ve historically called DevOps or CI/CD? Are these becoming legacy goals, or are we just doing the same routines for ourselves?
Rob Zuber: Terms like wireframe engineering are often just new words for old concepts, like TDD combined with AI. Automated validation and reliability are important because without the right tools to navigate the process, the advanced acceleration provided by AI is meaningless. The original goal of the Agile manifesto — working code in the hands of customers — has effectively returned because the economics of building software have changed dramatically. The flexibility of building code now means that we can skip the most advanced, capital-Agile practices—such as redundant meetings, planning poker, and comprehensive user stories—that became the antithesis of the original guiding principles.
Question: If you look at the car industry, when they brought robots, the assembly process did not change. Is it the same with software? Are the processes still the same to get from idea to product delivery?
Rob Zuber: I think overall the goals and principles are the same, but again, some of the critical elements in the process are there to protect against the cost of writing code. We spend a lot of time talking about and writing the perfect store user story. We’re estimating how long something will take when, honestly, the process of planning poker might take longer than building something at this point, so I think at some point the economy changes so much that the basis of the process needs to be questioned. The best example I came up with, which is a bit of a stretch, but if you take the car example for one second, yes, the factory added robots, but that was once in the factory and the flow looks the same. But when people built cars by hand, did we follow the same process? Because software engineering is like pursuing design during construction, which was something that always kept it from mass production … we never built the same thing twice.
But if you look at software before we had AI building everything, even then, most software development consisted of a bunch of pre-built components, like third-party services and open source software. We build different consumer apps or business apps, but we put together a lot of the same pieces. So that’s the most advanced and automated part, and then once we release the AI, you can take the final step, now I can quickly generate whatever I needed to put those things together. If you look at the early stages of production, there’s a bunch of people standing around the conveyor belt turning the bolts, and now we have a robot turning the bolts, but it’s still walking down the conveyor belt. We’re moving from bespoke professional software development to the first conveyor belt, and that transition felt very similar.
