AI-SDLC
Governing AI-Driven Software Delivery
AI-SDLC (AI-driven software development lifecycle) is an operating model that uses AI across software delivery while keeping people accountable for intent, risk, and outcomes. It is not a licence to ship generated code faster. The point is to turn rapid AI iteration into reliable, auditable delivery.
AI can help with planning, analysis, design, implementation, testing, deployment, and incident response. The constraint moves: implementation becomes cheaper, while clear requirements, trustworthy context, verification, and decision-making become more valuable.
The shift: from prompts to a delivery system
An engineer pasting a prompt into a chat tool can be useful. It is not yet an AI-SDLC. That approach loses the reasoning behind decisions, makes quality dependent on individual diligence, and gives leaders no reliable way to assess risk or impact.
An AI-SDLC makes five things explicit:
| Element | What it means in practice | Why it matters |
|---|---|---|
| Intent | A concise problem statement, business context, constraints, and measurable completion criteria. | Agents cannot resolve ambiguity that the organisation has not resolved. |
| Context | Versioned architecture decisions, coding standards, runbooks, and repository guidance available where work happens. | Good context reduces plausible-but-wrong changes and prevents each session starting from zero. |
| Autonomy boundary | A deliberate choice of what an agent may read, change, execute, or deploy. | The level of autonomy should follow reversibility and risk, not tool marketing. |
| Backpressure | Tests, linters, security checks, policy controls, and review gates that reject unacceptable work. | Verification provides evidence without prescribing every implementation step. |
| Learning loop | Production signals, defects, review findings, and incidents improve the context and guardrails. | The system compounds organisational learning instead of repeating the same mistakes. |
This is a useful way to read the AI-DLC methods and workflow tools: they are examples of structured, verifiable delivery, not a mandatory toolchain or replacement for engineering judgement.
Applying AI through the lifecycle
| Lifecycle activity | Useful AI contribution | Human-owned decision or evidence |
|---|---|---|
| Discover and plan | Summarise research, identify unanswered questions, draft options, and find similar work. | Problem framing, customer impact, priority, and success measures. |
| Design | Explore alternatives, generate diagrams, trace dependencies, and identify likely failure modes. | Architectural trade-offs, data classification, and threat model. |
| Build | Implement bounded changes, refactor, document, and explain unfamiliar code. | Scope, code review, and ownership of the merged change. |
| Verify | Generate test cases, find missing edge cases, analyse failures, and propose fixes. | Test strategy, acceptance criteria, and the decision that evidence is sufficient. |
| Release and operate | Summarise changes, correlate telemetry, triage alerts, and draft incident timelines. | Production access, release approval, incident command, and customer communication. |
Do not automate a weak process. If requirements are vague, tests are flaky, or a service has no owner, an agent will make the underlying problem happen faster and at greater scale.
Choose autonomy deliberately
Treat autonomy as a risk decision. A useful default is to increase it only when a task is bounded, reversible, and independently verifiable.
| Mode | Suitable work | Guardrail |
|---|---|---|
| Human in the loop | Architecture, security-sensitive work, production data, novel changes. | Explicit approval before consequential actions. |
| Human on the loop | Routine feature work and investigation where a person can observe and intervene. | Live visibility, stop controls, and clear escalation conditions. |
| Bounded autonomy | Mechanical refactors, test expansion, migrations with rehearsals, and documentation updates. | Narrow permissions plus automated checks and review before merge or release. |
Production changes, external communications, spend commitments, and access-control changes should remain deliberately constrained. An agent’s ability to use a tool is not approval to take the action.
Design the controls before scaling usage
Start with the controls that make ordinary software delivery safe, then extend them for AI-specific failure modes.
- Make repository guidance executable. Keep conventions, setup instructions, allowed commands, test expectations, and escalation paths close to the code. Maintain this guidance like any other production artefact.
- Protect secrets and sensitive context. Define approved models and accounts; use least-privilege, scoped credentials, and segregated environments. Do not assume a prompt is a secure boundary.
- Require evidence, not confidence. A passing build, targeted tests, static analysis, dependency scanning, and reviewable diffs are stronger than an agent’s explanation of why its change is correct.
- Threat-model agent workflows. Consider prompt injection through issues, documentation, logs, and third-party content; unsafe tool calls; data disclosure; and excessive permissions. Treat retrieved content as untrusted input.
- Keep a trace for consequential work. Record the request, relevant context, model or agent configuration, tool actions, approvals, checks, and deployment outcome. This is practical incident evidence, not paperwork for its own sake.
Measure outcomes, not generated output
Lines produced, prompts sent, and agent hours are activity metrics. They can rise while customer value, maintainability, or reliability falls. Pair delivery measures with quality and risk signals instead.
- Flow and responsiveness: lead time for changes, review wait time, and time spent unblocking work.
- Quality: escaped defects, change failure rate, rollback rate, flaky-test rate, and rework caused by AI-generated changes.
- Operational safety: policy violations, sensitive-data incidents, unauthorised tool attempts, and time to detect and contain them.
- Adoption health: percentage of eligible work with clear completion criteria and verification evidence; engineer sentiment; and distribution of review load.
Compare a pilot cohort with a similar baseline, and inspect the work itself. Faster merges that create more incidents are not a productivity gain.
A pragmatic adoption path
- Pick one bounded workflow. Start with a low-risk, high-volume task such as test generation, dependency upgrades, documentation, or a well-understood defect class.
- Set the contract. Define inputs, completion criteria, prohibited actions, permissions, reviewers, and the evidence required to progress.
- Build the verification path. Make the fast checks reliable first: tests, type checks, linting, security scanning, and a small set of meaningful integration checks.
- Run the pilot in the open. Capture prompts or task intent, diffs, failures, reviewer feedback, costs, and operational outcomes. Let engineers challenge the workflow.
- Expand by evidence. Broaden task scope or autonomy only where the pilot shows stable quality, manageable review load, and clear value. Update the guidance from what failed.
Why CTOs should care
AI-SDLC changes the economics of software delivery, but it does not repeal the need for engineering discipline. The teams that benefit most will not be those with the most autonomous agents. They will be the teams with clear product intent, healthy delivery controls, accessible institutional knowledge, and leaders willing to measure trade-offs honestly.
Your job is to make safe speed the default: give teams useful capability, preserve meaningful human accountability, and ensure the organisation learns faster than the tools change.
Explore Next
- AGENTS.md — Define the context, constraints, and operating boundaries for coding agents.
- Threat Modelling — Identify risks before an agent can introduce them into a system.
- The Test Pyramid — Build fast, layered evidence that changes work as intended.
- DORA Metrics — Measure whether faster delivery is also safe and reliable.
References
- AI in the SDLC — Overview of AI assistance across planning, development, testing, deployment, and maintenance.
- AI-Driven Development Lifecycle Method Definition — A methodology for intent, completion criteria, operating modes, and verification backpressure.
- AI-DLC Paper — A detailed proposal for an AI-driven development lifecycle and its operating model.
- AWS AI-DLC Workflows — Open-source, harness-neutral workflows that connect requirements, review evidence, and approvals.