ai-sdlc-framework/ai-sdlc

**The Decision Engine for spec-driven AI workflows**
Website · Documentation · Specification · Getting Started · Vision · Contributing
---
What this is
AI-SDLC is the **Decision Engine** for spec-driven AI workflows — the execution-and-governance half of a spec-driven development stack. Operators frontload the load-bearing decisions through a Definition-of-Ready gate; an autonomous orchestrator dispatches developer subagents through the dependency graph; cross-harness reviewers (Claude × Codex × …) verify the work in parallel; DSSE attestations seal every change; pull requests open themselves.
The leverage move is **cost asymmetry**: operator decisions made upfront — with full context, time to think, and access to stakeholders — are cheap and (mostly) correct. AI decisions made mid-execution under uncertainty are expensive and often wrong. The framework's value is not "AI writes code"; it's **"AI executes well-specified contracts deterministically."** Those are different products with different reliability profiles.
The operator's role shifts to **decision steward** — frame open questions, resolve them, sign off on resolutions, monitor the pipeline. Typing and rubber-stamping go to the framework.
AI-SDLC covers the **contract → shipped** half of the spec-driven funnel. Front-of-funnel tools like GitHub Spec Kit cover **idea → contract**; the two systems compose at the seam where a spec artifact becomes a backlog task ready for DoR. See RFC-0036 for the bridge design and adopter authoring model.
> **Read first:** VISION.md is the organizing thesis — the design philosophy that grounds every RFC, every CLI, every gate. If something in this repo doesn't trace back to one of its principles, that's a signal we've drifted.
---
The problem AI-SDLC solves
AI agents can build small greenfield projects, but software falls apart as it grows. The data is consistent:
- **Productivity paradox** — Experienced developers using AI tools are 19% slower on mature codebases, despite believing they are 20% faster (METR 2025)
- **Quality decline** — Refactoring dropped from 25% to 10% of changes; code churn rose from 5.5% to 7.9% (GitClear 2024)
- **Stability regression** — Every 25% increase in AI adoption correlates with a 7.2% drop in system stability (Google DORA 2024)
- **Trust gap** — Only 3% of developers express high trust in AI output (Stack Overflow 2025)
The root cause is not that AI agents write bad code. It is that **nobody orchestrates how they work as the codebase grows** — every decision gets deferred to the worst possible moment, made by the actor with the least context. AI-SDLC flips that.
---
The five pillars
The framework is one cohesive system, but it ships as five pillars you can adopt incrementally.
1. The Decision Engine — RFC-0011 · RFC-0035
A Definition-of-Ready gate (RFC-0011) refuses to dispatch tasks the operator hasn't actually decided yet. A forthcoming Decision Catalog (RFC-0035, Draft) makes the operator's open-question queue a first-class resource — ranked by leverage, routed to the right actor, surfaced with framework recommendations + counter-arguments + sub-decision graphs. The framework recommends; the operator decides; the orchestrator executes. → Concept page
2. Autonomous Pipeline Orchestrator — RFC-0015
cli-orchestrator tick walks the dependency graph (RFC-0014), runs admission filters (blocked, in-flight, DoR, dispatchability), dispatches admitted tasks into isolated git worktrees, runs the Step 0-13 pipeline (dev agent → 3 reviewers → attestation sign → PR open), quarantines failures, and resumes from checkpoint commits on interruption. Operators monitor; they don't type. Feature flag: AI_SDLC_AUTONOMOUS_ORCHESTRATOR=experimental. → Concept page · Runbook