Tech lead i AI-alderen: Fra ekspert til rammesetter

Innledning

I mange år var rollen som tech lead tett knyttet til én ting: Å være den som visste mest.

Den som kunne svare raskest.
Den som tok de riktige valgene.
Den som så løsningen før resten av teamet rakk å formulere problemet.

Men den rollen har aldri vært hele sannheten.

Og i AI-alderen blir det tydeligere enn noen gang.

Ikke fordi kompetanse er mindre viktig, men fordi kunnskap ikke lenger er knapphetsvare.
Alle på teamet har nå tilgang til en “ekspert” i lomma.

Forskjellen ligger ikke lenger i hvem som vet mest,
men i hvordan kunnskapen brukes og samkjøres.

Når riktig svar ikke lenger er flaskehalsen

Tidligere stoppet fremdrift ofte på én ting:
“Vi vet ikke hvordan vi skal gjøre dette.”

I dag er situasjonen ofte motsatt:
“Vi har ti mulige løsninger, hvilken skal vi velge?”

AI produserer forslag raskt.
Kode, arkitektur, mønstre, alternativer.

Men den gir deg ikke:

• kontekst
• konsekvenser over tid
• forståelse for systemet ditt
• eierskap til valget

Resultatet er ikke mindre usikkerhet, det er mer.

Og det merkes i hverdagen:

Én utvikler bruker AI til å generere strukturert logging med korrelasjons-IDer.
En annen får enkel string-logging.
En tredje introduserer et nytt mønster for feilhåndtering.

Alt fungerer.
Alt blir godkjent.

Men etter noen uker er det ingen som helt vet hva som er “måten vi gjør det på”.

Problemet er ikke mangel på svar.
Det er mangel på struktur rundt dem.

Fra ekspert til rammesetter

Det er lett å tolke dette som et skifte i rollen.
Men egentlig er det en tydeliggjøring.

En god tech lead har aldri først og fremst vært den som vet mest.
Rollen har alltid handlet om noe mer subtilt:

Å holde standarder samlet.
Å skape retning.
Å sørge for at systemet henger sammen.

Det du kanskje kjenner som det tause ansvaret, å holde standardene samlet over tid
(Les mer).

Det som endrer seg nå, er ikke hva rollen er,
men hvor synlig den blir.

Når alle er seniorer, og ingen “vet mest”

I mange team gir det ikke mening å snakke om “den beste utvikleren”.

Du har:

• erfarne utviklere
• sterke meninger
• høy faglig kvalitet

Utfordringen er ikke kompetanse.

Den er divergens.

Seniorutviklere tar gode valg.
Men de tar ikke nødvendigvis de samme valgene.

Og det blir tydelig i praksis:

Samme endpoint implementeres tre ganger:
én gang med service-lag, én gang direkte i controller, én gang via en “clean” variant.

Alle tre er faglig forsvarlige.
Alle tre kan argumenteres for.

Men systemet begynner å sprike.

Dette er ikke et kompetanseproblem.
Det er et koordinasjonsproblem.

AI forsterker forskjellene

Legg AI på toppen av dette, og forskjellene øker.

Nå har alle:

• tilgang til ulike forslag
• ulike prompts
• ulike preferanser
• ulike tolkninger

To seniorer + to AI-svar = fire retninger.

Og det stopper ikke der.

Én utvikler spør:
“Hvordan burde vi strukturere dette?”

En annen spør:
“Gi meg en rask løsning.”

De får forskjellige svar.
Begge føles riktige.

Uten struktur får du ikke bedre løsninger.
Du får mer fragmentering.

Dette er ikke et nytt fenomen, bare en akselerert versjon av noe vi allerede kjenner:
fra teknisk gjeld, hvor problemet sjelden er én dårlig beslutning, men mange små som aldri ble samkjørt
(Les mer).

Hvordan teamet bruker AI

Derfor er det første skiftet ikke teknologisk, men operasjonelt.

AI i seg selv gir ikke kvalitet.
Det gjør praksisen rundt den.

Uten struktur ser du fort:

• AI-generert kode med ulik stil og kvalitet
• inkonsistente mønstre i samme kodebase
• løsninger som ikke er forstått av de som implementerer dem
• økende behov for opprydding

Et klassisk eksempel:

