Alle indlæg · build.golfnext.com

Slet opsætningsguiden

Johann Böhler — Thu, 27 Aug 2026 00:00:00 +0000

Tænk på sidste gang du klonede et repository, du aldrig havde arbejdet i før.

Du læste README’en. Den bad dig installere en JDK, og du havde den forkerte, så du gik ud og fandt den rigtige. Den bad dig installere Node, og versionsfilen sagde 18, mens lockfilen tydeligvis ville have 20. Et sted nede i bunden stod der cp .env.example .env og så, med mindre skrift, udfyld værdierne. Udfyld dem hvorfra? Fra en kollega. Så du spurgte på Slack, nogen indsatte en blok KEY=value-linjer til dig, og nu ligger et produktionsnært login i en chathistorik for altid: søgbart, backet op, eksporteret til hvilket compliance-værktøj virksomheden nu købte sidste år.

Ingen har sat sig for at bygge det. Det er, hvad der sker, når instruktionerne bor i et dokument i stedet for i repoet.

Jeg er tech lead hos GolfNext, en dansk virksomhed der bygger software til golfklubber, og mit første indlæg på denne blog var en opgørelse over, hvad jeg var trådt ind i. Otteogtres repositories, fire produktlinjer, tretten års akkumulerede teknologivalg: Java og Maven og Spring, Kotlin og Gradle, Node, Python, PHP, JavaFX, React Native. At komme i gang i et af dem fra kold start tog mellem to og seks timer afhængigt af, hvilket man valgte, og jeg satte mig selv et mål om fem minutter fra klon til kørende kode.

Det her er det første seriøse forsøg på det. To værktøjer, begge fra samme person, jdx. mise lægger de rigtige værktøjer på din PATH, fnox lægger de rigtige hemmeligheder i dit miljø, og det er de to halvdele af ét problem. mise er kedeligt og bredt anvendt. fnox er ingen af delene endnu, og det vender jeg tilbage til. Det interessante er, hvad der falder væk, når begge er på plads, og hvad det gør ved de kodeagenter, jeg har kørende i de her repositories hele dagen.

Det er mise som i mise en place, det fra køkkenet. Udtales “meez”, /miːz/, én stavelse, uden -uh til sidst. Det vil du gerne have styr på, inden du siger det højt til et møde. fnox er nemmere: Fort Knox med de fleste bogstaver banket af, altså “eff-nox”, og navnet fortæller dig, hvad det er til.

Halvdel et: værktøjerne

Har du brugt nvm eller pyenv, kender du formen: erklær en version, cd ind, få den version. Forskellen er, at mise er ligeglad med, hvad versionen er af.

# .mise.toml
[tools]
java = "21"
maven = "latest"
node = "lts"
python = "latest"
gitleaks = "latest"

Det er en JVM, et build-værktøj, en JavaScript-runtime, en Python og en hemmelighedsscanner (gitleaks) i én fil, installeret med én kommando, på din PATH kun inde i dette katalogtræ. Tilføj mise activate til din shell-profil, og selv kommandoen forsvinder: cd ind i repoet, og værktøjerne er der, cd ud, og det er de ikke. Den sætter også de miljøvariable, der hører til, så JAVA_HOME peger på den JDK, dette projekt har fastlåst, i stedet for hvad dit styresystem sidst besluttede.

“Versionsstyring” underspiller det her, og jeg vil gerne være konkret om hvorfor. Det dyre ved en polyglot kodebase er skiftet, ikke den enkelte teknologi. Du bruger en formiddag i en Spring-service, hopper så til et Android-repo, så et lille Python-værktøj, og hvert hop er en chance for, at din shell er forkert på en måde, der giver en forvirrende fejl frem for en tydelig. I et af vores repositories fejler en nyere system-JDK ikke højlydt. Den ødelægger et mocking-bibliotek under test, adskillige lag nede, med en besked der intet har med Java-versioner at gøre. Det er en time af nogens liv, og du betaler den igen, hver gang en ny person starter, eller en computer bliver skiftet ud.

Et sprogspecifikt værktøj kan ikke hjælpe, fordi problemet ligger mellem sprogene.

En detalje, du lige så godt kan stjæle som opdage selv. Vi lader bevidst nogle af versionerne flyde: latest til scanneren, lts til Node. Hvad et build er lavet af, er fastlåst i CI-workflowet, og det er den fastlåsning, dependency-automatikken holder øje med og laver pull requests på. Fastlåste vi de samme versioner i .mise.toml også, ville vi have to steder at holde i sync, og det ene ville stille og roligt sakke bagud. Det ved vi, fordi det allerede var sket: en .mise.toml der påstod Node 22, mens alle fire workflows sagde 24. Kun én fil får lov at være den autoritative, og det er workflowet.

JDK’en er undtagelsen, fastlåst hårdt begge steder med vilje. En forkert major-version dér er præcis den mocking-fejl ovenfor, og jeg holder hellere to filer i sync end genopdager den fejl klokken fire om eftermiddagen. Alt andet flyder.

Den del, jeg ikke havde regnet med at holde af

Ethvert repository har en håndfuld ting, man gør ved det: bygger det, tester det, kører det, formaterer det. I et Maven-projekt er det mvn spring-boot:run -Dspring-boot.run.profiles=local. I et Gradle-projekt er det ./gradlew og et task-navn med fire ord klistret sammen. I et Node-projekt er det, hvad scripts-blokken nu siger i denne uge. Intet af det er svært. Alt af det er noget, man skal slå op, når man er i et ukendt repo, hvilket er præcis dér, hvor man har mindst tålmodighed til at slå noget op.

mise lader dig lægge de udsagnsord i samme fil som værktøjerne:

[tasks.build]
description = "Package the artifact"
run = "mvn clean package -B"

[tasks.test]
description = "Full test suite (integration tests need Docker)"
run = "mvn clean test -B"

[tasks.serve]
description = "Run the API on http://127.0.0.1:5001 (starts the stack first)"
depends = ["stack:up"]
run = "mvn spring-boot:run -Dspring-boot.run.profiles=local"

[tasks."stack:up"]
description = "Start the local database and the mocks. Idempotent"
run = "docker compose up -d --wait"

Så bliver grænsefladen mise run build, mise run test, mise run serve. I Android-repoet ved siden af ligger de samme udsagnsord oven på Gradle i stedet, og et af dem pakker et task-navn på fire ord, jeg stadig ikke kan skrive udenad. Lige meget. mise tasks viser, hvad et repository kan, med beskrivelser, og svaret ligger i repoet frem for på en wiki-side, der holdt op med at være sand i 2023.

To små konventioner har gjort sig fortjent. Et bart udsagnsord er det almindelige tilfælde, og verb:qualifier indsnævrer det: test og test:signer, stack:up og stack:down og stack:clean. Der er også altid en nødudgang, som pakker det underliggende build-værktøj direkte, så alt, den kuraterede liste ikke dækker, stadig er én kommando væk:

[tasks.mvn]
description = "Any Maven command, with this repo's JDK and environment"
run = "mvn"

Den nødudgang får betydning i anden halvdel af historien.

Halvdel to: hemmelighederne

Det her er den del, jeg faktisk ville til livs.

.env.example-mønstret er så udbredt, at det læses som best practice. Det er en konvention, der gav op. Se på, hvad den beder et team om.

En ny udvikler kopierer en fil med tomme nøgler og skal så skaffe rigtige værdier fra et sted, repoet ikke kan fortælle dem om. I praksis betyder det en person, hvilket betyder en chatbesked, og nu findes en hemmelighed i endnu et system med andre opbevaringsregler og anden adgangsstyring end det, man med vilje havde valgt. Når en værdi roteres, er enhver computer med den gamle stille og roligt forkert, indtil nogen opdager det, og fejlen dukker som regel op som en forvirrende 401 frem for en besked der siger “dit login er fire måneder gammelt”. Når en ny hemmelighed tilføjes, er alle andres .env ufuldstændig, og ingen får det at vide. Og filen selv ligger i dit arbejdskatalog i klartekst, ét uheldigt git add -A fra at blive committet, hvilket er grunden til, at ethvert repository med dette mønster også har en .gitignore-linje, nogen kunne slette.

Alternativet er ikke kompliceret. Læg værdierne i et hemmelighedslager, du allerede stoler på, læg referencer til dem i repoet, og lad den enkelte udviklers egen identitet afgøre, om de kan slås op.

Det er fnox. Her er stage-konfigurationen for en service, committet, uden værdier nogen steder:

# fnox.stage.toml
env = "exec"

[providers]
store = { type = "…", prefix = "/apps/checkout/stage/" }

[secrets]
DB_PASSWORD    = { provider = "store", value = "DB_PASSWORD",    if_missing = "error" }
PAYMENT_API_KEY = { provider = "store", value = "PAYMENT_API_KEY", if_missing = "error" }
SIGNING_KEY    = { provider = "store", value = "SIGNING_KEY",    if_missing = "error" }

type er den eneste linje, der er specifik for dig, og jeg har ladet den stå tom med vilje, fordi hvilket lager man bruger, er den mindst interessante beslutning i hele opsætningen. fnox taler med Vault, 1Password, SOPS og de store cloud-udbyderes egne hemmelighedslagre. Vi tog det, vores udbyder allerede gav os, af den kedelige grund at vi betalte for det, og det allerede havde en adgangsstyring, vi stolede på. Alt andet i filen er det samme, uanset hvad man vælger.

Hvad den fil køber:

Repoet dokumenterer sine egne hemmeligheder. Hvert navn, en service har brug for, står ét sted, i git, med reviewhistorik. Ny hemmelighed? Den står i filen, den kommer med git pull, og næste kørsel finder den enten eller fejler højlydt på grund af det if_missing = "error". Ingen skal have noget at vide.

Rotation holder op med at være en begivenhed. Skift værdien i lageret; enhver maskine samler den op ved næste kørsel. Der er ingen flåde af forældede kopier.

Adgang bliver igen et autorisationsspørgsmål. Om du kan køre mod et givent miljø, afgøres af din identitet i hemmelighedslageret, ikke af om nogen huskede at sende dig en fil. At fjerne nogens adgang bliver en rettighedsændring i stedet for et håb om, at de sletter en fil.

Og der er en tørkørsel. fnox check fortæller dig, om hver erklæret hemmelighed kan slås op af dig, uden at udskrive nogen af dem. Det er det hurtigst mulige svar på “er det mig eller er det i stykker”, hvilket er det spørgsmål, der æder onboarding-dage.

Så én bevidst tilbageholdenhed. Den env = "exec"-linje betyder, at hemmeligheder aldrig injiceres i en interaktiv shell, kun i miljøet for en underproces, fnox starter. fnox vil med glæde gøre det modsatte; der findes en tilstand, som lægger alt ind i din shell i det øjeblik, du træder ind i kataloget. Vi bruger den ikke. Jeg vil ikke have, at enhver proces startet fra det katalog arver produktionsnære credentials, og det gælder også editorer, og det gælder de kodeagenter, jeg har kørende derinde det meste af dagen. At begrænse hemmeligheder til fnox exec -- er hele forskellen mellem “buildet kan se signeringsnøglen” og “alt på min maskine kan se signeringsnøglen”.

Netop den del havde jeg undervurderet. Med intet på disken og intet i shellen findes en hemmelighed kun inde i en proces, som noget bevidst har startet, hvilket gør “hvad kan agenten nå” til en helt almindelig rettighedsbeslutning. Nægt den fnox og den håndfuld tasks, der kalder det, tillad den alt andet, og den kan læse hele repoet, bygge, teste og formatere, uden at en credential nogensinde havner i dens kontekst.

Så hullet, som jeg hellere selv vil sætte navn på, end at få det gjort for mig. fnox læser lageret som mig, med credentials der ligger på min maskine alligevel. En agent med en shell har slet ikke brug for fnox; den kan spørge lageret med udbyderens egen CLI. At nægte fnox alene lukker hoveddøren i en bygning uden vægge. Det, der gør det egentlige arbejde, er, at den samme tilladelsesliste heller ikke indeholder den CLI, og at det, der er inden for rækkevidde fra en udviklermaskine, er stage frem for produktion. En agent, der kan redigere .mise.toml, kan også skrive sig selv en task, der kalder hvad som helst. Nægtelsen er et hegn, ikke et bevis.

Men hold det op mod det, den erstatter: en .env-fil i arbejdskataloget i klartekst, læsbar for alt, der kan kalde cat, hvilket er enhver agent, nogen nogensinde har kørt. Injektion udelukkende ved kørsel plus en nægtelsesregel er, så vidt jeg kan se, omtrent så godt, som det bliver lige nu.

Hvor de to halvdele mødes

Hver for sig er det to udmærkede værktøjer. Sammen fjerner de en hel kategori af manuelle skridt.

Fordi mise-tasks bare er kommandoer, kan en task være fnox exec -- noget:

[tasks.gradle]
description = "The escape hatch from earlier, now with the build secrets loaded"
run = "fnox exec -- ./gradlew"

[tasks.secrets]
description = "Check that every build secret resolves for you"
run = "fnox check"

[tasks."serve:stage"]
description = "Run locally against stage secrets (needs cloud access)"
depends = ["stack:up"]
run = "fnox -c fnox.stage.toml exec -- mvn spring-boot:run"

