Onboarding i AI-alderen: Når nye utviklere lærer systemet av en modell som ikke kjenner det

En ny kollega, en ekstra rådgiver

En ny utvikler lurer på noe, kikker seg rundt og spør den som ser minst opptatt ut. Svaret kommer med kontekst: «Vi gjør det slik – det henger sammen med den gamle integrasjonen, lang historie.»

Den samtalen finnes fortsatt. Men nå har den nye utvikleren også en AI-assistent å spørre. Det kan gjøre det lettere å komme i gang: finne frem i ukjent kode, få forklart et mønster eller forberede et spørsmål til teamet.

Utfordringen kommer når en forklaring som høres riktig ut, bygger på forutsetninger som ikke gjelder hos dere. Assistenten foreslår kanskje å forenkle en integrasjon uten å kjenne begrensningen som gjorde den nødvendig. Den nye utvikleren har heller ingen grunn til å vite om den ennå.

Gapet mellom «best practice» og «vår praksis»

I etablerte systemer er det ofte et gap mellom hvordan ting «burde» gjøres og hvordan de faktisk gjøres. Mye av det handler om historie, kompromisser og bevisste valg, slik jeg beskrev i Hvordan evaluere og modernisere en eksisterende kodebase.

En erfaren kollega kan forklare bakgrunnen. For den nye utvikleren kan den først bli synlig i review: Løsningen er ryddig, men den passer ikke med måten resten av systemet fungerer på. Da er det lett å bruke tiden på å rette koden og glemme å forklare premisset som manglet.

Som tech lead bør du undersøke det sammen med den nye. Mangler forklaringen i dokumentasjonen? Er den utdatert? Hadde assistenten tilgang til den, og ble den faktisk lest? Eller hadde modellen relevant informasjon, men tolket den feil?

Det er ulike problemer, og de trenger ulike tiltak. Mer dokumentasjon hjelper lite hvis verktøyet ikke finner det dere allerede har skrevet.

Onboarding som lakmustest

Når en ny utvikler og en erfaren kollega forstår samme oppgave forskjellig, har dere noe konkret å undersøke. Det kan avdekke kunnskap som bare finnes i hodene til folk. Det kan også vise at teamets egen praksis er uklar eller moden for endring.

Her gjelder det samme som i Det tause ansvaret: Begynn med å lytte. Be den nye utvikleren vise hvordan hen kom frem til løsningen, og forklar hvilke hensyn teamet bygger på. Da får dere både undersøkt forslaget og gjort begrunnelsen tilgjengelig for den neste som lurer.

Gjør konteksten lesbar – for mennesker og modeller

1. En kort inngang til repoet

En kontekstfil kan beskrive arkitekturprinsipper, konvensjoner og bevisste avvik, med lenker til eksempler og beslutninger. AGENTS.md støttes av flere kodeverktøy. Sjekk likevel hvordan verktøyet deres finner og laster instruksjoner, hvilke filer som gjelder i den aktuelle mappen, og om det får tilgang til dokumentene dere viser til.

Vær også nøktern om effekten. Gloaguen og kolleger ved ETH Zürich testet kodeagenter med og uten kontekstfiler. I de undersøkte oppsettene ga filene ikke generelt høyere løsningsrate, mens kostnadene ved modellkjøringene økte med over 20 prosent i gjennomsnitt. Studien gir dermed ikke grunnlag for å anta at en slik fil automatisk gir bedre resultater.

Bruk filen til å gjøre viktige føringer tydelige, og prøv den på faktiske oppgaver. Den gir assistenten instrukser å følge. Dere må fortsatt kontrollere om den følger dem.

2. TDR-er som forklarer lokale valg

Dokumentér hvorfor dere har valgt en løsning, særlig når den lett kan se unødvendig komplisert ut for en som er ny. En TDR (Technical Decision Record) kan forklare begrensningen, alternativene og hva som må endre seg før valget bør vurderes på nytt.

Da får den nye noe mer å forholde seg til enn «slik gjør vi det her». Og teamet får en anledning til å sjekke om begrunnelsen fortsatt gjelder.

3. Dokumentasjon der den blir brukt

Prinsippet fra Hvordan etablere tekniske standarder som faktisk etterleves gjelder fortsatt: Gjør det lett å finne det som trengs i arbeidet. Markdown ved koden kan gjøre det enklere å oppdatere dokumentasjon sammen med en endring. Men plasseringen alene sikrer ikke at assistenten leser den.

Ligger viktig kunnskap i Confluence eller et annet system, må dere også sjekke tilgangen der. Prøv med verktøyet den nye faktisk bruker, ikke bare med din egen konto.

4. Gå gjennom en oppgave sammen

La den nye og fadderen gå gjennom én konkret oppgave fra den første uken. Hva foreslo assistenten? Hvilke forutsetninger bygget forslaget på? Finn den relevante koden eller beslutningen sammen, og sjekk om forklaringen stemmer.

Samtalen bør også gi plass til å utfordre dagens praksis. Kanskje begrensningen er borte. Kanskje den nye har sett en enklere løsning. Fadderens jobb er å hjelpe med å vurdere det, ikke bare å forsvare det som finnes.

Tech leadens mulighet

Be den nye notere noen eksempler på svar som ikke stemte med praksisen deres. Sett av tid etter et par uker til å gå gjennom dem sammen. Skill mellom manglende eller utdatert dokumentasjon, problemer med tilgang og svar som var feil selv med relevant kontekst.

Deretter kan dere prioritere: Hva førte til mest ekstraarbeid? Hva kan ramme neste person som begynner? Oppdatér en forklaring, rett en lenke eller justér en instruks, og sjekk om det hjelper på den aktuelle oppgaven. Listen blir nyttig fordi dere undersøker den sammen.

Kunnskap som kan deles

AI gir nye utviklere en ekstra måte å utforske systemet på. Som tech lead må du sørge for at den utforskningen også fører inn i samtalene med teamet.

Det krever ikke at all historikk skrives ned før noen kan begynne. Start med valgene den nye faktisk møter, forklar dem og gjør begrunnelsene lettere å finne. Målet er at den neste utvikleren skal kunne forstå både løsningen og hvorfor dere fortsatt mener den er riktig.