AWS AI-DLC in the APS: Fit Analysis for Large, Regulated Digital Delivery

Methodological Note

This paper analyses AWS's AI-Driven Development Lifecycle (AI-DLC) against a class of APS program, not a specific program under direct observation. The author is a software engineer inside the APS but is a distant observer of the delivery programs described here. Claims about program shape, bottlenecks and delivery mechanics are based on published evidence about SAFe at scale in regulated organisations, general knowledge of APS digital delivery practice and the AI-DLC primary sources listed in the appendix. Where a claim is analysis rather than sourced fact, it is flagged [AJ] (author judgment).

Citation tiers used throughout:

• [P] AI-DLC methodology paper (Raja SP, AWS, 2026), page numbers where useful
• [GH] awslabs/aidlc-workflows GitHub repository, specific file
• [AWS] AWS-authored blog or session, with URL and date in the appendix
• [3P] Third-party source (independent publication, analyst or conference summary)
• [AJ] Author judgment, not a sourced claim

Limitations

The observations and analysis in this paper should be moderated by the constraints and boundaries detailed below. These limitations are self-disclosed and are grounded in the trial implementation described in Appendix D.

• Greenfield custom software only. Framing and evaluation assume new-build custom code. Commercial off-the-shelf platforms (ServiceNow, Salesforce, Pega, MuleSoft) and BAU maintenance work are out of scope. AI-DLC's Reverse Engineering stage and incremental-change scenarios were not exercised.
• Single practitioner, early adoption. First use of AI-DLC; third use of Superpowers. Judgement improves with repetition and user error is plausible in several places (noted where relevant, e.g. the Level 1 Plan not triggering a simpler path).
• One trial implementation. Empirical evidence comes from a single feature build (Auto Search; see Appendix D), not a portfolio of projects. The project was small-scope and built by one person.
• Inception and Construction only. The Operations phase was not evaluated. At the Operations phase boundary, the trial output "Per the project workflow in CLAUDE.md, the Operations Phase is currently a placeholder" — Operations coverage in the AI-DLC rule set is stub-level at this snapshot [GH].
• Superpowers comparison is convenience, not equivalence. Superpowers appears in this paper because it was in concurrent use during the trial. It targets individual developers; AI-DLC targets delivery teams. Direct feature comparison is misleading outside that caveat.
• Snapshot in time. April 2026. Both AI-DLC and Superpowers evolve rapidly. Specific gaps called out here may close within one minor release.
• Agent-specific observations. The trial used Claude Code CLI as the AI coding agent. Behaviour may differ with GitHub Copilot, Amazon Q Developer, Cursor or Kiro.
• Practitioner-as-evaluator bias. The author is both user and reviewer of both methodologies. Friction described here may reflect user error as much as methodology weakness.

Executive Summary

AI-DLC is a well-designed, team-level AI-native coding workflow that is necessary but not sufficient for a digital delivery program of ~200–300 people working on a SAFe Agile Release Train with quarterly major releases, multiple SI vendors and complex regulated government-domain requirements.

What it does well

AI-DLC reimagines the build loop so AI initiates and drives work, humans validate at explicit decision gates and design techniques (e.g. Domain-Driven Design or DDD) are baked into the core rather than left to each team. Its published rule set is concrete, open source and installable in the popular AI coding agents most teams already use. For a single well-scoped feature team working in a new-ish codebase, AI-DLC can compress Inception from weeks to hours and shorten Construction cycles from sprints to days [P].

Where the fit breaks down

The primary constraint on a large APS digital delivery program is structural, not individual: release gating, change management overhead, cross-vendor coordination, regulatory and privacy approvals, APS mandatory compliance and legacy brownfield complexity. AI-DLC's Principle 8 (minimise specialist silos) [P:2] is a deliberate design choice that sits in genuine tension with common mandatory APS specialist roles (e.g. privacy officer, security architect, accessibility lead, data stewards etc). The methodology does not address CI/CD governance, inter-entity release coordination or AI Impact Assessment workflow, because those are explicitly outside its scope.

