Agentic SDLC
Purpose: Describe the software-development lifecycle Swifter runs — the proficiencies involved, the agents that carry each proficiency, the sequence in which they hand work off, and why this shape produces predictable software where unstructured "vibe coding" does not.
Reading time: ~8 minutes · Audience: anyone new to running work through Swifter · This page is the why and shape; the per-WI agent + command details are in Work-Item Run Sequences.
The shift — from vibe coding to a real SDLC
Generic chat-style LLM coding ("vibe coding") produces a different result every time the prompt is rewritten. The shape of the output depends on what the prompter happens to ask for that hour. There is no separation of analysis from implementation, no spec the next person can read, no convention enforcement, no test discipline — every change is a roll of the dice, and reviewers carry the consequence.
Swifter replaces that with a real software-development lifecycle: a sequence of specialised agents, each with a narrow proficiency, working off shared inputs (specs, guidelines, design system) and producing artefacts the next agent in the chain can read. The same work item run twice produces the same output, because the structure does. That is the whole point.
The blueprint covers Swifter as a tool for a full team — a team that already has analysts, developers, testers, and an architect, and that now does the work through a set of agents instead of by hand. The proficiencies do not disappear; they shift from typing code to writing specs, reviewing agent output, and amending the guidelines when the agent gets something wrong.
Proficiencies and agents
Each proficiency on the team pairs with a specialised Swifter agent. Humans direct the work, review the output, and own the guidelines; the agents execute. Multi-proficiency separation is the first reason this produces predictable software — every step has a single, narrow goal.
| Human proficiency | Swifter agent | What the human does | What the agent does |
|---|---|---|---|
| Business analyst / product owner | (Authors the work item; analyst agents read it) | Writes the work-item description to Cookbook standards; signs off on acceptance criteria | — |
| Frontend analyst | swifter-frontend-analyst | Reviews the generated component / page spec; refines the WI when the spec drifts | Reads Figma + project guidelines; produces component / page specs (data model, logic rules, Storybook stories) — no production code |
| Frontend developer | swifter-frontend-developer | Reviews the implementation against the spec; merges the PR | Reads the analyst's spec + project guidelines; writes production component / page code; updates Storybook |
| Backend analyst | swifter-backend-analyst | Reviews the generated scoped specifications; pairs on edge cases | Produces scoped specifications for the endpoint (DTO, logic, API contract) — no production code |
| Backend developer | swifter-backend-developer | Reviews the implementation against the spec; merges the PR | Implements the endpoint to the scoped specifications + project guidelines |
| Tech lead / architect | swifter-backend-architect | Runs the 6-step user gate that shapes project guidelines; amends PITFALLS.md and CONVENTIONS.md as patterns emerge | Scans the codebase; produces the 16 per-module guideline files (overview/) |
| QA tester | swifter-tester | Reviews acceptance criteria; reviews and amends the knowledgebase; reviews failing scripts | Generates test cases and Playwright scripts from acceptance criteria; runs them against Preview |
| Designer | (Figma is the source of truth; the frontend analyst agent reads frames directly) | Maintains the design system in Figma; per-screen frame references in WIs | — |
Routing. When a work item opens, the operator picks the right starting agent. Most work items begin with swifter-default:start — the autonomous triage agent — which routes the item to the appropriate specialised agent. Defects route straight to the developer; new components and pages route through the analyst; "Create API" routes to the backend analyst; sync items route through the analyst's sync skill. The full per-type routing table is in Work-Item Run Sequences.
The SDLC flow per vertical slice
A vertical slice is one user-visible increment that includes frontend, backend, and tests — the smallest unit Swifter can ship end-to-end. The full SDLC flow for one slice is below; smaller items (a single component, a defect, a sync) collapse some of the steps but keep the same order.
Each lane in the diagram is a Work Item — never bundled. The contract between specification and build is the analyst's structured spec; the contract between build and integration is the OpenAPI / Swagger document the BE analyst produced. Frontend and backend can build in parallel once the contract is fixed; they converge at integration.
The verification loop is built in. Between each lane is a human review step — the BA reviews the analyst's spec before the developer agent opens; the tech lead reviews the developer's code in the Dev tab before the PR; the QA reviews the tester's scripts before they run. Reviews are not added at the end; they are built into the lifecycle so problems are caught at the point where they are cheapest to fix. The per-WI lifecycle (BA writes → tech lead validates → spec → BA compares → execute → QA → close) is in Work-Item Lifecycle.
Why this beats vibe coding
Three structural properties produce the predictability vibe coding does not have:
| Property | What it means | Effect |
|---|---|---|
| Multi-proficiency separation | Each agent owns one narrow proficiency. The analyst never writes production code; the developer never invents requirements; the tester never writes implementation. | Each step has a single goal; reviewers know exactly where to look for which kind of mistake. |
| A repeating SDLC | The same sequence runs for every Work Item — Plan → Spec → Build → Integrate → Test → Deliver. The team learns it once. | The ~47% first-session ABANDONED rate observed in production engagement data is the project baseline, not failure: the lifecycle hands off cleanly from origin → development → integration. |
| Spec-driven generation | Code is generated from a spec the human has reviewed. The spec is the contract; the code is its mechanical translation. | The same spec produces the same code on rerun. Disagreements are resolved in the spec (cheap), not after implementation (expensive). |
Vibe coding lacks all three. There is no proficiency separation (one LLM does everything from product idea to production code), no repeating SDLC (each session reinvents the structure), no spec to review (the only artefact is the diff). Three properties absent → output quality depends entirely on the prompter; reviewers cannot catch what was never made visible.
Working with Agile / SCRUM
Swifter is a tool, not a methodology. Engagement teams continue to work in their normal Agile process — typically standard SCRUM — overlaid on the Work-Item workflow. The team is a full team: business analysts, frontend and backend developers, QA testers, an architect — all of them present, just doing the work through Swifter instead of by hand. The deliverable shape is unchanged from any other Agile project: at the end of a sprint, the team ships full working software increments vertically — frontend, backend, and tests, every layer needed for the increment to actually run.
The SCRUM cadence the engagement formalises during Development Process Setup maps onto the lifecycle above:
| SCRUM ceremony | What happens in the Swifter context |
|---|---|
| Sprint planning | Pull Work Items from the backlog; confirm head WIs and breakdowns. Each WI is a step in the lifecycle above. |
| Daily stand-up | Status, blockers, in-flight work sessions across the team. |
| Spec review (Swifter-specific) | BA + tech lead validate Swifter-generated specs before the developer agent opens. |
| AC review (Swifter-specific) | QA + BA validate Acceptance Criteria expanded by Swifter. |
| Sprint review | Demo working software from the PRs Swifter created during the sprint. |
| Retrospective | Engagement-level retrospective; feeds platform feedback and amendments to project guidelines. |
The two Swifter-specific ceremonies (spec review, AC review) are the only additions. They protect description quality — the cheapest place in the lifecycle to catch problems.
What this page does not cover
This page describes the shape of the SDLC and why. The operational detail lives in adjacent pages:
- Where to keep the implementation contract — Project Guidelines: the 16 per-module guideline files at
.swifter/specs/{module_name}/overview/. - What design source feeds the analyst — Figma: the single source of truth for UI.
- How to size and order the Work Items — Creation Sequence and Work-Item Breakdown.
- How to write a Work Item that runs on first read — Work-Item Composition, Type Templates, Lifecycle.
- Which agent + command to run per WI type — Work-Item Run Sequences.
Read this page once; come back when the team needs a refresher on why the lifecycle exists in this shape.