99 % begejstring, 1 % bekymring

Jeg sad og så en film en lørdag aften med min laptop åben på bordet ved siden af mig. Med jævne mellemrum kiggede jeg over, læste et par linjer og vendte tilbage til filmen. Claude Code, Anthropics terminalbaserede kodeagent, var i gang med at skrive hele frontenden i en af vores applikationer om fra Vue til React.

Ikke en komponent. Hele frontenden. Hver enkelt skærm applikationen har, hvilket er titusindvis af linjer.

Jeg havde givet den en snæver opgave og snævre rettigheder: byg et proof of concept, i sit eget hjørne, uden at røre noget, der betød noget. Ingen havde bedt mig om det. Det var noget, jeg ville vide svaret på.

Mandag viste jeg det til vores tech lead. Han blev oprigtigt begejstret, tog proof of conceptet ind i det rigtige repository, brugte en runde på at rydde op i fundamentet og sendte det i produktion. I løbet af en dag eller to blev den gamle frontend slukket.

GolfNext, hvor jeg arbejder, bygger den software, golfklubber kører på: booking og medlemskaber, selvbetjeningskioskerne der fungerer som reception, når ingen står bag skranken, og betalingsdelen ude på driving rangen, altså træningsbanen, hvor man betaler for en spand bolde og slår dem af. Jeg havde været der fire uger. Den applikation, jeg skrev om, er en, klubpersonalet sidder i hele dagen — så når den går ned, står der en på en klub ved en skranke med en kunde foran sig.

Før det tilbragte jeg år i en væsentligt større virksomhed, og det er stort set hele pointen.

En virksomhed lod en medarbejder med fire uger på kontoen erstatte en frontend, som personalet bruger, med sit weekendeksperiment — inden for en uge. Det er den del, jeg stadig synes er overraskende, og AI’en er det mindste af det.

Hvorfor skrive noget om overhovedet

Eftersom resten af dette indlæg bruger en del plads på, hvorfor gode idéer går i stå andre steder, er det kun rimeligt at lægge begrundelsen for denne her frem med det samme.

Det er ikke, fordi React er bedre end Vue. Vores mobilapps er allerede React Native, og hvis den desktopapplikation vi leverer på et tidspunkt flytter over på en webflade, ville React være det ene framework bag hver eneste frontend i GolfNext, web som desktop. Ét sæt idiomer i stedet for to, ét dependency-træ og ét svar på et spørgsmål frem for to, der hver især kun passer halvt.

Den anden grund er mindre flatterende at tale om og betyder mere i det daglige: kodeagenter er mærkbart bedre til React end til Vue. Der findes langt mere React i verden, så langt mere af det er gået ind i træningen. Hvis vi skal bygge software på den måde, vi bygger den nu, er der et argument for at stå der, hvor værktøjerne er stærkest.

Hvad der var sket på mit forrige job

Ingenting, eller tæt på. Men ikke af den grund, man nok ville gætte på.

Mit forrige job var en stor virksomhed, og jeg vil være fair over for den: den var ikke ved at drukne i bureaukrati. Der var ikke et vildnis af udvalg, en idé skulle igennem. Hvad der til gengæld var, var et lille antal seniorudviklere, som havde været der meget længe, sad på de fleste beslutninger og var godt tilfredse med tingene, som de allerede var.

Ingenting behøvede at blive formelt afvist, og for det meste blev ingenting det. Et forslag skulle bare undlade at vække interesse hos de to eller tre personer, hvis opbakning det krævede, og så skete det stille og roligt ikke. Det er en hårdere mur end en proces, for en proces fortæller dig i det mindste, hvad det næste skridt er.

Deployment-historien havde samme form. Releases var i høj grad manuelle, og evnen til at lave en — sammen med den adgang, man skulle have for at kunne undersøge noget, når det gik skævt — lå hos en håndfuld mennesker. Var man ikke en af dem, stoppede ens arbejde det sted, hvor det krævede noget, kun de kunne gøre, og så ventede det. Ikke af ond vilje. Det var sådan, rettighederne havde lagt sig gennem årene, og ingen, hvis dag det gjorde lettere, havde nogen grund til at ændre det.

