Hva betyr noe når alt forandrer seg?

Jeg har jobbet med softwareutvikling i rundt 20 år. For meg har det egentlig alltid handlet om det samme: å forstå et problem og finne en måte å løse det på.

Koden har bare vært veien dit.

Likevel endte vi opp med å bruke stadig mer av tiden på nettopp veien.

Et sted underveis ble softwareutvikling veldig voksent. Teamene ble større. Fagområdene smalere. Vi fikk frontend og backend, QA, produkteiere og flere lag mellom de som hadde problemet og de som skulle løse det. Systemene ble delt opp. Microservices skulle gi autonomi. Prosesser skulle gi kontroll. Patterns skulle gjøre løsningene gjenkjennelige. Branching-strategier skulle gjøre det trygt for mange mennesker å jobbe i samme kodebase.

Det meste hadde gode begrunnelser. Mye løste reelle problemer.

Men summen gjorde også noe.

Avstanden mellom problemet og den som faktisk kunne løse det ble større.

Jeg husker utvikling før dette som mer direkte. Vi satt tett på business. Vi snakket med folk, forstod hva de trengte og fikset ting. Vi jobbet på tvers av hele stacken. Det var mye frihet, mye ansvar og ganske mye utforsking.

Etter hvert ble det mer konformt. Mer fokus på hvordan ting skulle bygges, hvordan arbeidet skulle organiseres og hvilke mønstre man skulle følge.

Jeg har nok alltid vært litt allergisk mot dette. Ikke fordi struktur er dumt, men fordi struktur veldig lett begynner å leve sitt eget liv. Vi bygger kontrollmekanismer for å håndtere kompleksitet som delvis eksisterer fordi vi allerede har bygget så mange kontrollmekanismer.

Det er derfor det siste året har vært så merkelig.

For første gang på lenge føles det som om utvikling beveger seg den andre veien.

Vi sluttet å kode

Rundt jul gikk vi all-in på AI i SkyeTec.

Siden da har ingen i utviklingsteamet vårt skrevet kode.

Ikke én linje.

Det høres kanskje ut som at vi har sluttet å være utviklere. For meg føles det nesten motsatt.

Hvis jeg skal sette noen svært omtrentlige tall på det, brukte jeg tidligere kanskje 95 prosent av tiden på kode og fem prosent på å finne ut hva vi egentlig skulle lage.

Nå oppleves det omtrent motsatt.

Jeg bruker Claude og Codex om hverandre. VS Code er borte. Arbeidsflaten min er blitt en samling fargekodede terminalvinduer, gjerne med fire, seks eller åtte forskjellige ting gående samtidig.

Men den største endringen er ikke hvor mange ting jeg kan gjøre parallelt.

Det er hvilket nivå jeg kan begynne på.

Jeg kan fortelle en agent ganske overordnet hva jeg ønsker å oppnå. Så begynner den å jobbe. Når vi møter et veivalg hvor min vurdering faktisk er nødvendig, blir jeg dratt ned i detaljene.

Jeg slipper ikke detaljene fordi de er vanskelige.

Jeg slipper detaljene helt til de betyr noe.

Det er en ganske fundamental forskjell.

Utvikleren var aldri koden

En av de mer frustrerende reaksjonene tidlig i denne overgangen var tanken om at vi kanskje ikke trenger utviklere lenger.

Hvis utviklerens viktigste funksjon er å produsere kode, er det en forståelig konklusjon.

Jeg har bare aldri opplevd det slik.

De beste utviklerne jeg har jobbet med har vært gode til å forstå andre mennesker. De klarer å snakke med dem de skal lage noe for og finne ut hva behovet egentlig er. De forstår business. De ser sammenhenger. De deler kunnskap. De tar initiativ og eierskap.

De fanger opp når noe skurrer, ofte før det er åpenbart hva som er galt.

Erfaring blir ofte synlig som kunnskap, men kanskje enda oftere som dømmekraft.

Det er blitt ekstremt verdifullt.

Samtidig blir andre ting mindre viktige. Jeg bryr meg stadig mindre om hvilket programmeringsspråk en utvikler kan. Når jeg ser noen søke etter en «Java-utvikler», tar jeg meg i å lure på hvorfor akkurat Java er så viktig.

Vi trenger fortsatt å forstå hva teknologier gjør, hvilke egenskaper de har og hvilke avveininger de innebærer. Men vi trenger i stadig mindre grad å identifisere oss med implementasjonen.

