Danske virksomheder med store kodebaser står over for et praktisk spørgsmål: hvordan får man AI-kodningsværktøjer til at virke på tværs af hundredtusindvis af linjer kode, fordelt på hundredvis af filer og mapper? Anthropic har netop offentliggjort deres erfaringer med Claude Code i store kodebaser, og et mønster går igen. De virksomheder der forbereder kodebasen før de ruller ud, får produktive udviklere fra dag et. De der springer det over, får frustrerede udviklere der dropper værktøjerne igen.
Hvorfor søge-indekser ikke holder i store kodebaser
De fleste antager at AI-kodningsværktøjer bruger en form for indeksering til at finde rundt i koden. At der er en søge-database i baggrunden der holder styr på funktioner, klasser og relationer. Det er ikke tilfældet.
Claude Code navigerer en kodebase som en menneskelig udvikler gør det. Den læser filer, søger med grep, følger referencer på tværs af mappen og bygger sig en forståelse op undervejs. Ingen vektor-database, ingen embedding-indeks, ingen RAG-pipeline.
Det er en bevidst designbeslutning. Indekser bliver forældede. Den funktion teamet omdøbte for to uger siden dukker stadig op i søgeresultaterne. Den fil der blev slettet i fredags ligger stadig i embeddings. For små projekter er det et irritationsmoment. For store kodebaser med daglige ændringer er det en kilde til fejl der underminerer tilliden til værktøjerne.
Den agentbaserede tilgang undgår problemet ved at arbejde direkte med den aktuelle tilstand af koden. Men den stiller også højere krav til hvordan kodebasen er struktureret. Hvis mappestrukturen er ulogisk, filnavne er vilkårlige, og der ikke er nogen ledetråd for værktøjerne, tager det længere at navigere - præcis som det ville for en ny udvikler på teamet.
Fem udvidelsespunkter der styrer AI-værktøjerne
Anthropic beskriver en model med fem konkrete steder hvor virksomheden kan konfigurere hvordan AI-værktøjerne opfører sig. Tænk på det som fem håndtag der tilsammen afgør om værktøjerne følger teamets konventioner eller opfinder deres egne.
- Kontekstfiler - korte instruktionsfiler der automatisk indlæses når værktøjerne starter. De fortæller hvad der er vigtigt i netop dette projekt: navnekonventioner, arkitekturbeslutninger, filer der ikke må røres.
- Hooks - scripts der kører på bestemte tidspunkter, fx før en fil gemmes eller efter en ændring er lavet. De sikrer at teamets regler overholdes automatisk.
- Skills - pakkede instruktionssæt til specifikke opgaver som værktøjerne kun indlæser når de er relevante. Det holder den daglige kontekst slank.
- Plugins - bundtede konfigurationer der kan deles på tværs af teams. De forhindrer at gode opsætninger forbliver stamme-viden hos den ene udvikler der satte det hele op.
- Værktøjs-servere - forbindelser til interne systemer og API'er som værktøjerne ikke selv kan tilgå. Ticketsystemer, databaser, deployment-pipelines.
Ingen af disse er komplicerede i sig selv. Det afgørende er at nogen tager ejerskab over dem og vedligeholder dem løbende.
Tre mønstre fra virksomheder der lykkes
Anthropics erfaringer peger på tre organisatoriske mønstre der går igen hos de virksomheder der får reel værdi ud af AI-kodningsværktøjer.
Det første er at gøre kodebasen navigerbar. Det handler om pragmatiske ting: hold instruktionsfiler korte og relevante, scop dem til undermapper i stedet for at lægge alt i roden, ekskluder genererede filer så værktøjerne ikke spilder tid på dem, og byg et oversigtskort når mappestrukturen ikke er selvforklarende. Virksomheder der deployer sprogservere til symbol-navigation rapporterer markant bedre resultater. Et firma deployede LSP-servere på tværs af hele organisationen specifikt for at gøre C og C++ navigation pålidelig før de rullede AI-værktøjerne ud.
Det andet er aktiv vedligeholdelse. AI-modeller forbedres hurtigt. Regler der var nødvendige for seks måneder siden kan være bremser i dag. En begrænsning der forhindrede modellen i at arbejde på tværs af filer gav mening med ældre modeller, men blokerer bedre resultater med nyere. Anthropic anbefaler at gennemgå konfigurationen hver tredje til sjette måned eller efter store modelopdateringer.
Det tredje er organisatorisk ejerskab. Det er her skellet er størst. De udrulninger der spredte sig hurtigst havde en dedikeret infrastrukturinvestering før bred adgang blev givet. Ikke et stort team - en enkelt person med mandat over konfiguration og governance er nok som minimum.
Infrastruktur først slår bund-op adoption
En af de tydeligste observationer er forskellen mellem virksomheder der bygger infrastrukturen før de giver bred adgang, og dem der lader individuelle udviklere finde ud af det selv.
Bund-op entusiasme kan drive hurtig adoption, men den fragmenterer uden nogen der centraliserer hvad der virker. Hvert team opfinder sine egne konventioner. Gode opsætninger bliver ikke delt. Nye udviklere starter fra nul hver gang.
Infrastruktur-først tilgangen sikrer at udviklernes første oplevelse er produktiv. Værktøjerne kender allerede teamets konventioner, ved hvilke filer der er relevante, og følger de rigtige mønstre. Det er forskellen på et værktøj der føles som en erfaren kollega og et der føles som en praktikant på første dag.
Det mønster er velkendt fra andre teknologiskift. Virksomheder der ruller nye værktøjer ud uden forberedelse ender ofte med at projekterne aldrig når den forventede værdi. Fundamentet afgør udfaldet.
En ny rolle er ved at tage form
Anthropic beskriver en fremvoksende funktion de kalder en "agent manager" - en hybrid mellem projektleder og ingeniør der tager ansvar for AI-værktøjsøkosystemet. Rollen handler om at vedligeholde konventioner, udvikle skills og plugins, holde konfigurationer opdaterede og sikre at nye teammedlemmer får en produktiv start.
Det er ikke en fuldtidsstilling i de fleste organisationer. Men det er en funktion der skal varetages af nogen. Uden ejerskab forfatter konfigurationen, gode praksisser spredes ikke, og værktøjerne degraderer stille og roligt.
I regulerede brancher har virksomheder allerede etableret tværfaglige arbejdsgrupper med repræsentanter fra udvikling, sikkerhed og governance. Det er den slags struktur der giver mening når AI-værktøjer får adgang til produktionskode og interne systemer.
Hvad det betyder for danske virksomheder
De fleste danske virksomheder med store kodebaser bruger allerede AI-kodningsværktøjer i en eller anden form. Spørgsmålet er ikke om de skal bruge dem, men om de får reel værdi ud af dem.
Mønstrene fra Anthropics erfaringer peger i en retning der burde være genkendelig for enhver dansk virksomhedsleder: struktur før skalering, vedligeholdelse af det der er sat op, og klart ejerskab. Det er ikke AI-specifikke principper. Det er grundlæggende organisatorisk hygiejne.
Tre konkrete skridt er værd at overveje:
- Gennemgå jeres kodebase med friske øjne. Er mappestrukturen logisk? Er navnekonventioner konsistente? Kan en ny udvikler - menneskelig eller AI - finde rundt uden at spørge?
- Udpeg en ansvarlig. En person der ejer konfigurationen, indsamler hvad der virker, og sikrer at gode praksisser deles på tværs af teams.
- Genbesøg konfigurationen regelmæssigt. Modellerne ændrer sig. Regler der var nødvendige i januar kan være overflødige i juni.
Virksomheder der vil have hjælp til at finde den rigtige tilgang til AI i deres udviklingsteams bør starte med kodebasen, ikke med værktøjerne. Strukturen kommer først. Værktøjerne følger efter.
Kilde: Anthropic