Conditional framing

• If the bottleneck is team-level code throughput on greenfield or well-contained brownfield work: AI-DLC addresses it directly and the productivity gains are plausible at the levels that AWS claims, subject to the measurement caveats below.
• If the bottleneck is structural (release cadence, CR governance, cross-vendor integration, assurance gates, ministerial-level risk): AI-DLC is necessary but insufficient. Speeding Construction from four weeks to four days does not help if the release window is still quarterly and the CR queue is the gate.

Trial implementation findings

AI-DLC seems a good fit for documentation and compliance focused delivery with strong traceability and audit support. It also dives deeply into requirements and technical design; seeking clarification and suggesting options that match senior level BAs and developers. Two key concerns during trial implementation of Auto Search (see Appendix D for details) are: missing implementation of stated requirements and missing Operations phase. These should be investigated further before further investment of time and energy into AI-DLC.

Productivity claims need care

AWS reports 10–15x productivity gains, 40–60% velocity improvement and 40–60% defect reduction based on 100+ customer experiments [AWS - re:Invent 2025 DVT214; AWS DevOps blog 2026]. Independently measured studies of AI coding assistants report substantially smaller numbers: ThoughtWorks measured a team-level cycle-time improvement of ~8% when Copilot was used on roughly half of tickets, with a broader estimate of 5–15% across organisations; task-specific gains of 30–50% were observed for boilerplate work and 10–40% for business logic [3P - ThoughtWorks 2024]. These numbers are not measuring the same thing. The AWS figure aggregates full-workflow compression (Inception + Construction); the independent figures measure code-authoring or team cycle time. Neither number can be multiplied against total program lead time without a Lean value stream analysis, because coding is typically a small fraction of the total wait-weighted lead time in regulated delivery [3P - Poppendieck 2003; Forsgren, Humble, Kim 2018].

Illustrative math

Figure 2 — Lead-time value stream decomposition

Reading the chart: baseline lead time is 100 units; after AI-DLC it is 91 units. The 9-unit reduction is entirely inside the Coding segment. Wait, gating and release-window segments (the majority of lead time in a regulated program) are untouched by AI-DLC itself. If coding is a larger share of the baseline — 20% rather than 10% — the same 10x compression yields ~18% program-level reduction. Either way, the AI-DLC gain is bounded by the size of the coding slice in the current value stream. Measure this slice first [3P - Forsgren, Humble, Kim 2018].

What AI-DLC Is

AI-DLC is an AI-native software development methodology published by AWS in 2026. The methodology paper [P] defines the principles, phases, roles, artefacts and rituals. The awslabs/aidlc-workflows GitHub repository [GH] publishes the concrete rule files that make the methodology executable inside an AI coding agent.

Ten principles

1. Reimagine rather than retrofit
2. Reverse the conversation direction (AI initiates, human validates)
3. Integrate design techniques into the core (first flavour is Domain-Driven Design)
4. Align with current AI capability (AI-Driven, not fully autonomous)
5. Cater to building complex systems (not low-code use cases)
6. Retain what enhances human symbiosis (user stories, risk register)
7. Facilitate transition through familiarity (Sprints rebranded as Bolts)
8. Streamline responsibilities for efficiency (minimise specialist silos)
9. Minimise stages, maximise flow (human validation as "loss function")
10. No hard-wired opinionated SDLC workflows (AI proposes a Level 1 Plan per intent)

Figure 1 — AI-DLC phases, rituals and human approval gates

