SDLC to ADLC: The Pivot Every Engineering Org Will Make in 2026

Almost nobody adopted AI through a strategy meeting. A few engineers tried a tool, liked it, and told the rest of the team. Some months later the whole org is using something, procurement is catching up, and leadership is writing policy for a thing that already happened. DORA's 2025 research put AI use among technology professionals at 90%, with a median of two hours a day spent working with it. At that scale it stopped being a pilot program some time ago and became the default working method.

What did not change is the delivery system underneath. Work still moves from a ticket to a branch to a pull request to CI to a deploy to an incident follow-up, and it still moves because a person picks it up at each step and carries it to the next. The individual steps got faster. The path between them did not. DORA found the same thing from the other direction: teams that adopted AI heavily saw delivery throughput go up and delivery stability go down at the same time, and the hours saved writing code came back as hours spent auditing what the AI wrote.

That is the gap the move from SDLC to ADLC is trying to close. Not more AI in the editor, but a delivery lifecycle that can hold agent execution without losing control of it.

Key Takeaways

• The agentic development lifecycle (ADLC) is the delivery model for when autonomous agents execute parts of the work and humans still own intent, quality, risk, and release. It is a governance model as much as an automation model.
• The term is used two different ways in the market right now. One meaning is the lifecycle for building AI agents as products. The other, the one this post is about, is the lifecycle for building software with agents inside it. Check which one a vendor means before comparing.
• The real change is not code generation. Agents can now attach to engineering events, a ticket opening, CI failing, a dependency alert, and run a governed workflow instead of waiting in a queue for a person to notice.
• Agents fail in production when their scope is undefined. Narrow roles, explicit triggers, scoped permissions, and hard stopping points are what separate useful agent work from invisible work someone has to clean up later.
• Adoption takes about six months. Start with agents that only summarize and suggest, and let them do more only when your team has shown it can keep up with reviewing their output. Jumping straight to autonomous code changes buries reviewers in pull requests.
• Overcut sits at the orchestration and control layer of this model. If you are past single-agent experiments and need multiple agents coordinated across the lifecycle with scoped permissions, policy enforcement, approval gates, and a full execution history, that is the problem we build for.

What Is the Agentic Development Lifecycle

The agentic development lifecycle is the engineering model for software delivery when autonomous agents can execute parts of the work, while humans continue to govern intent, quality, risk, and release decisions. It does not describe agents taking over engineering jobs. It describes engineering teams no longer treating agents as isolated assistants, and starting to treat them as controlled execution units embedded in real delivery workflows.

A CI failure makes the difference concrete. Today a developer notices the red build, opens the logs, reads the diff, finds the failing test, works out which change caused it, checks who owns that code, writes a fix, opens a pull request, and waits for review. Very little of that is engineering judgment. Most of it is retrieval and assembly. Under an agent-driven flow, the logs and the diff get analyzed as soon as the build fails, likely root causes are identified, the relevant code context is gathered, a scoped fix is proposed, and a draft pull request is waiting when the developer looks. The human decides whether the fix is correct. The agent compressed the operational work around that decision.

That is the pivot. The lifecycle stops being only a way to manage developer activity and becomes a way to govern autonomous execution.

One clarification is worth making early, because the acronym is already ambiguous. Arthur, Glean, Salesforce, and others use ADLC to mean the lifecycle for building AI agents as products: evaluating probabilistic behavior, grounding context, monitoring drift after release. Cycode, Atlan, and the delivery-side vendors use it to mean the lifecycle of software delivery when agents are doing the work inside it. Both are legitimate uses of the same four letters and they solve different problems. This post is about the second one. When a vendor tells you they support the agentic development lifecycle, it is worth asking which lifecycle they mean.

From SDLC to Agentic Delivery: What Actually Changes

Traditional SDLC assumes humans are the execution layer. Even on a healthy agile team, work depends on people moving tickets, writing code, reviewing changes, updating docs, and handling production. Agentic delivery changes the shape of that work in one specific way.

The difference is not that code can be generated. Teams have known that for two years. The difference is that agents can respond to events across the lifecycle. A Jira issue is created. A pull request is opened. CI fails. A dependency alert appears. A release candidate is ready. An incident opens. Documentation drifts out of sync after an API change. In the old model, every one of those events waits for a person to notice it, understand it, and decide what happens next. The waiting is most of the elapsed time. In the new model, the event itself starts a governed workflow.

