Sådan beskriver du en færdig opgave, så din digitale medarbejder kan rette sit eget arbejde

Forestil dig, at du beder en digital medarbejder om at samle ugens tilbud, skrive et udkast til en kundemail eller rydde op i en prisliste. Der kommer noget tilbage, som ligner et resultat, og alligevel ender du med at bruge en halv time på at rette det til. En stor del af forklaringen ligger tit i selve opgaven. Den blev aldrig beskrevet ud fra det, den færdige aflevering skulle kunne for den person, der skal bruge den.

Det kan du gøre noget ved med to enkle greb: en beskrivelse af det færdige resultat, som kan efterprøves, og feedback, der er præcis nok til, at den digitale medarbejder selv kan rette sit arbejde.

En rigtig opgave som udgangspunkt

I juli udgav jeg en artikel om, hvordan jeg fik Codex til at bygge en ny version af phugl.dk. Hele forløbet ligger offentligt i casen på min blog, og det er et godt sted at se de to greb i praksis.

Kort fortalt fik Codex en hel opgave og en beskrivelse af det resultat, der skulle virke: Forsiden skulle hurtigt forklare, hvad phugl kan hjælpe med, og arbejdsmåden skulle have sin egen side. Codex fandt selv de berørte sider og den kode, der holdt den gamle forklaring på plads. En anden model læste planen igennem og pegede på logiske huller. Da den lokale version var klar, blev siden åbnet på mobil og computer, knapper og links blev prøvet af, og der blev taget skærmbilleder. Hver gang en test eller gennemgangen fandt en fejl, gik fundet tilbage til Codex, som rettede og kørte de samme tests igen, indtil testversionen fungerede.

Det, du kan tage med derfra, gælder langt bredere end hjemmesider: en tydelig beskrivelse af resultatet og fejl, der bliver sendt tilbage med adresse på.

Beskriv, hvad afleveringen skal kunne

En opgave er først færdig, når resultatet virker for den, der skal bruge det. Alligevel bliver mange opgaver formuleret som aktiviteter, for eksempel at kigge på hjemmesiden eller lave et udkast. Den slags kan betyde næsten hvad som helst, og så bliver resultatet derefter.

Prøv i stedet at beskrive afleveringen fra modtagerens stol. Et par tænkte eksempler:

• Et tilbud er færdigt, når priser og navne stemmer med de nyeste kilder, og en kollega kan sende det uden at slå noget efter.
• En månedsopgørelse er færdig, når lederen kan se de vigtigste tal på første side og selv finde videre ned i detaljerne.
• Et svar til en borger er færdigt, når det henviser til den rigtige regel og kan læses uden fagsprog.

Den tilgang ligger tæt på Anthropics offentlige vejledning i at evaluere digitale agenter. Vejledningen anbefaler at definere succes konkret, inden arbejdet går i gang, og at tage udgangspunkt i de kontroller, man allerede udfører i hånden. Den peger også på, at et forløb kan vurderes både på det endelige resultat og på vejen derhen, når det er relevant, og at kontrollerne skal måle den opgave, brugeren faktisk har. Teksten er skrevet til folk, der bygger systemer med kunstig intelligens, og den indeholder ingen løfter om bestemte besparelser. Idéen kan du alligevel bruge direkte som et råd: Skriv ned, hvad du selv ville tjekke, før du sagde god for resultatet. Så har du dine afleveringskriterier.

Feedback med adresse på

Når afleveringen rammer forbi, er den hurtigste vej frem at beskrive fejlen så præcist, at den kan rettes uden dig. I hjemmesideforløbet var problemet, at sproget på siden var intetsigende. Jeg gav kritikken og konkrete eksempler tilbage til Codex, som rettede siden, hvorefter de samme tests blev kørt igen.

Du kan bruge samme opskrift i hverdagen. God feedback peger på stedet, beskriver problemet og fortæller, hvad der skulle have stået. Et tænkt eksempel: En besked om, at tilbuddet virker forkert, tvinger dig til selv at finde fejlen bagefter. En besked om, at prisen på linje tre stammer fra den gamle prisliste, og at den gældende står i regnearket fra marts, kan en digital medarbejder handle på med det samme.

Microsoft Researchs publicerede retningslinjer for samspillet mellem mennesker og kunstig intelligens peger i samme retning. De anbefaler blandt andet, at det skal være let at rette systemet, at feedback skal kunne gives konkret, og at brugeren skal kunne se, hvad handlingerne ændrer. Der er tale om designprincipper til dem, der bygger systemerne, og de dokumenterer hverken en bestemt tidsbesparelse eller en fejlfri model. Som bruger kan du alligevel vende dem til en vane: Peg på det konkrete sted, og bed bagefter om at få vist, hvad der blev ændret, før du godkender rettelsen.

Lad rettelserne blive til noget varigt

Et sidste element fra casen er værd at fremhæve. Samtalen trænede ikke modellen på ny. Min kritik blev gemt som en regel i skriveguiden, som en test, der opdager, hvis de gamle formuleringer vender tilbage, og som kode, der kan genbruges. Næste lignende opgave begynder derfor et bedre sted, selv om selve modellen er den samme.

Du kan gøre noget tilsvarende uden at skrive kode. Gem det gode eksempel på en færdig aflevering sammen med opgavebeskrivelsen. Skriv den kontrol ned, der fangede fejlen sidste gang, og bed om, at den bliver brugt hver gang. Over tid får I en lille samling af eksempler og kontroller, der viser, hvordan færdigt arbejde ser ud hos jer.

Mennesket beslutter stadig

I casen beholdt jeg de beslutninger, der har en reel konsekvens. Hjemmesiden kunne bygges, testes og lægges i en testversion uden at vente på mig, mens beslutningen om at lægge den live lå særskilt hos mig. Det samme gjaldt mail, opslag og betalinger: Codex kunne gøre arbejdet klar, og det lå hos mig selv at sende, offentliggøre og godkende.

Den rollefordeling er et godt råd at holde fast i, når du prøver noget lignende af. Afleveringskriterierne og den præcise feedback løfter kvaliteten undervejs. Beslutningen om, hvad der forlader huset, ligger stadig hos et menneske.

Begynd med en opgave, der irriterer

Vælg en opgave, der allerede ligger på bordet og bliver løst på samme måde uge efter uge. Beskriv, hvad den færdige aflevering skal kunne for den, der modtager den. Lad den digitale medarbejder vise en testversion, og send hver fejl tilbage med sted, problem og det rigtige svar. Gem til sidst det gode eksempel og den kontrol, der fangede fejlen.

Det er en jordnær måde at begynde på, og du kan følge et helt gennemløb fra opgave til færdigt resultat i den offentlige case på phugl.dk.