%%{init: {'theme': 'neutral', 'themeVariables': {'edgeLabelBackground': '#ffffff'}}}%%
flowchart TB
    PO([Product Owner articulates Intent])
    PO --> L1[AI generates Level 1 Plan]
    L1 --> G0{{Human validates and approves Plan}}
    G0 --> Inception

    subgraph Inception[INCEPTION PHASE]
        In1[AI drafts user stories, NFRs, risks, PRFAQ]
        In1 --> In2[Team validates, refines, challenges]
        In2 --> In3[Units defined plus suggested Bolt plan]
    end

    Inception --> G1{{Approve Units and Bolt plan}}
    G1 --> Construction

    subgraph Construction[CONSTRUCTION PHASE]
        Co1[Domain Design - DDD modelling]
        Co1 --> Co2[Logical Design plus ADRs, NFRs, cloud patterns]
        Co2 --> Co3[Code plus Unit Tests]
        Co3 --> Co4[Functional, security, performance tests]
        Co4 --> Co5[Deployment Unit ready]
        Co5 -. next Bolt or next Unit .-> Co1
    end

    Construction --> G2{{Approve deployment}}
    G2 --> Operations

    subgraph Operations[OPERATIONS PHASE]
        Op1[Deploy to staging or production]
        Op1 --> Op2[AI analyses telemetry, detects anomalies]
        Op2 --> Op3[AI proposes runbook actions]
        Op3 --> Op4[Human approves, monitors outcome]
    end

    classDef gate fill:#fff4d4,stroke:#b58900,color:#333
    class G0,G1,G2 gate

Yellow diamonds mark the human approval gates that AI-DLC treats as a "loss function" that catches and prunes errors early before they propagate downstream [P:3]. Inception uses the Mob Elaboration ritual; Construction uses Mob Construction and Mob Testing rituals, iterating through Bolts of hours-to-days; Operations runs AI-driven telemetry analysis with human approval on proposed actions.

Three phases

• Inception Phase. Captures Intents, runs Mob Elaboration to decompose them into Units and User Stories, produces PRFAQ, NFRs, Risks and Measurement Criteria.
• Construction Phase. Iteratively turns Units into Deployment Units through Domain Design → Logical Design → Code and Unit Tests → Build and Test. AWS services are selected against well-architected principles.
• Operations Phase. AI analyses telemetry, proposes runbook actions, humans validate and approve.

Key artefacts: Intent, Unit (equivalent to Epic/Subdomain), Bolt (rapid iteration, equivalent to Sprint), Domain Design, Logical Design, Deployment Unit [P:3-4].

Adaptive depth

Inspection of the rule files confirms two mechanisms [GH: core-workflow.md; inception/workflow-planning.md]:

1. AI generates a Level 1 Plan that recommends which optional stages to execute or skip, with rationale. Humans approve or override before any stage runs.
2. Some stages are explicitly conditional in the rule files (Reverse Engineering is brownfield-only; User Stories and Application Design are conditional on complexity and user-facing impact).

Mandatory stages (Workspace Detection, Requirements Analysis, Workflow Planning, Code Generation, Build and Test) always run. Requirements Analysis always executes but varies between Minimal, Standard and Comprehensive depth.

Figure 3 — Adaptive workflow and Level 1 Plan mechanism

%%{init: {'theme': 'neutral'}}%%
flowchart TB
    I([Intent]) --> L1[AI: generate Level 1 Plan]
    L1 --> G{{Human: approve or override plan}}

    G -->|brownfield detected| RE[Reverse Engineering]
    G -->|always| WD[Workspace Detection]
    RE --> WD

    WD --> RA[Requirements Analysis - Minimal or Standard or Comprehensive depth]
    RA --> WP[Workflow Planning]

    WP -->|user-facing and complex| US[User Stories]
    WP -->|if warranted by plan| AD[Application Design]
    WP -->|always| CG[Code Generation]
    US --> CG
    AD --> CG

    CG --> BT[Build and Test]
    BT --> DU([Deployment Unit])

    EXT[Extensions - opt-in, hard constraints on non-compliance]
    EXT -.->|APS hooks go here| RA
    EXT -.-> BT

    classDef mandatory fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    classDef cond fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef gate fill:#fff4d4,stroke:#b58900,color:#333
    classDef ext fill:#dcfce7,stroke:#16a34a,color:#14532d
    class WD,RA,WP,CG,BT mandatory
    class RE,US,AD cond
    class G gate
    class EXT ext