An agent can enrich a thin bug report before anyone reads it. It can draft the pull request description, summarize what changed and why, and flag the parts a reviewer should look at hardest. None of that is exotic. What makes these workflows fail in practice is almost never model quality. Scope is what breaks them. An agent with a vague mandate and broad access produces work that nobody asked for and everybody has to check. The teams getting value assign narrow roles, explicit triggers, defined context boundaries, scoped permissions, and clear stopping points, and they treat all of that as the design rather than as configuration to fill in later.

Why This Is Not Another Wave of Developer Tools

It is easy to file this shift under developer tooling, and that reading misses what is different about it. Coding assistants help local productivity. They are genuinely useful when a developer is already inside the problem, and they will explain code, write a helper, draft tests, or suggest a refactor. But the developer still chooses the task, supplies the context, supervises the output, and reconnects the result to the delivery process. The assistant makes a person faster inside one step. It does nothing about the handoffs between steps, which is where the time actually goes.

An agent-driven lifecycle is an operating model rather than a tool. Agents are not sitting in an IDE waiting for a prompt. They are attached to engineering events. They know which repository, ticket, branch, log, or workflow they are acting on. They call approved tools through scoped credentials. They pause for approval at defined points, and every action they took is reviewable afterward. That last property is why governance has to be designed in at the start rather than added when the security review comes. Retrofitting an audit trail onto a system that was never built to produce one is one of the harder pieces of engineering work you can sign up for, and it is a large part of why we think most teams should buy the orchestration layer rather than build it.

Some decisions stay with people, and drawing that line clearly is part of the design. A code agent should not decide product scope. A review agent should not rewrite architecture without an explicit approval gate. A deployment agent should not approve its own rollout. Agents are valuable when they reduce coordination drag. They are dangerous when they create invisible work.

How the Industry Is Framing the Shift

The conversation about this pivot is not confined to one vendor or one corner of the industry, and the framings that have stuck are the ones that describe a change in what engineers are responsible for.

Dez Blanchfield's argument is that the shift redefines the engineering contract. In the legacy model, the value engineers provided rested on determinism: give the machine unambiguous instructions and it does exactly that. In the agentic model, engineers provide intent, constraints, and the tools within which the agent works out portions of the execution path itself. That is a real change in the job. It moves the hard work earlier, into alignment and boundary-setting, and it means a badly specified goal now fails at machine speed instead of getting caught in a design review.

DORA's 2025 findings supply the counterweight, and they are the more sobering half. AI functions as an amplifier. It magnifies the strengths of organizations that already deliver well and the dysfunctions of ones that do not. If requirements are vague, tests are thin, and ownership is unclear, agent output does not fix any of that. It produces the same problems faster and in greater volume. The same research found that 30% of developers report little or no trust in AI-generated code, largely because the models will not reliably say when they are unsure.

On the security side, the vendors building for this model are converging on the same list of concerns: hallucinated dependencies, secrets exposed through prompts, and agents holding broader access than the task required. Cycode's work on securing the agentic development lifecycle centers on discovering which AI tools and MCP servers are actually running in a development environment, which is a sharper question than it sounds. Most organizations cannot currently answer it.

Put together, the bottleneck is visibly moving. The open question is no longer whether AI can automate coding, but how well an organization can govern agent execution while holding onto quality, security, and accountability.

What This Requires from the Orchestration Layer

The hard part of an agentic system is keeping agent work safe, repeatable, observable, and useful across systems that were never designed to be driven by software. Real engineering workflows touch ticketing, repositories, CI, secret management, documentation, release checks, and production signals. Each of those has its own permission model, data model, and failure behavior. A control layer for agentic SDLC work has to supply several things at once, and missing any one of them tends to be what stops a rollout.

Event triggers. Workflows should start from real engineering events. An issue created, a pull request opened, CI failing, a comment posted, a label changed, a deployment finishing. These are better entry points than a human remembering to invoke something.

Repository context. An agent cannot review or fix work without understanding repository structure, ownership, recent changes, local conventions, and the test suite. Context assembly is most of what separates a useful suggestion from a plausible-looking wrong one.

Scoped permissions. An agent should reach only the systems and actions its workflow needs. Read-only triage and pull request creation are different risk classes and should not share a credential.

Secure execution. Secrets belong in a vault, retrieved at execution time, never pasted into a prompt or exposed to the model.

Policy enforcement. Some changes should be blocked outright. Others should require security review or a named approver. These rules have to live in the platform rather than in a prompt, because a probabilistic model cannot be relied on to follow an instruction every time.

Observability and auditability. Teams need to see what ran, why it ran, what context it used, which tools it called, what it changed, and where it stopped. Without that record, nothing about the system can be governed or debugged.

