Ole Tange, IT-nørd, programmør og politisk rådgiver i PROSA tilbragte en weekend med Claude Code. Det blev til både jubel, overraskelse, læring og mange aha-oplevelser. Han måtte blandt andet tage sig selv i flere gange at sige: "fuck hvor er det fedt".
Kodning med Claude og VSCodium - Produktivitet, eksperimenter – og faldgruber:
Jeg brugte min weekend i selskab med Claude og VSCodium.
Det blev en ret intens introduktion til, hvad AI-assisteret ud vikling faktisk kan – og hvor det stadig halter.
Allerede fra start ramte jeg nogle praktiske begrænsninger.
Claude har både en 5-timers grænse for brug og en ugentlig kvote, og jeg ramte ret hurtigt loftet.
Samtidig er det relativt dyrt at tilkøbe ekstra tokens.
Min løsning blev at oprette en ekstra konto og skifte mellem dem ved at flytte Claudes konfigurationsmappe.
Det fungerer – men har den ulempe, at samtalehistorikken følger kontoen.
Det betyder, at jeg ikke bare kan fortsætte en samtale på tværs af konti. Det var i praksis et minimalt problem.
Selve opsætningen i VSCodium var til gengæld ligetil.
Det den fedeste oplevelse, jeg har haft i længe: Jeg godkender en plan, sætter processen i gang – og ser derefter systemet arbejde sig frem mod en løsning.
Claude installeres som plugin i VSCodium, og med få klik via browseren er kontoen tilknyttet.
Konfigurationen ligger typisk i ~/.claude, og derefter er man i gang. Arbejdsgang: plan, kod, test.
Til større ændringer fungerede det rigtig godt for mig at starte med at bede Claude om en plan.
Når planen så fornuftig ud, bad jeg den implementere den – og derefter køre tests. Det lyder simpelt, men det ændrede faktisk min måde at ar bejde på.
Jeg fik tænkt ændringerne langt bedre igennem først, i stedet for at hoppe direkte i koden med en mindre klar ide om, hvad der skal ændres. Og hvis planen var forkert, var det nemmere at rette planen end koden bagefter.
Claude fangede ofte, at en ændring ville medføre kodeændringer andre steder i koden.
Nogle af disse ville jeg først have fanget under test. Automatiske tests som motor Automatiske tests er det, der virkelig viser styrken i en AI agent. Ikke bare fordi tests altid er gode – men fordi de gør det muligt at sætte udviklingen på autopilot i korte stræk.
Måske kender du test-driven-development?
Det er dét, men hvor du nærmest får foræret løsningen, hvis du bare har en god test.
Du kan ovenikøbet bede AI’en om at komme med forslag til testen, hvis du beskriver dit problem.
Når først testen er defineret, kan jeg i praksis bede agenten om at rette koden og genteste, indtil testen går igennem.
Fuck. Det. Er. Fedt.
Det den fedeste oplevelse jeg har haft i længe: Jeg godkender en plan, sætter processen i gang – og ser derefter systemet arbejde sig frem mod en løsning.
Jeg kigger ofte med i hvad Claude tænker, så jeg kan stoppe den, hvis den er på vej mod en forkert løsning.
Det er også skægt at se, når den når frem til samme konklusioner som jeg selv.
Når der er en løsning, skal mennesket stadig kvalitets sikre den.
Det kan ske her eller når ændringen senere committes til master-branch.
Hurtig afprøvning af “for vilde” idéer:
En af de største gevinster for mig var muligheden for at teste idéer, som ellers bare ligger i skuffen.
Jeg havde tre ændringer i tankerne, som hver især krævede ret omfattende indgreb i koden – uden garanti for forbedringer.
Hver af ændringerne ville nok have kostet en vinterferie at skrive om, og derfor har jeg ikke priorite ret dem.
Med Claude kunne jeg hurtigt få implementeret hver variant og køre dem igennem mine tests.
Resultatet var ret tydeligt: To af idéerne gav forbedringer under specifikke forhold, men en generel performance-penalty.
Den tredje gav for bedringer uden nævneværdige ulemper.
Den beholdt jeg – de to andre blev rullet tilbage.
Den største gevinst for mig er ikke kun hastighed, men at jeg faktisk får gjort ting, jeg ellers har udskudt.
Kodekvalitet: Ofte god – med fejlskud ind i mellem:
Generelt rammer Claude rigtigt.
Men jeg oplevede også tilfælde, hvor den lavede ændringer på 100 linjer, som i princippet kunne have været løst med én linje et andet sted.
Heldigvis kunne jeg skubbe den i den rigtige retning.
Et simpelt spørgsmål som “kunne det løses enklere rette dette andet sted?” var nok til, at den selv fandt en bedre løsning.
Det er nok her, at jeg ser den største risiko for AI-slop:
En ikke-programmør vil være ligeglad med, at der bliver lavet 100 linjer, som gør koden mere uoverskuelig – i stedet for en-linjes-ændringen.
Men det kræver, at man også kender den anden del af koden.
Til gengæld oplevede jeg ingen egentlige syntaksfejl.
Ophavsret:
Den kode, som blev genereret, var så skræddersyet til resten af min kode, at jeg på ingen måde er nervøs for, at der skulle være kopieret større afsnit ind af træningskode.
Det ville nok være anderledes, hvis jeg havde bedt den lave hundredvis af linjers generisk kode.
Da min software er open source, har jeg heller ingen bekymringer ved, om den bliver brugt til træning eller kom mer i hænderne på en konkurrent: Der er ingen fortrolige data i koden.
Commit, commit, commit:
Jeg fandt ud af, at jeg committer alt for sjældent.
Nu committer jeg efter hver eneste ændring – stor som lille, og Claude er ret god til at foreslå commit-beskeder.
Men hundredevis af småcommits med 2 linjes ændringer, hvor halvdelen bliver rullet tilbage to commits senere, er til gengæld noget, som dine kolleger vil hade dig for: Commits skal have en størrelse, at de udgør en afgrænset forståelig ændring.
Jeg lavede derfor en simpel regel: hvis commit-beskeden starter med “.”, er det en småændring, der senere skal samles med andre ændringer.
Her er interaktiv rebase uundværlig: git rebase -i HEAD~30
Den gør det muligt at samle commits og rydde op – ofte uden konflikter, hvis ændringerne hver især er små.
Når du så har rebaset, så kan du pushe til master (eller til jeres CI/CD).
Jeg skriver mindre kode – og bruger mere tid på at tænke, styre og kvalitetssikre.
Konklusion: et stærkt værktøj – med få forbehold:
Alt i alt er jeg positivt overrasket.
Den største gevinst for mig er ikke kun hastighed, men at jeg faktisk får gjort ting, jeg ellers har udskudt.
Små fixes, eksperimenter og oprydning bliver pludselig realistiske.
Jeg prøvede også et plugin fra Google, men oplevede flere fejl og behov for holde den i hånden langt mere.
Jeg fik heller aldrig OpenAI Codex til at fungere tilfredsstillende i min opsætning.
AI’en erstatter mig ikke som udvikler. Den ændrer min rolle.
Jeg skriver mindre kode – og bruger mere tid på at tænke, styre og kvalitetssikre. Og hvis jeg ikke gør det ordentligt, så risikerer kvaliteten at falde lige så hurtigt, som produktiviteten stiger.
Jeg har tidligere omtalt AI som en junior-programmør, som det er gratis at give opgaver til – det holder stadig stik.
Nyskabelse:
Der er eet sted, hvor AI ser ud til at komme til kort: At skabe noget, som aldrig er bygget før.
AI er fin til at finde løsninger, hvor vi allerede kender noget, der ligner.
Og det gælder for langt hovedparten af vores software. Men jeg spår, at der stadig vil være behov for forskning i nye algoritmer.
Måske tager jeg fejl. For vi har allerede set AI kan noget, der i hvert fald minder om kreativitet.
Læs også: Jeg er meget imponeret - og lidt skræmt