Nu er mise run gradle :app:assembleRelease et signeret release-build, og den, der kører det, skriver aldrig ordet fnox, lærer aldrig hvilke af buildets input der er hemmelige, og har aldrig en kopi af nogen af dem. Ingen skal huske, hvilke kommandoer der kræver hemmeligheder. Det gør tasken.

Der ligger også en til dem, der lever i en IDE:

[tasks.ide]
description = "Launch the IDE with the build secrets in its environment (macOS)"
run = 'fnox exec -- open -na "Android Studio" --args "$PWD"'

En IDE ved intet om noget af det her, så et build startet indefra den kan ikke signere. Start IDE’en gennem fnox, og dens Gradle arver miljøet. Det er én linje, og den er forskellen på et fungerende release-build og en signeringsfejl, ingen kan forklare, så den bliver i filen. Jeg griber ikke selv ud efter den ret tit: det meste af min dag er en terminal, en prompt og en agent, der skriver. Det er en præference, ikke en anbefaling, og tasken ligger der til den, der vil det modsatte.

Så er der opdelingen efter miljø. Én fil hver, de samme variabelnavne i dem alle, forskellige værdier bag navnene:

fnox.toml         # local
fnox.stage.toml   # stage
fnox.prod.toml    # production

En task peger på den fil, den har brug for. Alt, der hører til et miljø, ligger i det miljøs fil, så ingen kan komme til at parre stage-credentials med lokale indstillinger.

Den lokale er den fil, jeg ville pege på, hvis du kun læste én. Den erklærer næsten ingen hemmeligheder, fordi alt, hvad en lokal kørsel har brug for, allerede har en harmløs standardværdi committet i repoet: en lokal database, en mock foran alt eksternt, åbenlyst falske nøgler til de betalte tjenester. En frisk klon booter og svarer for en, der slet ikke har adgang til hemmelighedslageret, og alt, der ville nå en rigtig udbyder, fejler autentificering frem for at gøre noget dyrt. Adgang køber dig stage. Det er ikke prisen for at komme ind.

At committe referencer betyder at scanne efter værdier

At committe referencer til hemmeligheder virker kun, hvis du er sikker på, at intet ægte nogensinde smutter med. Så den samme opsætning bærer en scanner rundt, og mise installerer den, uden at nogen bliver bedt om det:

[tools]
gitleaks = "latest"

[hooks]
postinstall = "git config core.hooksPath .githooks"

mise trust er det første, nogen kører, og den første mise run derefter installerer værktøjskæden, hvilket også er det, der udløser postinstall-hooket og peger git på et katalog med en pre-commit-scanning. Den kommer som en sidegevinst ved det skridt, de alligevel skulle tage, frem for som en separat instruktion, folk springer over.

Hooket scanner kun staged indhold, så det er hurtigt, og hvis mise ikke er på PATH, springer det over med en høj advarsel i stedet for at fejle. En grafisk git-klients miljø er ofte minimalt, og at blokere nogens commit på grund af et PATH-problem er en god måde at lære dem at bruge --no-verify for altid. CI scanner de samme commits igen efter push.

Og deployments

Folk går som regel ud fra, at netop denne del virker anderledes, end den gør.

Vores deployede miljøer kører ikke fnox. Platformen, de kører på, læser selv de samme værdier fra det samme lager og giver dem til processen som ganske almindelige miljøvariable. Ingen applikationskode ved noget om det. Intet i runtimen importerer et bibliotek, og intet build skal have at vide, hvilket miljø det er til.

Det er med vilje. Lageret er sandheden. fnox er, hvordan et menneske læser den sandhed, med sine egne credentials, på sin egen maskine, og deploymentet læser samme sandhed med maskinens identitet. De to kan ikke komme fra hinanden, og applikationen ser på begge sider bare miljøvariable, som den altid har gjort.

Hvad det ikke løser

Den ærlige version, så.

Du skal stadig installere mise og lægge mise activate i din shell-profil. Det er et rigtigt opsætningsskridt, og det vil jeg ikke lade som om ikke findes. Det er ét skridt, det er det samme skridt i alle otteogtres repositories, og det bliver aldrig forældet, hvilket er tre ting, det afsnit det erstattede ikke kunne sige.

Docker er stadig dit eget. mise installerer værktøjer, ikke dæmoner. Vores lokale stacks kræver containere, og førstegangsoplevelsen for enhver uden Docker sat op er stadig et manuelt skridt og en download målt i gigabyte. Det samme gælder Xcode, som fortsat er sit eget vejrsystem.

At få værktøjskæden rigtigt fjerner den dumme del af en koldstart. Det gør intet ved den svære del, som er at forstå, hvad servicen egentlig laver. Det er stadig at læse kode, og det tager stadig dage.

Du lægger to afhængigheder oven i enhver udviklers hverdag. mise er modent og bredt anvendt. fnox er ungt. Vi har lagt rigtige arbejdsgange over i det, og går det i stå, står vi med en migrering. Jeg synes, det er et rimeligt væddemål: filen er deklarativ, værdierne ligger i et lager, vi ville beholde alligevel, og faldbacken er et shell-script, der læser de samme parametre. Men det er et væddemål, og at lade som om noget andet ville være uærligt.

Én linje i den konfiguration fortjener et grundigt review. fnox kan få besked på at køre en kommando, der logger dig ind i lageret, når din session er udløbet, hvilket er oprigtigt praktisk og samtidig betyder, at en committet konfigurationsfil nu bestemmer noget, der eksekverer på enhver reviewers computer. Læs den linje, som du ville læse et CI-workflow.

Der er også en fejltilstand med en vildledende besked. Peg udbyderen på den forkerte konto, og det, der kommer tilbage, er “not found”, hvilket læses som en manglende hemmelighed frem for en forkert identitet, og sender folk på jagt det helt forkerte sted. Begge vores filer bærer en kommentar, der siger præcis hvilken konto credentials skal slå op i.

Hvor vi faktisk er

To repositories helt på fnox. En håndfuld mere på mise. Tres og lidt til tilbage, hvoraf de fleste aldrig får brug for hemmelighedshalvdelen.

Jeg har ikke taget tid på det med et stopur, og jeg vil ikke opfinde et tal, jeg ikke har målt. Formen på svaret er alligevel klar nok. På en maskine, der har været igennem det her én gang før, med mise installeret og værktøjskæden i cachen og Docker kørende, er en klon til en svarende API under et minut. Rigeligt. Det, der er tilbage af de gamle to til seks timer, er alt sammen første-gang-på-denne-computer: at hente en JDK, trække images, installere mise selv. Den betaler man én gang frem for én gang per repository, og netop den anden del er hele forskellen fra, hvor vi startede.

I de repositories, hvor det her er landet, gik README’ens opsætningsafsnit fra en liste over ting at installere og et afsnit om at spørge en kollega ned til det her:

mise trust          # once, to allow this repository's config
mise run serve

To linjer, og den anden er den, du ville have alligevel. Den første er mise, der spørger, om du nu også stoler på en konfigurationsfil, som er ved at installere software og sætte miljøvariable, hvilket, i betragtning af at den fil nu kan køre kommandoer på din maskine, er en dialog jeg er glad for findes.

Mønstret generaliserer et godt stykke ud over vores egen teknologiske virkelighed, og derfor synes jeg, det er værd at skrive ned frem for at arkivere som en intern pligtopgave.

Slet så opsætningsguiden, for nu lyver den om, hvor meget arbejde der er.

Fire produkter, 68 repositories

Johann Böhler — Wed, 12 Aug 2026 00:00:00 +0000

Jeg startede hos GolfNext mandag den 3. august klokken 8:00. Jeg havde forestillet mig et stille kontor og tyve minutters ventetid. Størstedelen af teamet var der allerede og i godt humør. Jeg havde en cheesecake med, som vi spiste efter frokost, for jeg har været i Danmark længe nok til at vide, at det der med kage ikke rigtig er valgfrit.

Peter, der startede virksomheden i 2012, havde Claude åben, før jeg havde fundet mit skrivebord, og var i gang med de konti og rettigheder, jeg skulle bruge. En lille ting at lægge mærke til på en første morgen. Den fortalte mig mere end et onboarding-deck ville have gjort.

Det første indlæg på denne blog var et brev, jeg skrev til mig selv, før jeg havde skrevet under på noget, fyldt med forudsigelser om en virksomhed, jeg havde besøgt én gang. Her holder jeg det op mod det, der faktisk er her. Det meste af det følgende handler dog ikke om mig. Det er virksomheden, jeg gerne vil beskrive: hvad vi bygger, hvad der ligger under det efter tretten år, og hvad vi har tænkt os at gøre ved det.

Hvad GolfNext bygger

Hvis du aldrig har tænkt over, hvilken software en golfklub kører på, ser det sådan her ud. En klub er en lille virksomhed med flere kasketter på én gang. Der er en proshop, en driving range, medlemskaber, et bookingsystem og i stigende grad en simulator eller to. Bookingsystemet håndterer tee times, altså de starttider, hvor en gruppe er booket til at slå ud på første hul. Hele dagen i en klub er bygget op omkring det gitter.

Historisk kom hver af de kasketter som sin egen kasse, fra sin egen leverandør, med sin egen software vedhæftet. Køb automaten, få automatproducentens system, uanset om det passer til den måde, du driver din klub på.

Vores position er den modsatte. Jeres hardware og infrastruktur forbliver jeres, og I er frie til at vælge den software, der passer. Vi vil være åbne over for enhver integration, så uanset hvilket managementsystem en klub allerede bruger til sine tee times, er målet at spille sammen med det i stedet for at bede dem om at smide det ud. Frihed til at vælge, kraft til at forbinde.

Selvbetjeningskiosker. En digital reception, der kører døgnet rundt. Greenfee, udlejning og køb i proshoppen, uden at nogen skal stå bag en disk. Så vidt vi ved er den den eneste af sin slags i golf. En klub får færre bemandede timer og tjener fortsat penge uden for åbningstiden. En spiller får den samme bekvemmelighed, som vedkommende allerede har alle andre steder i sit liv.

Betaling på driving rangen. Betaling på rangen, der virker med alle mærker af boldautomater. Den kompatibilitet er produktet. Automaten tilhører klubben, eller den der solgte den til dem, og at kunne ligge oven på dem alle sammen er hele pointen. Kort, apps, wallets, pinkoder, med analytics bagved i realtid. Mange steder kører rangen stadig på kontanter, og det er her, efterspørgslen vokser hurtigst lige nu. Mere end 500 millioner bolde om året går igennem det. Det bliver til en hel del slicede slag.

Voucher-håndtering. Udstedelse, distribution og indløsning, alt sammen digitalt, fra en enkelt billet til en hel sponsorpakke.

Simulator-håndtering. Automatiseret adgangskontrol, så en simulator kun kører i en betalt session. Ikke mere tidstyveri, bedre udnyttelse.

Hvad det løber op i i dag: 400+ anlæg, 18 lande, 350.000+ aktive brugere. Grundlagt i Danmark i 2012 og stadig meget dansk, hvilket også er grunden til, at jeg gik hjem fra min første dag fast besluttet på at tage mit danske alvorligt.

Stakken, uden pynt

Otteogtres repositories. JavaFX på desktopsiden, PHP, Vue, React, React Native, Spring, Java, Kotlin. Det hele på AWS.

Skrevet ned på den måde ligner det ubeslutsomhed, og det er det ikke. Tretten år, fire produktlinjer, hardware ude i marken, og i det meste af den historie blev softwaren bygget af eksterne partnere, der var gode til deres arbejde. Hvert projekt valgte det, der gav mening den dag, det startede, og de fleste af de valg var fornuftige. Det, der aldrig skete, er, at nogen gik tilbage bagefter og fik valgene til at stemme overens.

Så, den ærlige tilstand, for jeg skrev i brevet, at jeg ville skrive den slags ned i stedet for at pudse det af.

En pæn del af de otteogtres repositories var ikke blevet rørt i årevis og blev aldrig arkiveret. Forks, spikes, engangsværktøjer, der overlevede deres formål. Jeg begyndte at arkivere i den første uge, langsomt, for de fleste af dem vidste jeg endnu ikke, hvad jeg kiggede på, og ikke at vide er en langt bedre grund til at lade noget være end til at slette det.

I koden kan man læse generationerne. Flere pakkestrukturer inden for det samme sprog, ingen af dem forkerte, alle sammen forskellige. En AGENTS.md skrevet til Codex og en CLAUDE.md skrevet til Claude, der ligger i det samme repository, beskriver det samme projekt og er uenige om det. En README.md, der dokumenterer en version af systemet, som ikke findes længere. En runtime, der gik end of life for et stykke tid siden og stadig kører. Og en release-proces, der er rigtig god for nogle af vores værktøjer og en snowflake for andre, hvor en del af den ligger i en pipeline og en del af den ligger i hovedet på nogen.

Sikkerhed ligger øverst i bunken. Af de niogtyve punkter om engineering practices, jeg har skrevet ned indtil videre, er fem markeret med høj prioritet, og alle fem handler om sikkerhed. Det er ikke en opdagelse om GolfNext specifikt. Det er sådan tretten års levering plejer at se ud alle steder, hvor ingen for nylig er blevet betalt for at gå og kigge efter.