These are the problems Overcut is built to solve. Overcut is an enterprise control plane for agentic SDLC workflows, running governed agents across Git, tickets, CI, approvals, logs, and sandboxed execution. Teams define event-driven workflows, assign agents to roles, scope access through project settings and vaults, and review execution history, failures, and audits in one place. It is the orchestration and governance layer for agent-driven delivery, which is a different product from a coding agent and solves a different problem. It is the control layer of the broader software factory model, and we have written separately about how multiple specialized agents coordinate inside it.

A Six-Month Adoption Path

A transition that starts with "let agents run the lifecycle" is too broad to survive contact with a real organization. The workable version starts with low-risk workflows and widens authority only as quality and governance are demonstrated. Six months is roughly the shape we see work.

Month 1: map the manual chokepoints. Find where engineers lose time. Tickets that always need the same three clarifications. Pull requests that sit because reviewers lack context. CI failures that take too long to classify. Documentation that only gets updated when someone complains. The goal at this stage is not automation. It is finding work that is repeatable, bounded, and easy to check.

Month 2: read-only workflows. Give agents jobs that summarize or suggest and nothing more. Ticket triage suggestions, pull request summaries, CI failure classification, incident recap drafts. No code, no changes to anything. The point is to build trust and to expose where context is missing, which it will be.

Month 3: draft-only actions. Let agents produce artifacts a human then approves. Technical plans, release notes, documentation updates, test plans, root cause analyses. This phase tends to reveal something uncomfortable and useful, which is how vague the tickets are. Agents surface ambiguity quickly because they cannot paper over it the way an experienced engineer silently does.

Month 4: scoped code suggestions. Now try small implementation workflows. A fix for a simple CI failure, a test snapshot update, a branch for a low-risk documentation change. The workflow still stops before merge. Permissions matter more here than anywhere else: a workflow that can open a pull request must not be able to approve it.

Month 5: connect events across the lifecycle. Once individual workflows are trustworthy, chain them. A ticket triggers triage, triage triggers a design draft, an approved draft triggers implementation. This is where the compounding shows up, and also where a weak gate in one workflow starts affecting the next one.

Month 6: measure and govern the system. By now the question should be sharper than whether people are using AI. Measure useful output rate, human approval and rejection rates, workflow failure rates, how often each permission is actually exercised, rework after agent changes, pull request review latency, CI recovery time, and documentation freshness after code changes. Most of these are things you should already be able to measure about human work, and usually cannot.

Overcut's control plane is designed to carry a team through all six phases, from a single narrow workflow to an operating model where execution is visible, permissions are scoped, secrets are protected, and approvals are part of the workflow rather than a step someone remembers.

What It Takes to Succeed

The pattern we see most often is that a team's first agent workflow does not reveal much about agents. It reveals the team. Agents magnify what an organization already is, and they do it fast, so the question to ask before adopting any of this is whether the org is ready for its output to arrive in higher volume. In our experience that readiness comes down to one requirement that cannot be skipped and four things that can be built, and agents themselves turn out to be the best tool for building them.

Verification is the requirement. Agents can produce more changes than a team can meaningfully review, and once review becomes rubber-stamping, every governance control above it is decorative. Time saved on creation gets spent on checking, and we have stopped expecting better models to change that. Reviewing is the work, so the review path needs to be sized, staffed, and measured before agent authority widens, which is why every phase of the six-month path above stops short of merge until the humans in the loop have shown they can keep up. Not every check has to be a person. Tests, linters, type checks, policy rules, and a second agent reviewing the first all count, and the more verification runs automatically, the more human review can concentrate on the changes that need judgment.

The rest is AI readiness, which is a plainer idea than the name suggests. It is whether the things an engineer silently knows about a codebase have been written down somewhere an agent can find them.

Documentation. Agents read what exists. If the architecture lives in three people's heads and the README describes the system as it was two years ago, agents will confidently build on the wrong picture. Runbooks, ownership maps, architecture notes, and decision records are the difference between an agent that reasons about your system and one that guesses at it.

Skills. Every team has procedures it repeats: how to cut a release, how to triage a flaky test, how to write a migration that will pass review. Written down as reusable skills, these give agents a known-good way to do a task instead of reinventing one on every run, and they give the team one place to fix a bad behavior rather than patching every prompt. The teams that get consistent output are the ones that codify their procedures.

Context. An agent working a CI failure needs the diff, the failing test, who owns that code, recent related changes, and the local conventions, and it needs them assembled before it starts rather than discovered halfway through. Context assembly is most of what separates a useful fix from a plausible-looking one, and it is a platform concern to solve once rather than something to leave to each workflow's prompt.

