Hvordan AI skaper bedre tverrfaglige lagspillere

Overleveringer er fossefall i forkledning

Jeg er en forkjemper for tverrfaglige team der fagområdene ikke bare lemper oppgaver over til hverandre, men faktisk løser problemer i fellesskap.

For hva skjer når designere «leverer» skisser til utviklere? Da har vi i praksis gjeninnført fossefallsmetodikken. Vi har bare gjemt den inne i sprintene og kalt det smidig.

Konsekvensene er forutsigbare:

→ Designet blir dårligere, fordi utviklernes perspektiver aldri kommer inn i prosessen. De vet ting om systemet, dataene og begrensningene som ville endret løsningen – hvis de hadde blitt spurt før skissen var «ferdig».

→ Koden blir dårligere, fordi utviklerne bygger noe de ikke har eierskap til. Når du ikke forstår behovet bak en løsning, kan du ikke ta gode valg i alle de små veikryssene som ikke står i skissen. Og de er mange. En medfølgende spesifikasjon hjelper lite – den arver de samme blindsonene, så lenge den er skrevet uten perspektivene fra resten av teamet.

For en skisse er et bilde av en forståelse. Og forståelse kan ikke overleveres. Den må bygges sammen.

Tverrfaglighet krever at vi snakker hverandres språk

Godt samarbeid krever at vi forstår hverandres disipliner. Det betyr ikke at designeren skal kode, eller at utvikleren skal lage skisser – men nok til at vi kan stille hverandre gode spørsmål.

En designer som forstår teknologien under panseret, designer løsninger som faktisk lar seg bygge. En utvikler som har kjent brukernes smerte på kroppen, tar de mange små beslutningene i riktig retning – uten at noen ber om det.

Det er der verdien ligger. Ikke i overleveringene, men i alt som skjer mellom dem.

Så, hva har AI med dette å gjøre?

I Variant eksprimenterer vi mye, og legger ressurser i å ligge langt fremme når det kommer ny teknologi. Det har ført til at jeg det siste året har jeg brukt mye tid på å utvikle løsninger med AI. Det jeg synes er mest spennende, er det som gjerne omtales som AI-drevet utvikling. Altså ikke «vibing».

Det viktigste premisset er å bygge implementeringsplaner i fornuftige steg – med kontrollpunkter og testing underveis, av både menneske og maskin. Det er slik jeg unngår at både jeg og AI-en mister kontekst og går oss vill i skogen. God arkitektur, team av agenter, skills og CI-pipelines med automatisk testing bygger opp under det samme: at hvert steg kan verifiseres før neste tas.

Produktene som kommer ut av dette er en åpenbar gevinst. Men læringen betyr minst like mye.

For nå sitter jeg midt i alle beslutningene. Arkitektur, datamodell, testing, design, prioritering. Jeg kan ikke lenger skyve noe over gjerdet – det er ingen på andre siden. Hver beslutning jeg pleide å overlate til «noen andre», må jeg nå forstå godt nok til å ta selv.

Og det er dette som har overrasket meg: Dette er den mest effektive tverrfaglige treningen jeg har hatt. Den gjør meg til en bedre lagspiller på ordentlige team – fordi jeg nå vet hva som skjuler seg bak spørsmålene utviklerne stiller, og hvorfor de stiller dem.

Et råd jeg selv følger

AI-en din vet ikke hvem du er. Fortell den det!

I md-fila til prosjektet (f.eks. CLAUDE.md): Beskriv bakgrunnen din og hvor teknisk du er – gjerne med styrker og svakheter. Ikke la AI-en ta beslutninger over hodet ditt. Krev at den er pedagogisk.

Det er fristende å bare klikke OK på anbefalinger. Da får du et produkt, men du lærer ingenting. Jeg ber AI-en gi anbefalinger, men også begrunne dem og forklare – slik at neste beslutning er litt mer min egen.

Behandler du AI-en som en autopilot, blir du passasjer i ditt eget prosjekt. Behandler du den som en kollega som forklarer seg, sitter du igjen med noe som kanskje er mer verdifullt enn selve produktet:

Du forstår hele verdikjeden du er en del av.

Og det er kanskje det tverrfaglighet egentlig handler om.