The AI Development Lifecycle (ADLC) Explained for Non-Engineers

One of the most disorienting things about joining an AI project for the first time is that the lifecycle doesn't map cleanly to anything you've done before. Agile sprints still happen, but they feel different. There are phases called "training" and "eval" that don't have equivalents in traditional software development. And the point at which something is "done" keeps shifting.

The AI Development Lifecycle (ADLC) is a framework that makes this navigable. It names the six phases of an AI project, explains what happens in each one, and — critically — defines who owns what across roles. No ML background required to use it.

## Why AI projects need their own lifecycle framework

Traditional software development frameworks (Agile, Scrum, Waterfall) describe how to build deterministic systems. Input → process → output. The spec describes the output. Engineering builds it. QA verifies it matches the spec.

AI systems break this model at the spec layer. You can't fully specify an AI output in advance — the model's behavior is learned from data, not programmed from a spec. This means the lifecycle has to include phases that traditional frameworks don't have: a phase where you define what the AI is allowed to learn and do (Framing), a phase where you verify whether it learned it correctly (Eval), and a phase where you monitor whether it continues to behave correctly in production (Production monitoring).

The ADLC adds these phases explicitly. It also defines the non-engineer roles clearly — something most AI development frameworks ignore entirely.

## The six phases

### Phase 1: Discovery

**What happens**: The team determines whether AI is the right solution for the problem, and if so, what kind of AI system is appropriate.

**Key questions**: Is this actually a probabilistic problem, or does it just sound like one? Is there sufficient data to train or tune a model? What's the risk profile if the AI is wrong?

**Who owns it**: The PM or BA typically runs the AI intake interview. Delivery lead documents the decision. Engineering contributes technical feasibility input.

**Output**: A suitability verdict (yes/no/conditional) with documented reasoning. A risk register for the AI component.

**What "done" looks like**: The team has agreed that AI is appropriate for this use case, documented why, and identified the risk level. Everyone agrees on what happens if the AI fails.

---

### Phase 2: Framing

**What happens**: The team defines what the AI must do, what it must not do, and what it must hand off to humans. This phase produces the most important document in the ADLC: the Specify document.

**Key questions**: What can this AI decide autonomously? What requires a human? What's the fallback behavior? What guardrail conditions apply?

**Who owns it**: The PM is the Spec Owner — they write and own the Specify document. The BA contributes the 6 AI requirements sections (confidence thresholds, handoff triggers, guardrail conditions, fallback behavior, data quality specs, eval threshold). QA contributes the eval threshold definition.

**Output**: A Specify document — the behavioral contract for the AI system. This document governs everything that follows.

**What "done" looks like**: The Specify document is written, reviewed by the team, and signed off by the Spec Owner. Architecture does not begin until this document exists.

---

### Phase 3: Architecture

**What happens**: Engineering designs how the system works — what model to use, how to structure the data pipeline, how the AI integrates with existing systems, what the inference infrastructure looks like.

**Key questions**: Which model (fine-tuned, prompted, RAG-augmented)? What data does it need access to? How does it connect to the product? What does the fallback implementation look like?

**Who owns it**: Engineering leads this phase. PM reviews for alignment with the Specify document. Delivery lead ensures the eval plan is documented before Build begins.

**Output**: A system design that implements the Specify document. An eval plan (golden set definition, rubric, threshold, judge methodology).

**What "done" looks like**: Engineering, PM, and QA have reviewed the architecture. The eval plan exists and has been approved. The golden set scope has been agreed on.

---

### Phase 4: Build

**What happens**: Engineering builds it. The model is trained, tuned, or integrated. The product features are developed. The eval infrastructure is set up.

**Key questions**: Are edge cases that surface during Build handled consistently with the Specify document? If the Spec needs to change, who decides?

**Who owns it**: Engineering. PM is on call for Spec clarifications. BA maintains a decision log for any requirement changes. QA prepares the golden set.

**Output**: A working AI system ready for evaluation.

**What "done" looks like**: The system behaves as specified in controlled testing. The golden set is ready. The eval infrastructure can run.

---

### Phase 5: Eval

**What happens**: The AI system is evaluated against the golden set using the rubric defined in Architecture. The team makes a GO / CONDITIONAL GO / NO-GO decision.

**Key questions**: Did the model hit the eval threshold? Are there failure modes that require guardrail changes? Is the system safe enough to ship?

**Who owns it**: QA leads the eval execution. PM makes the go/no-go call (the Spec Owner signs off). Delivery lead ensures the process was followed and the verdict is documented.

**Output**: An eval report with scores across all eval dimensions. A formal GO / COND / NO-GO verdict with documented evidence.

**What "done" looks like**: The eval report exists. The threshold was either met or the exception is documented and approved. A signed verdict exists. The production readiness checklist is complete.

---

### Phase 6: Production

**What happens**: The AI system goes live, is monitored, iterated on, and eventually deprecated or replaced.

**Key questions**: Is the AI behaving as expected in production? What signals indicate something is wrong? Who decides when to pull it offline?

**Who owns it**: Engineering owns the infrastructure. PM owns the incident policy and monitors against the Specify document. Delivery lead owns the monitoring cadence.

**Output**: A live AI system with monitoring, an incident playbook, and a clear ownership model.

**What "done" looks like**: This phase doesn't end — but it has checkpoints. At each checkpoint, the team reviews monitoring data against the rubric and decides whether to continue, adjust, or deprecate.

---

## The ADLC vs. Agile: do they conflict?

They don't. The ADLC maps onto Agile sprints. You run sprints within each phase. What the ADLC adds is clarity on what each sprint is for and what the phase gate is.

The phase gate is the most important addition. Before you move from Framing to Architecture, the Specify document must exist. Before you move from Architecture to Build, the eval plan must exist. Before you move from Eval to Production, the GO verdict must exist.

These gates prevent the AI project failure mode: moving forward because the calendar says to, without the artifacts that make the next phase safe.

## Why non-engineers need this more than engineers do

Engineers understand intuitively when something isn't ready — they see the model performance numbers, the hallucination rate, the latency. They know when it needs more work.

The challenge is that the pressure to ship often comes from stakeholders who don't see those numbers. The PM who doesn't know the eval threshold. The delivery lead who doesn't know the GO verdict is missing. The executive who sees "the AI works in the demo" and schedules the launch.

The ADLC gives non-engineers the vocabulary to participate in these decisions. When you can ask "has the eval threshold been met?" and understand what the answer means, you're no longer bystanders to the most critical decisions in an AI project.

[Learn the ADLC in the free 90-minute seminar →](https://forwarddeployed.app/seminars)