AI SDLC: the software development lifecycle with AI
AI SDLC means the AI software development lifecycle, also written AI-SDLC or AISDLC. It covers how teams define, design, build, verify, release, operate, and improve software when AI contributes to engineering or becomes part of the delivered system.
Two responsibilities meet here. AI-assisted software development uses coding agents and other AI tools to help produce software. AI system development creates applications whose behavior depends on models, prompts, retrieval, tools, or autonomous agents. A team may be doing both at once.
LockedIn Labs publishes AISDLC.ai as its engineering reference for this discipline: original specifications, implementation guidance, source-linked research, and practical tools. Our approach combines human accountability, independent verification, and controls matched to the system’s risk.
A coding assistant is one component. The lifecycle also needs an accepted outcome, architecture, data boundaries, review ownership, test evidence, a release decision, and an operating plan. Faster generation makes those responsibilities more valuable.
How AI SDLC relates to traditional SDLC, DevOps, and MLOps
These practices overlap. The useful question is which responsibilities your delivery system covers and which remain unowned.
| Practice | Primary concern | Connection to AI SDLC |
|---|---|---|
| Traditional SDLC | Requirements, design, implementation, testing, and maintenance. | Provides the engineering foundation. AI adds model, prompt, context, and agent changes that also need review. |
| DevOps / DevSecOps | Repeatable delivery, security checks, infrastructure, and operations. | Provides the pipelines and operating controls that enforce an AI release policy. |
| MLOps / LLMOps | Model and data versions, evaluations, serving, and model behavior. | Supplies model-specific evidence alongside application and business-outcome verification. |
| Agentic SDLC | Agents performing development tasks across multiple stages. | Requires scoped identities, bounded tools, traceable work, independent checks, and named release authority. |
AI-native software engineering brings these responsibilities into the delivery workflow. Changes to a model, retrieval corpus, tool permission, or prompt can matter even when application code is unchanged.
The eight phases of the LockedIn Labs AI SDLC framework
Our enterprise AI SDLC framework organizes delivery into eight phases. Verification operates across them; each phase produces evidence for the next decision.
Intake and classify
Define the use case, affected people, data sensitivity, and permitted actions. Assign a risk tier and a named owner before granting tools or access.
Define and decompose
Turn the intended outcome into acceptance criteria, constraints, and bounded tasks. State how success will be measured and what must remain a human decision.
Architect and threat model
Choose the application, model, context, and integration boundaries. Examine misuse, data exposure, tool permissions, failure recovery, and the path to enterprise systems.
Build in a governed workspace
Use approved repositories, models, dependencies, and pipelines. Version code, prompts, and configuration; retain provenance for human and agent changes.
Verify, validate, and red-team
Run independent checks against the candidate artifact. Evaluate software correctness, model behavior, security, data boundaries, agent trajectories, and the accepted business outcome.
Authorize and deploy
Bind the release decision to the artifact and its evidence. A named authority accepts the deployment conditions, including rollback and operational ownership.
Operate, supervise, and control
Monitor workload outcomes and system behavior. Route incidents to owners, constrain runtime actions, and preserve the record needed to investigate failures.
Recertify, transfer, and retire
Reassess material changes, rehearse handover, and retire identities and access when the system’s scope or lifecycle ends.
An AI SDLC implementation checklist
Start with one bounded delivery workflow. Establish the outcome, capture a baseline, and expand only when the workflow can produce evidence that its owners can inspect.
- Outcome: document acceptance criteria and the person who accepts them.
- Scope: list allowed data, repositories, tools, dependencies, and external actions.
- Context: supply current architecture, constraints, interfaces, and test commands to the engineering team and its agents.
- Independence: protect gate policy, evaluation sets, and release authority from the generator’s write permissions.
- Evidence: connect each candidate artifact to test results, failed attempts, repairs, approvals, and provenance.
- Operations: assign incident ownership and exercise rollback, recovery, and handover.
- Measurement: compare accepted outcomes, rework, escaped defects, intervention, and total delivery cost against the baseline.
Use the AI SDLC Adoption Workbench to classify a use case, then the deployment blueprints to examine an architecture. These are planning references; your team implements and verifies the production controls.
A useful pilot is small enough to review completely: one repository, one owner, explicit acceptance criteria, a protected test suite, and a reversible release path. Measure the accepted result, including the work needed to repair a rejected candidate.
Independent verification is the release foundation
Generation and acceptance need separate authority. A model can propose a change or advise a reviewer; passing an independent gate requires evidence produced by the checks designated for that system.
The LockedIn Labs AISDLC-CQ specification defines 39 citable code-quality and verification clauses across four cumulative levels. Its Java profile and controlled failure-and-repair demonstration make the verification path inspectable.
Deterministic tests, static analysis, schema checks, dependency policy, and security controls address repeatable properties. Model and agent evaluations address behavior under representative and adversarial conditions. Neither replaces the person accountable for the release.
Our framework draws on external work including the NIST AI Risk Management Framework and NIST Secure Software Development Framework. Those references retain their own authorship and scope. The published framework and conformance self-assessment do not confer independent certification.
Explore AI SDLC with LockedIn Labs
- AI SDLC specifications
Code quality, deployment evidence, and delivery-pod accountability, with explicit publication and draft status.
- Agentic engineering knowledge atlas
Definitions, context engineering, harness engineering, evaluation, private AI, and implementation patterns.
- AI SDLC news and briefings
Primary-source developments in GPU infrastructure, agents, evaluation, and software delivery.
- AI software engineering perspectives
Original arguments about delivery pods, product judgment, verification, and accountable deployment.
- AI-native SDLC training
Explore the lifecycle within the LockedIn Labs engineering education program.
- AI SDLC implementation with LockedIn Labs
Discuss workflow adoption, engineering enablement, and enterprise implementation with the firm.
Common AI SDLC questions
Is AISDLC a product or a development practice?
AI SDLC is a development discipline used by multiple organizations. AISDLC.ai is the LockedIn Labs publication; our framework, specifications, perspectives, and reference tools are published here with attribution. Similarly named projects can have different publishers and approaches.
Does AI SDLC replace software engineers?
Our framework assigns people responsibility for intent, architecture, independent assurance, and release. Agents assist with bounded work; responsibility remains with named human owners.
Can we start without training our own model?
Yes. Choose approved tools and models that fit a bounded use case, then establish access controls, representative evaluations, and a protected release path. Model training is a separate decision driven by the workload and evidence.
How should a team evaluate an AI SDLC framework?
Ask what it requires, how those requirements are enforced, who owns exceptions, and which artifacts prove the result. Inspect the source, version, evaluation coverage, repair history, and operating responsibilities.
Where is the current LockedIn Labs specification?
The current AISDLC-CQ reader and standalone Markdown use stable addresses. The specification library also links archived editions and companion draft profiles.
The AI-native SDLC playbook: source and commentary
Anthropic’s Claude Academy playbook connects six lifecycle stages through committed artifacts, evaluation, and human judgment. Our AI-native SDLC knowledge entry links the original lessons and explains how the approach relates to intent, context, harnesses, verification, and operations.
Read Sam M. Sweilem’s playbook review and acceptance crosswalk, then use the companion essays on binding release evidence to a change and measuring accepted outcomes. These are original LockedIn Labs implementation proposals, with the source’s recommendations distinguished from our extensions.
Public AI engineering notes on GitHub
Use the LockedIn Labs AI Engineering Notes by Sam M. Sweilem for four practical review worksheets: an AI SDLC release checklist, an agentic workflow control matrix, FDE hiring evidence, and an AI implementation acceptance brief. The notes reference the maintained specifications and make each decision reviewable.