AI-Assisted & Agentic SDLC: The Software Development Lifecycle in the AI Era.

First, let's go over the terms.

There are many terms related to AI in software development that are often used interchangeably. It’s important to distinguish between three of them before we continue:

The Agentic SDLC is the focus of this article: a development process in which AI agents perform tasks independently, while humans set the parameters and evaluate the output. AWS released a concrete framework for this under the name AI-DLC (AI-Driven Development Lifecycle), with phases such as Inception, Construction, and Operations. Note the difference from the Agent Development Lifecycle, also known as ADLC. That term, claimed by companies such as IBM and Salesforce, refers to building an AI agent as a product: how you design, test, and deploy an agent. That is a different topic.

In short: the Agent Development Lifecycle is about building an agent, while the Agentic SDLC is about how agents build your software. This article focuses on the latter: how AI is changing the way a dev team works.

The classic SDLC.

In the traditional SDLC, developers write every line of code themselves. The process proceeds linearly from requirements to design, build, test, deploy, and monitoring, and a human is at the helm at every step. AI plays no role, or at most a marginal one: a spell check, a search query—nothing that fundamentally changes the work. This is not an outdated model; for many organizations, it’s still the daily reality, and for certain types of work, it’s the right approach. Where every line counts and the margin for error is zero, you want a human making every decision. Code is written and reviewed entirely by hand; AI tools are not embedded in the workflow.

This results in maximum control and predictability: every decision can be traced back to a specific person. The downside is speed, because everything moves as fast as people can type, read, and review. Governance is virtually a non-issue here. This is the model that most compliance frameworks implicitly assume: responsibility is clear because a human is involved at every step, and there are no new questions about who is liable when a machine makes a decision, because no machine makes decisions.

De AI-Assisted SDLC.

In the AI-Assisted SDLC, the process remains linear, but the developer is joined by an AI assistant. AI tools generate code suggestions, assist with code reviews, write test cases, and explain unfamiliar code. Humans still make all the decisions; the AI simply speeds up each step. Developers use AI tools every day, but a human presses the button every time. No process runs without someone approving and committing the output. The benefits lie at the individual level, not in the system. Think of a co-pilot in the editor, AI suggestions in your merge request, or a chat assistant next to your terminal. This is where the vast majority of software organizations are right now, even though the market talks as if everyone will be working with agents tomorrow. The leap from the traditional SDLC is significant and immediately noticeable, and it’s tempting to think that more AI suggestions automatically mean higher productivity.

Time wasted due to inefficiency.

There’s a catch. According to GitLab’s annual DevSecOps survey, it turns out that teams spend an average of seven hours per person per week on inefficiencies: switching between tools, rebuilding context, and waiting for handoffs. If you use AI solely to type faster, you won’t solve that problem. You’ll produce code faster but shift the bottleneck to review, integration, and wait times. That’s the AI paradox: greater individual speed, but not necessarily greater gains in overall turnaround time.

The benefits are real, especially when it comes to repetitive work: boilerplate code, setting up tests, documentation, and figuring out unfamiliar code. But measuring this accurately is harder than it seems, because lines of code or the number of suggestions don’t tell the whole story. Look at the turnaround time from issue to merge, at review time, and at how much rework is required. This is also where the first real governance questions arise. Who is responsible for AI-generated code that goes wrong? The answer is still clear—humans approve it—but you’ll want to document which tools you use, what data they access, and how you prevent sensitive code from leaking to an external service. Now is the time to establish an AI usage policy, before agents start working independently.

By Agentic SDLC.

In the Agentic SDLC, AI agents carry out parts of the development process independently. It’s not a human who accepts a suggestion, but an agent that takes on an issue, opens a merge request, repairs a CI/CD pipeline, and only provides feedback to a human when a critical decision needs to be made. You have agents in production that independently open merge requests or edit issues. You have an AI catalog or similar structure in which agents play a central role. There’s a clear distinction between what an agent is allowed to do independently and what always requires human approval. Your merge request queue regularly contains MRs with “opened by agent” as the source. The process is no longer purely linear: it becomes a collaborative effort in which humans and agents each have their own distinct roles.

Humans define the framework; the agent makes operational decisions within that framework. Reviews are shifting from a line-by-line approach to a behavioral one: Is the agent doing what we agreed upon? Is it staying within the guardrails? And if something goes wrong, can we reconstruct what happened? The primary artifact shifts along with it: no longer just the code, but also the context, the intent, and the evaluation criteria used to assess the agent.

How does that work at Cube?

At Cube, agents are now up and running in production. They’re taking over routine tasks that used to be handled manually by people, such as pre-sorting merge requests or refining new issues. What used to be a manual step is now partly automated. We monitor progress through merge request reviews and pipeline logs, not by looking over their shoulders. The benefit here is no longer about typing faster, but about eliminating wait times and handoffs—exactly the kind of inefficiency the AI paradox is all about.

And this is where governance becomes a serious issue. Who is responsible for an agent that acts outside its scope, and how do you audit a process that runs partially autonomously? The EU AI Act sets requirements for high-risk AI systems, and agents that independently propose changes to production code may fall under these requirements. The direction is clear: logging agent actions, transparent guardrails, and human approval for critical decisions are no longer optional extras. For us, this starts with role-based access and logging via an MCP server.

Where does your organization stand?

It's not a quiz, but there are some concrete clues. Go through them and see where they lead you.

• You’ll recognize yourself in the classic SDLC if your dev team doesn’t use AI tools—or only uses them occasionally. Code is written and reviewed entirely by hand. For your team, AI is a topic discussed in management meetings, not in day-to-day development practice.

• You’re following the AI-Assisted SDLC if AI tools are used daily, but a human must approve and implement the output each time. You see productivity gains per developer, but no process runs without someone pressing the button. This is where most organizations are right now, and it’s not a setback. It’s the foundation upon which the rest builds.

• You’re in the Agentic SDLC if you have agents in production that take independent actions within the parameters you’ve set. You have a clear distinction between what an agent is allowed to do on its own and what always requires human approval. Your governance has evolved accordingly: logging, guardrails, and auditing.

Most organizations follow the AI-Assisted SDLC while dipping their toes into the Agentic SDLC. That’s exactly where it gets interesting, because the transition from assistance to independent execution doesn’t require more AI, but rather a different process to support it.

How well can your processes handle the output?

The temptation is to want to move to the next model simply because it’s possible. But the benefit isn’t in how autonomous your agents are; it’s in how well your process can handle the output. Most organizations benefit more from a more rigorous review process and clear guardrails than from an additional agent. What remains constant across all three models is that humans decide what is good enough. AI speeds up typing, takes over routine work, and will soon handle entire steps independently, but judgment doesn’t disappear. It simply changes form: from writing code yourself to setting frameworks and assessing behavior. Those who keep that judgment sharp can handle any model. That way, the transition to autonomously operating agents becomes a natural progression rather than a source of fear.