The extension mechanism is where APS-specific gates (PIA, AIIA, ISM, accessibility) attach without modifying the core workflow [GH: core-workflow.md].

Extensions

The rule files ship with two extensions (security baseline, property-based testing). Extensions follow an opt-in pattern at Requirements Analysis via *.opt-in.md files [GH: core-workflow.md]. Enabled extensions are hard constraints and block stage completion on non-compliance. This is the correct extension point for APS-specific additions (Privacy Impact Assessment, AI Impact Assessment, DTA Digital Service Standard 2.0 checklist, accessibility compliance).

Installation paths

AI-DLC rule files can be placed in .aidlc-rule-details/ for GitHub Copilot workspace rules, Cursor, Cline, Claude Code CLI or OpenAI Codex; in .amazonq/aws-aidlc-rule-details/ for Amazon Q Developer; or in .kiro/aws-aidlc-rule-details/ for Kiro IDE [GH: core-workflow.md].

Pros and Cons

Gap Analysis vs APS Mandatory Requirements

Mapping AI-DLC against the APS digital delivery mandatory layer. Ratings: Covered / Partial / Gap.

Figure 4 — APS compliance overlay

%%{init: {'theme': 'neutral'}}%%
flowchart TB
    subgraph APS[APS MANDATORY LAYER]
        subgraph AIDLC[AI-DLC NATIVE SCOPE]
            IN[Inception] --> CO[Construction] --> OP[Operations]
        end
        PIA[PIA - Privacy Act 1988 / APPs]
        AIIA[AIIA - DTA AI Policy v2.0]
        DSS[DSS 2.0 - 14 criteria]
        PSPF[PSPF - data classification]
        ISM[ISM / Essential Eight - ACSC]
        ACC[WCAG 2.2 AA - DDA 1992]
        REC[Records - National Archives Act]
    end
    PIA -->|gate before| IN
    AIIA -->|gate before| IN
    DSS -->|criteria 1-2 align| IN
    PSPF -->|classification scope| IN
    PSPF -->|tool approval| CO
    ISM -->|security controls| CO
    ACC -->|accessibility testing| CO
    REC -->|artefact bridge| CO

    classDef aps fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef aidlc fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    class PIA,AIIA,DSS,PSPF,ISM,ACC,REC aps
    class IN,CO,OP aidlc

Competitive Landscape Summary

Adjacent offerings from major consultancies and vendors. The distinction that matters most is whether the offering is a methodology (reusable process), a platform (tooling) or a service (paid engagement).

• ThoughtWorks AI/works [3P]. Platform plus methodology. Six capabilities: Reverse Engineering, Dynamic Spec Development, Spec to Code, Developer Experience, Control Plane, Runtime Ops. "3-3-3" framework: 3 days to concept, 3 weeks to prototype, 3 months to MVP. Independently measured: ~8% team cycle-time improvement; 5–15% across organisations; 30–50% on boilerplate; 10–40% on business logic. Stronger emphasis on legacy modernisation than AI-DLC.
• Consultancy offerings (McKinsey / QuantumBlack, PwC, Deloitte and similar). Service-shaped rather than methodology-shaped. Emphasis on value-case framing, executive communication and risk/assurance wrap around AI-assisted delivery. [AJ]
• GitHub Copilot Workspace + workspace rules. Tooling, not methodology. AI-DLC rule files install directly into this context.
• Amazon Q Developer. Vendor-aligned to AI-DLC [GH]. Natural fit if the program is AWS-heavy.
• Claude Code CLI, Cursor, Cline. Coding agents with rule-file support. AI-DLC portable to all three [GH].
• Kiro IDE. AWS-aligned IDE with native AI-DLC support [GH].

For a program that wants portable methodology over product and engagements, AI-DLC is a strong starting point. The principal qualifications are the APS mandatory layer gaps identified above and the trial implementation findings (interaction overhead, instruction adherence gaps, and model fine-tuning outcome) detailed in Appendix D.

Daily Workflow Overview