Jeg tenker mer og mer på utviklerne våre som tech leads for agentene sine.

Oppgaven er ikke å fortelle maskinen nøyaktig hvordan hver linje skal skrives.

Oppgaven er å forstå hvor vi skal.

Utforskning ble billig

Det er kanskje dette jeg liker aller best.

Vi kan leke igjen.

Tidligere kunne vi ha fem mulige løsninger på et problem. Så diskuterte vi dem, forsøkte å forutse konsekvensene og valgte én. Det måtte vi. Å bygge alle fem bare for å se hvilken som fungerte best ville vært absurd.

Nå er det stadig oftere enklere å prøve.

Det endrer forholdet mellom tanke og handling.

Jeg har laget spill på plattformer jeg knapt kjenner. Jeg har bygget en liten DAW på en helg fordi jeg hadde lyst til å se om en idé fungerte. På jobb hopper vi inn i fagområder vi tidligere ville brukt lang tid på å lære oss detaljene i.

Det interessante er ikke at ting går fort.

Det interessante er hva som skjer når kostnaden ved å være nysgjerrig faller.

Lag noe. Se på det. Snakk om det. Finn ut om ideen faktisk var god.

Men denne nye kapasiteten skaper også en ny begrensning.

Når det plutselig blir veldig lett å lage ting, blir det også veldig lett å lage for mye.

Det har vi fått kjenne på.

Den nye flaskehalsen er ikke nødvendigvis hvor fort vi kan bygge. Det er hvor fort vi kan forstå, bruke, reagere og lære.

Så på en litt paradoksal måte har den voldsomme økningen i kapasitet gjort oss enda mer opptatt av noe veldig gammelt: korte feedback-looper.

Få noe fungerende ut. Bruk det. Se hva som skjer. La erfaringen styre neste steg.

Forskjellen er at loopen nå kan starte nesten med en gang.

Kontroll må flytte på seg

Det er lett å tolke denne måten å jobbe på som mindre kontroll.

Jeg tror det er feil.

Når både mennesker og agenter får større autonomi, blir kontroll viktigere. Men den må ligge på riktige steder.

Vi har brukt mye av softwarehistorien på å legge kontroll inn i selve arbeidsflyten. Pull requests. Branching-strategier. Godkjenningsprosesser. Overleveringer. Roller som kontrollerer andre roller.

Noe av det trenger vi selvfølgelig fortsatt.

Men stadig oftere prøver vi å flytte kontrollen ut av veien og ned i systemene.

Agentene må vite hvem de er. De må vite hva de får lov til. De må ha riktig kontekst. Det må være mulig å se hva de har gjort. Noen handlinger kan være autonome. Andre skal stoppe ved en hard grense og vente på et menneske.

Agentene kan få stor frihet til å utforske, bygge og teste. Men det betyr ikke at alt de lager automatisk skal tas i bruk. Nye funksjoner kan stå avslått til vi bestemmer oss for å aktivere dem. Produksjon er fortsatt en eksplisitt beslutning.

Frihet og kontroll er ikke motsetninger.

God kontroll er kanskje nettopp det som gjør stor frihet mulig.

Og det samme gjelder mennesker.

Eierskap skalerer bedre enn kontroll

Jeg har alltid hatt mest tro på team hvor folk kjenner hverandre godt, har det bra sammen og føler stort eierskap til det de lager.

Det er teamet hvor noen fikser noe på en søndag uten at noen har bedt om det.

Ikke fordi det forventes.

Fordi de bryr seg.

Hvis du har ansatt flinke, pålitelige og motiverte mennesker, synes jeg det er et merkelig utgangspunkt å bygge et system rundt at de må passes på.

Jeg trenger ikke et sett med individuelle måltall for å forstå om folk i teamet mitt gjør en god jobb. Jeg jobber med dem. Jeg snakker med dem. Jeg ser hvordan de tar eierskap, hvordan de samarbeider og om vi sammen beveger oss i riktig retning.

Hvis det finnes noe teamet mener det er nyttig å måle, måler vi det. Hvis kunden ønsker å vite om noe faktisk blir bedre, selvfølgelig måler vi det.

Men måling er et verktøy. Det er ikke en erstatning for ledelse.

For meg handler lederrollen stadig mer om å fasilitere. Sette retning. Koble mennesker sammen. Diskutere. Sørge for at folk har det de trenger. Gi ansvar til dem som kan og vil ta det.

Og skape rammer hvor det er lov å prøve og lov å feile.

