Delivery
The right loop of the Double Loop — six nodes from implementation to impact. Delivery begins at the crossing point: validated acceptance criteria hand off from Discovery, and what engineering receives is derived from a tested prototype, not a speculative document.
Overview
Delivery is the build-and-measure loop. It runs counterclockwise through six nodes — Implementation, Automated Verification, E2E / AC Execution, Deploy, Observability, and Impact — answering whether the thing was built correctly and whether it moved the needle. Each node has specific outputs, AI opportunities, and human judgment checkpoints. What connects them is the repo: every node reads context from and contributes artifacts back to the same version-controlled source of truth.
Delivery starts at the crossing point, not at a blank page. The problem definition, solution direction, designs, prototype, and acceptance criteria all happened upstream in Discovery — the PM built a working prototype with an AI coding agent, validated it with stakeholders, and authored the acceptance criteria from what was tested. So the acceptance criteria that enter Implementation describe what was built and validated, not what someone hoped would be built. That upstream work is what makes the delivery loop reliable.
From Implementation forward, those criteria flow without retyping: into engineering context, into test cases, into release artifacts, into production monitoring. No manual synchronization. No version drift. It holds because the source holds — and the source was validated before delivery began.
Mapping to the classic SDLC: the six nodes are the back half of the familiar software lifecycle. Implementation and the two verification nodes are "build and test"; Deploy is "release"; Observability and Impact are "operate and learn." The classic SDLC's planning, requirements, and design phases live upstream in Discovery — that's the boundary the Double Loop draws.
The Six Nodes
The loop runs counterclockwise through six nodes. Node 1 (Implementation) is the entry point from Discovery's acceptance criteria; node 6 (Impact) is the optional exit back across the crossing point, where an Impact signal becomes the Signal that starts Discovery again. Delivery can also run independently — incremental improvements and hotfixes may enter here directly without a full Discovery cycle.
What it is: Production-quality code shaped by the acceptance criteria handed off from Discovery, plus the repo's conventions, design system, and component structure. The entry point from Discovery. Engineers receive a working shell — presentation layer implemented, production patterns applied, Storybook stories included — and add the production-specific pieces.
What it produces: Production-ready code shaped by repo conventions; the working shell that engineers review, adapt, and own.
AI's role: Scaffold from specifications so the starting point is a working shell, not a blank file — imports, file structure, naming, styling applied by default. Production pattern matching draws on steering documents and the production codebase to generate code that reads like a team member wrote it: correct error handling, auth middleware wiring, logging format. Cross-layer consistency is the highest-value contribution for full-stack features — generating UI, API, and data layer from one set of criteria eliminates integration bugs from different engineers interpreting differently. Code review assistance pre-flags accessibility gaps, design-system violations, missing error handling, unvalidated inputs, SQL injection vectors, and missing auth checks before a human reviews.
Human judgment: Does this match production patterns? Are there edge cases the generated code doesn't handle? Architecture, business logic, integration complexity, performance, and security hardening require engineering judgment. AI raises the quality floor of what reaches review — it doesn't replace the review.
What it is: Unit, integration, and CI pipeline checks confirming the implementation is internally consistent before wider validation.
What it produces: Passing (or failing) unit and integration suites, CI status, and the first quality signal on the build.
AI's role: Generate unit and integration test stubs from the implementation and acceptance criteria; re-run suites automatically when tokens change, components are regenerated, or dependencies are upgraded — catching regressions without new maintenance overhead. Running a regression suite is mechanical work AI should own.
Human judgment: Does a failure matter, and which cases are worth covering? Deciding whether a red build is a real defect or a brittle test is engineering judgment.
What it is: End-to-end tests run against the acceptance criteria authored in Discovery. The AC written in the left loop is validated in the right loop — the load-bearing connection between the two circles.
What it produces: Test results traced to the originating acceptance criteria, validated components, and QA sign-off for handoff. Results flow to the test management system, linked to backlog stories via case keys.
AI's role: Generate E2E test stubs from acceptance criteria — Playwright tests navigating to component stories, API tests validating response shapes and status codes — with test-management case keys embedded in titles so every result flows back to its originating requirement automatically. Automated execution navigates the application, interacts through the accessibility tree, validates behavior, and reports results without manual coordination.
Human judgment: Which edge cases, boundary conditions, and failure scenarios did the criteria not explicitly cover — and is the software ready to ship? The triage decision — requirements gap, implementation gap, or test gap? — is irreplaceable QA judgment.
What it is: Release to production. Not the end — the beginning of the measurement phase.
What it produces: Validated release artifact, changelog, release notes, completed change request, environment promotion, post-deployment validation report.
AI's role: Assemble release artifacts automatically — changelogs from git history, change lists with validation status, release notes, pre-populated change-request templates. Run a comprehensive pre-deployment pass: full suite against staging, visual regression, bundle size comparison, health checks, end-to-end smoke tests. For database migrations, validate backward compatibility, generate rollback scripts, estimate migration duration on large tables, and flag queries that would break after the migration. Draft deployment notifications and release-page updates.
Human judgment: Release should be boring. Go/no-go decisions, CAB approval, rollback-vs-hotfix judgment, migration sequencing, and release timing all require human accountability. AI makes release boring by automating the preparation, validation, and communication — so the human's question is "is everything green?" not "will this work?"
What it is: Is the system working? Telemetry, error rates, latency, operational health. Operational signals — distinct from strategic impact.
What it produces: Production monitoring insights, anomaly alerts, log-pattern findings, and incident investigation support.
AI's role: Continuously monitor production signals and flag issues proactively — latency creeping up on an endpoint, error rates rising for a code, a JavaScript error spike after deploy, drop-off at an interaction point — especially valuable for feature-flagged changes where flag-on and flag-off populations can be compared. Accelerate incident investigation by correlating logs across services, identifying the deployment that introduced a change, and drafting an initial analysis from the evidence. Transform logs from a reactive debugging tool into a proactive quality signal.
Human judgment: Incident severity assessment and root cause determination. AI correlates the evidence; determining the actual root cause requires understanding system architecture and the intent behind code changes.
What it is: Did it move the metric? Post-deployment measurement against the original problem statement. The persevere / pivot / kill decision node. When impact signals warrant a new problem cycle, this node hands back to Discovery — becoming the Signal that starts the left loop again. This is the node that closes the loop, and the one where AI has the most untapped potential.
What it produces: Impact measurement against acceptance criteria and the original problem, feedback synthesized from production signals, and new context fed back into the next Discovery cycle.
Close-out: Impact is also where a feature's active work is archived. When the feature has shipped (or is killed), the agent sets its status and moves the feature folder from docs/work/ to docs/_shipped/ — keeping the working set small as features accumulate. If Impact loops back to Discovery, the archived feature keeps a link to the work it became the signal for, so the thread stays visible.
AI's role: Close the feedback loop that most processes break down on. Information flows forward easily (criteria → code → test → deploy); information flowing backward — production insight informing the next problem cycle — is where teams fail. AI tags production issues with the originating requirement and design artifacts, generates periodic reports on how deployed features perform against their original acceptance criteria, surfaces patterns across incidents that suggest systemic issues, and feeds production data into the next cycle so it starts with real-world context rather than assumptions.
Human judgment: Did we solve the problem we set out to solve, and what now — persevere, pivot, or kill? User feedback interpretation requires product intuition. The SDLC is a cycle, not a pipeline: what happens here determines whether the whole cycle was successful.
Where AI Contributes Most, By Domain
The AI contribution across the delivery loop is not evenly distributed across engineering domains. Frontend, backend, data, and infrastructure each have distinct nodes where the generation-to-validation loop applies most directly — and distinct nodes where human judgment carries more weight. Some domain work also reaches back across the crossing point into Discovery's Designs and Prototype nodes; those rows are flagged.
| Domain | Highest-Value Nodes | What AI Does | What Stays with Humans |
|---|---|---|---|
| Frontend | Implementation, E2E / AC Execution (plus Discovery: Designs) | Design-to-code translation from frames (in Discovery's Designs node); Storybook story generation; accessibility tree validation; component scaffolding with production tokens and patterns applied | Design intent validation; API integration; error state and edge case handling; performance optimization |
| Backend | Implementation, Automated Verification | API contract generation from acceptance criteria; service scaffolding following codebase conventions; cross-layer consistency validation; pre-review flag for auth gaps, missing validation, SQL injection vectors | Architecture decisions; business logic; performance trade-offs; security hardening; integration complexity |
| Data Engineering | Implementation, Deploy | Schema generation from acceptance criteria; migration script scaffolding; backward-compatibility validation; migration duration estimation on large tables; rollback script generation | Data modeling decisions; query optimization; migration sequencing under live traffic; schema design trade-offs |
| Infrastructure | Deploy, Observability | Pre-deployment validation against staging; bundle size comparison; health check verification; post-deployment anomaly monitoring; log pattern detection after deploys | Infrastructure architecture; capacity planning; incident severity assessment; rollback vs. hotfix decisions; compliance validation |
The pattern across all domains: AI handles the translation and consistency work — converting specifications into first-draft implementations, surfacing mismatches between layers, and running repeatable checks that don't require contextual judgment. Human judgment carries the decisions that require understanding of what the system is for, how it behaves under production conditions, and what the right trade-offs are for this team and this architecture.
One Source. Many Consumers.
The backlog is a downstream consumer of acceptance criteria — not the place they are authored.
This is a governing principle of the delivery loop, not a technical detail. When requirements live in the backlog, they are disconnected from the work itself — from the design files, the code, the test results. Changes don't propagate. Decisions aren't visible next to their context. AI agents making API calls to external systems to retrieve requirements are slower and less reliable than agents reading context directly from the repo they're working in.
When the repo is the source of truth, a different set of things becomes possible. Acceptance criteria, designs, test cases, and implementation all live in the same version-controlled place. The agent has context without API round-trips. Decisions are auditable — what was decided, when, and why, sitting alongside the artifacts those decisions produced. And the backlog, the wiki, and downstream tools receive accurate copies automatically, without manual synchronization.
For each role: PMs author acceptance criteria in the repo (in Discovery), agents publish to the backlog. Engineers work from the repo context, not from stories remembered from a standup. QA derives tests from the repo criteria, not from a separate test management entry. The backlog becomes a status layer — tracking what's in progress, what's done — rather than the authoritative record of what should be built.