I de seneste par årtier har regeringer og andre brugt milliarder på at lære folk at kode. Man troede, at det var et af de få erhverv, der ville være sikkert i en verden under forandring, men det viser sig, at skrivning og manipulering af kode er en af de aktiviteter, som AI-modeller er bedst egnede til. Teknologivirksomheder har afskediget over 1 million medarbejdere i de seneste år, og Microsoft tilbød 60.000 fratrædelsesordninger så sent som i sidste uge. Det er et skræmmende og dybt forvirrende øjeblik for folk i softwareindustrien.

For omkring en måned siden skrev jeg et internt notat, hvor jeg detaljerede den AI-adoptionssti, som Proton skal følge for at forblive konkurrencedygtig og sikker, og hvad vi hidtil har forsømt som organisation, og som vi må rette op på for at gøre denne uundgåelige overgang til en succes. Der er næppe tvivl om, at organisationer, der ikke formår at transformere sig hurtigt nok, i sidste ende vil skuffe deres teams og dem, der er afhængige af dem.

Notatet tjente også et andet formål, nemlig at overbevise mine kolleger om, at vi ikke er passive aktører i denne forandring, at virksomheden har brug for deres talenter og ekspertise til at gennemføre den, og at denne overgang giver muligheder for dem, der vælger at forberede sig på den og engagere sig i den.

Notatet er ikke et dybdegående ingeniørdokument. Det går ikke i detaljer med sikkerhed, pålidelighed eller infrastruktur. Det peger snarere på den retning, vores branche som helhed bevæger sig i.

Notatet findes i sin fulde længde nedenfor.

Download en PDF af AI-manifestet(nyt vindue)

AI @ Proton, ingeniørmanifest

Det bør ikke overraske nogen hos Proton, mindst af alt i ingeniørafdelingen, at softwareudvikling er blevet uigenkaldeligt forandret i år, hvis ikke før. LLM’er og tilhørende værktøjer har fået evnen til at skrive kode i en grad, hvor en erfaren Proton-ingeniør for et par dage siden sagde til mig, og jeg citerer: ”Ingen skriver kode i {business unit name} længere”. Ligesom at huske telefonnumre i det 20. århundrede eller at ride på heste i det 19. århundrede, er det at skrive fremragende kode manuelt en kernekompetence, hvis tid er forbi.

Det er generelt en fantastisk ting. Meget af kodeskrivningen var og er tidskrævende slid, i hvert fald i produktion og i stor skala. Dokumentation og test er begge nødvendige ting, som få bryder sig om at gøre, og som historisk set ofte er blevet forsømt, hvilket har ført til dårlig kommunikation, ineffektivitet og problemer med pålideligheden. Boilerplate er indbegrebet af softwareudviklingsslid, og det bliver måske aldrig noget, et menneske skal bekymre sig om igen. Modeller kan nu rådgive om og foreslå arkitekturer og systemdesigns, som – selv om de ofte er ufuldkomne – bidrager meningsfuldt til diskussion, beslutningstagning og uddannelse.

Uden for Proton fejer AI-revolutionen hen over verden. Meget af det er tom snak og overfladiske, kosmetiske kampagner, der mere handler om at blive set som innovative end om reelt at være det. Men meget af det er meget reelt, og de investeringer, som disse virksomheder (inklusive vores konkurrenter) foretager nu, vil være med til at bestemme det forretningsmiljø, vi skal operere i fremover. Det handler ikke om at jagte trends – vi sakker bagud her, og det er en eksistentiel trussel mod selve missionens succes.

Så hvorfor føles det ikke hos Proton, som om revolutionen er kommet? Hvorfor er produktiviteten ikke steget dramatisk, hvis alle allerede bruger LLM’er hele tiden? Jeg tror, det bunder i tre ting, som vi alle skal rette op på, hvis vi skal lykkes i den nye æra, som allerede er her i dag, og ikke er på vej.

Den første er en ændring i ingeniørkulturen og ingeniørmentaliteten. Dit job har ændret sig fundamentalt. Det er ikke længere at skrive kode, og LLM’er er ikke her for at hjælpe dig med at skrive bedre kode hurtigere. Dit job er at hjælpe LLM’en med at skrive bedre kode hurtigere. Hver ingeniør er nu teamleder og leder, og dine direkte rapporter er de modeller og agenter, du bruger. At guide dem direkte og rette dem, når de tager fejl, er en del af det, helt sikkert. Men et team på to personer, som altid parprogrammerede sammen, ville ikke være meget af et team, og det samme gælder et team, hvor ingen arbejdede, når teamlederen var til møde. AI skal kunne arbejde autonomt og kontinuerligt med mindre og mindre menneskelig overvågning. Dit job er at identificere problemer, som LLM’en ikke kan løse på egen hånd, og hjælpe den med ikke bare at løse dem denne gang, men med at kunne løse dem bedre næste gang, ikke kun for dig, men for alle: kontekstfiler på repository-niveau, delte færdigheder og prompts samt en vane med at sikre, at gentagne fejl udløser en undersøgelse og en rettelse. Dit job er at presse grænserne for, hvad LLM’en kan gøre autonomt, træde til for de ting, den ikke kan, og altid tænke over, hvordan du kan forbedre status quo.

