Tre terminaler og en telefon

I juli sad jeg på en fortovscafé i Rom med telefonen i hånden. Hjemme på maskinen kørte tre Claude-sessioner. Jeg læste, hvad de havde lavet, sendte dem videre og bestilte en pizza mere.

Den uge gik der omkring 50 ændringer i produktion. Jeg skrev ikke en linje kode.

Det lyder som en flex, og der ligger en indrømmelse i det: jeg kan ikke selv skrive den kode. Jeg har ingen uddannelse i det. Jeg har været selvstændig siden 3.g, først med et marketingbureau for internationale e-com-kunder, så med mine egne webshops, og indtil januar i år havde jeg aldrig bygget software.

Hvad dagen faktisk består af

To til tre terminaler kørende ad gangen. De arbejder på hver sin del af systemet, så de ikke går i vejen for hinanden.

De tunge opgaver bliver sat i gang, inden jeg går i seng. Når jeg står op, ligger resultatet der. Det er den ene vane, der har flyttet mest, og den er også den mest banale: en model, der arbejder mens du sover, er otte timer, du ikke betaler for med din egen tid.

Mens de kører, læser jeg. X, YouTube, folk der finder ud af noget med de samme værktøjer og poster det. Halvdelen af det, jeg kan i dag, har jeg fra nogen, der beskrev deres eget setup, fordi de syntes det var sjovt.

Og så telefonen. Jeg styrer sessionerne derfra, når jeg ikke er ved skrivebordet. Det var det, der gjorde Rom-ugen mulig, og det er også det, der gør, at der ikke rigtig findes en fyraften.

Kontrollen flytter fra koden til resultatet

Der findes kode i det, jeg har bygget, som jeg ikke kan læse, fordi den er teknisk på en måde, jeg aldrig har lært. Når jeg ikke kan reviewe en diff, skal kontrollen ligge et andet sted.

Så den ligger på resultatet. Tre spørgsmål, hver gang:

Kan jeg gå ind i produktet og se, at det gør præcis det, jeg bad om? Findes der en test, der fejler, hvis nogen laver det om? Og var min beskrivelse præcis nok til, at en fejl overhovedet ville være synlig?

Det sidste spørgsmål er det, jeg bruger mest tid på nu. En upræcis specifikation giver kode, der gør noget upræcist, og modellen protesterer ikke undervejs. Den bygger glad det, du bad om. Du opdager det tre uger senere, når en bruger gør noget, du ikke havde tænkt på.

Hvor det går galt

Tre ting, som er sket, og som kommer til at ske igen.

Modellen gør præcis det, jeg bad om, og det jeg bad om var forkert. Det sker igen og igen, og det er min fejl hver gang.

To terminaler rører den samme fil. Så skal en af dem laves om, og den ved det ikke selv.

Og den ubehagelige: jeg accepterer noget, jeg ikke forstår, det virker, og tre uger senere holder det op med at virke. Nu skal jeg sætte mig ind i det under tidspres i stedet for i ro. Det er prisen ved at flytte kontrollen til resultatet, og jeg har endnu ikke fundet nogen måde at slippe for den.

Hvad det koster

Fire måneder med fjorten til seksten timers dage. Omkring en million linjer kode. Den 13. august klokken 23:41 mergede jeg 404 commits på én gang, efter halvandet døgns arbejde i træk.

Det er ikke en arbejdsform, jeg vil anbefale nogen, og jeg vil heller ikke lade som om, den var nødvendig. Den var et valg, jeg traf, fordi det pludselig var muligt at bygge noget, jeg havde troet lå uden for min rækkevidde, og jeg ville se hvor langt det kunne komme.

Rom-ugen er det eksempel, jeg selv vender tilbage til, fordi den viser grænsen tydeligt: jeg kunne følge med i, hvad der blev bygget, fra en telefon på en fortovscafé, og jeg kunne ikke have skrevet en eneste linje af det selv.