Da jeg lavede en forudsigelse om det hele udefra, skylder jeg dig resultatet. Det ligger nogenlunde, hvor jeg regnede med, og det mener jeg som et fair udfald snarere end en klage. Det her er tretten års kontinuerlig levering fra folk, der sendte funktioner ud, som kunderne rent faktisk havde brug for, på deadlines, med de prioriteter de fik stukket i hånden. Man ville finde nogenlunde det samme billede i de fleste virksomheder på den alder, og jeg vil hellere være den, der rydder op, end den, der sukker over det. Den ene forudsigelse, der ramte præcist, var den kedelige: jeg gættede udefra på, at repoerne ville være underautomatiserede, og det er de. Det er min åbning.

Det, jeg tog fejl af

Jeg havde gjort mig klar til, at produkterne ville være det svage punkt. Virksomheder med en stak som vores har ofte “sendt-alligevel”-software ovenpå, den slags hvor man kan mærke deadlinen i brugerfladen.

Sådan er det ikke her. Produkterne er gode. Der er plads til forbedring i dem alle sammen, selvfølgelig. Men det, jeg bliver ved med at lægge mærke til i møder, er, at alle tænker fra kundens side først, også folk uden nogen teknisk baggrund overhovedet. Hvad oplever spilleren, der står ved kiosken klokken halv seks om morgenen. Hvad skal en klubmanager forklare et medlem, når noget går galt.

Det instinkt er svært at eftermontere i et team. Pakkestrukturer kan refaktoreres og README-filer kan skrives om, og begge dele er bare arbejde. At lære en gruppe mennesker at bekymre sig om personen i den anden ende er et problem af en helt anden slags, og det har vi ikke.

Det vi startede i uge to

To integrationer landede næsten med det samme, og de er det samme væddemål i forskelligt tøj. Platformen er kun åben, hvis den rent faktisk forbinder til de systemer, klubberne allerede kører.

teeControl er et managementsystem, som mange klubber bruger, og vi integrerer det, så det virker gennem vores kiosker. Førstehåndsindtrykket er godt. Førstehåndsindtryk er også billige, og der er et stykke vej herfra. Vi har brug for ordentlige testsystemer. Vi kommer sandsynligvis til at skulle justere nogle af vores egne flows, så de passer til deres. Der er stadig beslutninger, der skal falde på plads i begge ender. Det bliver en proces snarere end en sprint, og det siger jeg hellere nu end at skrive et triumferende indlæg om det i uge to.

Lightspeed er en spillervendt app, som vi gerne vil understøtte som betalingsmulighed. Peter havde allerede bygget en første version, før jeg kom, og at overtage den var min anledning til at få fingrene i rigtig kode her for første gang. Ti tusind linjer, læst fra ende til anden, og derefter kørt og rodet med, indtil jeg forstod, hvad den lavede. Det gav en liste af fejl og en stak opfølgende stories, hvilket er det, der kommer ud af at læse hvad som helst grundigt. Det mere nyttige resultat er, at den nu også ligger i mit hoved og ikke kun i hans.

Og Verifone-terminaler på skrivebordet, som er den jævnlige påmindelse om, at en stor del af vores software ender i en fysisk genstand, som nogen skal røre ved.

Den tilgang, John og jeg landede på, er at springe den store forudgående specifikation over. John er den anden udvikler, selvom det ikke yder ham retfærdighed, for han er lige så meget løsningsarkitekt og projektleder som ingeniør. Få en testinstans, byg op mod den, lad virkeligheden skrive dokumentationen. To uger inde kender jeg ikke systemerne godt nok til at skrive en god specifikation, og at lade som om ville bare producere et dokument, vi stille og roligt ville holde op med at læse i september.

En lille ting, der er værd at give videre til enhver, der overvejer at arbejde et sted som her. Jeg brugte mine første par dage på at være tålmodig omkring adgange, ud fra en antagelse om, at der var en proces, jeg skulle vente på. Så sagde jeg højt, at det her stort set var det, jeg var blevet ansat til, og om jeg måtte få dem nu. En halv time senere havde jeg AWS. Ventetiden var udelukkende min egen opfindelse.

Hvordan vi udruller

Det mest interessante problem i de første to uger lå ikke inde i et repository. Det var at finde ud af, hvordan ændringer kommer ud til kunderne.

Jeg brugte en fredag på ordentligt detektivarbejde. CloudWatch-logs på den ene skærm, et downloadet database-snapshot på den anden, og transaktionstilstande stillet op mod det, koden mener burde være sket. Et sted derinde fandt jeg fyrre commits, der aldrig var blevet pushet nogen steder. Det er den ucharmerende halvdel af at hente viden hjem. Adgange er den nemme del. At genopbygge en forståelse af, hvad systemet rent faktisk gør, tager meget længere tid.

Vi har ikke nogen gradvis udrulning i dag. Det, vi har, er kunder, der er fysiske steder, og en håndfuld af dem ligger en kort køretur fra kontoret. Så den første ring er geografi. Nogle få nærliggende klubber får den nye version først, og hvis det går galt, er redningsplanen tyve minutter i bil med en reserveterminal i bagagerummet. Det tog omkring fem minutters samtale at nå frem til, for når man først lægger mærke til, hvor kunderne er, er det et ret oplagt træk. Det er ikke det, jeg ville tegne på en tavle. Det er tilgængeligt i denne uge, og det køber tillid nok til at blive ved med at levere, mens det ordentlige bliver bygget.

At lære spillet og ordene for det

På dag tre spillede jeg den første golfrunde i mit liv, sammen med kolleger. Syv eller otte slag per hul. Aldrig ti. Vi mistede ikke en eneste bold hele runden, hvilket jeg får at vide er den mere imponerende statistik for en begynder. Ingen skrev en score ned.

Jeg vil anbefale den generelle version af det til enhver, der starter i en virksomhed, hvis domæne de ikke kender. Ikke golf specifikt. At gå ud og gøre det, softwaren handler om.

Ugen efter satte John og jeg os ned til det, der blev de mest nyttige to timer i uge to: at blive enige om, hvad vi kalder tingene, før tre systemer hver opfinder deres eget ord for det samme begreb. Ni huller er en loop. Stroke index rangerer hullerne efter sværhedsgrad. Der er rating category. Intet af det er eksotisk, hvis man spiller golf, og det er alt sammen usynligt for en udvikler, der aldrig har stået på et teested, hvilket for to uger siden var mig.

At få ordforrådet rigtigt tidligt koster næsten ingenting. At få det forkert koster dig tre services, tre navne for én ting og et oversættelseslag, ingen havde tænkt sig at bygge. Jeg kørte ét tjek, som jeg vil anbefale enhver, der gør det her: jeg fik Claude til at verificere “loop” på egen hånd, fordi det lugtede for mig af et ord, udviklere opfinder og derefter overbeviser sig selv om er domænesprog. Det kom tilbage som rigtig golf. At bruge modellen til at tjekke vores eget ordforråd, i stedet for til at skrive kode, er en af de bedre anvendelser, jeg har fundet til den indtil videre.

Niogtyve punkter, og hvor det her er på vej hen

Forbedringslisten ligger i ClickUp nu, mest så jeg kan holde op med at bære rundt på den i hovedet. Niogtyve punkter, alle stadig i backloggen, groft grupperet i repository-standarder og konventioner, sikkerhed og hemmeligheder, CI/CD og test og afhængigheder, infrastruktur og data, arkitekturretning, og AI og agenter.

Det første, vi rent faktisk har rullet ud, er det mindst spændende punkt på hele listen. mise, som fastlåser og installerer de rigtige sprogversioner per projekt, så man kloner et repo, og den korrekte Java dukker op af sig selv. Med så mange teknologier spredt over så mange repositories er den skat, man betaler hele dagen, at skifte mellem dem, og netop den skat kan undgås.

Målet har ikke ændret sig siden brevet. Byg et landskab, hvor kontekst er billig at samle op. Hvis en ny udvikler, eller en frisk AI-session, hurtigt kan forstå en service, kan arbejdet gå i gang med det samme, af hvem der end tager fat. Hvis de ikke kan, starter hver opgave med arkæologi. Alt på den liste med niogtyve punkter ligger nedstrøms af den ene sætning.

Scorekortet

Hvilket bringer mig tilbage til brevet og løftet om at rette mine egne opgaver offentligt.

Bliv ved tasterne. Holdt. To terminalrettelser sendt ud, pull requests reviewet, og jeg har overtaget ejerskabet af en af apps’ene. Jeg bygger stadig, hvilket var den betingelse, jeg satte, før jeg takkede ja til jobbet.

Genopbyg forståelsen, ikke bare adgangen. For det meste. CloudWatch-eftermiddagen, database-snapshottet, Lightspeed-overdragelsen: det er den rigtige form for arbejde. Det, jeg endnu ikke kan påstå, er at kunne frigive hvad som helst i stakken uden at spørge nogen.

Åbenhed i det åbne. Holdt, og lettere end jeg havde regnet med, mest fordi rummet her gør det let.

Nu den anden halvdel.

Mål nummer et skred. “Gør arbejdet synligt” stod øverst på listen, og denne blog var måden. Hvert eneste indlæg før det her blev skrevet, før jeg havde skrevet under på kontrakten, hvilket viser sig at være det nemmeste tidspunkt overhovedet at skrive om en virksomhed. Så startede jeg rent faktisk, og i to uger var der ting foran mig, der betød mere end et blogindlæg. Jeg vil ikke kalde det en krise. Jeg skrev, at hvis der blev stille, skulle jeg tage det som et advarselstegn, så: noteret.

Koldstarten er milevidt fra fem minutter. Jeg satte mig selv fem minutter fra klon til kørende kode og bad fremtidige mig om at tage tid på det. Jeg har ikke taget ordentligt tid på det, hvilket er sin egen lille fiasko. Jeg har klonet nok af de her repositories efterhånden til at give et fair skøn. Et sted mellem to og seks timer afhængigt af hvilket, man vælger, lad os sige fire i gennemsnit. At få iOS-buildet til at køre tog det meste af en dag med Xcode, pods og emulatorer. mise er det første rigtige skridt mod at lukke det hul, og et skridt er ikke et tal.

Det fælles AI-kit er punkt niogtyve ud af niogtyve, og den del er med vilje. I brevet kaldte jeg det den ting, der gør “AI-first” fra et slogan til rigtigt fælles værktøj. To uger inde kan jeg se, hvorfor det ikke kan komme først. Et fælles kit bygget oven på otteogtres inkonsistente repositories ville mest af alt bare indkode inkonsistensen. Fundament først, kit bagefter, og den rækkefølge vil jeg forsvare. Det, jeg ikke vil lade som om, er, at rækkefølgen er gratis. Indtil vi når dertil, får jeg en masse gearing ud af et setup, jeg har brugt et år på at finpudse, og som ingen andre her har endnu.

Og dagene åd pladsen til at tænke. Jeg skrev, at den kreative, legende tid ikke er en belønning, man optjener, når det seriøse arbejde er gjort, at den er det seriøse arbejde. To uger inde er det det første, kalenderen tager. Én ting hjælper her, og den er specifik for den her branche: golf er sæsonbetonet. Klubberne har travlt nu, så vi har travlt nu. Platformen bliver stille hen over vinteren, og det er der, værktøjskassen til 2027-sæsonen bliver bygget. At have en form på sit år er mere nyttigt, end jeg havde regnet med.

Det, jeg tog mest fejl af, er også det, jeg er gladest for. Jeg mødte op forberedt på modstand. Jeg regnede med at skulle gøre mig fortjent til adgange, argumentere for omfang og føre sag for hver eneste ændring. Næsten intet af det var der, og den modstand, jeg mødte i de første fjorten dage, havde jeg selv taget med.

To uger er ikke længe nok til at konkludere ret meget. Spørg mig igen til vinter, når klubberne bliver stille, og vi finder ud af, hvad vi rent faktisk gør med tiden.

Få Claude Code til at tie stille (og andre tilpasninger, der har gjort sig fortjent)

Johann Böhler — Wed, 24 Jun 2026 10:00:00 +0000

Det første, jeg gjorde med Claude Code, var at få den til at tale mindre.

Claude Code er Anthropics terminal-kodeassistent — du taler med den, og den læser, skriver og kører kode i dit projekt. Ud af boksen er den høflig. “Certainly! I’d be happy to help you with that. The issue you’re seeing is likely caused by…” Jeg læser hurtigt, jeg betaler per token, og jeg har ikke brug for opvarmningen. Det slog jeg fra. Jeg kører et community-plugin, caveman, der skærer svarene ind til benet: ingen artikler, ingen høfligheder, hver eneste tekniske detalje intakt. “Bug in auth middleware. Token expiry check uses < not <=. Fix:” — og så rettelsen.

Det kræver tilvænning. Nogle af de komprimerede sætninger får dig til at stoppe op og læse dem to gange; et fragment kan bære mere mening, end det først lader ane, og du bruger det sparede sekund på at afkode det. Men byttet falder klart ud til min fordel. Jeg kommer hurtigere til sagen, kontekstvinduet fyldes langsommere, og hvis en linje er decideret uklar, er der altid nødudgangen: bed den om at udfolde den. Den brokker sig aldrig.

