AIDLC Frequently Asked Questions

AIDLC, the AI Development Life Cycle, is a five-phase framework for building software with AI coding agents as part of the team: Analyze, Ideate, Develop, Launch and Curate. Agents draft the requirements, designs, tests and code; people approve each step, and every incident feeds a rule back into the cycle.

No. Agents take on more of the drafting, which raises the value of judgment: deciding what to build, writing criteria and specs precise enough to build from, approving plans and reviewing results. Every approval in AIDLC belongs to a named person, so someone accountable stays in the loop at each phase.

No. Vibe coding means prompting loosely and accepting whatever comes back. AIDLC is the opposite discipline: written acceptance criteria, an approved plan before code, tests before the implementation, review at each change's risk tier, and rules enforced outside the prompt.

The framework documented on this site is written and maintained by RJ Lindelof, drawing on his teams' work with coding agents in production. It is a practitioner methodology, not a product, and it works with whichever AI tools a team already uses.

The SDLC was organized around the cost of people writing code. AIDLC is organized around the cost of people verifying code that agents write. The stages map closely, but tests move before the code, documents become contracts that agents read, review scales by risk tier, and incidents produce rules every future agent run follows.

No. They share an acronym but are different frameworks. AWS's AI-DLC is a detailed workflow engine with many stages, delivered through specific agent harnesses. AIDLC on this site is a five-phase, tool-agnostic methodology focused on the operating model around agents. The comparison page explains when each fits.

No. AIDLC is a practitioner framework published openly on this site, not a standards-body specification, and this site does not offer a certification. Teams that need an audit-facing frame usually pair it with an existing standard such as ISO/IEC 5338 or the NIST AI Risk Management Framework.

No. The phases describe the state of a piece of work, not stages of a calendar, so a team has work in all five at once. Analyze and Ideate usually run per feature, Develop per ticket, Launch per release and Curate continuously, and work can move backward on purpose when a later phase finds a problem.

Always a named person. Agents can draft almost every artifact, but the product owner signs the brief, the tech lead approves the design, the ticket owner approves the plan, a reviewer approves the pull request and the release owner makes the go decision. An agent can be responsible; it is never accountable.

The work goes back with an artifact, to the phase that owns the decision, and the move is counted. An ambiguous requirement returns to Analyze as an open question, an unbuildable spec returns to Ideate as a change request, a failing gap test returns from Launch to Develop, and an incident returns to Analyze with a new rule, test or eval.

Release assurance. Launch runs the full suite against the integrated release candidate, re-checks mutation scores on critical modules, looks for gaps as an independent critic, and adds only the checks that cannot exist before there is a release: smoke tests, health checks and a rehearsed rollback. It writes a new test only when it finds a gap.

From the artifacts that reach it. Ideate's API and data contracts name every module boundary, the spec traces to every acceptance criterion, and the ticket contract lists the external systems, data contract and blast radius for each slice. Contract tests come straight from Ideate's contract, and the ticket that completes a user journey writes that journey's end-to-end test.

It would if it were planned, which is why it is not. A gap found in Launch is an exception and a metric: a rising count means the criteria or Develop's gates need fixing upstream. When a gap test passes on the current code, nothing goes back at all; the test is kept and the Develop gate that missed it is tightened.

In Develop, before the code. Each acceptance criterion becomes a unit, integration, contract or end-to-end test at the level it needs, and the agent implements until the tests pass. Launch runs the full suite against the integrated release and writes a new test only when it finds a gap; a failing gap test goes back to Develop.

It builds on both. AIDLC uses the Given/When/Then criteria of behavior-driven development and the tests-before-code order of acceptance test-driven development. What it adds is the agent: precise criteria let a coding agent generate the tests before the implementation, with gates that stop it from weakening them later.

Generate tests from the acceptance criteria rather than the code, require each new test to fail before the implementation exists, block agents from editing existing tests, and gate critical modules on a mutation score instead of coverage. Mutation testing changes the code on purpose and checks that a test notices.

A test Launch writes when its assurance pass finds something the suite does not cover, such as an untested acceptance criterion, a module boundary or a surviving mutant. If the gap test fails, it has found a defect and goes back to Develop as the feedback. If it passes, the code was right and the suite was thin, so the test is kept and Develop's gate is tightened.

Mutation testing makes small deliberate changes to the code - flipping a condition, changing a value - and checks that at least one test fails for each change. A change no test notices is a surviving mutant. AIDLC gates critical modules on a mutation score rather than coverage, because coverage only shows which lines ran, not whether the tests would catch a real bug.

No. AIDLC is model-agnostic and works with Claude, ChatGPT, Gemini, Claude Code, Codex, Copilot, Cursor or an in-house engine. Pin whichever model you use and run your evals before changing it, so an upgrade is a reviewed change rather than a silent shift in behavior.

Yes. Model the five phases as states in the engine's workflow, store each artifact as a typed, versioned record with human approvals kept separately, turn exit criteria into automated checks followed by named approvals, and enforce the hard rules in the runtime rather than in prompts. The reference architecture page lays out seven layers and shows the data and configuration.

The five phases stay the same, but evals take the role that tests play for code. Write eval cases before changing a prompt, model or retrieval setup, pin all three as code, gate every change on the eval suite, release with a one-step rollback to the previous configuration, and turn every bad production output into a new eval case.

All of it is on this site and free to read: the five phase pages with entry and exit criteria, a worked example that follows one invented feature through every phase, copyable templates for the ticket contract, PR fields, hard rules and instruction file, a prompt library, a cheatsheet, a reference architecture with implementation examples, and a research library that lists every source.

No. Agents work on a local repository without it, and the method does not depend on any protocol. MCP becomes useful once agents need your wider systems - the tracker, docs, CI and telemetry - because it gives them a standard, governed interface where read and write access can be split and audited.

Yes, when behavior is pinned first. Build reviewed architecture notes, write characterization tests that record what the code does today, and only then let agents change it in small batches. Without that safety net, an agent's change can look right and still alter behavior nobody documented.

The Rollout Playbook on this site plans it in four overlapping phases over roughly nine months: a baseline and configuration in the first weeks, then assisting, delegating and finally compounding. A small team can skip most of that ceremony, but it keeps the core controls: a short usage policy, an instruction file, plan first, tests before merge and a rollback path.

Yes. Its controls - agent identities, least-privilege permissions, risk-tiered review, human approvals and an audit trail for every agent run - map onto the frameworks auditors already use, including SOC 2, ISO/IEC 27001, HIPAA and the EU AI Act. The Security and Compliance page shows the mapping.

No. AIDLC runs inside Scrum, Kanban and DevOps. Refinement produces the ticket contract, sprints plan around review capacity rather than authoring capacity, and retrospectives feed the learn loop. What changes is where the bottleneck sits, not the framework you use to manage the work.

One named owner, usually a Director or VP of Engineering, accountable for policy, measurement and vendors. A platform or developer-experience team owns agent identities, CI integration, budgets and the shared instruction files; security owns data classification and vendor review; and each team lead owns review standards and risk-tier assignments for their codebase.

Capture a baseline before you start, then report delivery outcomes against it: cycle time from ticket to production, review latency, change failure rate and escaped defects. Do not report adoption, the share of code written by AI or suggestions accepted as success, because those measure usage rather than outcomes, and check each quarter that faster authoring is not just building a queue at review.

Use the contact form on this site. Every message is read, and questions that come up more than once are answered on the site itself, which is how several of the pages here began.