Skip to content

Back to the catalog

What is the AI-Native SDLC? AI SDLC, AI-DLC, and ADLC Explained | Endor Labs
endorlabs.comarticle

What is the AI-Native SDLC? AI SDLC, AI-DLC, and ADLC Explained | Endor Labs

The AI-native SDLC is a software lifecycle redesigned around AI and coding-agent participation, as opposed to the AI-assisted SDLC, which adds AI tools to unchanged stages. The Endor Labs guide separates AI-DLC (the AWS methodology), AI SDLC and the two meanings of ADLC (Agentic vs Agent Development Lifecycle). It also covers stage-by-stage changes and AppSec implications: AI-generated code flaws, dependency choice, reachability analysis and governing agent actions.

TL;DR Defines the AI-native SDLC against AI-assisted SDLC, AI-DLC and ADLC, and outlines what agent-driven development means for application security.
Document

What it claims

The Endor Labs guide is a terminology explainer with no data. It argues that an AI-native SDLC differs from an AI-assisted one in structure: specs become the main input to code generation, review shifts toward intent and test coverage, and new controls track which changes came from an agent. On naming, it says AI-DLC means AWS's AI-Driven Development Life Cycle, in which AI drives execution while humans oversee and decide. IBM credits AWS's Raja SP with coining that term in 2025. IBM and Atlan use ADLC to mean Agent Development Lifecycle, the building and operating of agents as products. Endor Labs uses ADLC to mean Agentic Development Lifecycle. The guide's advice is to write "AI-driven SDLC" for the general idea and to state which meaning of "AI SDLC" is meant.

How it works

The stage-by-stage changes are mostly practices a team can adopt:

  1. Write tighter acceptance criteria, because an agent acts on a ticket literally.
  2. Document architecture decisions, interface contracts and informal conventions so agents can follow them.
  3. Make review and security checks record whether a change came from an assistant (suggested, then accepted) or an agent (executed the task).
  4. Keep verification independent, using static analysis and human-designed tests, because generated tests can share the blind spots of generated code.
  5. Route changes by risk. A copy edit and a change to authentication logic should not share a review path. This idea is credited to a daily.dev post, "The AI-native SDLC won't be one process."

A hypothetical example shows the gap: an agent upgrading a logging library edits 14 files, adds a transitive dependency, runs tests and opens a PR. Reviewing the final diff does not show the commands it ran or the systems it touched outside the repository.

For triage, the guide recommends reachability analysis. It separates a vulnerable function that is merely present in a dependency from one the application calls through a traceable path, and it says to fix the reachable one first as PR volume grows.

Limits

The page is vendor content. It positions its AURI product as combining agentic reasoning, deterministic program analysis and a code context graph, but it gives no evaluation, benchmark or usage details. It also gives no metrics for any of its claims. The detail on governing agent actions, including who owns the controls and where policy applies, is deferred to separate Endor Labs guides.

Organisations named here

  • Endor Labs
  • Amazon Web Services
  • IBM
  • Atlan
  • daily.dev
  • AURI
  • AWS
  • Raja SP

Technologies named here

  • AURI by Endor Labs
  • AI-DLC
  • AWS
  • static analysis

Techniques named here

  • AI-native SDLC
  • AI-assisted SDLC
  • Agentic Development Lifecycle
  • Agent Development Lifecycle
  • Reachability analysis
  • Spec-driven code generation