Den tilstand er det mindst mulige eksempel på det, hele dette indlæg handler om. Claude Code ud af boksen er generisk. Den er bygget til at være fornuftig for alle, hvilket betyder, at den er optimal for ingen. Gevinsten ligger ikke i modellen selv — du kan ikke ændre, hvor god den er, kun hvilken én du kører. Gevinsten ligger i at forme værktøjet om din egen arbejdsgang.

Fælden

Tilpasning er ikke gratis, og jeg vil være ærlig om regningen. Du kan hælde uger i et setup, ingen anden kan læse — heller ikke dit fremtidige jeg.

De værktøjer, der drev konfigurerbarhed længst, er dem, alle hylder: vim og git. Dybe, kraftfulde, uendeligt indstillelige. Og, vil jeg forsigtigt påstå, ikke just særligt tilgængelige. Dybden er både pointen og prisen. Vim er det eneste værktøj, jeg kender, med et meme om, hvordan man overhovedet lukker det — det burde sige os noget.

Jeg hører indvendingen oftest om git: “men git er da så nemt.” Er det nu det? Det er nemt — lige indtil din første rigtige merge-konflikt, eller eftermiddagen, hvor du rebaser det forkerte og stille skriver din egen historik om uden nogen ren vej tilbage. Ja, du kan godt se, hvor du prøver at komme hen. Det kan ham, der sidder med æsken til et puslespil på halvtreds tusind brikker, også — med det færdige billede trykt lige der på låget. At se målet er ikke det samme som, at vejen er tilgængelig. Det er to forskellige påstande, og vi bliver ved med at blande dem sammen.

Her er overbevisningen, sagt rent ud i stedet for som en klage: et godt værktøj bør være så tilgængeligt, som det overhovedet kan være — og derefter, når det har gjort sig fortjent, tilbyde uendelig dybde til enhver, der vil grave. Den tilgængelige del er hele opgaven, ikke en trøstepræmie til begyndere. Dybden er bonussen, du lægger ovenpå.

Min målestok for enhver Claude Code-tilpasning er ét spørgsmål: ville jeg kunne række det til en kollega uden en times briefing? Hvis svaret er nej, overlever det sjældent. Min stak holdes bevidst simpel og dum. Her er, hvad der er tilbage efter det filter.

Hvad fortjente en plads

Den kortfattede output-tilstand. Dækket ovenfor. Den enkeltvis mest virkningsfulde ændring, fordi den rører hvert eneste svar. Mindre at læse, færre tokens brændt, længere levetid for konteksten.

Statuslinjen. Den betyder mere, end den lyder til. Jeg har som regel flere ting i gang på én gang og mister overblikket over, hvor jeg er — hvilket repo, hvilken opgave, hvor meget budget jeg har tilbage. Min statuslinje viser det hele i én stribe: modellen, jeg kører på, hvor fyldt kontekstvinduet er, hvor jeg står i forhold til min 5-timers forbrugsgrænse (Claude Code sætter et loft over, hvor meget du kan køre inden for et rullende fem-timers vindue), og min nuværende mappe. Ingen klik, ingen gætteri. Jeg kigger ned og kender min situation. For enhver, der jonglerer mere end én ting ad gangen, er det den billigste sindsro, jeg har købt.

Indstillingslaget. Det er her, det bliver personligt, og hvor mulighederne aldrig hører op. Min konfiguration spiller en lyd, når Claude er færdig, så jeg kan kigge væk og blive kaldt tilbage. Den sender OS-notifikationer. Du kan få den til at logge formålet med hver session, holde styr på tokens og pris, hvad end du beslutter er værd at vide. Der findes ingen “rigtig” opsætning — pointen er, at hooks’ene findes (små kommandoer, værktøjet kører automatisk på bestemte tidspunkter, for eksempel når det er færdigt), og at du former dem til dit formål. Mit er “sig til, når du er færdig.” Dit kunne være noget helt andet.

Ingen af dem er smarte. Det er netop pointen. Hver enkelt fjerner en lille, daglig friktion, og ingen af dem kræver en forklaring.

Selve ledningsføringen

Lyden er et Stop-hook i settings.json:

"hooks": {
  "Stop": [{ "hooks": [{
    "type": "command",
    "command": "afplay ~/.claude/sounds/done.mp3",
    "async": true
  }]}]
}

async: true, så den aldrig blokerer sessionen, og afplay er bare den indbyggede macOS-afspiller — skift den ud med hvad du vil.

Statuslinjen er knap nok mere end det. Claude rækker dit script en klump JSON ved hver gengivelse; scriptet printer en linje. Du peger på det én gang:

"statusLine": {
  "type": "command",
  "command": "bash ~/.claude/statusline.sh"
}

og scriptet læser de felter, det er interesseret i, fra stdin:

input=$(cat)                                                  # session state, as JSON
model=$(jq -r '.model.display_name'                          <<<"$input")
ctx=$(  jq -r '.context_window.used_percentage // 0 | floor' <<<"$input")
fh=$(   jq -r '.rate_limits.five_hour.used_percentage // 0 | floor' <<<"$input")
dir=$(  jq -r '.workspace.current_dir'                       <<<"$input")

Derfra er det bare at tegne strenge. Min tegner en lille farvet bjælke for hver procentdel — grøn, så gul, så rød, efterhånden som den fyldes — og højrejusterer stien, så striben ender med at se sådan ud:

Opus 4.8  xhigh  · CTX ████░░░░░░ 38%  · 5h ██░░░░░░░░ 21%        ~/dev/golfnext

(xhigh der er bare det niveau af ræsonneringsindsats, jeg holder modellen på.) Det er hele molevitten. Ingen framework, ingen afhængighed at holde opdateret. Et shell-script og en klump JSON.

Hvad jeg ikke automatiserer

Mere automatisering er ikke altid en gevinst. Noget af det flytter bare omkostningen hen et sted, du ikke kan se, og dem lader jeg være slået fra.

Du kan få Claude til at linte og formatere hver fil i samme øjeblik, den redigerer den. Lyder ryddeligt. Det er det modsatte. Hvis et hook omformaterer en fil lige efter, modellen har rørt den, er modellens billede af den fil nu forældet — så næste gang den arbejder der, må den læse hele filen igen for at følge med. Du har byttet et rent diff for en langsommere, mere token-sulten session. Jeg vil hellere have, at den bare kører linteren én gang, til allersidst, når tænkningen er færdig.

Samme logik gælder automatisk model-fallback. Du kan få den til stille at skifte til en mindre model, når dit første valg er optaget. Det vil jeg ikke have. Jeg vælger en model bevidst, som regel fordi opgaven kræver den større ræsonneringsmodel — den, der standser op og arbejder et problem igennem, før den svarer. Hvis den er overbelastet, vil jeg hellere komme tilbage om to timer og skrive “tag den her op igen” end at lade noget stille række mit svære problem videre til en model, der ikke kan bære det. Bekvemmelighed er ikke et dårligere svar værd, som jeg ikke opdagede, jeg fik.

Vinduet bør være en ikke-begivenhed

Folk taler meget om at styre kontekstvinduet — komprimere det (få værktøjet til at opsummere samtalen indtil videre for at frigøre plads), holde øje med det, pleje det. Jeg prøver aldrig at være i den samtale.

Måden, jeg undgår det på, er strukturel: skub det tunge arbejde over på subagenter — separate hjælpe-instanser af Claude Code, hver med sin egen private kontekst — og hold hovedtråden ren. En subagent tager af sted, brænder sin egen kontekst af på at læse og søge, og rækker det korte svar tilbage. Hovedsessionen forbliver let. Gjort rigtigt rækker jeg næsten aldrig ud efter komprimering, fordi jeg aldrig lader vinduet blive fyldt i første omgang.

Men her er den ærlige del: jeg synes, det er en lugt i sig selv, at nogen af os overhovedet skal vide det her. Ingen burde behøve at forstå kontekstvinduer for at begynde at være produktiv med værktøjet. Det er en nuværende begrænsning forklædt som en færdighed. Om et par år vil jeg vædde på, at det er abstraheret helt væk, og at vi taler om det, som vi taler om at styre vores egen RAM — hvilket vil sige, at det gør vi ikke. Jeg optimerer omkring det i dag, og jeg prøver ikke at forveksle det at arbejde uden om en begrænsning med noget, der er værd at lære fra sig.

Kan jeg bevise det? Ikke med tal. Jeg har ikke et rent før-og-efter, og jeg er skeptisk over for enhver, der citerer en pæn procentdel for det her. Hvad jeg har, er en fornemmelse: vinduet fyldes langsommere, budgettet rækker længere, sessionerne forbliver lette længere. Det er subjektivt, og jeg ville mærke det i samme øjeblik, det var væk.

Sådan finder du dine egne

Den svære del er ikke at konfigurere noget. Det er at vide, hvad der overhovedet er muligt.

Claude Code bevæger sig hurtigt — det føles som ti nye kommandoer om ugen. Så hurtigt, at modellen selv ikke kan følge med. Jeg spørger den om en rigtig slash-kommando — “hvad gør /goal, kan du forklare det?” — og den aner ikke, at kommandoen findes. Der er noget komisk over det: det mest kapable, jeg arbejder med, kan ofte ikke fortælle dig om funktioner, der er kommet til efter dens træningsgrænse. Den er bagud på sig selv, helt bogstaveligt. Du kan ikke bare spørge modellen, hvad den kan. Du er nødt til at gå og kigge — læs changelogen, skim en guide, peg den ud på det åbne web, hvor det friske faktisk lever.

Den næste ting, jeg vil prøve, er slet ikke en indstilling. Jeg har et halvt dusin projekter i gang, så jeg vil bygge ét lille meta-repo: ét sted, der peger på dem alle, og som enhver — ikke kun jeg — kan navigere i. Samme instinkt som alt andet her: hvis det kun virker for mig, virker det ikke rigtigt.

Det er hele filteret, når det kommer til stykket. Tag de to-tre ting, der dræber en rigtig, gentagen friktion. Lad resten ligge, uanset hvor smart det ser ud. Målet var aldrig det mest avancerede setup. Det var det, du stadig ville være glad for at række videre til en anden.

Loop-debatten er et dårligt ord for autonomi

Johann Böhler — Wed, 24 Jun 2026 00:00:00 +0000

Der er en genre af indlæg, der florerer lige nu. Du har sikkert set dem. “Jeg skriver ikke prompts længere — jeg designer loops.” “Loop-engineering er det nye prompt-engineering.” Jeg læser dem grundigt — jeg prøver at lære det her lige så hurtigt som alle andre, og dem, der skriver dem, er som regel langt foran mig. Men jeg sidder hver gang tilbage med den samme kløe: jeg kan ikke helt få ordet til at passe på det, jeg faktisk laver hele dagen.

Jeg bruger Claude Code de fleste dage. For dem, der ikke har mødt det: Claude Code er Anthropics kodeagent — du giver den en opgave i terminalen, og den læser filer, skriver kode, kører tests og itererer, i stedet for bare at række dig et stykke kode, du selv skal indsætte. Evnen er reel, og jeg læner mig hårdt op ad den. Det, der spænder ben for mig, er ordforrådet, så jeg prøvede at jorde det.

Jeg gjorde det kedelige: jeg målte alt. Hver rigtig opgave, jeg kørte gennem Claude Code, fik to tal ved siden af sig — hvad den kostede i tokens, og et groft estimat af, hvad det samme arbejde ville have kostet i hånden, i tid. En måneds rækker. Det er det mest uglamourøse artefakt, man kan forestille sig, og det er det, der til sidst fik “loop”-debatten til at falde på plads for mig.

Det, der faldt på plads — i hvert fald for mig — er, at en stor del af diskussionen handler om det forkerte ord. “Loop” er ikke sagen. Autonomi er. Og autonomi kommer ikke som en kontakt, du vipper; det kommer én opgave ad gangen — hvilket, hvis du var med under sidste store arkitektur-diskussion, burde føles besynderligt bekendt.

“Loop” er fire forskellige ting

En del af grunden til, at debatten føles grumset, er, at “loop” udfylder mindst fire roller på én gang, og folk taler forbi hinanden, fordi de hver især holder en forskellig en.

Der er agent-loopet — tænk, handl, observér, gentag. Det er bare sådan en agent virker. Den læser situationen, foretager en handling, ser på resultatet, beslutter hvad der er næste skridt. Det har altid eksisteret. Det er ikke en teknik, det er definitionen.

Der er Ralph — bash-hacket. Det er fællesskabets navn for det groveste tænkelige loop: pak agenten ind i et bogstaveligt while-loop i din shell, og lad den køre den samme prompt igen og igen, indtil den selv erklærer sig færdig. (Navnet er bare folklore; teknikken er pointen.) Groft, til tider effektivt — autonomiens gaffatape.

Der er funktionerne — slash-kommandoer som /loop og /goal, indbygget i værktøjer som Claude Code. De pakker den samme idé ind i noget mere kontrolleret end en bash-onelinjer.

Og der er “loop-engineering” — filosofien. Diskursen. Indlæggene.