Tests. A test suite is the cheapest verification there is, and it is the one agents lean on hardest. Thin coverage means an agent's change can pass CI and still be wrong, which pushes the whole burden back onto human review. Coverage on the paths agents are allowed to touch directly sets how much authority you can safely hand them.

Read as a checklist, that list looks like a year of cleanup before the first workflow can run, and that is where most teams would stall. It does not have to work that way. Readiness work is exactly the kind of work agents are good at, because it is bounded, repetitive, and easy to verify, and it is the work engineers never get to. So the teams we see succeed run agent workflows to build readiness first, and the workflows that widen authority later come after.

The first readiness workflows are usually the easiest to justify. A coverage workflow that finds the modules with the thinnest tests, writes tests for the existing behavior, and opens a pull request per module, so that a reviewer is checking whether the test describes the code correctly rather than writing it from scratch. A documentation workflow that runs when a pull request merges, compares what changed against the docs that describe it, and opens a follow-up with the update, which is the only way we have seen docs stay current past the first month. A gap-finding workflow that reads the repository the way a new hire would and reports what it could not work out: undocumented setup steps, modules with no clear owner, conventions that exist in the code but nowhere else. Each report is a readiness backlog the team did not have to write itself.

Skills come out of the same loop. When a workflow does a task well, the procedure it followed can be captured and reused, and when a reviewer corrects it, the correction lands in the skill rather than in one person's memory. Over a few months the team ends up with a written operating manual for its own codebase that no one had the time to produce by hand.

The compounding is the point. Every one of these workflows produces artifacts a human approves, which means they fit in month three of the path above, before any agent is allowed to change production code. And every artifact they produce makes the next workflow more reliable: better docs give agents better context, better tests give them cheaper verification, better skills give them a known-good procedure. Teams with unclear ownership and thin tests do get their existing problems back faster and in higher volume when they hand agents authority too early. The same teams, running readiness workflows first, end up with the codebase they should have had all along, and only then the authority question becomes easy.

Where This Goes

Moving from SDLC to agent-driven delivery does not remove people from the process. It changes which part of the process they hold. Agents take the repetitive, bounded work first, at low risk, and their authority grows only as human oversight proves it can keep up. Architecture, intent, quality standards, risk, and the final call on what ships stay with engineers.

The teams that handle this well over the next year will not be the ones running the most agents. They will be the ones with defined agent responsibilities, permission boundaries that mean something, approval checkpoints in the right places, execution that runs safely, and a complete record of what every agent did and why. Put those together and the org stops being a collection of engineers using AI tools and starts running as a software factory: a delivery system where agents do the bounded work continuously, humans hold the gates, and the codebase, tests, and docs get better with every run. That is the end state the ADLC is building toward, and it is what turns agentic delivery from a collection of impressive demos into something an engineering organization can actually operate.

FAQs

What is ADLC and how does it differ from SDLC?

ADLC describes a delivery lifecycle where AI agents execute parts of planning, coding, testing, review, documentation, CI remediation, and maintenance under human governance. SDLC tracks human-driven work through stages and assumes people are the execution layer. ADLC adds governed agent execution, event-driven triggers, policy controls, approval gates, and a visible execution record. SDLC manages activity; ADLC has to govern actions taken on someone's behalf.

Does ADLC mean the lifecycle for building agents or for building software with agents?

Both meanings are in active use, which causes real confusion in vendor conversations. Arthur, Glean, and Salesforce use the agentic development lifecycle to describe building and operating AI agents as products, including evaluating probabilistic behavior and monitoring drift. Cycode, Atlan, and delivery-side platforms use it for software delivery with agents working inside the lifecycle. Ask which one a vendor means before you compare two products.

What capabilities does an agentic development lifecycle require that an SDLC does not?

Event triggers that start workflows from real engineering signals, repository context assembly, defined agent roles, permissions scoped per workflow, secret handling through a vault rather than a prompt, policy enforcement at the platform level, and an audit trail covering what ran and why. An SDLC tracks work. An ADLC has to control and record actions, which is a materially higher bar.

How quickly are engineering orgs expected to make this pivot?

Narrow-scope workflows are moving first: CI failure triage, pull request summaries, bug triage, documentation updates. Each one takes a few months to roll out properly, because the work is in setting permissions, handling failures, and building approval paths rather than in getting the agent to produce output. A team that starts with read-only workflows can realistically reach chained, scoped code workflows in about six months.

Where does Overcut sit in an ADLC architecture?

At the orchestration and control layer. Overcut connects the engineering systems, defines the event-driven workflows, scopes what agent-triggered actions can touch, manages secrets through a vault, enforces policy and approval gates, and keeps a full execution history. It coordinates agents across the lifecycle rather than acting as another coding agent inside one step of it.