A typical AI-DLC flow for a new business capability, with program-level context woven in [P]; [GH].

Week 0 — Intent and Level 1 Plan

• Product Owner articulates an Intent, e.g. "Add a provider eligibility check for a new programme stream."
• AI (the team's coding agent running AI-DLC rules) generates a Level 1 Plan recommending which stages to execute [GH: core-workflow.md]. The team reviews the Plan, approves or amends and agrees the scope of this increment (one Unit or multiple).
• The Plan is written to aidlc-docs/inception/plans/execution-plan.md and locked behind an explicit approval [GH: workflow-planning.md].

Week 0–1 — Mob Elaboration (Inception)

• Whole-team session in one room (or virtual equivalent) with a shared screen. Product Owner, developers, QA, UX, tech lead. Facilitator drives [P:3-4].
• AI asks clarifying questions, generates candidate user stories, NFRs, risks and a PRFAQ. The team challenges, adjusts and validates.
• Output: one or more Units, each with user stories, acceptance criteria, NFRs, risk register entries, measurement criteria and a suggested Bolt plan.
• Mob Elaboration replaces what would otherwise be days of elicitation workshops + BA writing + review loops. In a regulated APS context, it does not replace the AI Impact Assessment, Privacy Impact Assessment or accessibility review — these must be wired in as extension gates before Requirements Analysis completes.

Weeks 1–N — Mob Construction (Construction)

Per Unit, the team (often a small pair, sometimes a full mob) works through the Construction sequence with AI driving and humans validating:

• Domain Design. AI proposes aggregates, entities, value objects, domain events, repositories, factories [P:3]. Developer validates against real-world scenarios.
• Logical Design. AI extends Domain Design with architectural patterns (CQRS, event-driven, circuit breakers) and candidate services (Lambda, Fargate, DynamoDB, etc.) [P:3-5]. Developer approves or overrides.
• Architecture Decision Records. AI writes ADRs for each significant decision. Developer reviews and approves.
• Code and Unit Tests. AI generates both from Logical Design. Developer inspects, runs, adjusts.
• Build and Test. AI executes functional, security and performance tests. On failures, AI proposes fixes; developer approves re-runs [P:6-7].

Each cycle is a Bolt: hours to days, not weeks. Multiple Bolts per Unit, in parallel where Units are loosely coupled. Program-level integration with other teams on the ART still happens at PI Planning, System Demo and Integration Events — the Bolt does not replace these.

Continuous — Operations

AI analyses production telemetry (metrics, logs, traces), detects anomalies, predicts SLA breaches, recommends runbook actions [P:5-7]. Developer on-call validates, approves, monitors outcome. This is the weakest-specified phase in the methodology. In practice, most APS programs have mature observability platforms already running. AI-DLC Operations complements these; it does not replace them.

Role-by-Role Breakdown

How existing roles change. AI-DLC's Principle 8 deliberately reduces specialist silos [P:2]. In an APS context this is not followed in full; roles below are the practical reconciliation.

Records Generated

What the team produces, where it lives and how it integrates with agency records. AI-DLC native records (all live under aidlc-docs/ in each repository) [GH: various rule files]:

• aidlc-docs/audit.md — append-only log of every AI prompt, user response (raw), approval and decision, ISO-timestamped.
• aidlc-docs/aidlc-state.md — current stage, execution plan, extension configuration, stage progress checklist.
• aidlc-docs/inception/plans/execution-plan.md — the approved Level 1 Plan for the increment.
• aidlc-docs/inception/requirements/requirements.md — functional and non-functional requirements.
• aidlc-docs/inception/requirements/requirement-verification-questions.md — clarifying questions and answers.
• aidlc-docs/story-artifacts/*.md — per-Unit user stories and acceptance criteria.
• aidlc-docs/design-artifacts/ — Domain Design, Logical Design, ADRs per Unit.
• aidlc-docs/construction/plans/*-code-generation-plan.md — approved code generation plans per Unit.
• aidlc-docs/inception/reverse-engineering/ (brownfield only) — architecture, component inventory, technology stack, dependencies, business overview, interaction diagrams.

Bridging to agency records (APS extension pack adds these) [AJ]:

• PIA artefact linked from aidlc-docs/inception/compliance/ and logged in agency records system.
• AIIA artefact linked and logged against the system register required under DTA AI Policy v2.0.
• Accessibility test reports (automated + manual) linked.
• Security assessment (ISM mapped) linked.
• BRS/SRS abridged artefacts where agency gate processes still require them. Treat these as derived from AI-DLC artefacts, not separately maintained.
• Records of significant architectural decisions logged under agency architecture governance in addition to ADRs in-repo.

Integration with SAFe ART and CR Process

• PI Planning. Keep it. AI-DLC does not address cross-team planning at program level. Intents captured at or feeding PI Planning become inputs to Mob Elaboration sessions. Recommended rhythm: Mob Elaborations happen during or immediately after PI Planning for the top-priority Intents, such that Units are ready before Bolts start.
• Feature / Story decomposition. Replace SAFe Feature writing with AI-DLC Mob Elaboration for the portion of Features owned by AI-DLC teams. Features become equivalent to AI-DLC Units (approximately — see Appendix A). Maintain a Feature → Unit mapping in ART-level tooling so RTE-level reporting continues to work.
• Iterations / Sprints. Replace with Bolts for AI-DLC teams. The SAFe 2-week iteration becomes a container for multiple Bolts. Team Demo can move to System Demo cadence only.
• System Demos and Integration Events. Keep. These are cross-team and have no AI-DLC equivalent.
• Change Request process. Integration with change management is the most uncertain aspect. For each Deployment Unit, the program's change process still applies. What does change is the quality of CR evidence — AI-DLC artefacts (ADRs, test reports, risk register, audit log) give change advisory boards richer input than typical CR packs. Recommendation: agree a CR evidence template that maps to AI-DLC artefacts so reviewers read the template, not the entire aidlc-docs/ tree. [AJ]
• Release train cadence. Quarterly major releases are structural. AI-DLC does not touch this unless the program decides to shorten the release window. That decision is independent of AI-DLC adoption.

Tool Compatibility

Compatible coding agents

• GitHub Copilot + workspace rules. Rules in .aidlc-rule-details/. Widely available across APS under existing Microsoft enterprise agreements.
• Amazon Q Developer. Rules in .amazonq/aws-aidlc-rule-details/. Native vendor path.
• Claude Code CLI. Rules in .aidlc-rule-details/. Requires direct API access (internal endpoint via GovAI Model Brokerage or, for developers with approved access, the Anthropic API).
• Cursor, Cline. Rules in .aidlc-rule-details/. Case-by-case agency approval.
• Kiro IDE. Rules in .kiro/aws-aidlc-rule-details/. AWS-aligned IDE.
• OpenAI Codex. Rules in .aidlc-rule-details/.

Data Classification

AI-DLC is silent on classification. For OFFICIAL: Sensitive or higher, use only model endpoints approved for that classification. This is a program-level control, not an AI-DLC-level control.

Change Log

• 2026-04-23: Initial draft. Part 1 (IT executive brief), Part 2 (delivery team guide), Appendices A–C.
• 2026-04-24: Author review and structural trim. Retitled paper. Removed Roadmap and FAQ sections. Reviewed citations and claims. Paper date advanced to 2026-04-24.
• 2026-04-24: Added Limitations section disclosing scope and sample boundaries. Added Appendix D with Auto Search trial process and consolidated AI-DLC vs Superpowers observation table.
• 2026-04-24: Added quantitative metrics table and top five differences commentary to Appendix D.
• 2026-04-27: Final review. Added Superpowers comparison block in Appendix D and split trial-rationale sentence to handle Auto Search and Superpowers separately. Added URLs for DTA AI Policy v2.0, Digital Service Standard v2.0 and APS AI Plan 2025 in Appendix C.

End of paper.