“It’s not just accelerating the phases,” says Sanz. “It’s turning it into a continuous loop where you’re building, testing, and reviewing, all the time.” A process that previously required five or six engineers can now move far faster with the same team, freeing more of their time for specification, review, and verification, with features reaching UAT in roughly a quarter of the time, he adds.

In the new AI agent era, the continuous integration and continuous delivery (CI/CD) pipeline — the series of automated unit tests, functional checks, acceptance criteria, validations, and security tests that code goes through before deployment — is still essential. But AI agents have shifted what’s possible.

“Historically, building robust CI/CD pipelines required more specialized engineering effort; agentic AI is making that capability much more accessible, adds Sanz. “Many of the repeatable nonfunctional requirements and quality checks can be built in from the start and embedded into the delivery pipeline.”

In the age of AI agents, the volume of code developers can produce has risen sharply. A National Bureau of Economic Research (NBER) study used data from 100,000 GitHub developers and found that autonomous coding agents increase coding activity (by the number of code commits) by 180%. However, this falls sharply to 30% for actual releases, with the study noting human bottlenecks in the production chain.

The downside of this agility is that with so much power at our fingertips, the likelihood of creating (and shipping) technical debt also sharply increases. “As we get faster at shipping code, we can also get faster at creating problems if we’re not careful,” says Sanz. AI can produce highly plausible code very quickly, but without the right verification and governance, that does not necessarily translate into production-ready software.

“The later you find a bug, the more expensive it is to fix it, and that doesn’t go away just because you have AI,” Sanz adds. “You risk creating shadow code and unclear accountability. If you’re not careful, you can amplify existing problems.”

Others add that the noise creates a new form of cognitive load: higher code review time. “Code generation is close to free now,” says Stephanie Hippo, Platform Engineering Director at Honeycomb, an observability platform. “That’s shifted the constraint downstream so now review is the new bottleneck.”

GitLab, which provides a DevOps platform for the SDLC, is seeing the same downstream pressure. “The assumption that faster code generation equals faster business outcomes no longer holds,” says Manav Khurana, Chief Product and Marketing Officer at GitLab. “Faster code generation shifts pressure downstream into review, security, testing, and deployment,” he adds.

GitLab’s recent “AI Accountability Report” bears this out: 78% of organizations say developers are writing and committing code faster, yet only 21% report productivity gains across the full software lifecycle.

Now, newfound roles and responsibilities are emerging as AI agents enter software engineering workflows. “It’s an augmentation of very capable people,” says Sanz. “We need people that are willing to get their hands dirty and own the whole value stream.” While language-specific implementation skills may become less differentiating, he sees broader engineering and DevOps expertise as still critical.

Papadopoulos raises the harder question this creates: where the next generation of very capable people will come from. “The struggle that built today’s senior engineers’ judgment is being automated away,” he says. “So we have to train that judgment deliberately — teaching juniors to treat AI as a tutor, not an authority, and giving them the testing skills to prove to themselves that it can be confidently wrong.”

For instance, CI/CD takes experience to get right. “Building it is a commodity; knowing what to build is not,” he says. Now, the ability to see how different components fit together, understand the organizational standards, and guide agents becomes the new edge. “That still requires strong engineering and DevOps experience: AI makes the implementation easier, but knowing what good looks like remains the hard part.”

GitLab’s Khurana describes the same shift more simply: “The skill that matters most now is judgment.” As agents generate implementations faster, human engineers increasingly stand out for their understanding of requirements, systems architecture, and the consequences of what agents produce.

Others also see the engineer taking on more of a guidance role. “The role emerging is orchestrator,” says Papadopoulos. “A lot of people think that AI now replaces engineers, designers, project managers, but that is incorrect.” One example is the forward-deployed engineer, a position popularized by Palantir and AI companies that puts greater emphasis on AI-first building, agent orchestration, and driving outcomes tied more closely to business results.

Another practice emerging in the SDLC is preserving engineering context throughout the new agent-driven continuous development loop. For example, Sanz uses Markdown files to continually update engineering documentation. “You can keep a live document and feed it into Claude using a plug-in to update documentation based on context,” he says. “The agent is always keeping the latest view of the world.” Since LLMs are nondeterministic and can hallucinate, such context engineering helps retain accuracy and reduce errors caused by missing or ambiguous context.

Papadopoulos adds a caveat: these files are no longer just documentation. “The Markdown files are effectively the source code the agent works from,” he says. “An agent can help keep them current, but a human still has to own and review every change. Otherwise, the documentation is up to date, and nobody actually understands the system.”

This also gives rise to what Hippo calls “harness engineering”: treating the context, tools, feedback signals, and evaluations surrounding an agent as a first-class engineering discipline. “The fundamentals of software are all still there,” she says. “They’re just wearing slightly different costumes now.”

Inclusion of AI within the SDLC isn’t just about smart optimizations — it’ll also take keen security response to mitigate the risks. And today, that security forethought is still nascent. “The problem today is that teams are often using agentic tools in their own way,” says Sanz. “There’s often no set standards vetted by people that actually understand security and architecture.”

The downside of outsourcing SDLC tasks to agents is that they can fail both catastrophically and quietly.

Take two recent loud examples: Replit’s AI coding agent deleted a live database despite instructions not to make changes, while an AI coding agent used by PocketOS deleted its production database and backups, disrupting software its customers relied on. Many AI agent failures involve what Papadopoulos calls an “intent error,” in which an agent produces something plausible but fails to match the actual intent and business context behind the user’s prompt.

