AI · Approach
Agentic SDLC
A public kit and operating model for teams moving from AI-enabled to AI-native delivery - aligned with AWS AI-DLC, not an employer product.
Part of my AI leadership work. Public kit: use Open the kit above (also listed under Build).
In brief
Agentic SDLC treats delivery as orchestration: humans set context and gates; agents do bounded work; evals and review decide what merges. The goal is faster delivery without trading away quality, governance, or architecture. Use Open the kit above for the MIT templates. Detail on names, pillars, AWS mapping, and rollout follows.
Names in this space
There is no single industry label yet. The map below keeps the labels distinct.
- Agentic SDLC - category label for this page and kit: humans orchestrate, agents execute bounded work, evals plus review gates hold quality. Not owned by one cloud vendor.
- AI-DLC (AI-Driven Development Life Cycle) - AWS's named, open-source methodology (overview; workflows: awslabs/aidlc-workflows). Most visible named method in this space. This page is not an AWS AI-DLC implementation.
- AI-native - maturity outcome: workflow designed around intent, agents, gates, and human ownership. Descriptive language, not a kit rebrand.
- Public kit - MIT templates anyone can copy: use Open the kit above. Aligned with AWS AI-DLC in operating model; not a port of AWS workflows, Amazon Q rules, or the AWS agent roster.
Shared operating model: code generation is not the bottleneck. Context, gates, and ownership are. AI-driven does not mean AI-controlled.
What the kit is
Two layers:
| Layer | What you do |
|---|---|
Guide (docs/) | Read - habits, run order, swarm rules, terminology, scope |
Copy (templates/) | Copy into your repo and fill for real work |
This practice is how teams move from AI-enabled (AI bolted onto old process) toward AI-native delivery. The kit name stays Agentic SDLC; AI-native is the maturity outcome.
Executive summary
Many teams still use AI as line-level autocomplete. That helps individuals; it does not fix delivery when review, integration, and ownership fall behind.
Agentic SDLC treats delivery as orchestration: humans set context and gates; agents do bounded work; evals and review decide what merges. The goal is faster delivery without trading away quality, governance, or architecture.
From generation to orchestration
Autocomplete-style tools flood branches with unverified code. Speed without architectural alignment is fake productivity.
The bottleneck is no longer generation. It is integration, verification, and keeping humans accountable for what ships.
[Legacy Copilot Flow]
Human -> Writes Prompt -> Co-pilot Suggests Lines -> Human Debugs/Fixes
[Agentic SDLC Flow]
Human Orchestrator -> Engineers Verifiable Context -> Agent Swarm Iterates/Tests -> Automated Evals Pass -> Human Approves Architectural Fit
Engineers move from writing every line to acting as system orchestrators: architectural fit, dependencies, security, and product logic stay human-owned.
How the kit runs
One increment at a time. Humans own merge. Agents do bounded work. Skip a stage only when the increment is truly tiny and the skip is written down. Do not skip the context gate or the human merge decision.
Intent brief -> Technical PRD (+ optional stack addendum)
|
v
Project AI rules loaded
|
v
Context gate
|
+---------------------+---------------------+
| |
v v
Single unit: construction board Swarm (2+ units):
unit DAG -> swarm board
plan / impl / verify
| |
+---------------------+---------------------+
|
v
Eval gate
|
v
Ops handoff
Fillable artifacts (copy from the kit): intent brief, technical PRD, optional stack addendum, context-gate checklist, construction board or swarm pack, eval quality gate, ops handoff, and a PR checklist to paste into the pull request.
The four pillars of Agentic SDLC
1. Context engineering and verifiable specifications
Standard PRDs and vague tickets fail for agents because they assume tribal knowledge. Agentic SDLC replaces that with explicit, machine-readable instructions.
- Intent before generation: An intent brief states who is blocked and what "done" looks like before a technical PRD.
- Architecture-as-context: Repos carry system boundaries, API contracts, and pattern rules in the tree (project AI rules, agent rules, or local index layers). Agents must consume those bounds before drafting code.
- Deterministic entry conditions: Work does not enter an agent path until success criteria are explicit and testable. If an automated check cannot evaluate completion, the task stays blocked.
2. Multi-agent orchestration swarms
Use a swarm when an increment has two or more independent units. Single-unit work stays on one agent and a short construction board. The public kit defines the practice in docs/swarm.md (see Open the kit above).
Instead of one model planning, coding, and self-approving in the same path, separate roles and a unit dependency DAG:
- Unit dependency DAG: List units with
depends_on. Parallel batches are units with no edge between them. One unit or a cyclic graph means no swarm. - Planning agent: Produces a task graph, file bounds, and acceptance checks for a unit. Does not write product code.
- Implementation agent: Consumes an approved plan handoff and drafts code inside those bounds. Draft branch only - never self-merge.
- QA / Verifier agent: Checks the diff against the PRD and plan (not the implementer's story), runs the named project check, and fails closed on blockers.
Convergence is the project check exit code, not an agent claim. Humans grant autonomy (gate every unit vs gate per batch) and still Own merge. This maps to the AWS AI-DLC Construction swarm operating model (units, DAG, project-check convergence) without claiming an AWS implementation.
3. Eval-driven quality gates
LLM output is non-deterministic. Manual review alone is too late. Automated evals should catch failures before humans spend review time.
- Pre-flight agent reviews: Structural checks on completed drafts - complexity, common AI regressions, and policy rules you care about.
- CI before human review: Agent branches stay out of human pull-request review until they pass required tests and security static analysis (SAST).
- Fix the system, not only the prompt: When the same class of failure shows up twice, update project AI rules and/or a named automated check before the next agent run.
4. Micro-sprints and the Delegate, Review, Own loop
Long loops let agent context drift. Work stays in short, isolated micro-sprints.
+--------------------------------------------------------------+
| DELEGATE |
| The engineer provides constrained context and verifiable |
| goals (and, for multi-unit work, a unit DAG) to Planning / |
| Implementation / QA roles. |
+------------------------------+-------------------------------+
|
v
+--------------------------------------------------------------+
| REVIEW |
| The engineer evaluates the pull request for architecture, |
| security, and edge cases - not for polishing every syntax |
| detail the evals already covered. |
+------------------------------+-------------------------------+
|
v
+--------------------------------------------------------------+
| OWN |
| The human signs off. Accountability stays with the human; |
| AI leverage scales, responsibility does not get outsourced. |
+--------------------------------------------------------------+
Honest mapping to AWS AI-DLC
| AWS AI-DLC phase | Kit artifact | Same idea | Not the same |
|---|---|---|---|
| Inception | Intent brief + technical PRD | Intent before generation; humans validate | No AWS "mob elaboration" ritual |
| Construction | Context gate, construction board, eval gate | Bounded agent work; human review and merge | No claim of AWS rules / Q Developer workflows |
| Construction swarm | Unit dependency, swarm board, role prompts, handoffs | Units + DAG + parallel batches + project-check convergence + human Own | No aidlc-swarm.ts, no 14-agent roster |
| Operations | Ops handoff | Keep context after ship; human owns prod | Lightweight checklist, not an AWS ops method |
Key performance indicators
Story points and lines of code are weak maturity signals here. Prefer:
- Review-to-merge cycle time: Human-to-human review vs human-to-agent review.
- Defect escape rate (DER): Whether faster feature velocity brings more production regressions or hotfixes.
- Outcome baselines: Measure before and after on real feature workflows. Do not treat story points or lines of code as maturity signals.
Delivery metrics cited elsewhere on this site are measured pilot outcomes from lived practice - not guarantees from this kit.
Implementation roadmap
A phased, lower-risk rollout:
- Phase 1: Context stabilization (weeks 1-3): Standardize repo structure. Add machine-readable context and strict lint/format rules as basic agent boundaries. Install shared project AI rules once.
- Phase 2: Pilot micro-sprints (weeks 4-6): Pick a low-risk component. Train champions on micro-sprints; use swarm mode only when work splits into two or more independent units.
- Phase 3: Automated eval integration (weeks 7-9): Wire test generation and agentic review into CI so quality gates are enforced, not optional.
- Phase 4: Standardization (week 10+): Roll rules across product lines; adjust metrics from pilot data; keep ops handoff so context survives ship.
Claims
- This kit does not claim personal invention of Agentic SDLC or AI-DLC.
- It is not a port of
awslabs/aidlc-workflowsor an AWS product. - Map the shared operating model; do not impersonate AWS ritual names as if they were this kit's brand.