Skip to content

AirSDLC Philosophy

The Foundation: AWS AI-DLC Principles

The AirSDLC is a practical, open-source implementation of the AI-Driven Development Lifecycle (AI-DLC) framework developed by Amazon Web Services.

The AI-DLC was introduced by Raja SP, Principal Solutions Architect at AWS, as "an AI-centric transformative approach to software development" designed to fully integrate AI capabilities into the fabric of software development.

Note: For complete information about the original AWS AI-DLC framework, see the official AWS blog post and the AI-DLC white paper. For attribution details, see AI-DLC-ATTRIBUTION.md.

To understand AirSDLC's design, it's essential to understand the foundational AI-DLC principles from which it derives.

The Core Paradigm: AI-Driven Execution with Human Oversight

Traditional software development treats AI as an assistant to humans. The AI-DLC—and by extension, AirSDLC—inverts this relationship:

AI is the primary executor. Humans are the validators and strategic decision-makers.

This paradigm shift has profound implications:

Traditional SDLC AI-DLC / AirSDLC
Human creates artifacts AI generates artifacts
AI assists with code completion AI proposes complete designs
Human is the bottleneck AI is the accelerator
Validation is optional Validation is mandatory
Documentation is an afterthought Documentation is generated by default

The human expert's cognitive load shifts from creation to evaluation—a much higher-leverage activity.

Core AI-DLC Concepts

1. The Three Sequential Phases

AI-DLC defines a strict "sequential knowledge handoff" across three distinct phases. Each phase's validated output becomes the non-negotiable input for the next:

  1. Inception: The "WHAT and WHY" phase
  2. Translates Business Intent into a locked, buildable contract

  3. Output: A validated domain model (Unit of Work)

  4. Construction: The "HOW" phase

  5. Transforms the contract into tested, deployable software artifacts

  6. Output: Validated designs and production code (Deployment Unit)

  7. Operation: The "MAINTAIN" phase

  8. Deploys, monitors, and fixes software using full context
  9. Output: Context-aware incident response (Fix-It Bolts)

2. The Core Artifacts

AI-DLC defines specific artifact types that flow through the lifecycle:

Unit of Work (UOW)

The primary container for a major piece of functionality, replacing the traditional "Epic." It is the main output of the Inception phase.

Mandatory Core Composition (the five "problem-defining" artifacts): 1. PR/FAQ (Press Release / Frequently Asked Questions) 2. User Stories 3. Non-Functional Requirements (NFRs) 4. Risk Descriptions 5. Measurement Criteria

Extensibility: Custom artifacts (e.g., Sequence Diagrams, Domain Models) can be added, but the five core artifacts are mandatory.

Bolt

A "single workable unit that only has a single goal," replacing the traditional "Sprint." Bolts are sequential, tactical steps to build a UOW, measured in hours or days.

Core Composition (the "solution-defining" artifacts): 1. Validated Logical Design & Architecture Decision Records (ADRs) 2. Generated Code & Comprehensive Test Suite 3. Deployment Unit

Deployment Unit

The final, "operations-ready" package from the Construction phase, containing code, tests, and Infrastructure-as-Code (IaC) configurations.

Fix-It Bolt

A special, micro-sized Bolt generated by AI for bug fixing during the Operation phase. It follows a structured process: Root Cause Analysis (RCA) → Proposal → Validation → Execution.

3. The Core Rituals

AI-DLC mandates specific "Mob" collaborations that serve as human-in-the-loop validation gates. These are synchronous, collaborative sessions:

Mob Elaboration (Inception)

  • Participants: Cross-functional team (Product, Engineering, Domain Experts)
  • Purpose: Review, refine, and validate the AI-generated draft UOW
  • Output: Validated Unit of Work
  • Cadence: As-needed for new major features

Mob Construction (Construction)

  • Participants: Technical team (Architects, Senior Engineers)
  • Purpose: Review and validate AI's proposed architecture and ADRs for a Bolt before code generation
  • Output: Validated Logical Design & ADRs
  • Cadence: Before starting each Bolt