Fire forskellige højder, ét ord. Ikke så sært, at det forvirrer.

Men her er det, de alle deler, sætningen hver af dem gentager på sin egen dialekt: mål, verifikation, stopbetingelse. Den trio er den egentlige substans. Alt andet er bare et spørgsmål om, hvilket lag den enkelte tilfældigvis stirrer på.

Lad os gøre det konkret. Tag den mest kedelige nyttige ting, jeg automatiserer: at adressere review-kommentarer på en pull request.

Mål: løs alle review-kommentarer på denne PR.
Verifikation: CI er grøn, og hver kommentar-tråd er reelt adresseret — ikke “jeg tror, jeg fiksede det,” men checket består, og tråden er lukket.
Stopbetingelse: ingen åbne kommentarer tilbage, eller den rammer et iterationsloft og giver bolden tilbage til mig.

Det er et loop. Det er også bare en opgave med en klar definition af færdig og en regel for, hvornår man stopper. Trioen er hele spillet.

Og læg mærke til, hvad der får eksemplet til at virke: en maskine, ikke mig, kan afgøre, om målet er nået — checket er grønt, eller det er ikke. Det er det, jeg fremover vil kalde verifikation — et automatisk, dømmefrit signal om, at arbejdet faktisk er gjort. Hold fast i ordet. Hvor meget af det en opgave har, er det, der afgør alt det senere.

Det er ikke loops. Det er autonomi.

Her er den del, det tog mig et stykke tid at se. Læs de tre kriterier igen — mål, verifikation, stopbetingelse — og spørg: ændrer noget af det sig, alt efter om jeg trykker enter mellem hvert skridt, eller en harness (scriptet eller værktøjet, der omslutter agenten) gør det for mig? Nej. Intet. Målet er målet, verifikationen er verifikationen, stopbetingelsen er stopbetingelsen; de er identiske, uanset om et menneske rykker hver iteration frem, eller et script gør det. Den eneste variabel er hvem der drejer håndsvinget mellem skridtene — og det er slet ikke et spørgsmål om loops. Det er et spørgsmål om autonomi: hvor meget du stoler på, at tingen kører videre uden dig i stolen.

Hvilket giver mening, når man ser, hvor lidt der egentlig er ved et loop — nogenlunde sådan her:

while not done:
    observe()              # look at where things stand
    act_toward(goal)       # take the next step
    done = verified()      # the stop condition: is the goal actually met?

Det er det hele. Så “bør jeg designe loops” er lidt af en kategorifejl — loopet er trivielt, et while og et if. De svære dele gemmer sig bag ordet, og der er to af dem. Den første: hvor langt er du villig til at træde væk fra en kørende proces? Det er tillid. Den anden, den jeg næsten aldrig ser nævnt: når du først træder væk, hvor kører tingen så rent faktisk, og har du råd til at køre den der? Det er infrastruktur — og i modsætning til tillid er det ikke rigtig op til dig endnu, fordi det billige, standardiserede sted at køre autonome agenter ikke findes.

Hvad arbejdet faktisk koster

Det andet spørgsmål — har du råd til at køre det — er det, ingen lader til at blogge om, sandsynligvis fordi næsten ingen tænker på at måle det. Så det gjorde jeg. Min hverdag med Claude Code er overvåget — jeg kører det på min egen maskine, med mig selv i stolen. Men det tal, jeg var ude efter, var det andet: hvad det samme arbejde ville koste målt pr. forbrug, betaling pr. token, sådan som du ville være nødt til at betale for at køre det i skyen uden mig som barnepige. Det er den dyre bane, og det er den, der afgør, om uovervåget overhovedet er på bordet. Så i en måned loggede jeg den forbrugsmålte pris for hver rigtig opgave, ved siden af et ærligt estimat af, hvor lang tid det ville have taget mig i hånden.

Tohundrede og tyve opgaver. Omkring $1.360 i forbrugsmålt pris — og, efter mit eget estimat, tæt på 540 timers tilsvarende håndarbejde. Femhundrede og fyrre timer er den bedre del af tre måneders fuldtids-ingeniørarbejde. Det røg ud ad døren på én.

Sæt et hvilket som helst rimeligt tal på en ingeniørtime, og de forbrugsmålte $1.360 står over for arbejde til tyve til fyrre gange så meget — omkring tredive til en normal fuldt belastet timepris, hvor man tæller løn plus overhead og ikke bare det, der ryger på kontoen. Multiplikatoren behøver ikke være præcis: halvér mine timeestimater, hvis du synes, de er rundhåndede, og det er stadig en størrelsesorden.

Formen på forbruget betyder lige så meget som størrelsen. Median-opgaven kostede $2,45. To tredjedele af alt lå under fem dollars — bugfixes, små features, skrøbelig CI-konfig, dependency-bumps. De dyre kørsler er sjældne, og det er de tunge af slagsen: en hel feature, bygget fra ende til anden, koster nogle tiere af dollars, og de største enkeltrækker er features i $40–55-lejet. Læg flere runder review oven på en af dem, og en komplet ændrings-livscyklus kan runde $100. Det er undtagelserne, ikke normen.

Den del, der afgør, hvor man skal starte: jeg markerede de rækker, der er rent review-og-fix-arbejde — at adressere PR-kommentarer, fikse et fejlende build, løse merge-konflikter. Hele den kategori lå under en tiendedel af det samlede forbrug — de fleste opgaver fra et par cents til et par dollars, halvdelen under en dollar. Og den krævede sjældent meget af mig. Kommentarerne er afgrænsede, fiksen er som regel lokal, og verifikationen er allerede sat op: buildet er grønt, eller det er ikke. Det er den mest checkbare, mindst dømmekrævende del af cyklussen — hvilket gør den til det oplagte første sted at lade noget køre på egen hånd.

Den reelle pengelækage er ikke prisen på den enkelte opgave. Det er churn — kørsler, der brændte krudt af på noget, der ikke havde brug for det. En ændring, der burde have kostet tyve dollars, kostede hundrede, fordi jeg lod den male løs på et problem, jeg bare burde have styret den igennem. Det spild, ikke prisen pr. opgave, er det, der er værd at lave ingeniørarbejde imod.

Det skræmmende tal er mest af alt en måle-artefakt

Der findes en version af det her, hvor nogen ser den månedlige total og får et chok. “Brugte du hvor meget på en AI?” Og jeg forstår det godt — $1.360 om måneden er et oprigtigt alarmerende tal.

Men det er mest af alt en artefakt af, hvordan det opgøres, ikke af, hvad arbejdet er værd — og det er ikke engang det, jeg betaler. De $1.360 er det forbrugsmålte tal, jeg målte. Min faktiske regning er det faste abonnement, jeg kører det hele på: en “Max”-plan i mellemlaget, brugt i et normalt tempo — ikke et hamr-alt-igennem-modellen, lad-mig-lige-google-det-med-Claude-også-tempo, bare støt rigtigt arbejde — som løber op i omkring €110 om måneden, lad os sige $120. Samme tastetryk, samme output, samme måneds arbejde; det forbrugsmålte tal er cirka ti gange abonnementet, udelukkende på grund af hvordan det afregnes.

Og her er den del, der stille og roligt afvæbner hele pris-panikken: du arbejder overvåget alligevel. Du sidder der. Du styrer. Det dyre, ubegrænsede “åh gud, hvad laver den”-scenarie er det uovervågede — agenten, der maler løs på egen hånd, mens måleren spinner. Hvilket er præcis det, du er mindst klar til at stole på i første omgang.

Så de to store bekymringer — “det er for dyrt” og “jeg kan ikke lade den køre selv endnu” — viser sig at være den samme grænse set fra to sider.

Så hvad bygger man egentlig?

Ikke et autonomt loop — ikke endnu, og ikke til det meste af det. Det, jeg bygger i stedet, er en menneske-udløst kæde af skills, hvor “skill” bare betyder en navngiven, genbrugelig opgave, du kan række agenten, som en gemt kommando. En af mine passer pull requests: når jeg har åbnet en PR, sætter jeg den i gang, og den holder øje med de ting, der kræver en reaktion — en ny runde review-kommentarer, et fejlende build — og arbejder dem, indtil PR’en er grøn, eller den rammer noget, den ikke kan håndtere, og prikker mig på skulderen. Jeg starter den; den starter ikke sig selv.

Det interessante er, hvad der ikke kører modellen. Overvågningen er et almindeligt shell-loop, der poller GitHub hvert par minutter for en håndfuld billige signaler — åbne, uafklarede kommentar-tråde, CI-status, om PR’en er blevet godkendt — og den vækker kun agenten, når det sæt rent faktisk ændrer sig:

# the watcher is dumb and free — no model in this loop
while pr_is_open; do
    signals="$(unresolved_threads)::$(failing_ci)"   # cheap GitHub calls
    if [ -n "$signals" ] && [ "$signals" != "$last" ]; then
        wake_agent "$signals"     # the only line that spends tokens
    fi
    last="$signals"
    sleep 600                     # 10 min; an idle PR costs nothing
done

Agenten spinder kun op, når sættet ændrer sig, og selv da gør den det afgrænsede — læser de nye tråde, fikser de værdige i arbejdstræet, kender forskel på et “min kode er i stykker”-build og et “infrastrukturen væltede”-build — og lægger sig så til at sove igen. Den dyre del, modellen, sidder bag den billige del, et script der ved, hvordan man læser en status. Den gating er det meste af tricket til at holde de her ting overkommelige.

Min er den pragmatiske udgave, dog, ikke evangeliet. Peg den mod en andens repo, og den har brug for rigtige guardrails. En PR-kommentar er upålideligt input, hvilket gør en åben watcher til en prompt-injection-flade: nogen kan efterlade en kommentar, der styrer agenten mod noget, der intet har med PR’en at gøre, eller bare spamme kommentarer for at blive ved med at vække den og stille og roligt drive regningen op. Forbi legetøjsstadiet vil du have en classifier, der afgør, hvad der overhovedet er værd at reagere på, og en eskaleringsvej — en OS-notifikation, et Slack-ping, en ticket — til de ting, den ikke selv bør røre. Men man kommer overraskende langt på de rå signaler alene; “åbne, uafklarede kommentarer plus CI-status” er allerede nok til at være reelt nyttigt.

Og formen kan generaliseres. En anden, jeg bliver ved med at ville gøre færdig: et ugentligt job, der scanner de åbne Dependabot- og Renovate-pull requests, merger og rydder op i de kedelige, hvor intet reelt skal ændres, og eskalerer resten — de bumps, der kræver en egentlig refaktorering, eller hvor et API kan brække under dig. Samme skelet hver gang: en billig trigger, et afgrænset job, og en klar linje, hvor det giver bolden tilbage til et menneske. At bygge de loops, og de små toolkits omkring dem, er stille og roligt ved at blive sin egen slags software engineering — mindre “prompt modellen,” mere “design den harness, modellen kører inde i.”

To regler, jeg ville hugge i sten, før jeg byggede noget af det. For det første: release er ikke et job for modellen — det er din CI/CD. Lær ikke en agent at gøre det, din pipeline allerede gør gratis, deterministisk, med et revisionsspor; det er ikke autonomi; det er at genopfinde et løst problem. For det andet: monitorering er ikke et job for modellen — det er Sentry og Grafana. Betal ikke en hjerne for at glo på et dashboard; kobl i stedet alarmen tilbage til en trigger, så agenten kun får problemet i hænderne, når noget rent faktisk er gået i stykker. Og uanset hvad du bygger, så sæt et loft på fiks-loopet — en hård iterationsgrænse plus en menneskelig “godt nok, send det”-port — ellers bliver den $20-fiks stille og roligt til en $100-fiks, mens du er til frokost.

Intet af det er forsigtighed. Menneske-i-loopet er ganske enkelt måden, man starter på: du løsner snoren én iteration ad gangen, efterhånden som dine egne evner skærpes og — vigtigere — efterhånden som din verifikation bliver god nok til, at du ville stole på resultatet uden at stå og kigge over skulderen.

Vi har haft præcis den her diskussion før

Hvis alt det her føles bekendt, er det, fordi vi spillede hele stykket igennem for ti år siden. Det hed microservices, og jeg var med. Hurtig genopfriskning, hvis du gik glip af den æra: omkring 2014 begyndte teams at hakke store, enkeltstående applikationer — “monolitter” — op i mange små, uafhængigt deploybare services. Den højlydte diskussion gik på, hvor små de skulle være.

Frådet er identisk. Dengang var det ubesvarlige spørgsmål “hvor lille er en microservice — kan den være 200 linjer?” I dag er det “Ralph eller /goal, og hvor mange agenter?” I begge tilfælde er det et fællesskab, der størrelses-diskuterer sig igennem en ting, før nogen overhovedet ved, hvad der faktisk betyder noget.

Den gode praksis kom også før navnet. Vi opdelte systemer efter domæne — rene snit, ejede grænser — længe før nogen sagde “microservices.” Og agent-loopet plus en verifikations-harness fandtes længe, før nogen brandede det som “loop-engineering.” Navnet dukkede op og tog æren for arbejde, folk allerede lavede.

