Så tvingar jag fram tydliga acceptanskriterier från AI

Acceptanskriterier är platsen där en vag idé blir testbar. Om en coding agent inte kan avgöra om ett kriterium är uppfyllt utan att tolka vad jag "nog menade" är kriteriet fortfarande för svagt.

Acceptanskriterier ska vara körbara i huvudet

När en modell skriver "lösningen ska vara robust, snabb och användarvänlig" har jag inga acceptanskriterier. Jag vill kunna läsa ett kriterium och omedelbart föreställa mig ett test som kan passera eller faila.

Börja med beteende, inte implementation

Ett bra kriterium beskriver observerbart resultat. Given en pausad session, when användaren återkommer inom giltighetstiden, then samma frågeposition och tidigare svar återställs. Det säger vad systemet ska göra utan att låsa vilken databas eller framework som används.

Tvinga modellen att fylla tre fält

Jag använder ofta precondition, action, expected result. Om ett krav inte går att uttrycka så är det ofta ett tecken på att problemet är för vagt. Den fullständiga mallen med Given/When/Then finns beskriven i detalj i Så får jag modellen att leta efter det jag själv glömt — Spec Kits nuvarande templates bygger fortfarande på just den strukturen.

Lägg till negativa kriterier

Happy path räcker sällan. För viktiga flows vill jag minst ett criterion för invalid input, duplicate action, permission failure och unavailable dependency. Negativa kriterier gör att agenten inte kan tolka "fungerar" som bara den snyggaste demon.

Mätbara betyder inte alltid millisekunder

Mätbarhet kan vara binär: ingen obehörig användare kan läsa resursen, ett retry skapar inte dubbla orders, en osourcad claim blockerar publicering. Jag undviker fejkprecision bara för att kriteriet ska se tekniskt ut.

Kriterierna blir en upstream-gate

Jag låter inte planeringen börja om materiella krav fortfarande saknar testbar definition. GitHub Spec Kits quality checklist gör samma distinktion: requirements ska vara testable/unambiguous, success criteria measurable och acceptance scenarios definierade innan feature readiness.

Det här minskar promptingbehovet senare

Ju tydligare acceptanskriterier, desto mindre behöver jag styra agenten med nya instruktioner under implementationen. Den kan själv jämföra förändringen mot ett stabilt kontrakt. Bra criteria är alltså inte byråkrati; de är komprimerad framtida prompting.

Min praktiska tumregel

Om kriteriet inte går att göra till ett tydligt test är det fortfarande ett önskemål, inte ett acceptanskriterium.