Last updated September 18, 2026
4 min read
A fictional ticket says add team invitations. One engineer imagines email-only invites. Another expects reusable links. The agent confidently implements the first interpretation and writes tests around it. A specification would have exposed the product decision before implementation and test generation shared the same assumption. This is an explicitly fictional composite, not a customer result.
In this article
A vague ticket hides product choices
Turn nouns and verbs into observable examples. Who may invite, how long an invite lasts, what happens on reuse, which audit event appears, and how revocation works are separate decisions. A title and happy path cannot carry them.
Risk of coding before testing, July 2026 bounds this claim. A very recent preprint in a bounded setup; it needs replication.
| Evidence point | Interpretation |
|---|---|
| 1 | Ticket: add invitations |
| 2 | Spec: six observable decisions |
| 3 | Test: tied to criterion ID |
| 4 | Verdict: bounded to one version |
Treat the table as a working diagnostic. Replace illustrative labels with repository evidence before making a budget, staffing, or release decision.
Acceptance criteria need proof methods
Give each acceptance criterion a stable ID and expected evidence. One may require a policy test, another an integration test, and another a manual product review. The mapping helps a reviewer see unproved promises and tests that prove nothing requested.
Order matters because later checks inherit the intent and scope established earlier. A skipped step does not remove uncertainty. It hands that uncertainty to a reviewer under time pressure.
Independent intent reduces self-confirmation
A July 2026 preprint reported that showing faulty generated code before test generation reduced fault detection in its setup. The study is early, but the mechanism is plausible: code can anchor the test writer. Keep criteria available independently of the implementation.
NIST AI RMF Core adds a second evidence boundary. Voluntary risk guidance, not certification or product proof.
A procedural fix can be inspected, rehearsed, and improved. A warning without an owner or artifact usually disappears during the next busy sprint.
Baseline one version for one proof attempt
Freeze the specification version used for the current check. If the product decision changes, create a new approved version and mark prior evidence stale where needed. This is change control, not a claim that product learning must stop.
paqad-ai v1.67.0 was the current public release when this article was checked on July 21, 2026. Its repository describes risk routing, specialist roles, structured state, deterministic checks, documentation sync, and local audit records. These are product mechanisms, not independent outcome proof.
Use the AI workflow audit guide to map current practice, compare the bar with production-ready AI code, and use the AI coding consultant guide when the team needs outside ownership.
Decision rule: If a criterion has no observable behavior or proof method, it is not ready to guide implementation.
Frequently Asked Questions
Is a specification the same as a long requirements document?
No. Use the smallest structured artifact that removes consequential ambiguity. A low-risk change may need a few criteria, while a payment or permission feature needs stronger invariants and failure behavior.
Can a specification change after coding starts?
Yes, through an explicit approved version. Record why it changed and which plan steps, tests, and prior evidence became stale. That preserves learning without hiding drift.
Who owns the specification?
The product or domain authority owns intended behavior. Engineers contribute feasibility and proof methods. The AI worker may draft language, but it should not silently decide unresolved product rules.
What next?
Apply the specification readiness worksheet to one current feature. If the repository cannot answer the questions it exposes, install paqad-ai and test a governed workflow with local evidence and explicit human authority.