Imagine your own expert software engineering team, ready to use all the industry best practices - at your fingertips.
That's SDLC Studio: it gives your AI agent a team that plans, builds and independently reviews the work - and proves it's done. Across every AI coding agent.
v5.1, in its fifth major version · 7,000+ automated tests · benchmarked across three model eras, published either way · it ships with its open defects listed by id · it builds itself through its own pipeline
Define the what and why.
Make requirements verifiable.
Plan the work. Link everything.
Independent review against criteria.
Traceable evidence in your repo.
115 def create_project(name):
116 if not name:
117 raise ValueError("name required")
118 project = Project(name)
119 + audit.log("project_created")
120 return projectAgent-agnostic - one install, the same discipline
Two things grated once you pointed this at a real backlog. Measured on one machine, over 822 stories and 667 bugs - the same corpus, before and after.
The third number is the honest one: the checks got slower, because there are more of them. What got fast is what you type. And fixing one bug no longer invalidates anybody else's: evidence used to be tied to a whole file, so a single line moving forced other units' checks to be re-run by hand before anyone could commit - it is now tied to the exact spot a test covered. What this means for an existing project →
Every tool in this category has a unit of work. Spec-driven tools take one ticket: write a spec, plan it, build it, start again from an empty page. Ours is a sprint - a prioritised batch, driven to a goal, reviewed at its boundary, closed with a retrospective that has to produce something.
Say "plan the next sprint" and it ranks the backlog by WSJF - cost of delay over story points - into one coherent increment. Say "run the sprint" and it builds, tests and independently reviews every story for your approval. Then, like a real team, it gets better each iteration.
Most of what this discipline buys you is a property of a set. Our own published measurement: on one small, well-specified change the full pipeline costs about 3.1x the tokens and buys little. The value is in the fan-out.
A batch of one has no boundary between delivery and close, so every finding is close work by construction. One run delivered in 5 hours and took 6h35m to close - only 18% of it gate time.
Fan-out needs two or more file-disjoint groups. The planner says it plainly: a one-unit batch is delivered sequentially. There is nothing to fan out.
WSJF is a ranking function. A set of one has exactly one ordering - so the prioritisation decision was already made by whoever typed the ticket.
An 18-point run measured 228k tokens per point; a 100-point run measured 52k. Small batches are the expensive ones, which is the opposite of the intuition.
One review found two units shipping in a single commit that contradicted each other. Neither ticket was wrong on its own - and a one-ticket view has nowhere to stand to see it.
And a sprint has somewhere to put things: a finding outside the ticket is filed and ranked, not silently dropped or done unpriced. The full argument, with its measurements →
Not a faster engine - the discipline around it. Where other tools align the agent on intent, SDLC Studio also argues back with facts.
A spec the agent produced and is trusted to honour drifts within days. Here acceptance criteria are executable and get run, and reconcile recomputes status from a census of the files - a claim that does not match reality fails a gate.
Volume of AI-authored change buries review. The two-role gate makes author-review separation mechanical and pushes an adversarial pass to a fresh context - you ratify evidence, not every line.
A fixed ceremony is too heavy for a fix, too light for a release. The two-backlog model and sizing let a change flow at the weight it warrants - lite for a small repo, the full gate where it earns its keep.
By release, nobody - the model included - can say what "done" meant. Here evidence is a build artefact: the verify report, the review record, the mutation ledger. The proof outlives the sprint.
Not role prompts - named people with a working method, things they won't trade away, and an honest account of how each of them fails. They build the work and review it, and never as the same instance on the same unit. Your AI stops marking its own homework.
Guards the why. Won't let a story ship that doesn't serve the goal it was written for.
Shadow: trades depth for reach.
Builds it. Test-first and ledger-first - won't ship a path that isn't proven.
Shadow: gold-plates the interesting problem.
Proves it. Turns every acceptance criterion into a test that actually runs.
Shadow: blocks on risks nobody will hit.
Vetoes card data outside the vault.
+ grown from your PCI scopeThe Shadow is not decoration. Off-script, a reviewer drifts back into agreeing with you. Naming the failure mode is what keeps the pressure-test honest - and lets you read a review with its bias visible.
Out of the box: Dani, Sam and Lena - the Three Amigos. Run persona generate --team and it writes named seats whose non-negotiables come from your domain: a payments QA paranoid about idempotency, a games QA about frame budgets. Edit a card and it's yours - generation never overwrites it. Meet the team →
And the other cast - who the product is for: Alan Cooper-style personas (primary, secondary, negative) plus stakeholder cards with veto lines, modelling the people who use it now and the ones who will. Personas →
Most scanners optimise for recall and hand you the triage: four hundred findings, you read thirty, you stop trusting the tool. Audit inverts that. Every candidate faces a panel of sceptics briefed to refute it, and only survivors are filed - as real bugs and change requests, with allocated ids.
No restructuring, no PRD, no adoption. If the findings aren't worth having, you stop there.
pre-flight: 8 lenses, 2 rounds, 3 votes
~190 agents / ~6.8M tokens / ~35 min - proceed? [y/N]
find architecture · code-quality · security
112 candidates raised across 8 lenses
verify refute panel, 3 votes, 2 of 3 to survive
13 survived · 7 refuted · 0 unjudged
merge duplicates folded, 12 distinct findings
file 12 artefacts written with allocated ids
BG0302..BG0311, CR0425, CR0426Security findings are remediation-only by design: location, weakness class, realistic impact and a concrete fix. No proof-of-concept payloads, and a committed secret is reported by its location plus rotation instructions - the value is left where it is.
Before a line is planned, the team writes down the three things that decide whether the work is right. Each is a real, editable Markdown file, and each has a seat that answers for it.
The Product Owner answers for it. The product requirements: the features, who they serve, the non-negotiables. Authored with you, or reverse-engineered from existing code - and never signed off by the seat that wrote it.
Dani, Engineering. The technical design: architecture, stack with real rationale, API and data models, ADRs - plus an architecture assessment on brownfield.
Sam, QA. The test strategy: coverage targets, test levels and the quality gates that block a build - the bar the whole pipeline is measured against.
The specification layer is the biggest lever you can pull. How the three stack →
The discipline the tools hold the agent to, at every step.
A PRD, epics and stories - authored with you, or extracted from existing code and checked against its tests.
Every story carries Given/When/Then criteria with executable Verify: lines.
A request becomes sized work only via refine; a sprint is gated before a line of code is written.
An independent reviewer - never the author - signs off. A self-review cannot clear the gate.
Criteria are run, drift is reconciled, tests are mutation-checked. Proven, not asserted.
Status: DoneA story reaches Done only when its executable acceptance criteria pass and an independent reviewer signs it off. The tools recompute status from the files, so a hand-edited status is caught by conformance.
# the story's Verify: lines are executed
[APL] US0433: ac=3 pass=3 fail=0 manual=0
# and the Done gate reads the report
transition --id US0433 --status Done
✓ executable criteria pass
✓ independent sign-off recorded
US0433 → DoneMost vibe-coding and spec-driven tools assume a blank slate - and fall apart on the code you already have. SDLC Studio adopts it: it reads your existing codebase, extracts a testable specification, and validates it against your real tests before it changes a line.
An interview turns your idea into a PRD, epics and stories - the spec written with you, before any code exists.
prd generate reads your codebase and extracts a testable spec; SDLC Studio then writes tests from it and runs them against your real code (code verify) - the spec is trusted only once they pass. The discipline arrives without a rewrite.
A product is rarely one repo - a web app, an API, a mobile backend, a shared library. The Product Vision Document sits above the PRDs: one writable master that maps every product feature to the repo that owns it, projected read-only into each child repo and kept honest by a drift check. Coordinate a whole product without the vision rotting in a handover doc.
# one master, mapping features to the repos that own them
PF0007 Single sign-on → auth-service (PRD §3)
PF0011 Task sync → taskflow-api (CR0042)
PF0014 Offline mode → taskflow-mobile (RFC0009)
# projected read-only into every child repo
pvd sync ✓ 3 repos
pvd drift ✓ no projection is staleVibe coding is fast and blind. Spec-driven tools plan, then trust the agent to honour it. SDLC Studio plans, estimates, builds, reviews independently and proves - then learns from it.
| Practice | Vibe codingprompt & hope | Spec-driven toolsplan, then trust | SDLC Studioplan, prove, learn |
|---|---|---|---|
| The unit of work | a prompt | one ticketa spec per run | a sprinta ranked batch, to a goal |
| A written specification | ✗ | ✓ | ✓ |
| Planning enforced before any code | ✗ | ✓ | ✓ |
| Acceptance criteria that run, not just prose | ✗ | ~prose only | ✓ |
| Backlog ranked into one increment (WSJF) | ✗ | ✗a set of one has one ordering | ✓ |
| Parallel delivery across file-disjoint lanes | ✗ | ✗ | ✓ |
| Review at a delivery boundary, not after the fact | ✗ | ✗no boundary exists | ✓ |
| Independent review - the author is never the reviewer | ✗ | ✗ | ✓ |
| Estimation & sizing - story points + cost forecast | ✗ | ✗ | ✓ |
| Velocity measured, and it replaces the default | ✗ | ✗ | ✓ |
| Retrospective + lessons - gets better each sprint | ✗ | ✗ | ✓ |
| Evidence kept as a build artefact | ✗ | ✗ | ✓ |
| Status recomputed from the files - no drift | ✗ | ✗ | ✓ |
| Adopts existing code - spec extracted & validated against its tests | ✗ | ✗no test-validated extraction | ✓ |
| Adversarial audit of a repo it has never seen | ✗ | ✗ | ✓ |
| Works across every AI coding agent | ~no discipline | ~often one tool | ✓ |
Enforced planning cut defect escapes 4-5x for 1.07-1.18x the tokens - about three to seven cents a ticket. And on today's frontier model the traps don't bite in any arm, which we say out loud on the same page.
Beside them: n=5 per cell, a Fisher exact p of 0.083, token actuals that are lower bounds, a 6.9x spread in tokens per point, and no recommended batch size because the data cannot defend one. Read the evidence →
Proudly supported by Anthropic through the Claude for Open Source programme. Sponsorship supports development - not an endorsement of any claim here, which is why the benchmark evidence is published whichever way it points.
One line to install. Then say what you want - the discipline holds.
Prefer to read it first? Inspect the script or pin a checksummed release →