Så den ærlige version af kontrasten handler ikke om hastighed. Den handler om, hvor meget af det, man allerede kan, man faktisk har lov til at gøre. Hos GolfNext var den, der gennemgik mit weekendeksperiment, også den, der kunne sende det i produktion. Der hvor jeg arbejdede før, ville det have været to forskellige personer og en kø.

Hvordan en idé får et ja her

To veje, og ingen af dem har et godkendelsestrin.

Den første er en samtale. Nogen siger tingen højt, de der er i rummet er enige om, at den er værd at lave, og så bliver den lavet. Intet dokument. Den anden er en opgave i vores tracker, som er det samme med en titel og en ansvarlig, så den ikke bliver glemt.

Der er ingen tredje vej, hvor idéen tager af sted for at blive evalueret. Værd at være præcis omkring, hvad det betyder og ikke betyder: den port, vi ikke har, er den der afgør, om en idé må prøves. Code review og releaseprocessen ligger præcis, hvor man ville forvente.

De fleste af idéerne kommer fra vores stifter, som startede virksomheden i 2012. Han har flere af dem på en uge, end teamet kan bygge på en måned, hvilket nemt kunne være udmattende og for det meste ikke er det, fordi strømmen går i begge retninger, og en idé fra en udvikler får samme modtagelse som hans. Jeg har budt ind med flere, siden jeg startede, og ikke én af dem fik den behandling, jeg havde spændt op til.

Vores tech lead skrev noget, der lå tæt på det her, på denne blog to uger inde i sit eget job — han var mødt op med paraderne oppe efter modstand og fandt næsten ingen. Fire uger inde, fra en anden stol, vil jeg sige det samme. Forskellen er, at jeg nu har en historie, der er konkret nok at være uenig i.

Modtagelsen er heller ikke bare en godkendelse, og det er den del, jeg ikke havde regnet med. Vis noget til vores stifter, vores produktchef eller vores direktør, og inden for et minut sidder en af dem og bygger videre på det højt: hvad der kunne ligge oven på det, hvad det ellers kunne bruges til, hvor værdien for virksomheden i virkeligheden ville lande. Man kommer ind med én ting, man har lavet, og går ud med tre ting, den kunne blive til. Det er en god fornemmelse, og det er også en grund til at møde forberedt op: en idé her vokser i det øjeblik, man viser den, så det betaler sig at have tænkt over, hvor den kunne føre hen, før nogen anden gør det.

Hastigheden er den del, jeg stadig ikke har vænnet mig til. Nogle gange er en idé fra formiddagen live inden for fireogtyve timer. Andre gange tager det to uger. Det er sjældent et kvartal.

Den del, jeg ikke vil løbe let hen over

“En AI skrev en frontend, som personalet bruger, om, og vi sendte den i produktion to dage senere” er enten godt ingeniørarbejde eller en historie, der ender skidt.

Så her er detaljerne.

Agenten kunne oprette, og det var det hele: ingen ændring eller sletning af noget, der allerede fandtes, og alt af det ude i sit eget hjørne. Intet af det, den lavede, var én merge fra en golfklubs mandag morgen.

Derefter læste et menneske det igennem. Vores tech lead klikkede sig gennem hvert enkelt view — der er ikke så mange, tyve eller tredive med nogle formularer og modaler, en halv times klikkeri — og konklusionen var, at det så godt nok ud til at erstatte den gamle applikation uden at ødelægge noget. Hvad han ikke havde, var års historie med kodebasen; han havde været der omtrent lige så længe som mig. Så reviewet var ikke institutionel hukommelse. Det var nogen, der ved, hvordan en sund React-kodebase ser ud, der læste denne igennem, før den kom i nærheden af en klub.

Der, hvor han til gengæld brugte tiden, var fundamentet frem for opførslen: at få udtrykket tættere på den applikation, vi erstattede, få Biome ind, få styr på hvordan mapper og filer navngives, og at skille de steder ad, hvor agenten havde stablet halvtreds Tailwind-klasser på en enkelt div — omstruktureret, og derefter en linting-regel, så det ikke kan komme igen. Et menneske skal fortsat kunne læse tingen. Det er det arbejde, der gør det forsvarligt at bygge funktionalitet oven på, i stedet for at sætte næste etage på noget, der allerede læner sig som tårnet i Pisa.