Og så lagde det sig. Det ærlige tilbageblik på microservices er ikke “vi revolutionerede alt.” Det er “vi byggede stort set videre, som vi allerede byggede, bare med renere snit.” De fleste teams gik fra en monolit til to eller fem services, ikke fra én til to hundrede natten over. Forandringen var reel, og den var udramatisk, fordi det meste af det, vi byggede, allerede var småt.

Men her er korrektionen, der faktisk betyder noget, den del størrelses-diskussionen overså dengang. For microservices var den reelle forskel aldrig mønsteret. Det var fundamentet. Containere, så skyen, så Kubernetes gjorde små, uafhængigt deploybare services billige og standardiserede at køre. Mønsteret lå nedstrøms for infrastrukturen — og infrastrukturen dukkede op for at møde det.

For loops er vi kun halvvejs. Kapacitets-fundamentet er ankommet, og det er modellen. En enkelt række på mit ark er en feature, jeg ville have sat to dages håndarbejde af til, leveret for omkring halvtreds dollars. Det var fuldstændig umuligt for to år siden, til enhver pris, med ethvert loop. Loopet ændrede sig ikke; det, der sad inde i det, blev godt nok til, at man kan betro det rigtigt arbejde. Det er container-øjeblikket — den rå kapacitet, der lander.

Det, der ikke er ankommet, er resten af stakken. Der findes ikke et billigt, standardiseret, sikkert sted til rent faktisk at køre autonomi uovervåget — ingen pendant til den managed sky og Kubernetes, der forvandlede “jeg har en lille service” til “og her er det oplagte, overkommelige sted at køre den.” Intet siger endnu “lad denne agent male løs på egen hånd natten over, uden at det koster en formue eller løber af sporet.”

Så: modellen er containerne; Kubernetes er ikke bygget endnu. Og “loops” — filosofien, størrelseskrigene — er nanoservices-frådet om igen: “hvor absurd småt kan vi gøre det?"-overdrivelsen, der udspiller sig på en stak, der stadig mangler sin nederste halvdel.

Autonomi er gradvist, ikke en kontakt

Hvilket bringer mig tilbage til, hvor jeg startede. Du vipper ikke fra “jeg holder øje med alt” til “den kører selv.” Ingen gik fra én service til to hundrede på en weekend, og ingen ved deres fulde fem går fra overvåget-alt til autonom-alt heller.

Snoren løsnes én verificerbar opgaveklasse ad gangen, begrænset af præcis én ting: hvor checkbar verifikationen er. Det sker allerede. En PR-watcher, der auto-fikser fejlede builds, er snoren allerede løsnet — på en snæver, afgrænset, maskin-checkbar klasse, hvor prisen for at tage fejl er lav, og et grønt check fortæller sandheden. Imens forbliver feature-design og produktionsændringer i snor længe, måske for altid, fordi verifikationen er dømmekraft, og dømmekraft passer ikke ind i et CI-check.

Så når du læser “jeg designer loops, ikke prompts,” så forstå, hvor det kommer fra. Det er ikke en løgn. Men læg mærke til, hvem der plejer at sige det: folk i de store AI-labs — dem, der bygger modellerne — eller med reelt ubegrænsede token-budgetter, eller begge dele. For dem mangler det manglende fundament ikke; måleren gælder ikke på samme måde, som den gælder for dig. “Bare kør loops” er en fuldstændig ærlig beskrivelse af deres virkelighed. Det er rapportering fra forkanten: sandt der, hvor det rapporteres fra, med det bedste værktøj og de mest checkbare problemer, solgt som en universel recept, det ikke er endnu — ikke for nogen, der arbejder mod et reelt budget.

Så jeg melder mig ikke ud af debatten — jeg melder mig ud af ordet. Jeg bygger den overvågede kæde, skærper mine egne evner og min verifikation, og lader hver opgaveklasse fortjene sit slæk ét check ad gangen. Det er den del, jeg kan handle på i dag, mens resten bliver diskuteret færdigt.

Hvilket er det samme træk, der viste sig at være rigtigt med microservices: spot frådet, lad størrelseskrigene rase, og bliv ved med at sende den kedelige udgave, der rent faktisk virker.

En ren maskine

Johann Böhler — Tue, 23 Jun 2026 00:00:00 +0000

I sidste indlæg satte jeg mig et mål for de første halvfems dage: en koldstart på fem minutter. Fra frisk bærbar til kørende kode på under fem minutter — klon projektet, kør det lokalt, ram et live-endpoint, bestå testene, alt sammen før kaffen bliver kold. Den korteste ærlige vej fra en ny medarbejders første morgen til deres første rigtige bidrag. Det er den on-ramp, jeg vil bygge for teamet hos GolfNext, den danske golf-tech-virksomhed, jeg er på vej til at starte hos.

Før jeg kan række det videre til nogen anden, skylder jeg det til min egen maskine. Et nyt job betyder, at en ny MacBook er på vej, så jeg rettede det samme mål mod mig selv først.

Det to år gamle bogmærke

For omkring to år siden rullede et dotfiles-repo forbi i min GitHub-timeline — det feed, der viser, hvad de folk, man følger, arbejder på. Det tilhørte Manuel Brandstetter, en tidligere kollega og en af de bedste udviklere, jeg har arbejdet sammen med. Han overtog som lead på scrumlr.io, det open source-retrospektivværktøj, jeg var med til at bygge, efter at jeg forlod inovex, det tyske konsulenthus, hvor vi havde arbejdet sammen. Så da hans setup rullede forbi, stoppede jeg op og kiggede. Ingen stor pitch, bare der i forbifarten: alt det, der gør en bærbar til hans bærbar, versionsstyret ét sted. Jeg husker, at jeg tænkte, klart og højt: “Det burde jeg gøre.” Så lod jeg være. I to år.

Hvis du aldrig har holdt dotfiles: det er de små konfigurationsfiler, der stille former din maskine. Din shell-opsætning, dine editor-indstillinger, din git-konfiguration — de dusinvis af små præferencer, du ellers ville bygge op i hånden, fra hukommelsen, hver gang du får en ny computer. Et dotfiles-repo lægger dem under versionsstyring, så maskinen bliver reproducerbar i stedet for håndlavet og glemt.

Grunden til, at jeg aldrig fik gjort det, er den kedelige: det føltes altid som en eftermiddag, jeg kunne bruge på noget mere presserende. Men det smarte ved en helt ny bærbar er, at den fjerner undskyldningen. Du skal sætte maskinen op alligevel. Så kan du lige så godt sætte den op én gang, ordentligt, på en måde du aldrig skal gentage.

Det review, jeg kører hver december

Det er en vane, jeg har holdt i årevis. Et eller andet sted i den stille uge omkring jul sætter jeg mig ned og gennemgår mine værktøjer. Bruger jeg stadig det bedste til hver opgave, eller bare det, jeg tilfældigvis valgte for tre år siden og aldrig satte spørgsmålstegn ved? Det er som regel en eftermiddag alene — med changelogs, halvt huskede Hacker News-tråde, en smule “hvad bruger alle andre nu”.

I år havde et forspring. Et par uger forinden var jeg gået på jagt efter noget i stil med nvm, men til alle runtimes, ikke kun Node: Python, Go, Java, det hele. Jeg fandt mise, som gør præcis det, og at bytte en skuffe fuld af sprog-specifikke versionsstyringsværktøjer ud med ét enkelt var det mest tilfredsstillende, jeg havde gjort ved mit setup i månedsvis. Den lille sejr er nok det, der stille og roligt skubbede et to år gammelt “det burde jeg gøre” over i “gør det nu”.

Så i år kørte jeg gennemgangen som en samtale i stedet. Jeg pegede Claude — Anthropics AI-assistent, den samme jeg skal bygge med på arbejdet — mod mit nuværende setup og stillede den skarpe version af spørgsmålet: hvad her er forældet, hvad mangler, hvad ville du ændre, og hvorfor. Så lod jeg den researche og argumentere for sin sag.

Jeg holdt resultatet ærligt ved at gøre det til en diff. Det gamle setup blev på min main-branch; det reviderede gik på en branch, jeg kaldte cleanup. Så hver anbefaling var en linje, jeg kunne læse, acceptere eller afvise, ikke en sort boks, der omskrev min maskine, mens jeg ikke kiggede. Den ramme betød mere, end jeg havde regnet med. Et review, man kan læse linje for linje, er et review, man rent faktisk stoler på.

To ting kom ud af det: en måde at behandle hele maskinen som ét repo, og en kort liste over værktøjer, jeg havde været dum at springe over.

chezmoi: maskinen som et repo

Værktøjet er chezmoi. Det holder dine dotfiles i et git-repo og renderer dem ud på enhver maskine, du ejer — chez moi, passende nok, fransk for “hjemme hos mig”.

Det, der solgte mig frem for en almindelig mappe fuld af symlinks, er modellen. Filerne i repoet er kilden til sandheden; du apply‘er dem for at skrive de rigtige filer ind i din home-mappe. Rediger, se diff’en, apply, commit. Det understøtter templating (én fil kan tilpasse sig en arbejdsmaskine kontra en privat), og det holder hemmeligheder helt ude af repoet — mine SSH-nøgler bliver inde i 1Password, udleveret til git efter behov, aldrig skrevet til en fil, chezmoi ved et uheld kunne committe.

Den del, der endelig indfriede det to år gamle løfte, er bootstrappet. På en ren Mac kommer hele maskinen tilbage med tre kommandoer:

brew install gh chezmoi
gh auth login                              # sign in to GitHub in the browser
chezmoi init --apply bitionaire/dotfiles   # clone + render everything into place

Den sidste linje kloner repoet, installerer mit shell-framework, lægger hver konfigurationsfil på plads og kører et sæt førstegangs-opsætningsscripts. Én navngivningskonvention klarer det meste af magien: en fil ved navn dot_zshrc i repoet bliver til ~/.zshrc på maskinen. dot_config/ghostty/config bliver til ~/.config/ghostty/config. dot_-præfikset er bare chezmois måde at skrive et indledende punktum uden at forvirre din filbrowser. Når først det falder på plads, læser repoet som et spejl af din home-mappe.

De værktøjer, gennemgangen faktisk ændrede

Jeg kørte allerede oh-my-zsh med powerlevel10k-prompten. Gennemgangen pressede hårdt på for tre tilføjelser, og havde ret i alle tre:

Ghostty — en hurtig, moderne terminal. Jeg havde holdt mig til macOS-standarden i årevis af ren træghed. Ghostty er hurtigere, kan temasættes i en almindelig tekstfil (hvilket betyder, chezmoi kan spore den), og renderer de powerline-glyffer, min prompt bruger, uden en separat Nerd Font-installation.
fzf — en fuzzy finder, og den, der ændrede min hverdag mest. Ctrl-R forvandler shell-historik fra en blind pil-op-jagt til en levende fuzzy-søgning. Ctrl-T lægger en filsti ind i det, du er ved at skrive. Pipe hvad som helst ind i den — git branch | fzf — og du får en interaktiv vælger gratis.
zoxide — et smartere cd. Den lærer de mapper, du faktisk bruger, og lader dig hoppe efter et fragment af navnet. z dot lander mig i mit dotfiles-repo fra hvor som helst på maskinen, uanset hvor dybt det er begravet.

Ingen af dem er eksotiske — det er værktøjer, mange terminal-tunge folk allerede sværger til, og jeg havde bare aldrig sat mig ned for at tilføje dem. At koble dem på er nogle få linjer shell-konfiguration:

# fzf — fuzzy finder (Ctrl-R history search, Ctrl-T file picker)
command -v fzf >/dev/null 2>&1 && eval "$(fzf --zsh)"

# zoxide — smarter cd (`z ` jumps by frequency + recency)
command -v zoxide >/dev/null 2>&1 && eval "$(zoxide init zsh)"

Automatisering af de dele, jeg plejede at klikke mig igennem

En frisk Mac er ikke bare dotfiles. Det er en eftermiddag med at downloade apps, trække dem til Programmer, og klikke sig igennem de samme Systemindstillinger, du har sat på hver Mac, du nogensinde har ejet. Det er den del, gennemgangen automatiserede, og den del, jeg er mest stolt af.

Apps kommer fra en enkelt Brewfile — et manifest, Homebrew læser for at installere alt i ét hug:

brew bundle --file=Brewfile   # installs every CLI tool, app, and App Store entry

Én fil opremser kommandolinjeværktøjerne, desktop-apps’ene (1Password, Firefox, Ghostty, Docker, editoren) og endda Mac App Store-køb. Ny maskine, én kommando, og en snes apps installerer sig selv.

Så er der macOS-indstillingerne. chezmoi kører opsætningsscripts ved første apply, og et af dem er bare en liste af defaults write-kommandoer — den scriptbare side af Systemindstillinger. En smagsprøve:

defaults write -g KeyRepeat -int 2                            # fast key repeat
defaults write -g ApplePressAndHoldEnabled -bool false        # hold a key to repeat it
defaults write com.apple.finder AppleShowAllFiles -bool true  # show hidden files
defaults write com.apple.finder _FXSortFoldersFirst -bool true  # folders on top