Continuous Oversight (Operation)

  • Participants: On-call team, SRE
  • Purpose: Expedited validation of AI-proposed operational actions (deployments, fixes, scaling)
  • Output: Go/No-Go decision on production changes
  • Cadence: Real-time during incidents or deployments

4. The Foundational Interaction Loop

Underpinning all AI-DLC rituals is a four-stage cycle that defines the human-AI partnership:

1. [AI] Propose & Decompose
   ↓
2. [AI → Human] Clarify & Question
   ↓
3. [Human] Validate & Direct
   ↓
4. [AI] Implement & Update
   ↓
   (Loop repeats)

Stage 1: Propose & Decompose The AI analyzes input and creates a detailed plan or artifact.

Stage 2: Clarify & Question The AI actively seeks context, identifies ambiguities, and defers critical decisions to humans.

Stage 3: Validate & Direct The "Mob" (human expert or team) provides judgment, makes strategic decisions, and gives approval or refinement feedback.

Stage 4: Implement & Update Only after validation, the AI executes the plan and generates final artifacts.

This loop ensures that AI never proceeds with critical decisions without human oversight.

AirSDLC's Interpretation of AI-DLC

AirSDLC takes these theoretical AI-DLC concepts and makes them actionable for real-world software teams. Here's how AirSDLC interprets and extends the core framework:

The "Unit of Work" → Validated AI-DAA

In formal AI-DLC, the Unit of Work (UOW) is an abstract container for problem-defining artifacts. In AirSDLC, this is concretely represented by:

  • AI-PRD (AI-generated Product Requirements Document) - Contains User Stories, NFRs, Risks, Success Metrics
  • AI-DAA (Domain Architecture Analysis) - The technology-agnostic domain model using DDD patterns

Together, these form the Validated Unit of Work that locks in the "what" before proceeding to "how."

"Mob Elaboration" → Inception Phase Validation

The AI-DLC "Mob Elaboration" ritual is implemented in AirSDLC's Phase 1: Inception. After the AI generates the AI-PRD and AI-DAA:

  • The architect/team reviews for domain accuracy
  • The AI is prompted to generate a "Coverage Report" (does the DAA address all PRD requirements?)
  • The human validates or requests refinement
  • Once approved, the DAA is locked as the input to Phase 2

"Mob Construction" → Collaborative Design Session

The AI-DLC "Mob Construction" ritual is the heart of AirSDLC's Phase 2: Collaborative Design. This is where the framework introduces a unique pattern:

The AI as "Socratic Sparring Partner"

Instead of a traditional design review, the human architect engages in an active dialogue with the AI:

  1. The architect provides the DAA and an initial RFC
  2. The architect prompts the AI to challenge the design using patterns from the Architectural Playbook
  3. The AI asks probing questions, proposes alternatives, and analyzes trade-offs
  4. The human refines the design iteratively
  5. Once robust, the AI generates the finalized AI-ADR

This is not passive code review—it's active, AI-augmented design thinking.

"Bolts" → Actionable ADR Components

In AirSDLC, a Bolt corresponds to a discrete, implementable component from the finalized AI-ADR. For example:

  • ADR: "Implement a Room Booking System with an Outbox Pattern"
  • Bolt 1: "Create the POST /bookings API endpoint"
  • Bolt 2: "Implement the Outbox relay worker for booking events"
  • Bolt 3: "Add monitoring for booking conflicts and availability checks"

Each Bolt is small enough to complete in hours or days, making progress visible and reducing risk.

"Continuous Oversight" → Context-Aware Operations

AirSDLC extends AI-DLC's operational vision by leveraging the full traceability chain. When a production incident occurs:

  1. The AI correlates the error to the specific Bolt, ADR, DAA, and PRD
  2. It provides a "Triage Summary" with full context
  3. It proposes a Fix-It Bolt (hotfix) based on design intent
  4. The human validates and approves deployment

This transforms on-call from a manual scramble into a structured, AI-assisted investigation.

Key Philosophical Decisions in AirSDLC

1. Domain-Driven Design as the Modeling Language

