Hur jag får AI att granska en specifikation innan den kodar

En specifikation som ser tydlig ut kan fortfarande tvinga coding agenten att fatta produktbeslut under implementationen. Därför vill jag reviewa specen innan första raden kod skrivs och behandla oklarheter som blockers, inte som något agenten ska improvisera bort.

Den billigaste buggen är den som stoppas före kod

När jag ber en coding agent granska en specifikation innan den börjar bygga är målet inte en extra sammanfattning. Jag vill hitta motsägelser, otestbara krav, dolda beroenden och edge cases innan de hinner bli filer, migreringar och UI-beslut.

Reviewern ska försöka underkänna specen

Jag separerar författare och reviewer mentalt, ibland även som olika agents. Reviewerns instruktion är inte "förbättra detta". Den är: hitta skäl till att implementationen kan bli fel trots att texten ser komplett ut. Det skapar en annan typ av läsning.

Fem saker jag letar efter

Jag använder fem kategorier: ambiguity, missing state, untestable requirement, boundary condition och dependency assumption. GitHub Spec Kits specifikationschecklista arbetar, vid skrivande stund, på liknande sätt med testbarhet, mätbara success criteria, edge cases, scope och dependencies — strukturen kan ändras om repot byggs om, men principen är ett bra tecken på att spec review bör vara strukturerad, inte estetisk.

Gör varje fynd handlingsbart

"Specen är otydlig" är värdelös feedback. Ett bra fynd bör innehålla plats, problem, konsekvens och föreslagen resolution. Exempel: FR-12 saknar beteende när sessionen återupptas efter expiry; risk: två olika klienter kan tolka samma state olika; beslut krävs: resume eller restart.

Separera blocker från förbättring

All kritik ska inte stoppa bygget. Jag använder BLOCKER för sådant som kan ge fel funktion eller datamodell, WARNING för risker som bör beslutas, och NIT för redaktionella förbättringar. Då slipper agenten lägga två timmar på att polera en formulering medan en state transition fortfarande är odefinierad.

Review före plan, och igen före implementation

Den första reviewn testar problemdefinitionen. Den andra testar om planen faktiskt löser specen. Det är två olika frågor. En bra spec kan få en dålig plan och en bra plan kan bli felimplementerad. Därför vill jag inte slå ihop gate:arna.

Resultatet ska bli en beslutbar spec

En färdig review betyder inte att dokumentet är perfekt. Det betyder att kvarvarande osäkerheter är explicita och att implementationen inte behöver gissa om materiella produktbeslut. Då har reviewn gjort sitt jobb.

Min praktiska tumregel

Coding får börja först när materiella oklarheter är beslutade eller explicit accepterade som risk.