Det review er den egentlige sikkerhedsmekanisme i den her historie, ikke modellen og ikke min prompt. Og ikke testene, for denne frontend har aldrig haft nogen særlig testsuite. Det var allerede sandt før omskrivningen. Omskrivningen gjorde det bare vigtigere.

Det var også kun frontend. Samme API, samme data, intet rørt på betalingsvejen.

Hvad vi ikke har, er en gradvis udrulning, og det har denne blog allerede indrømmet: vores kunder er fysiske steder, så den første ring er geografi, og hvis en release går skævt på en klub i nærheden, er redningsplanen tyve minutter i bil. Det er et reelt sikkerhedsnet, og jeg vil ikke kalde det en canary-deployment.

Det, jeg stadig bærer rundt på, er, at ingen har læst hver linje af den kode, som man læser kode, man selv har tastet. En omskrivning, der ser færdig ud, er det mest flatterende output en agent laver, for hullerne er udeladelser snarere end fejl, og en udeladelse dukker ikke op i en demo. Jeg regner med at blive ved med at finde dem et stykke tid endnu. Indtil videre er der ikke gået noget i stykker ude på en klub.

Planen, weekenden hørte til

Ingen havde bedt om den omskrivning. Det var den første del af noget længere, jeg havde skitseret, og det der afgjorde timingen var banalt: jeg kiggede på, hvor meget af min Claude Code-kvote der var tilbage for måneden. Ubrugte tokens bliver ikke overført. Kapacitet, jeg ikke havde brugt, var kapacitet GolfNext allerede havde betalt for, og at bruge den kostede virksomheden ingenting.

Så jeg brugte den. Hen over den periode startede jeg proofs of concept for de fleste af vores applikationer, alle i ét sprog med én kodestruktur, for at finde ud af, hvordan en samlet stack faktisk ville se ud i stedet for at diskutere det i det abstrakte. Præcis én af dem, React-frontenden, er nået i produktion. Resten er stadig proofs of concept, og det vil jeg hellere sige lige ud end lade det her læse som en migrering, der allerede er sket.

Vi kører to administrationsportaler, hver med sin egen backend og sit eget login. De tjener forskellige formål, men der er ingen god grund til, at de er separate applikationer, og jeg ved oprigtigt ikke, hvorfor de blev bygget sådan — det ligger år før min tid. Hvad jeg ved, er, at alle udviklere her og alle i ledelsen er enige om, at der kun bør være én. Prisen for at have to lander på dem, der bruger dem: klubpersonalet logger ind to gange.

Planen er at ende med én. Først en auth-bro, så ét sæt loginoplysninger virker på tværs af begge. Dernæst selve sammenlægningen: én frontend og én navigation, med begge backends stadig kørende bagved. Først derefter backenden, hvor de to services erstattes af én, så der er ét sprog og én kodestruktur under hele portalen i stedet for to af hver.

Der er en grund til, at den vej er værd at gå nu frem for om to år. Ambitionsniveauet her er ikke beskedent. Vi er i atten lande i dag, planen omfatter en hel del flere, og en hel del flere brugere bag dem. Meget af det kommer gennem integrationer: hver klub kører allerede et eller andet administrationssystem, og vores position er at arbejde sammen med det, de har, frem for at bede dem om at smide det ud. Hver enkelt af dem er endnu et system at tale med og endnu et sæt antagelser at holde styr på.

To portaler, to backends og to autentificeringsordninger er til at leve med i den størrelse, vi har nu. Det er præcis den slags, der holder op med at være til at leve med, når det går godt. Så argumentet for at lave det ucharmerende strukturelle arbejde er, at der stadig er luft til at lave det, og det er også derfor, “lad os samle stacken” bliver mødt med begejstring her frem for et krav om at retfærdiggøre det. Alle ved godt, hvad der er på vej.

Det er en lang vej snarere end en sprint, og det meste af den er ikke sket endnu. At få frontenden over på React var forarbejdet til det hele, det der skulle være på plads, før nogen af de trin kunne begynde, og derfor var det netop det eksperiment, jeg valgte en lørdag aften. Trin to var at vise hele planen til de mennesker, der skulle leve i den.

Hvor de 1 % blev af

Vores tech lead trak i samme retning og ville have resten af vores frontends over på React. Ledelsens reaktion på hele pakken — portalerne, backenden, frontendene — var, i runde tal, 99 % begejstring og 1 % bekymring.

