Arkitektur med AI som sparringspartner – uten å miste eierskapet

En sparringspartner som er lett å spørre

Du sitter med et arkitekturvalg og trenger noen å diskutere med. AI kan foreslå tilnærminger, forklare mønstre og hjelpe deg å finne svakheter i et forslag. Den er tilgjengelig klokken 23, når tanken endelig løsner og resten av teamet har logget av.

Det er nyttig. Men svaret kan være overbevisende lenge før det passer systemet deres. Som tech lead må du hjelpe teamet med å undersøke det som ligger bak forslaget: antakelsene, begrensningene og avveiningene.

Hva gjør du med svaret?

«Hvordan bør vi bygge dette?» er et helt greit sted å begynne. Problemet oppstår hvis det første svaret også blir beslutningen.

Prøv å gå videre: «Her er begrensningene våre. Hvilke alternativer finnes? Hva taler mot forslaget ditt? Hva må vi undersøke før vi velger?» Det gir teamet mer å arbeide med. Dere må fortsatt vurdere om svarene holder.

Et forsøk hos Anthropic gir grunn til å være oppmerksom på forståelsen underveis. I en randomisert studie lot Shen og Tamkin 52 utviklere lære seg et ukjent Python-bibliotek med og uten AI-assistent. AI-gruppen fikk i gjennomsnitt 50 prosent på en forståelsesprøve rett etter oppgaven, mot 67 prosent i gruppen uten AI. Studien målte læring av biblioteket, ikke kvaliteten på arkitekturvalg eller kompetanse over tid.

Innad i AI-gruppen så forskerne at utviklere som brukte assistenten til forklaringer og oppfølgingsspørsmål, ofte viste bedre forståelse enn dem som overlot arbeidet til den. Bruksmåtene var ikke tilfeldig fordelt. Det er derfor en observasjon, ikke bevis for at en bestemt måte å spørre på gir bedre læring.

Et velformulert forslag forteller heller ikke hvor godt teamet har undersøkt det. Det må komme frem i diskusjonen.

Prøv forslaget mot systemet dere har

I Hvordan håndtere uenighet i teknologivalg skrev jeg om design review: et kort, fokusert møte der relevante stemmer legger frem argumenter basert på erfaring og fakta. Forslag utviklet med AI hører hjemme i samme prosess.

Den som legger frem forslaget, bør kunne forklare hvorfor det passer. Teamet vurderer kompleksitet, drift, kompetanse og sammenheng med resten av systemet. Mangler det opplysninger i samtalen med modellen, kan et velkjent mønster se langt mer egnet ut enn det er.

Jeg så det utspille seg i en migrering. En eksisterende kodebase måtte flyttes til et annet språk og en annen plattform, av strategi- og sikkerhetshensyn. Modellens første arkitektur lot det nye systemet skygge det gamle: kjøre ved siden av, ta imot de samme dataene, skrive ingenting, og bare logge hva det ville ha gjort.

Dette er en variant av dark launching, som Fowler beskriver. Selve mønsteret krever ikke at systemene kjører på samme server. Men den foreslåtte løsningen i denne migreringen lot seg ikke bygge. Det gamle systemet kjører på en utdatert server der deploy-agenten er død og ikke lar seg starte, så ingenting kan deployes dit: verken den nye appen ved siden av den gamle, eller loggingen sammenligningen ville ha krevd på den gamle siden.

Å flytte det til en ny server først ville kostet en nedetid for databaseflyttingen og tømmingen av køene – og en ny nedetid senere, for å skru skyggekjøringen av. Flere iterasjoner gikk samme vei.

Det som til slutt ga en arkitektur som lot seg bygge, var utviklerne, både nye og mangeårige, som satte nok av det eksisterende systemet i ord til at begrensningene ble synlige.

Mønsteret var velkjent. Det modellen manglet, var opplysningen om én død prosess på én gammel server. Den sto ikke skrevet noe sted, men var avgjørende for arkitekturen. Her trengte vi erfaringen til dem som kjente systemet.

Spørsmål som hjelper teamet videre

Som tech lead trenger du ikke gjøre design review til en eksamen. Du skal hjelpe teamet med å finne ut om forslaget holder. Tre spørsmål er et godt utgangspunkt:

• Hvorfor passer dette hos oss? «AI-en anbefalte event sourcing» sier lite om behovet. Be om sammenhengen mellom problemet og valget.
• Hvilke alternativer vurderte vi? Få frem hva som ble valgt bort og hvorfor. Hvis teamet bare har sett på ett forslag, kan dere undersøke et alternativ sammen.
• Hva vet vi ennå ikke? Kanskje ingen kan svare på hva som skjer når trafikken tidobles. Da trenger dere en undersøkelse, en ansvarlig og en avtale om når svaret skal være klart.

«Det vet vi ikke ennå» kan være et ansvarlig svar. Det avgjørende er hvordan teamet følger det opp, og om usikkerheten må avklares før beslutningen tas.

La teamet eie beslutningen

I Det tause ansvaret skrev jeg om å la teamet utfordre og forbedre forslagene før de blir standarder. Det samme gjelder her. De som skal bygge og drifte løsningen, trenger anledning til å påvirke valget.

Et ferdig dokument gjør ikke den jobben alene. Sett av tid til spørsmål. Lytt til den som kjenner den gamle deploy-løsningen, og til den nye utvikleren som ikke forstår hvorfor et alternativ ble forkastet. Begge kan se noe forslaget mangler.

Et praktisk mønster

Du kan legge opp arbeidet slik:

1. Utforsk med AI. Arbeid individuelt eller i par. Beskriv kjente begrensninger, be om alternativer og undersøk modellens begrunnelser.
2. Gjennomfør design review. Vurder forslagene med teamet og dem som kjenner driften. Skriv ned antakelser og åpne spørsmål.
3. Avklar det som avgjør valget. Fordel undersøkelser eller små utprøvinger. Ta beslutningen når teamet har et tilstrekkelig grunnlag, og noter usikkerheten som gjenstår.
4. Skriv en TDR. Dokumenter valget, alternativene og teamets begrunnelse i en Technical Decision Record. Avtal hva som kan gi grunn til å ta valget opp igjen.

Til neste design review: Be den som legger frem forslaget, ta med én forkastet tilnærming og én antakelse som fortsatt trenger å sjekkes. Da har dere noe konkret å undersøke sammen, før arkitekturen blir kode.