I størstedelen af min karriere har jeg primært brugt min tid på at skrive kode.
Ikke på at tænke. Ikke på designet. Fingrene på tastaturet, wiring, timer brugt på at finde ud af, hvordan det ene build tool nu skulle konfigureres i en ny kontekst. Man startede ugen med en klar idé og sluttede den med måske tres procent af arbejdet udført. Implementering er langsom, nådesløs og fuld af små omveje som ingen har med i estimatet.
Samtidig voksede en anden liste stille i baggrunden: artiklen der blev delt i chatten; konferenceoplægget med 200.000 visninger, som alle snakkede om, men du aldrig nåede at se; den nye bog, Thinking in Platforms, på hylden med ubrudt ryg. Den vage intention om at forstå, hvordan det programmeringssprog du bruger håndterer closures, hukommelse eller scheduling - ikke brugen, men mekanikken.
Den liste blev aldrig kortere. Der var altid en opgave. Saven forblev sløv, fordi der altid var mere brænde at save.
Flaskehalsen flyttede sig, og vi opdagede det knap nok
Så blev AI god til rugbrødsarbejdet.
Ikke til at beslutte, hvad der skal kodes eller til at vurdere, om en abstraktion holder over de næste tre features. Men den mekaniske produktion af kode - den del, der plejede at være flaskehalsen - går nu hurtigt, og Claude Code og Codex bliver ikke trætte klokken fire om eftermiddagen.
Det betyder, at mange af os for første gang i femogtyve år har fået rigtige timer tilbage.
Og dette gjorde de fleste af os med dem.
Vi fyldte hullet med mere af det samme
Det oplagte greb, når én agent kører, er at starte en til - og så en mere. Fem terminaler, fem branches, fem opgaver i gang, og du skifter mellem faner som en flyveleder med for meget kaffe.
Det føles produktivt.
Men se, hvad der sker over en hel dag. Dit output skalerer ikke lineært med antallet af jobs, for nu er det dig, der er integrationspunktet. Alle branches skal reviewes, og review er det kognitivt dyre arbejde - ikke længere det at skrive koden. Du skifter kontekst hvert tredje minut, hvilket koster mere, end skiftene sparer. To af de fem viser sig at løse det forkerte problem, hvilket du ville have opdaget på ti sekunder, hvis du havde været til stede, da du skrev prompten i stedet for halvt at overvåge en anden terminal.
Først og fremmest: at køre fem agenter er at bruge den nyvundne tid på præcis den samme aktivitet som før. Vi fik tid og konverterede den straks tilbage til implementeringsvolumen - fordi implementeringsvolumen er det, vi altid er blevet målt på.
Hvad tiden egentlig er til
Grunden til at bruge tiden på at lære er ikke selvudvikling i vitaminpille-og-løbetur-forstand. Evnen, som AI ikke har erstattet, er præcis den, som dybde skaber.
En agent giver dig med stor selvtillid noget, der kompilerer, klarer de tests, du bad om, og alligevel er forkert på en måde, du først opdager i produktion om fem uger. Det eneste forsvar er, at du ved nok til at kunne mærke at det er forkert. Den fornemmelse er ikke et personlighedstræk. Den kommer af at have læst om netop den type fejl, set det eksempel, af at have skilt ting ad, og af at have prøvet idéen i en proof of concept og set at den ikke virker.
Jo bedre AI bliver til at producere muligheder, jo mere består jobbet i at vælge mellem dem. At vælge godt kræver kendskab til mulighedsrummet - og det kommer af research. Den, der har læst bredt, beder desuden om bedre ting fra starten, og netop der afgøres det meste af kvaliteten.
Så helt konkret, sådan ville jeg bruge de genvundne timer:
-
Bunken. De gemte artikler, de bogmærkede oplæg, det paper der bliver ved med at blive citeret. Ikke skimmet klokken 23. Læst ordentligt, i dagslys, som en del af dit normale arbejde.
-
Bag kulisserne. Kig på din kode, den linje du altid har skrevet men aldrig rigtig har forstået, og undersøg hvordan den virker. Hvordan beslutter garbage collectoren hvad der skal ryddes op? Hvad gør compileren ved den generic? Hvorfor ser API'et sådan ud? Viden om hvordan tingene virker akkumulerer.
-
Værktøjet du bliver ved med at høre om. Installer det. Giv det to timer og et rigtigt problem, ikke en tutorial. Som regel konkluderer du, at det ikke er noget for dig - og netop den konklusion er værd at have med til næste arkitekturdiskussion.
-
Bevidste eksperimenter. Et spike uden en tilknyttet opgave. Byg noget småt om eller prøv en alternativ tilgang for at opleve fordele og ulemper i praksis i stedet for at stole på et blogindlæg.
-
Dit eget fag. Hastigheden af forandringer falder ikke. At følge med skal ikke være et luksusprojekt, man betaler for med aftener og weekender. Det skal dækkes inden for arbejdstiden - det er nyt og værd at forsvare.
Den ærlige indvending
Nogle gange er fem parallelle jobs det rette. Der findes uger med stramme deadlines og kendt scope, hvor arbejdet er mekanisk, og hvor volumen er afgørende. Jeg argumenterer ikke for at du skal bo i et kloster.
Argumentet er imod, at det er standard. Parallelitet bør være en beslutning, du træffer af en grund - ikke noget, der sker automatisk, fordi ledige hænder føles ubehageligt, og det nemmeste middel mod ubehaget er at starte en agent til.
Der findes også en version, der peger i den modsatte retning: læsning som udsættelse, faner som hobby, læring der aldrig rører ved det, du leverer, tidsfordriv. Testen er enkel: ændrede det, du læste, noget du gjorde, argumenterede for eller afviste den følgende måned? Hvis ikke, underholdt du dig selv med ting der ikke var relevant for dit arbejde.
Det jeg bliver ved med at vende tilbage til
Vi brugte år på at sige, at vi ikke havde tid til at slibe saven, fordi vi var optaget af at save brænde. Den undskyldning holder ikke længere.
De udviklere, der får mest ud af denne tid, var ikke dem, der kørte flest agenter parallelt, men dem der endelig fik tid til at kigge i bunken.