Jeg havde sat hver eneste af dem i hånden på hver Mac i et årti og aldrig tænkt på at skrive dem ned — nu er de en fil. Det er ikke totalt. Apple blokerer bevidst for at scripte de sikkerhedsfølsomme dele, så at give tilgængelighedstilladelser og logge ind på iCloud forbliver manuelt. Men de dusinvis af små knapper, der plejede at æde en eftermiddag, tager nu sekunder, og jeg skal aldrig huske dem igen.

Et godt review skærer lige så meget væk, som det tilføjer

Overraskelsen var, hvor meget samtalen talte mig fra. Et værktøjs-review handler ikke kun om nyt legetøj; det handler om at lægge mærke til det skidt, man har slæbt rundt på.

Så cleanup-branchen slettede ting. De ældre versionsstyringsværktøjer, jeg havde samlet sammen, plus en håndinstalleret Python, blev alle foldet ind i den ene mise, jeg havde taget i brug et par uger forinden. En genvej, jeg havde lavet for at omgå en gammel Docker-finurlighed, der siden er rettet — væk. Et virvar af arbejde-kontra-privat git-konfiguration, jeg havde samlet på tværs af job, fladet ud til én identitet. Hver af dem var en lille beslutning, jeg havde taget for år tilbage af en god grund, og så aldrig genbesøgt, da grunden var udløbet.

Det er den egentlige værdi i at gøre det med en sparringspartner. Overladt til mig selv har jeg en tendens til at tilføje. Bedt om at forsvare hver enkelt del højt, fik jeg endelig fjernet.

Hvad jeg tager med mig

Det imponerende var ikke, at en AI kan skrive en konfigurationsfil — det ved alle, den kan nu. Det var gennemgangen. Den rakte mig ikke et generisk “bedste setup”; den kiggede på mit, spurgte, hvad jeg faktisk laver hele dagen, og argumenterede for ændringer, der passede, med begrundelsen vedhæftet, så jeg kunne skyde igen, hvor den tog fejl. Mindre et værktøj end det december-review, jeg allerede kører, med en kyndig person på den anden side af bordet.

Og det lukkede en cirkel. Den fem-minutters koldstart, jeg vil give GolfNext-teamet, er præcis det samme, skaleret op: en ny person, en ny bærbar, og en kort vej til rigtigt arbejde uden en uges opsætnings-skat. Jeg byggede bare den personlige version først.

Så hvis du har dit eget “det burde jeg gøre”-bogmærke, der samler støv — et repo, der engang rullede forbi i din timeline, måske — så er det her dit tegn. Vent på den næste rene maskine. Og sæt den så op én gang. To år for sent slår stadig aldrig.

Referencer

Værktøjerne og dokumentationen, det er værd at bogmærke, nogenlunde i den rækkefølge, de optræder ovenfor:

chezmoi — dotfiles-manager. Start med quick start og user guide.
Homebrew og Brewfile / brew bundle — installer apps og CLI-værktøjer fra ét manifest.
oh-my-zsh — Z shell-framework, med powerlevel10k-prompttemaet.
Ghostty — hurtig terminal med konfiguration som tekst.
fzf — fuzzy finder til kommandolinjen.
zoxide — et smartere cd, der lærer dine vaner.
mise — én versionsstyring til node, python, go og resten.
1Password SSH-agent — hold private nøgler ude af repoet og væk fra disken.
Repoet, der startede det hele: Manuel Brandstetters dotfiles.

P.S. — et Dock-trick, der intet har med dotfiles at gøre

En gratis godbid til de Mac-brugere, der nåede så langt. Det har intet med noget af ovenstående at gøre, men det er den slags lille ting, der stille har glædet mig i årevis: du kan smide blanke mellemrum (spacers) ind i Docken for at dele dine apps op i klynger. Samme defaults write-trick som resten af indlægget. Kør det én gang per spacer, du vil have:

# full-height spacer (run again for each extra one)
defaults write com.apple.dock persistent-apps -array-add '{tile-data={}; tile-type="spacer-tile";}' && killall Dock

# half-height spacer (run again for each extra one)
defaults write com.apple.dock persistent-apps -array-add '{"tile-type"="small-spacer-tile";}' && killall Dock

Træk i mellemrummene som ethvert andet Dock-ikon, eller træk et ud af Docken for at fjerne det. Bittelille ting. Får en proppet Dock til at føles organiseret.

Et brev til mig selv, før dag ét

Johann Böhler — Mon, 22 Jun 2026 00:00:00 +0000

“I may have something of interest to you, Johann. Would be great to connect 👍🏼.”

Det er hele beskeden. Den landede på LinkedIn ud af det blå, fra en rekrutterer ved navn Joe — hvilket, i betragtning af hvor ofte den slags kommer ind under et lånt fornavn, måske endda er hans rigtige. Ingen virksomhed, ingen rolle, ingen detaljer. Den slags besked, man normalt arkiverer uden at tænke nærmere over det.

Denne her ender med, at jeg forlader et job, jeg godt kan lide, i en virksomhed jeg ikke har ét ondt ord at sige om, for en virksomhed hvis navn Joe ikke engang ville fortælle mig. Det måtte jeg selv finde ud af. Nå ja — mig selv og en AI.

Jeg skriver det her før min første arbejdsdag. Jeg har ikke skrevet under på kontrakten endnu; jeg kender ikke engang min startdato. At skrive virksomhedens blog, før jeg officielt har jobbet, lyder bagvendt. Måske er det også det. Jeg gør det alligevel, fordi jeg går rundt med flere tanker, end jeg kan rumme, og fordi jeg vil have et nedslag — noget at læse igen om seks måneder og holde op mod det, der rent faktisk skete.

Så det her er to ting på én gang. Historien om, hvordan en besked på to linjer blev til et job, og et brev til en fremtidig udgave af mig selv.

En tilståelse, før vi begynder: Jeg har aldrig skrevet et blogindlæg i mit liv. Jeg begynder nu med vilje — det at skrive fastholder idéer, der ellers bare er damp. Så her er jeg, og tænker højt.

Fra tre brødkrummer til en virksomhed

Jeg spurgte Joe, hvad hans besked handlede om. Det viste sig at være en rolle som Lead Engineer i en lille, men veletableret virksomhed: den første hjørnesten i et AI-first-udviklingsteam — et team, der bygger software mest ved at styre AI i stedet for at taste hver linje i hånden. Joe ville ikke nævne virksomheden. I stedet gav han mig brødkrummer — dansk sportstech, eksisteret siden 2012, 400+ anlæg i 18 lande.

Så jeg rakte brødkrummerne til Claude, Anthropics AI-assistent. På sekunder navngav den virksomheden: GolfNext, i Ry, en kort køretur fra hvor jeg bor i Danmark. De bygger det selvbetjeningsudstyr, golfklubber kører på — mere om det senere.

Den lille øvelse er mere eller mindre jobbeskrivelsen. Hvis man kan pege en AI mod tre vage spor og få den til at rekonstruere virksomheden bag dem, så er det jo arbejdet. Så jeg svarede med en fuldt ud AI-genereret besked, åbent mærket:

“Full disclosure, Joe: this reply is AI-generated. Felt fitting for an AI-first pitch — and yes, I let the agent do the detective work too. 😄”

De skrev tilbage. Et par dage senere kørte jeg ud til Ry og tilbragte en time på GolfNext-kontoret, og da jeg gik derfra, vidste jeg, at jeg ville have det. Tegnet var det første, de sagde, da jeg satte mig: “Let’s just have a chat here and talk openly.” Intet teater.

Før jeg bandt mig til noget, ville jeg vide præcis, hvad jeg gik ind til, så jeg spurgte. Thomas Herskind, der står for produktet hos GolfNext, sendte en oversigt over de systemer, de driver i dag. Jeg læste den og skrev tilbage med alt det, jeg mente var værd at tage fat på først, punkt for punkt. Det blev langt. Meget langt.

Thomas’ svar var på seks ord. “Congrats on your first novel, Johann!”

Jeg grinede højt. Man lærer meget om et sted af, hvordan det driller en, før man overhovedet har skrevet under.

De 70 idéer før denne her

Intet af det forklarer, hvorfor en besked på to linjer uden detaljer overhovedet fangede min opmærksomhed. Det kræver, at jeg spoler et par måneder tilbage — og først fortæller, hvem der skriver, nu det her er internettet.

Jeg er generalist. En full-stack-udvikler, der aldrig har haft noget imod at lære, hvad et projekt nu krævede. Seksten år i faget: en masse backend, en masse webapps, et par år som teamleder, og medskaber af scrumlr, et open source-værktøj, teams bruger til at holde retrospektiver — de møder, hvor man kigger tilbage på, hvad der gik godt, og hvad der ikke gjorde. Jeg har aldrig været den udvikler, der elsker teknologi for teknologiens skyld. Det, der trækker i mig, er den anden ende: brugeren, designet, værdien, det der gør nogens dag en smule lettere. Og at nå dertil uden alt for mange omveje. Det er CV’et på ét afsnit. Kløen er den del, det ikke kan bære.

Jeg havde længe haft en kløe efter at bygge noget af mit eget. Hvad som helst, der måske kunne vokse til en forretning — og en undskyldning for at skubbe Claude, så langt den kunne, og finde ud af, hvor meget rigtig software den egentlig kunne bygge. Det første projekt udsprang af en irritation, jeg havde slæbt med på tværs af job. Release notes — den “hvad er ændret”-liste, der er ment til dem, der bruger softwaren — bliver ved med at havne i commit-beskeder, de korte noter udviklere efterlader til hinanden. “Upgrade ESLint to version 10.” Hvem er det til? Så jeg byggede et lille produkt, der lader dig skrive ordentlige ændringsnoter i almindeligt sprog, lige ved siden af koden, og række dem til de produktansvarlige, der burde eje dem. Bygget fra bunden på cirka to uger — det brugerne ser, backenden bag det, pipelinen der sender opdateringer ud af sig selv. Det hele, med AI bag det meste af tastaturet.

Det føltes godt nok til, at jeg blev grådig og rakte ud efter noget meget større: en agent, der holder softwareprojekter i live. Vedligeholder dem, udvider dem, mest på egen hånd, med release-notes-værktøjet som sin første patient. Det var der, jeg ramte en mur, og muren lærte mig mere end de fleste af mine færdige projekter.

Noget af det var omfang. Jeg havde pakket et helt produkt rundt om noget, der burde være startet som et lille eksperiment. Men den dybere lektie handlede om værktøjet. Nutidens AI er virkelig fremragende på en blank side, og til små, velafgrænsede ændringer. Den bliver usikker, i samme øjeblik man beder den rive fat i store stykker kernelogik. Den begynder at hallucinere — selvsikkert at opfinde ting, der ikke er der. Den rydder aldrig helt op efter sig selv. Gammel kontekst hænger ved og lister sig ind i næste forsøg. Et så ambitiøst byggeri kræver en klar plan for hvordan man kommer derhen, før man skriver en eneste linje, og at holde den plan sammen på egen hånd, i stjålne aftener og weekender, var bare ikke noget, jeg kunne magte. Det projekt er parkeret, ikke begravet.

Så jeg skiftede taktik. Jeg satte Claude til at være sparringspartner på mindre ting, den slags jeg kunne gøre færdig på et par uger. Jeg pitchede en idé; den gik ud og undersøgte markedet og kom som regel tilbage med det samme svar — overfyldt, allerede finansieret, lad være. Surt. Også nyttigt.

Efter omkring 70 af dem holdt jeg op med at pitche og stillede det åbenlyse spørgsmål: hvad burde jeg så lave? Svaret var forfriskende ligetil. Hold op med at jage et smart produkt. Find nogen med et rigtigt problem, og hjælp dem med at bygge en softwaredrevet proces rundt om det, der sparer dem alvorligt meget tid. Og da den kender min måde at arbejde på, skitserede den nogenlunde, hvordan det kunne se ud. Et par måneder senere landede Joes to linjer i min indbakke — og rollen bag dem viste sig, da jeg først spurgte, at være et næsten perfekt match til den skitse. Beskeden uden detaljer var præcis det, jeg havde fået besked på at gå ud og finde.

Hvad det egentlig handler om

På høje tid, jeg fortæller, hvad det egentlig var, jeg havde fundet. GolfNext bygger selvbetjeningsværktøjer og hardware til golfklubber — forestil dig en boldautomat, medlemmerne selv betjener på driving rangen, eller et system, der tager den fummelfingrede, fejlbehæftede opgave med at sælge og indløse vouchere og gør den rolig. I årevis har dygtige eksterne partnere bygget det meste af den software, og det har bragt virksomheden langt. Skiftet nu, som de lagde det frem for mig, er, at GolfNext vil have ingeniørvidenen til at bo inde i virksomheden: et team, der forstår hele landskabet indefra, til den slags stabile, langsigtede vækst, der kommer af at eje det, man afhænger af. Ingen dom over dem, der har bygget det indtil nu — bare det naturlige næste skridt for en virksomhed, der regner med at være her længe.

Jeg er en af de første brikker i det. Opgaven: suge landskabet til mig — det samme, som Thomas gav mig et forhåndsblik af i den oversigt — overtage udviklingen bid for bid, og før længe være med til at bygge et team op omkring det.

