AI SDLC is a complete software development lifecycle in which specialized AI agents carry work through nine stages — and every transition between stages requires evidence, not declarations. One process for many domains, a full audit trail in Jira and GitHub, and a human owning every strategic decision.
AI agents writing code without a process produce fast — and unpredictably. AI SDLC separates two powers: merit (who creates the stage's content) and flow (who moves work forward). No role holds both at once.
A business initiative, a domain work package, and a small fix all pass through the same stages. The work type changes the stage's output — never the process itself. Zero exceptions, zero side doors to "Done".
The domain answers the question where work lands and who decides. The process answers the question what happens next. No domain gets a lifecycle of its own.
A status change is pure mechanics: it fires only once gate evidence exists. The transition script verifies evidence — it never creates it. The merit decision is made earlier, by the right role.
This is not just our observation. The 2025 DORA report (Google Cloud, ~5,000 respondents) finds AI adoption now correlates positively with delivery throughput — but still negatively with delivery stability. Code arrives faster and changes break more often. DORA calls AI an amplifier: it magnifies an organization’s strengths and its weaknesses alike. DORA’s own conclusions point to small batches, automated testing and fast feedback loops as the counterweight. The separation of powers described below is our answer to that diagnosis — it is not a DORA recommendation. Full figures and sources are on the Results page.
Click a stage to see its contract: who is accountable, what gets produced, and what evidence opens the transition forward.
Every stage ends with a single line of machine-format evidence, published in Jira by the accountable role — and only by that role. The evidence is pinned to an exact code revision (a 40-character commit SHA): the verdict covers what will actually ship, not "roughly this version".
The system runs fail-closed: evidence that is missing, ambiguous, duplicated, or pinned to a different revision means the transition is refused with a machine-readable refusal packet. There is no "pushing" a status through: the transition script checks the evidence live in Jira, every single time.
When the code changes after a verdict is issued, all evidence expires together and the verification stage runs again on the new revision. This closes the classic gap of "we tested it, then someone pushed one more commit".
| Stage | Accountable role | Gate evidence | Transition fired by |
|---|---|---|---|
| Analysis | Analyst Agent | ANALYSIS GATE: PASS | Director |
| Architecture | Architect Agent | ARCHITECTURE GATE: PASS | Director |
| Implementation planning | Planner Agent (solution architect) | IMPLEMENTATION PLANNING GATE: PASS | Director |
| Development | Routed developer agent | DEVELOPMENT GATE: PASS | Director |
| Verification (QA) | QA Agent | VERIFICATION GATE: PASS | QA Agent |
| Release / Close | Release Agent | RELEASE GATE: PASS | Release Agent |
| Learning | Process Owner | LEARNING GATE: PASS | Process Owner |
When a change is architectural in nature or touches a security surface (authentication, cross-tenant data, secrets, new dependencies…), the Verification stage requires additional specialist verdicts — all pinned to the same revision. QA refuses PASS until the full set exists. When in doubt, the classification tilts toward "required". This is audit-ready evidence for SOC 2 / ISO 27001.
When a gate refuses, work does not "fall to the developer by default". It returns to the earliest stage whose accepted contract turned out to be wrong: a flawed requirement — to Analysis, a flawed design — to Architecture, a flawed implementation — to Development. A later role never quietly patches someone else's contract.
An agent role is not a "general prompt" — it is a persistent, versioned skill with an input/output contract, permissions limited to the task, and a ban on stepping outside its assigned scope. Roles fall into two disjoint classes.
Owner of all domains. Decides scope, priority, risk, and result acceptance. The sole source of strategic decisions.
Temporary, for the span of one initiative. Coordinates sequencing and cross-domain dependencies; performs no merit work.
Permanent, one per domain. Runs the domain queue, fires transitions based on evidence, delegates all content to merit roles.
Guardian of coherence: assesses domain health against its strategy and boundaries. Recommends corrections — does not run the queue and does not change scope.
Turns a need into accepted scope: requirements, testable acceptance criteria, estimation, risks.
Architecture decisions (ADRs), threat model, system boundaries — or an explicit, justified "N/A". Architecture is always visited.
The implementation package: work units, target paths, specialist selection per unit, concurrency, verification commands.
Specializations: backend, frontend, browser testing, DevOps. Deterministic routing by file paths; one is accountable for the merged result.
The sole author of the verification verdict and the only role firing the transition out of QA. Consumes specialist verdicts; never issues them itself.
SAST/SCA scans, threat model validation, the security verdict. Evidence for QA — not authority over status.
Mechanical execution: merge only through the deterministic merge gate, post-deployment runtime verification, cleanup.
Runs the Learning stage: a retrospective for every delivery, lessons turned into process improvements with an assigned owner.
The hard boundary: a Director never creates merit content — no analysis, architecture, code, or verdict. A merit role never changes status in Jira. As a result, no single agent can both "do and approve" — the same principle that separation of duties in financial auditing is built on.
A business initiative goes through its own cross-domain analysis and architecture, then decomposes into Domain Work Packages (DWPs) — durable delivery units, each belonging to exactly one domain and passing through the full lifecycle at its own pace. Purely domain work (debt, maintenance, small changes) enters the domain queue directly — with no artificial initiative. A domain is an area of business ownership, not a technical layer: the interface, API and database of one change all belong to the same domain.
The process is tool-independent — Jira materializes state, it does not define it. Every stage, gate evidence line, verdict, and operator decision lands as a durable, role-signed record on the issue. Below — a real run of one issue, step by step.
Statuses are changed only by the transition script, which verifies gate evidence live in Jira. Human and agent see the same state; nobody "drags cards" by hand.
Who is currently working is recorded by a claim label — ownership metadata, not an extra status. Zero fictional "waiting for handoff" states.
Code ships exclusively through pull requests from isolated branches. The merge is executed by a deterministic merge gate once the evidence set is complete — no agent merges "by hand".
Agents do the work and prove its quality — but accepting the result belongs to the Operator. An issue does not reach "Done" until a recorded human acceptance exists at the Learning stage. Scope, priority, risk, and domain boundaries are decisions reserved for humans; an agent that discovers them escalates — it never decides alone.
The Learning stage closes the loop: every delivery ends with a retrospective, and a detected process defect gets fixed or becomes a separate task with an owner. A process that measures and improves itself — that is the difference between "we use AI" and "we run a system that delivers better every week".
This process is not a slide-deck concept. It runs in production: it drives real deliveries — including a security product built to audit standards — with real gates and a real evidence history. We would be glad to walk your team through the full cycle on an example of your choice. We run adoption itself as a process too: three phases with hard exit conditions, where "no-go" is a legitimate outcome that ends with a report, not a sanction — and retrospectives are about the process, never about people.