AirSDLC adopts Domain-Driven Design (DDD) as the standard for domain modeling. Why DDD?

  • Business-Centric: DDD focuses on the core business logic, not technical implementation
  • Ubiquitous Language: Ensures shared understanding between domain experts and developers
  • Strategic Boundaries: Bounded Contexts and Context Maps manage complexity
  • AI-Friendly: Structured patterns (Aggregates, Entities, Value Objects, Domain Events) are explicit and machine-readable

The AI can be trained to identify and generate DDD patterns from a well-structured PRD, making the Inception phase highly automatable.

2. Technology Agnosticism in the DAA

A critical principle: The AI-DAA is 100% technology-neutral.

It describes the business domain using pseudocode and DDD patterns without specifying: - Databases (SQL, NoSQL, etc.) - Programming languages (Go, Python, Java, etc.) - Frameworks (Spring, Django, Express, etc.) - Deployment platforms (AWS, GCP, Kubernetes, etc.)

Rationale: This ensures domain understanding is not polluted by technical constraints. A single DAA can be implemented as a Python monolith or as Golang microservices—the business logic remains the same.

3. Pragmatism Over Dogma

While AI-DLC provides a comprehensive framework, AirSDLC recognizes that context matters. Not every feature requires the full ceremony.

AirSDLC introduces the Hybrid Model: - Full Workflow (PRD → AI-DAA → RFC → AI-ADR): For complex, high-risk, or unfamiliar domains - Lightweight Workflow (PRD → TIP → RFC → AI-ADR): For simple, well-understood features

The decision is based on a simple matrix considering: - Feature complexity - Team maturity - Timeline pressure - Risk level

Non-Negotiable: Validation is never skipped, regardless of workflow choice.

4. Validation as a First-Class Activity

In AirSDLC, validation is not an afterthought—it is a mandatory gate at every phase:

  • PRD-to-DAA Coverage: Does the domain model address all requirements?
  • DAA-to-ADR Alignment: Do technical decisions respect domain invariants?
  • ADR-to-Code Compliance: Does implementation match the design?

AI-driven validation reports make this fast and consistent, turning what was once a manual checklist into an automated safety net.

5. The Knowledge Repository as the Central Artifact

Traditional SDLCs produce: - Code (in version control) - Documentation (in wikis, often stale) - Decisions (in meeting notes or people's heads)

AirSDLC produces a single, interconnected Knowledge Repository: - All artifacts (PRD, DAA, RFC, ADR, Bolts) are stored and linked - The repository is machine-readable and queryable - It serves as the "brain" for AI-driven operations - Post-mortems feed back into the repository, closing the learning loop

This repository is not just documentation—it is the single source of truth for the entire system.

The Virtuous Cycle of Knowledge

AirSDLC creates a feedback loop between development and operations:

Design (Writes to Repository)
   ↓
[Knowledge Repository]
   ↓
Operations (Reads from Repository)
   ↓
Post-Mortems (Write back to Repository)
   ↓
Future Design (Informed by operational learnings)

This cycle ensures that: - Design decisions inform operations - Operational learnings improve future designs - Architectural knowledge compounds over time

Summary: The AirSDLC Mindset

To successfully adopt AirSDLC, teams must embrace a fundamental mindset shift:

  1. Trust AI to Generate: Let AI create first drafts of domain models, designs, and code
  2. Validate Rigorously: Human expertise focuses on evaluation, not creation
  3. Model Before Implementing: Invest in understanding the "what" before deciding "how"
  4. Capture Knowledge: Treat documentation as a first-class artifact, not a chore
  5. Trace Everything: Maintain an unbroken chain from business goal to code
  6. Learn Continuously: Feed operational insights back into design knowledge

The result is faster development, better designs, and more maintainable systems.

Next: Lifecycle - The three phases in detail

References

Original AWS AI-DLC Framework

Attribution: The AI-DLC methodology is © Amazon Web Services, Inc. AirSDLC is an independent, open-source implementation of the AI-DLC framework.

Next: Lifecycle - The three phases in detail