Her er en tilståelse, der lyder underligt i en ingeniørblog: Jeg har knap skrevet kode i hånden i månedsvis. Kald det et halvt år på mine egne projekter, et par måneder på arbejdet. Ikke fordi jeg holdt op med at bygge. Byggeriet rykkede bare et niveau op. Mere af min dag går nu med at styre AI, gennemgå det, den giver tilbage, og designe de værn, der holder dens output sikkert og korrekt. Det er der, faget er på vej hen — og det er præcis det team, GolfNext beder mig bygge. Ingen kan ærligt fortælle dig, hvor det hele lander; jorden flytter sig med få ugers mellemrum. Men retningen er klar nok til at pege på, og at pege på den er jobbet.

Det er hvad. Før hvordan er der et farvel, jeg skylder.

At forlade noget godt

Først den ærlige del, ingen nyder at skrive. At sige ja her betyder at forlade Salling Group — en af Danmarks største detailvirksomheder — og jeg vil ikke have et eneste ord af det her læst som en klage. Salling var det perfekte første skridt, da jeg landede i Danmark: en ægte kultur, mennesker der virkelig passer på hinanden, arbejde jeg er stolt af. Jeg leverede ting, der betød noget, under deadlines uden plads til fejl, ved siden af ingeniører, jeg lærte en hel del af. Jeg fik gode venner der. En del af mig er ked af at gå.

Grunden til, at jeg flytter mig, er ikke en fejl ved stedet. Det er en forskel i, hvad jeg er skruet sammen til. I en virksomhed af den størrelse bliver hver beslutning vejet af mange omtænksomme mennesker, hvilket er præcis sådan, en stor detailvirksomhed gør sig fortjent til og fastholder folks tillid. Men det betyder, at det er sjældent at være tæt på rattet, og endnu sjældnere at styre hurtigt. Jeg vil have rattet. Jeg vil pege på en retning og bevæge mig. Den kløe er størstedelen af grunden til, at jeg begyndte at bygge ting ved siden af i første omgang, og det er præcis det, denne nye rolle rækker mig. At forlade noget godt af den rigtige grund er stadig at forlade noget godt. Begge dele er sande på én gang.

De mål, jeg sætter mig

Nu til hvordan. Den mur, jeg ramte på sideprojektet, er hele grunden til, at målene herunder ser ud, som de gør. Hvis AI er stærkest inden for klare grænser, er svaret ikke at prompte hårdere. Det er at bygge et landskab, hvor grænserne er tydelige — hvor kontekst er billig at række videre, hvor en ændring er nem at skære lille, hvor værnene fanger det, modellen tager fejl af, før et menneske skal. For det er der, jeg tror, det hele er på vej hen: den knappe ressource i software bliver, hvor hurtigt hvem som helst — menneske eller AI — kan sætte sig ind i en kontekst, de aldrig har set. Hvis en ny udvikler og en frisk AI-session begge kan forstå en service hurtigt, kan arbejdet gå i gang med det samme, af den der griber det. Hvis de ikke kan, starter hver opgave med arkæologi. Det meste af det følgende handler i virkeligheden om den ene sætning.

Ét forbehold, der betyder noget: Jeg er ikke begyndt endnu. Det her er de standarder, jeg vil holde mig selv til, ikke beslutninger jeg træffer alene — rækkefølgen og prioriteterne bliver til sammen med de mennesker, der har drevet systemerne i årevis.

Gør arbejdet synligt. Denne blog er mål nummer ét. Når man bygger viden op inde i et team, er det værste, man kan gøre, at låse den inde i private kanaler og enkelte hoveder. At skrive det ned i det åbne tvinger klarhed frem, trækker gode folk til, holder alle ærlige. Så den findes nu. Fremtidige mig: hvis disse indlæg gik i stå, så tag det som et advarselstegn.

Genopbyg forståelsen, ikke bare adgangen. At overtage fra et eksternt team handler ikke rigtig om at samle adgange og kodeord. Det handler om at genopbygge forståelsen indefra. Så: hver konto tjekket og sat i mit navn, hvert dokument læst og skærpet, indtil jeg kan drive og release hvad som helst i stakken uden at ringe til en ven. Det er den uglamourøse halvdel af de halvfems dage, og det er den halvdel, alt andet venter på.

Byg et landskab, alle kan bygge i. Det er det, jeg holder mest af. Konkret:

En fem-minutters koldstart. Frisk laptop til kørende kode: forstå projektet, kør det lokalt, ram et live-endpoint, få testsuiten igennem, alt sammen på under fem minutter. Det er rampen ind til at bygge og afprøve, ikke en regelbog for, hvordan man skriver kode. Fremtidige mig, den her kan måles — gå ud og tag tid.
Dokumentation, der bor lige ved siden af koden, så kontekst er én mappe væk i stedet for én Slack-besked væk.
Automatisering af alt det, vi ellers ville lave i hånden to gange.
Teknisk gæld betalt af, dér hvor den reelt står i vejen — ikke en hovedrengøring, bare det der spærrer.
Et fælles sæt prompts og presets til AI’en, så alle starter fra den samme gennemprøvede opsætning i stedet for at bygge den op forfra hver gang. Det er det, der gør “AI-first” til reelt fælles værktøj i stedet for en floskel.

Pointen er ikke at være de eneste, der kan bygge. Det er at være kvalitetsporten, der gør en rå idé til noget, man kan stole på, og den hjælpende hånd, der gør det sikkert og let for alle andre at bygge.

Bliv ved tasterne. Det sagde jeg til Joe, før jeg havde sagt det til nogen hos GolfNext, fordi det ville spare os begge tid. Jeg har ledet et team før, fireogtyve mennesker, og jeg trådte tilbage til at bygge med vilje. “If ‘Lead’ means setting technical direction while still building, I’m very in. If it means drifting away from the code, I’m the wrong guy.” Den linje begyndte som et filter for jobbet. Nu er den et mål. Fremtidige mig: hvis du er drevet væk fra koden, ved du, hvad du skal gøre ved det.

Ansæt fremragende folk, og stol så på dem. Ikke i de første halvfems dage, og ikke min beslutning alene, men det er den vej, det her går, og det former de tidlige valg. Et lille team af fremragende folk har næsten ikke brug for proces. Hold barren høj, også når I er underbemandede. Den del er i det mindste ikke mig, der projicerer min læseliste over på dem: da ansættelser kom på bordet i Ry, fortalte de mig, at de hellere ville køre underbemandet i et par måneder end tage den forkerte person ind bare for at få mere kapacitet. Det fortalte mig mere om stedet, end noget pitch kunne have gjort. Giv folk kontekst i stedet for godkendelser. Bedøm arbejdet, ikke larmen. Sig som udgangspunkt ja, og stop kun for at diskutere ved de døre, man ikke kan gå tilbage igennem. Og lad der være plads — rigtig plads — til at brainstorme, til at skændes om idéer, til at bygge ting, der måske ikke virker. Den kreative, legende tid er ikke en belønning, man tjener ind, når det seriøse arbejde er gjort. I dette fag er den det seriøse arbejde.

Et kompas, ikke en regelbog

Målene er planen. Under planen ligger et kompas, og det er værd at vise frem, for det vil forme, hvordan jeg styrer.

Det, jeg ikke møder op med, er et manifest. Jeg tror ikke på, at en kultur kan skrives til live. Den vokser ud af sit miljø og menneskene i det, dag for dag, i tusind små øjeblikke ingen skriver ned — og derfor kan den kun ledes ved eksempel, aldrig ved håndhævelse. Hvad GolfNexts værdier faktisk er, finder vi ud af sammen, i arbejdet. Og jeg mener sammen i begge retninger. Jeg ankommer med overbevisninger — det her indlæg er fuldt af dem — men jeg regner med at blive forandret mindst lige så meget, som jeg forandrer noget, og at tage arbejdsmåder til mig, jeg ikke engang har overvejet endnu.

En del af det skylder jeg inovex, det tyske konsulenthus, hvor jeg tilbragte syv år — den længste strækning af de seksten. De havde en trekant — Medarbejdere, Kunder, Økonomi — og de mente hvert hjørne af den: fair løn, friheden til at vælge de rigtige værktøjer til opgaven, fornuftige og agile arbejdsmåder, ægte omsorg for de mennesker, der laver arbejdet. Det meste af det holder jeg stadig fast i. Min egen vægtning ligger bare en smule anderledes. Hvor deres trekant sætter medarbejdertilfredshed, sætter min Craft — håndværket. Ikke fordi tilfredshed ikke betyder noget, men fordi jeg er kommet til at tro, at den vokser ud af at lave godt arbejde sammen, snarere end at være noget, man kan sigte direkte efter.

Så de tre punkter, jeg styrer efter, er Kunden (sigtet — at løse det problem, folk virkelig ville savne), Craft (svinget — at bygge det godt, og blive bedre ved at bygge det) og Kapital (det lange spil — at holde sig stærk nok til at spille runden færdig, og holde viden inde i huset, så intet vigtigt bor i ét enkelt hoved). Læn dig for hårdt op ad én af dem, og du slicer; få alle tre til at svinge sammen, og bolden falder i.

Hvad jeg har læst, og hvad jeg tog med

En god del af målene ovenfor — den høje bar, tilliden, den næsten fraværende proces — har jeg fra No Rules Rules, Reed Hastings’ og Erin Meyers bog om, hvordan Netflix bliver drevet. Argumentet, komprimeret: skru talenttætheden op, til du har et team af fremragende folk, brug åbenhjertighed til at holde dem ærlige over for hinanden, og begynd så at fjerne reglerne — for de fleste regler findes for at forhindre dårlige udfald fra middelmådige præstationer, og har man ikke dem, koster reglerne mere, end de sparer.

Den del, jeg vender tilbage til igen og igen, er udgiftspolitikken. Den koger ned til én enkelt instruks: handl i virksomhedens bedste interesse. Det ligner en politik om kvitteringer. Det er det ikke. Det er en erklæring om, hvem der har ansvaret. En regelbog rækker dig et svar, en anden har regnet ud engang, til en situation, der måske ikke længere er din. Én instruks rækker dig målet og lader dig selv finde svaret til den situation, du faktisk står i. Det er mere vægt at bære. Det er også det, der gør dig til en reel del af det hele i stedet for en, der eksekverer andres beslutninger — og det er der, kreativitet og initiativ kommer fra. Man får ikke en uventet god idé ud af en, der følger trin.

Den del, der skal trænes. Intet af det virker uden åbenhjertighed, og åbenhjertighed kommer ikke gratis — for nogen. Trækket mod at glatte tingene ud er universelt, og at holde af nogen uden at sige tingene er den fejltype, der føles venlig og ikke er det. Fjern reglerne og behold høfligheden, og du får ikke frihed. Du får et team, der stille driver, mens alle gætter.

Så jeg læste også Radical Candor, Kim Scotts bog om præcis det her — brugbar feedback kræver begge halvdele på én gang: man skal faktisk holde af mennesket, og man skal faktisk sige tingene. Deraf dette løfte, på skrift, hvor enhver kan holde mig fast på det: forvent, at jeg er meget klar omkring, hvad jeg mener, hvad jeg har besluttet, og hvorfor — også når svaret er, at jeg tog fejl.

Og alligevel — ikke en kultur, man kan kopiere. Ét forbehold over det hele. Jeg vil ikke importere Netflix’ kultur en bloc. Den voksede ud af en bestemt virksomhed, i et bestemt marked, i en bestemt størrelse, og meget af det, der får den til at virke dér, rejser ikke godt. Bogens berømte skarpe kant rejser dårligst af det hele: keeper-testen, hvor enhver, en leder ikke ville kæmpe for at beholde, bliver sendt afsted med en generøs fratrædelse. Den del ville jeg lade blive helt og aldeles. Talenttæthed tjent ved at ansætte omhyggeligt er noget andet end talenttæthed vedligeholdt ved at skære fra — og en så hård kant har meget amerikanske rødder. Det er ikke sådan, jeg ville ønske, et lille team i Danmark skulle føles. Der er mindst lige så meget at hente i, hvordan dygtige folk i virksomheder som Google og Apple har bygget og drevet deres teams — og de kulturer er uenige med Netflix’ på flere punkter, med vilje. Vores bliver sin egen — formet i Ry, ikke kopieret ind fra Californien. Den virkelige test af alt det her er, hvad alle gør, når ingen håndhæver noget.

Hvilket lander tilbage, hvor udgiftspolitikken startede. Overtag ikke andres regelbog. Overtag vanen med at spørge, hvad der reelt er bedst her, lige nu, med de mennesker vi faktisk har — og bliv ved med at være villig til at ændre svaret, når situationen gør.

En note til fremtidige mig

Når du læser det her, ved du alt det, jeg ikke gør. Startdatoen. Om de første halvfems dage gik efter planen. Hvilke af disse mål der overlevede mødet med virkeligheden, og hvilke der var sødt naive. Noget af det vil se indlysende ud bagefter. Noget af det vil se sjovt ud.

Jeg ville have det skrevet ned, før jobbet kunne begynde at forme mine svar — mens det hele stadig er overbevisning, før det størkner til erfaring.

Thomas spøgte allerede med, at mit første lange svar til ham læste som en roman. Betragt dette indlæg som efterfølgeren. Længere, og denne gang offentlig. Lad os se, hvor tæt jeg ramte.