Jeg vil være præcis omkring den 1 %, for den var ikke, hvad jeg havde forventet. Jeg havde spændt op til omkostninger eller risiko for kunderne. Hvad de var bekymrede for, var, hvordan de nuværende udviklere ville have det med det.

Det er mennesker, der har bygget denne software i årevis, i en stack de selv har valgt, og to af os — begge omkring en måned inde ad døren — foreslog at ændre den. Det er den rigtige ting at være bekymret for, og det er den bekymring, der aldrig optræder i et estimat.

Så vi holdt en brainstorm med teamet og holdt vores egne holdninger tilbage, indtil alle andre havde talt.

Det er sværere, end det lyder. Vi havde allerede vores forslag skrevet ned. Hver gang nogen bevægede sig i retning af det, var det fristende at hoppe ind og give dem ret, hvilket ville have afsluttet diskussionen og gjort alt derefter til samtykke i stedet for input.

Da vi endelig lagde vores på bordet, var der ingen, der var uenige. Sammenlægningen af portalerne og det, der følger efter, var de decideret begejstrede for. Selve React-standardiseringen var de bare fine med, og det er den mest interessante halvdel af sætningen: det er den del, der erstatter den stack, de selv havde valgt, og “fine med” forekommer mig en helt rimelig ting at føle omkring det. Ingenting i forslaget blev ændret som følge af mødet, hvilket er den mindst tilfredsstillende måde, et møde kan gå godt på, og det vil jeg hellere fortælle end pynte på. Vi arbejder i den retning nu.

Begejstring fra ledelsen er nem at komme til her. Det er en feature, og det er det meste af grunden til, at de fireogtyve timers omløbstid overhovedet findes. Begejstring fra de mennesker, der skal leve i koden hver dag, er den, man skal gøre sig fortjent til, og den eneste pålidelige måde, jeg kender til at gøre det, er at holde sin mund i den første halvdel af mødet.

Begejstring kræver disciplin

Jeg vil ikke efterlade det her som et indlæg om, hvor rart det er hos os, så lad mig sige, hvad miljøet faktisk kræver, for det er ikke ingenting.

Et sted, der siger ja inden for fireogtyve timer, virker kun, hvis det, man lægger frem, fortjener et ja inden for fireogtyve timer. Ingen af forslagene i dette indlæg blev skitseret i det møde, hvor de blev præsenteret. Vores tech lead og jeg har brugt mange timer sammen på planer og arkitektur og gennemgået dem grundigt, før nogen andre så dem, og hver især læste vi op på det først. De fleste idéer, jeg har bragt frem her, var undersøgt, før de blev præsenteret — ikke undervejs i diskussionen.

Weekendens proof of concept er det tydeligste eksempel. Formålet var ikke at producere kode. Det var at tage den mest risikable antagelse i en plan og få den afklaret, før nogen blev bedt om at binde sig til planen. Det er forberedelse forklædt som en hobby.

Det er den del, jeg gerne vil understrege for enhver, der tror, at en begejstret kultur lyder behagelig. Når der ikke er nogen gatekeeper, du skal overbevise, er der heller ingen, der kontrollerer din tankegang for dig. Den grundighed, en proces ville have påtvunget dig, skal komme fra dig selv i stedet, og den skal være der før mødet frem for efter. Begejstring sænker ikke barren for professionalisme. Den flytter barren over på dig.

Og det gør det her til en særlig slags arbejdsplads snarere end en entydigt bedre en. Er man ambitiøs og kan man godt lide at lave forarbejdet ordentligt, er det det bedste miljø, jeg har arbejdet i — hvad man kan nå, er afgrænset af ens egen tænkning frem for af nogens godkendelseskø. Vil man hellere have en proces, der fortæller, hvad der er det næste, og et udvalg til at dele vægten af at have taget fejl, tror jeg, man ville synes, det var ubehageligt.

Hvis du overvejer et sted som det her: det hurtigste ved GolfNext er ikke værktøjerne eller agenterne. Det er afstanden mellem at få en idé og at få lov til at prøve den.

Man skal godt nok passe på, hvad man tænker på en lørdag aften. Det kan være i produktion tirsdag.