AI har ikke gjort dette mindre viktig.

Jeg tror det har gjort det viktigere.

Det organisatoriske kartet begynner å se gammelt ut

Det er vanskelig å se for seg at dette ikke også påvirker hvordan vi organiserer teknologiselskaper.

Frontend-utvikler. Backend-utvikler. QA. Plattformutvikler.

Jeg er mindre sikker på hvor interessante disse grensene er fremover.

Folk trenger ikke være like. Tvert imot. Forskjellig erfaring, temperament, fagkunnskap og perspektiv blir viktig.

Men jeg tror flere igjen kan være det jeg ganske enkelt ville kalt utviklere.

Mennesker som forstår problemer og kan få ting til å skje.

Det samme gjelder arkitektur.

Jeg har tidligere vært bekymret for hva som skjer når agentene får stor frihet over tid. Vil systemene gradvis råtne? Vil vi ende opp med enorme kodebaser ingen mennesker lenger forstår?

Jeg er mindre bekymret for det nå.

Vi lar agentene gjennomgå det de selv og andre agenter har bygget. Vi lar forskjellige modeller utfordre hverandre. Vi bygger opp kontekst rundt systemene. Og når noe ikke lenger gir mening, river vi det opp.

Det har vi allerede gjort flere ganger.

Arkitektur kan få lov til å være mer fremvoksende når kostnaden ved å endre den faller.

Vi mennesker kan flytte oppmerksomheten mot egenskapene vi faktisk ønsker: sikkerhet, funksjonalitet, ytelse og endringsevne.

Hvordan systemet ser ut under panseret blir gradvis mindre interessant.

Og det er verdt å huske én ting:

AI kommer aldri igjen til å være så dårlig som den er i dag.

Vi er ikke ferdige

Arbeidsformen vår har endret seg flere ganger bare det siste året. Vi har gått inn i blindveier, snudd, revet ned ting vi nettopp hadde bygget og flyttet grensene for hva vi lar agentene gjøre.

Det er ikke et problem. Det er selve poenget.

Vi lærer dette ved å gjøre det. Ved å gi folk rom til å utforske, gå litt for langt innimellom og ta med seg erfaringene tilbake. Mye av det vi gjør i dag hadde vi neppe kommet frem til i et strategimøte for et år siden.

Og det kommer til å endre seg igjen.

De som venter på å forstå dette fullt ut før de begynner, kommer til å vente for lenge.

Hva er det egentlig vi prøver å oppnå?

Vi eksperimenterer nå med arbeidsflater hvor mennesker, kunder og agenter er i de samme samtalene.

Det er ikke en skisse av hvordan vi tror utvikling kan se ut en gang i fremtiden. Vi gjør det nå.

Vi snakker om hva som fungerer og ikke fungerer. Agentene handler på konteksten, henter inn det som mangler og samarbeider med andre agenter. De reagerer på brukerfeedback og operasjonell innsikt uten å vente på at noen skriver en oppgave. De kan også ta egne initiativ.

Da begynner skillet mellom å diskutere et problem og å løse det å bli uklart.

Hvor langt dette kan dras, vet vi ikke ennå. Men vi har ingen planer om å vente på at noen andre finner det ut.

Mennesker trenger ikke mer informasjon. Vi trenger innsikt. Vi trenger å forstå hva som betyr noe. Sette retning. Gjøre avveininger. Snakke sammen.

Og etter hvert kommer vi til et større spørsmål.

Hvis maskinene kan gjøre stadig mer av det mekaniske arbeidet, hva ønsker vi egentlig å bruke mennesker til?

Det enkleste svaret er mer. Mer produksjon. Mer effektivitet. Mer vekst. Mer penger.

Jeg håper vi klarer å være litt mer ambisiøse enn det.

Vi står foran en teknologisk endring vi ikke aner hva som kommer ut på den andre siden. Den kan endre softwareutvikling, organisasjoner og kanskje etter hvert selve forholdet vårt til arbeid. Det betyr at vi også har en mulighet til å påvirke retningen.

Jeg håper teknologien blir en demokratiserende kraft. At skaperevnen den gir ikke bare samles hos noen få selskaper. At flinke mennesker får større handlingsrom. At teknologi fjerner mer meningsløst arbeid enn den skaper. At vi bruker mindre tid på å betjene systemene våre og mer tid på hverandre.

Det er store spørsmål. Vi kommer ikke til å tenke oss frem til alle svarene.

#FÅDETPÅ