Att godkänna en prompt

I ett deterministiskt system beskriver kravtexten vad som ska byggas, och koden är något annat än kravet. I ett generativt system faller de ihop.

Beteendet styrs av en instruktion i löptext, av tröskelvärden för när ett svar godtas eller avvisas, och av regler för när ett flöde ska avbrytas eller lämnas vidare till en människa. De texterna är funktionen.

Att godkänna att en funktion är klar är därför att godkänna en lydelse, ett tal eller ett villkor. Inte en rad i en kravlista som någon annan sedan översätter.

Rollen att godkänna förutsätter samtidigt att du kan bedöma det du godkänner. Ligger funktionen i en text kan ingen bedöma den åt dig utan att samtidigt bestämma vad den ska göra.

Godkännandet flyttar då antingen till den som skrev texten, vilket lämnar verksamheten utan beslut, eller stannar hos dig som en formalitet där du skriver under något du inte läst. De två utfallen ser likadana ut i en projektplan. Skillnaden märks först när någon frågar varför systemet gjorde som det gjorde.

Så här går det fel

En produktägare godkänner en funktion på en förevisning. Det hon såg var tre svar. Det som styrde dem var en instruktion hon aldrig läste.

I drift börjar lösningen hänvisa vidare i fall där ingen tänkt sig det, eftersom instruktionen säger något hon hade invänt mot om den lästs upp. Hon kan visa att hon godkände funktionen. Godkännandet pekade på ett möte och inte på en version, så vilken lydelse hon godkände går inte att visa.

Det här måste någon bestämma

Att du läser lydelsen innan du godkänner den, och att ett godkännande pekar på en namngiven version av en text.

Vad som räcker som underlag: en formulering du kan återge med egna ord, ett utfall mätt mot fallsamlingen, och besked om vad ändringen väntas göra.

Och att en känsla inte är ett godtagbart skäl, varken för att godkänna eller för att avvisa. Den går inte att pröva en gång till av någon annan.