Papadopoulos draws a distinction between the two failure modes. “Deleting a database you were told not to touch isn’t an intent error — it’s an agent holding authority it should never have had, which is a guardrails problem,” he says. “An intent error is quieter and, in some ways, more dangerous: the code that seems to work perfectly, passes its tests, and does the wrong thing until someone notices — often after errors have accumulated — because the agent filled a gap in the specification with a sensible assumption that doesn’t fit your business.”

That doesn’t mean shutting experimentation down. Rebecca Fox, founder and CTO at Relentica and former Group CIO at NCC Group, argues that leadership’s role is to create “safe boundaries, not unnecessary barriers.” Teams need clear rules around what data can be shared, which tools are approved, and how generated code is reviewed and governed. “Using AI safely is now a core engineering skill, just like secure coding or testing,” she adds.

“Security and compliance review that can’t keep pace with AI generation isn’t review — it’s theater that creates liability,” says Papadopoulos. Sanz adds that guardrails should be built into every action an agent takes. Yet applying human-in-the-loop checks uniformly across all agentic actions introduces paralyzing friction.

So, where do you really need human checks? It’s a context-dependent question that most organizations are only beginning to unravel.

Papadopoulos offers a practical rule of thumb: “Humans belong at the points where the decision requires context, judgment, or accountability that no rule can encode and, critically, at a volume low enough that the human can genuinely engage.” For him, this involves the up-front specifications that guide agentic development, verifying high-impact work, approving actions that meet certain value thresholds, and architectural or irreversible decisions. Anything that can be specified in advance, he argues, belongs in an automated guardrail instead. “Every rule you make a human responsible for catching hundreds of times a day turns into a rubber stamp,” he says. “The way through the review bottleneck isn’t faster review; it’s moving effort upstream into specification so less reaches review in the first place.”

However, these checks can’t be treated as a one-time configuration. Given the rapid pace of change in the AI space, these guardrails will likely need to be reviewed iteratively, too. “An agent that performs well today may behave differently tomorrow as models, dependencies, and organizational policies change,” says Relentica’s Fox.

Some controls might require additional infrastructure to implement. “Guardrails, prompt guarding, rate limiting, and everything that comprises that space should be at the gateway level — a central control point for requests entering and leaving AI systems,” says Michael Levan, AI architect and Forward Deployed engineer at Solo.io, a cloud-native infrastructure company.

Another challenge to overcome is the risk of silent errors. “AI embedded in the SDLC doesn’t just add new vulnerabilities,” says Papadopoulos. “It hollows out the human review and traceability that compliance regimes were built to assume.” One way to address this is to assess the visibility of the signals that agentic actions create. He notes that agents accelerate DevOps tasks that “fail loudly” — a broken build, a red test — just as readily as those that “fail silently,” such as an over-permissive access policy or a test that passes for the wrong reason. “Telling those two apart is now the DevOps engineer’s core job,” he says.

When implemented with the right controls, agentic AI can be deployed safely in production while giving organizations capabilities that were once “nice-to-haves” reserved for highly mature software engineering teams and impractical for everyone else. “By reducing the cost of delivery, capabilities that were previously ‘nice to have’  become economical to build in by default,” explains Sanz.

But for Sanz, the real value lies in a bigger shift: allowing one person to orchestrate an entire project. “You can have a single custodian over the value stream who can understand intent [and] govern end to end,” says Sanz. “It allows you to own the entire pipeline.”

Papadopoulos agrees with the model but adds a warning. “A single orchestrator per codebase is the right approach, but it concentrates the understanding in one person,” he says. “Your bus factor drops to one, and to zero the day that person leaves. The work is also cognitively relentless because AI removed the easy stretches between the hard decisions. Invest in a backup orchestrator, and treat sustainable pace as an organizational decision, not a personal one.”

For Papadopoulos, the end benefits of using AI in the SDLC are indeed manifold. “Increased agility, less shadow code, better accountability, stronger governance, faster delivery — you get all of it,” he says. However, Papadopoulos clarifies these aren’t really AI benefits per se, but the benefits of any well-oiled software engineering organization, with or without AI.

The uncomfortable truth, he adds, is that AI will execute written processes. That’s a tough reality for many enterprises, which typically rely heavily on undocumented human work and discretion. “A lot of processes in many organizations don’t work because the process is good,” says Papadopoulos. “They work because people make them work.” In effect, AI holds up a mirror to the software organization.

Thus, fully reaping the benefits of agentic AI in the SDLC will require cultural change. “The organizations that get the full benefit — the agility, the governance, the accountability — aren’t the ones that bought the best tool,” he adds. “They’re the ones that did the hard work of making their process actually good, rather than merely functional because humans rescue it.”

All in all, reinventing the SDLC isn’t about simply applying past DevOps methodologies to an agentic world. It means rethinking the lifecycle itself, with developers acting more as orchestrators and taking greater ownership of the pipeline. But making the most of agentic AI will require new practices as well.

The answer isn’t simply to insert agents into the existing lifecycle. As Hippo puts it, “Without the surrounding scaffolding, ‘agents changing the SDLC’ is really just ‘agents adding more code for humans to untangle.’”

At the same time, Sanz cautions companies against redesigning the entire development organization around an imagined agentic future overnight. “Start small,” he says. Build a handful of use cases, establish champions, learn how teams actually use the tools, and develop standards from there. Or, as he puts it: “Build for what they know, not for what they think the world will be in two years.”

The opportunity, then, is not simply to use AI to produce more code, faster. It’s to redesign the SDLC for an era in which code generation is no longer the primary constraint — putting greater emphasis on specification, judgment, governance, and end-to-end ownership. Organizations that get those elements right will be best positioned to turn agentic development from an experiment into a production capability.