Acceptance-Criteria-Driven Development (ACDD)
A reader summed up AIDLC's testing model in one phrase: acceptance-criteria-driven development, "a natural evolution for the SDLC in an AI context." It fits. The criteria drive the tests, the tests drive the code, and the agent does most of the writing in between. This page is the practical guide: the loop, how one criterion becomes several tests, a scorecard for criteria, worked examples across domains, and how ACDD relates to TDD, ATDD and BDD.
What ACDD Is
In ACDD, nothing is built that does not trace to a written acceptance criterion, and nothing is called done until a test proves each criterion holds. The criteria are written first, in Given/When/Then form, in Analyze. A coding agent turns them into failing tests in Develop, then implements until the tests pass. Launch verifies the integrated release against the same criteria.
What makes it an evolution rather than a rename is the agent. Writing tests first used to be the expensive, easily skipped step. An agent can now generate them from good criteria in minutes, which moves the expensive step upstream: writing criteria precise enough to generate the right tests. In ACDD, criteria quality is the main lever on software quality, and it is reviewed like code.
The ACDD Loop
Six steps, repeated per ticket. The only way back is through the criteria: if something is wrong, the criterion is fixed first and the tests follow.
The product owner and an agent write each criterion as Given/When/Then, with an ID and the boundary it crosses.
A second person scores the criteria with the scorecard below. Anything an agent would have to guess goes back.
The coding agent writes at least one test per criterion, at the right level, and shows each one fail.
The agent builds until the tests pass, without editing or weakening them.
The mutation gate checks the tests would catch a change; a reviewer checks the diff against the criteria.
The pull request lists each criterion ID with the tests that prove it, so Launch and auditors can follow the chain.
One Criterion, Several Tests
A criterion is not one test. It implies a test at every level it touches, and a well-written criterion makes those levels obvious before any code exists.
| If the criterion... | It implies | Example from a refund feature |
|---|---|---|
| States a business rule | Unit tests for the rule and its edges | Refunds above the order total are rejected; exactly the total is allowed |
| Crosses a module or system boundary | A contract or integration test across it | The refund request reaches the payment service in the agreed format |
| Completes a user journey | An end-to-end test, owned by the ticket that completes it | A customer requests a refund and sees it confirmed in their order history |
| Says what must never happen | A negative test, usually at the boundary | A customer can never refund another customer's order |
| Sets a quality bar | A measurable non-functional test | The refund confirmation appears within the time limit the brief sets |
| Depends on a model's behavior | An eval case | The support assistant routes every refund dispute to a person |
The Criteria Scorecard
Score each criterion before it goes to an agent. A criterion is ready only when it passes every line; anything less goes back to its author with the failing line named.
Scorecard (copy into your review)
Criterion ID: ____
[ ] One behavior - no "and" joining two outcomes in Then
[ ] Observable - Then names something a test can assert
[ ] Data state - Given says which records, in what condition
[ ] Actor - Given or When names who acts
[ ] Boundary named - any service or external system it crosses
[ ] Negative covered - what must never happen has its own criterion
[ ] Measurable - any quality bar has a limit from the brief
[ ] Traceable - has an ID the spec, tests and PR can cite
Ready for an agent only when every box is ticked.Scored example
Draft: "Users can refund orders quickly and safely."
One behavior no - "quickly and safely" is two outcomes
Observable no - "safely" cannot be asserted
Data state no - which orders, in what state?
Boundary named no - the payment service is not mentioned
-> back to the author
Rewrite:
AC-7 Refund within the order total (crosses: orders -> payments)
Given a paid order with total T owned by customer C
When C requests a refund of amount R, where R is not more than T
Then the payment service receives a refund request for R
AC-8 No refund of another customer's order
Given a paid order owned by customer C
When a different customer D requests a refund on it
Then the request is rejected and no payment request is sentExamples Across Domains
Invented criteria in four kinds of system, each with the tests it implies. Adapt the shape, not the details.
Given an account with a daily transfer limit L
and transfers totaling L today
When the owner starts another transfer
Then it is blocked with a "daily limit reached" messageImplies: unit tests at, below and above the limit; an integration test against the ledger service; a negative test that the blocked transfer never posts.
Given a workspace member with the "viewer" role
When they open a project's settings page
Then they see the settings read-only
and no edit request reaches the APIImplies: split into two criteria (the "and" is a second outcome); an end-to-end test for the page; a contract test that the API rejects edits from viewers.
Given a provider with a booked slot at time S
When a second patient tries to book slot S
Then the booking is refused and slot S is offered as unavailableImplies: a concurrency test with two simultaneous bookings; synthetic patient fixtures only, never real records.
Given a customer message that disputes a charge
When the triage assistant classifies it
Then it is routed to a human agent, never auto-answeredImplies: a blocking eval case, plus a unit test that the routing code honors the assistant's "route to human" decision.
ACDD, TDD, ATDD and BDD
ACDD stands on all three. What changes is who writes the tests and what that does to where the effort goes.
| Practice | What drives the code | Who writes the tests | Where the effort goes |
|---|---|---|---|
| TDD | A developer's next small test | The developer | Writing tests and code in tiny cycles |
| ATDD | Acceptance tests agreed with the business | Developers and testers, together | Agreeing acceptance tests before building |
| BDD | Behavior described in Given/When/Then | Developers, from shared scenarios | A shared language for behavior |
| ACDD in AIDLC | Reviewed Given/When/Then criteria with IDs and boundaries | A coding agent, under gates that stop it weakening them | Writing and reviewing the criteria; reviewing tests and diffs |
ACDD Anti-Patterns
Criteria written after the code
They describe what was built, not what was needed, and every test passes on day one.
Tests generated from the implementation
They confirm whatever the code does, bugs included. Generate from the criteria instead.
Adjectives as criteria
"Fast", "secure", "intuitive" cannot be asserted. Replace each with a limit or an observable outcome.
Only the happy path
Without negative and empty cases, the agent tests the demo and nothing else.
Fixing the test instead of the criterion
When a test turns out wrong, the cause is usually the criterion. Fix it there and regenerate, or the next agent repeats the mistake.
No trace in the pull request
If the pull request does not map criterion IDs to tests, nobody can tell which criteria are actually proven.
Frequently Asked Questions
ACDD is building software so that nothing is built without a written acceptance criterion and nothing is done until a test proves each criterion. Criteria are written first as Given/When/Then, a coding agent turns them into failing tests, and the agent implements until those tests pass. In AIDLC it is the testing model that runs from Analyze through Launch.
It builds on all three: the tests-first order of TDD and ATDD and the Given/When/Then language of BDD. The difference is that a coding agent writes the tests, under gates that stop it weakening them, so the human effort moves upstream to writing and reviewing the criteria and downstream to reviewing tests and diffs.
The product owner is accountable for them, usually drafting with an agent in Analyze, and a second person reviews them with a scorecard before any tests are generated. Engineers contribute the boundaries and negative cases they know about. The agent may propose criteria but never approves them.
Start With One Ticket
Score the next ticket's criteria with the scorecard, fix what fails, then let the agent write the tests first.