AI usage guidelines som faktisk etterleves

Tirsdagens spørsmål

Mange organisasjoner har nå en AI-policy. Den ligger i et styringsdokument, og den handler om datasikkerhet, lisenser og godkjente verktøy. Den er viktig, og den er fullstendig irrelevant for hvordan teamet ditt faktisk jobber på en tirsdag.

For policyen svarer ikke på de spørsmålene som avgjør kodekvaliteten:

Når bruker vi AI, og når gjør vi det ikke? Hva betyr «review-klar» når koden er generert? Hvordan tar vi inn nye mønstre AI foreslår?

Det er de spørsmålene en guideline må svare på. Og som med alle standarder gjelder det samme prinsippet som i Hvordan etablere tekniske standarder som faktisk etterleves: den får først verdi når den brukes.

Policy vs. praksis

Policy eies av organisasjonen, handler om risiko, og leses én gang. Praksis eies av teamet, handler om kvalitet, og brukes hver dag.

Feilen mange gjør, er å skrive praksisen i policy-språk. Ti sider. Formelle formuleringer. Lagret der ingen jobber. Da skjer det samme som med alle standarder ingen bruker: ingenting.

Én side. I repoet. Eid av teamet.

En AI-guideline som lever, ser omtrent slik ut, og den får plass i én fil, docs/ai-usage.md:

Forstå før du merger

Du står ansvarlig for all kode du åpner PR for – uansett hvem eller hva som skrev den. Kan du ikke forklare den, er den ikke klar.

Forklar komplekse valg i PR

Er sentrale deler generert? Si det. Har du godkjent et valg du ikke selv ville tatt? Begrunn det. «AI foreslo det» er ikke en begrunnelse.

Nye mønstre tas i fellesskap

AI foreslår gjerne mønstre vi ikke bruker. Noen er bedre enn våre. Men de innføres ikke i én PR. De tas opp med teamet, og ender som TDR hvis vi adopterer dem.

Bruk teamets kontekst

Kontekstfilen i repoet – AGENTS.md, eller den verktøyspesifikke varianten deres – gir assistenten våre konvensjoner. Bruk den. Svar uten kontekst er svar for et annet system.

Del det som fungerer

Gode prompts for gjentakende oppgaver hører hjemme i docs/prompts/. En god prompt er teamets eiendom, ikke din hemmelighet.

Det er alt. Fem punkter.

Hvorfor så kort?

Fordi lengde er omvendt proporsjonal med etterlevelse. En guideline på én side kan leses i onboarding, lenkes i PR-kommentarer og siteres i review. En på ti sider kan ingenting av dette.

Og fordi det korte formatet tvinger frem det viktigste spørsmålet: hva er egentlig våre prinsipper? Hvis du ikke får dem ned på én side, har dere dem ikke ennå.

Den mest nyttige énsideren jeg har hatt på et team, het ikke engang AI-guideline. Den het «Slik passerer du code review på første forsøk»: ti punkter, satt sammen av det som kom tilbake i review etter review på de fleste AI-skrevne PR-ene på teamet. Punktene var ikke vedtatt. De var observert.

Forankring skjer i øyeblikkene

Dokumentet er bare startpunktet. Guidelinen blir kultur gjennom de små øyeblikkene:

• når en senior sier «god PR – og takk for at du forklarte det genererte valget»
• når review-kommentaren lenker til guidelinen i stedet for å peke finger
• når noen bryter den med god grunn, og det blir en diskusjon, ikke en irettesettelse
• når retrospektivet spør: «fungerer punktene fortsatt, eller skal vi justere?»

Det er samme mekanisme som all kultur: den bygges gjennom praksis, ikke vedtak.

Det som IKKE hører hjemme i guidelinen

Like viktig som innholdet er det du utelater:

• verktøyvalg (endres for fort, hører hjemme i TDR-er)
• sikkerhet og datahåndtering (hører hjemme i organisasjonens policy)
• detaljerte prompt-regler (hører hjemme i prompt-biblioteket)

Guidelinen skal svare på ett spørsmål: hvordan bruker vi AI med kvalitet hos oss? Alt annet er støy som svekker den.

Den ubevisste praksisen

Teamet ditt bruker AI hver dag, så spørsmålet er ikke om dere har en praksis – den har dere allerede. Spørsmålet er om den er bevisst.

En guideline på én side gjør den implisitte praksisen eksplisitt, og først da kan den diskuteres, forbedres og eies av andre enn den som skrev den.