Dette er ikke ekspertisens død. LLM’en er hurtig. Du er langsom, men du bærer på en livslang erfaring, vurderinger og forståelse. Du er også (forhåbentlig) meget mindre tilbøjelig til at hallucinere og blive vildledt af dårlige eller ondsindede input, og du er ansvarlig over for dig selv, dine kolleger og over for Proton på en måde, en model aldrig kan være. Sammen kan I gøre langt mere, langt hurtigere, end nogen af jer kan gøre alene.

Det er heller ikke slutningen på god ingeniørpraksis. Vedligeholdelsesvenlighed og hastighed er bedre på velarkitekturerede kodebaser. Dokumentation og tests forbliver afgørende. Når det er sagt, skal vi være åbne for, at bedste praksis ændrer sig, i takt med at omkostninger og kapaciteter ændrer sig. Test er et godt eksempel på dette. Gammel bedste praksis siger, at for mange tests (især end-to-end-tests) er et dårligt kompromis i en verden, hvor det er dyrt at skrive og vedligeholde tests. Hvis det bliver billigt at skrive og vedligeholde tests, vil det sted, hvor vi trækker den grænse, sandsynligvis også ændre sig.

Den anden grund til, at vi ikke har kunnet udnytte AI-revolutionen fuldt ud, er, at vi næsten er helt fastlåst i fase 1 – at bruge LLM’er til at gøre opgaver hurtigere som en del af eksisterende arbejdsgange. Men kodeskrivning er ikke den eneste del af softwareudviklingens livscyklus, og hvad sker der, når man fjerner en flaskehals? Så opstår der en ny. Måske er det CI’ens hastighed og kapacitet. Måske er det design, godkendelser, specifikationer og kodegennemgange (ja, vi skal og vil nå til et punkt, hvor det meste af den menneskelige kodegennemgang ophører). Måske ændrer arbejdsgangen sig ikke meget, men LLM’er giver os endelig mulighed for at investere i automatisering, som før var for dyr. Hvis vi ikke ser på alle vores processer holistisk og nådesløst fjerner flaskehalse, opnår vi ikke vores fulde potentiale. Ofte vil fjernelse af disse flaskehalse ikke kun indebære optimering af dele af vores eksisterende arbejdsgange, men også en omarbejdning og gentænkning af dem helt. Det er fase 2, og vi skal derhen nu.

Den tredje grund er et kollektivt handlingsproblem. At bruge LLM’er effektivt til at skrive kode er noget, den enkelte ingeniør kan gøre for sig selv. At genopbygge eller optimere CI-processen for et helt team, en forretningsenhed eller en virksomhed er en meget tungere opgave, og det kommer med alternativomkostninger og afvejninger. Ikke umuligt, og mange hos Proton har gjort fantastiske ting på egen hånd, hvoraf noget har spredt sig vidt og bredt. Men for at omstille virksomheden som helhed kræver det både organisation og ressourcer i et omfang, som vi simpelthen ikke har investeret i endnu. Hvad angår diskussionen om softwareudviklingens livscyklus i det foregående afsnit, ved vi i mange tilfælde ikke engang, hvor flaskehalsene er, fordi vi ikke har investeret i de nødvendige værktøjer til at finde ud af det. En vis forsigtighed kan have været berettiget tidligere – det tog tid at finde ud af, hvordan man bedst bruger disse nye værktøjer, og vi vil fortsat opfordre til eksperimentering. Men det er på tide at forpligte sig som organisation til den transformation, som øjeblikket kræver.

Så hvad betyder det for dig som ingeniør? Din handlefrihed og dine ansvarsområder er begge blevet større. Du er ikke kun ansvarlig for, at arbejdet bliver gjort, du ejer nu også måden, det bliver gjort på, og er derfor ansvarlig for løbende optimering og maksimal automatisering (og for at dele disse forbedringer med dine kolleger – succes hos Proton er en holdsport). Det er også dit ansvar at markere og eskalere nødvendige forbedringer, som du ikke kan gennemføre på egen hånd. Proton vil for sin del organisere og allokere ressourcer til de kritiske investeringer, der er nødvendige for at komme gennem fase 2 og fuldt ud realisere potentialet i AI-revolutionen.

Kort sagt, vi er i en ny verden. ”Programmering” er død. Ingeniørfaget er ikke dødt, og det er ekspertisen heller ikke. Dit gamle job er væk. Dit nye job som bygger vil give dig mulighed for at gøre mere og få større indflydelse, end du nogensinde har haft, hvis du griber muligheden. Og Proton vil sætte dig i stand til at gøre det, og du vil høre mere om indsatsen i de kommende dage og uger. Eksperimenteringens æra fortsætter, men tiden er inde til at handle. Fremtiden er her – lad os gøre den til vores.

Forsidebillede af: Bernard Leonardo
Instagram: @dranreboel
Websted: https://dranreboel.myportfolio.com/work