En utvikler bruker AI til å generere mapping mellom DTO og domain.
Neste utvikler bruker AutoMapper.
En tredje skriver det manuelt.

Ingen av valgene er feil,
men systemet mister konsistens.

Hva betyr det i praksis?

Som tech lead bør du definere:

• Når bruker vi AI, og når gjør vi ikke?
• Hva er “review-klar” kode hos oss?
• Hvordan evaluerer vi forslag før de tas i bruk?
• Hvordan dokumenterer vi valg som er gjort med støtte fra AI?

Et konkret grep mange team mangler:

En kort AI usage guideline i repoet.

Ikke som policy, men som en del av hverdagen:

• “Forstå før du merger”
• “Forklar komplekse valg i PR”
• “Nye mønstre tas i fellesskap”

Det er samme prinsipp som for standarder generelt:
de fungerer først når de faktisk brukes i hverdagen
(Les mer).

Kvalitet i en verden med generert kode

Når kode kan produseres på sekunder, flyttes kvalitetssikring:

Før:

• Fokus på hvordan skrive god kode

Nå:

• Fokus på hvordan vurdere god kode

Det krever:

• felles forståelse av kvalitet
• tydelige standarder
• konsistente review-prosesser

For uten en delt forståelse vil hvert individ, og hver AI, trekke i sin retning.

Et kjent mønster:

En PR ser “ryddig” ut.
Koden er strukturert.
Navnene gir mening.

Men:

• feil håndteres ulikt
• logging mangler kontekst
• mønsteret avviker fra resten av systemet

Alt ser riktig ut lokalt,
men bryter helheten.

Praktiske grep

• PR-maler som gjør kvalitet eksplisitt
• automatisert håndheving der det er mulig
• eksempelkode som viser hva “bra” faktisk betyr

Poenget er ikke flere regler.
Det er å gjøre forventningene tydelige i praksis.

Mindre fokus på “riktig løsning”

I et AI-drevet miljø blir én ting tydelig:

Den perfekte løsningen er sjelden problemet.

Problemet er:

• at valget ikke er forstått
• at det ikke er forankret
• at det ikke kan evalueres senere

Igjen ser vi samme mønster:

Ikke én feil beslutning,
men mange små som aldri ble gjort eksplisitte.

Hva bør du optimalisere for?

• forståelige valg
• dokumentert kontekst
• mulighet for revisjon
• felles eierskap

Ikke perfeksjon.

Fra kontroll til mekanismer

Når kompleksiteten øker, er det fristende å stramme inn:

• flere regler
• mer kontroll
• mer godkjenning

Men det skaper flaskehalser.

I stedet må du bygge mekanismer:

• tydelige standarder
• automatisert håndheving
• gode defaults
• lav friksjon for riktig praksis

Standarder fungerer bare når de oppleves som støtte, og ikke tvang.
Ellers mister de eierskap og etterlevelse.

Tech lead som synkroniseringspunkt

I praksis blir rollen din dette:

Du er ikke eksperten.
Du er synkroniseringspunktet.

Du sørger for at:

• standarder henger sammen
• teknologistakken utvikler seg i én retning
• beslutninger er forståelige over tid
• avvik er bevisste og dokumenterte

Du eier ikke alle valg,
men du eier helheten.

Den faktiske verdien

I et sterkt team er det lett å undervurdere rollen:

“Alle er jo flinke.”

Nettopp derfor er rollen kritisk.

Ikke for å løfte enkeltpersoner,
men for å sikre at summen ikke blir fragmentert.

Og det merkes først når det begynner å gjøre vondt:

• når onboarding tar lengre tid
• når bugs er vanskelige å spore
• når små endringer får uforutsigbare konsekvenser

Utfordringen ligger ikke i enkeltvalg,
men i fravær av felles retning.

Avslutning: Å lede det ingen helt forstår

AI gjør ikke utvikling enklere.
Den gjør den raskere og mer uoversiktlig.

Du kan ikke lenger være den som vet mest,

men du kan være den som:

• skaper struktur
• gir retning
• gjør kvalitet konkret
• holder systemet samlet

Din verdi er ikke å ha svarene.

Det er å sørge for at teamet ikke spriker i møte med dem.

Det er det tause ansvaret.

Og i AI-alderen er det ikke mindre viktig.
Det er selve rollen.