Der er to historier om AI og kode. Den ene er den alle taler om: at sprogmodeller skriver programmer for os. Den anden er den der er vigtigere, men som næsten ingen taler om: at programmer holder sprogmodellerne i skak.
De to historier er den samme historie. Men man skal fortælle dem sammen for at forstå hvor feltet egentlig er på vej hen.
Hvad modellen gør for koden
Den første halvdel er velkendt. Jeg skriver kode hver dag sammen med en sprogmodel. Den kender syntaks bedre end jeg gør, husker standardbiblioteket bedre end jeg gør, og kan skrive en test hurtigere end jeg kan formulere hvad der skal testes.
Det er ikke trivielt. Det er ikke "autocomplete på steroider", som den kedelige version af fortællingen lyder. Det er at en kollega med et encyklopædisk overblik sidder ved siden af mig, og jeg kan bede om et udkast på en funktion, en refaktorering, et bud på hvorfor en test fejler. Otte ud af ti gange rammer den rimeligt. To ud af ti gange ved jeg mere end den, og jeg retter.
Det er arbejdsdelingen. Ikke erstatning. Ikke magi. Arbejdsdeling.
Hvad koden gør for modellen
Den anden halvdel er mindre synlig, men den er grunden til at AI-systemer begynder at virke i produktion.
En sprogmodel alene er upålidelig. Den hallucinerer, den glemmer, den vælger ord ud fra sandsynligheder, ikke fakta. Hvis du beder den om at regne på et regnskab, gætter den sig frem. Hvis du beder den om at finde en fil, opfinder den måske stien.
Svaret er ikke at lave en bedre model. Svaret er at stoppe med at bede modellen om at gøre alt.
Du giver den et værktøj i stedet. Et stykke kode der regner rigtigt. En funktion der virkelig henter filen. En database der faktisk har de rigtige tal. Modellen bliver orkestrator, ikke motor. Den beslutter hvad der skal gøres, koden gør det.
Det er her det symbiotiske forhold bliver konkret. Modellen er fleksibel men upålidelig. Koden er stiv men korrekt. Sæt dem sammen, og du får et system der både kan forstå sprog og levere præcise resultater.
Nushell som eksempel
Jeg bruger Nushell som min daglige shell. For dem der ikke kender det: Nushell er en shell hvor alt er struktureret data. I stedet for at sende tekststrømme mellem programmer, sender Nushell tabeller og records med typer.
ls | where size > 10mb | sort-by modified er ikke tekst der parses. Det er en tabel der filtreres og sorteres. Hver kolonne har en type. Hver operation er en transformation af strukturen.
Det betyder to ting i samspillet med en sprogmodel.
Den første: modellen kan skrive Nushell-kode der næsten altid virker, fordi fejltolerancen er lav og strukturen er eksplicit. Når den skriver from csv | where amount > 1000, ved den præcis hvad kolonnerne hedder og hvilken type de har. Mindre raden, færre hallucinerede feltnavne.
Den anden, og vigtigere: når modellen skal arbejde med mine data, kan jeg give den Nushell som værktøj. Den udtrykker sin intention i et lille script, scriptet kører mod faktiske filer, og resultatet kommer tilbage som struktureret data modellen kan arbejde videre på.
Der er intet magisk i det. Det er bare at vælge et værktøj hvor strukturen er synlig nok til at modellen forstår den, og stiv nok til at den ikke kan digte sig igennem.
Compound AI systems
Der er et navn for det her. Det kaldes compound AI systems — sammensatte systemer hvor én eller flere sprogmodeller indgår sammen med databaser, værktøjer, retrievers, kode og andre modeller. Det er blevet et forskningsfelt i sig selv, blandt andet fordi Berkeley og en række andre begyndte at påvise at kombinationen ofte slår en enkelt stor model, selv på benchmarks hvor sidstnævnte burde være bedst.
Pointen er ikke akademisk. Pointen er at den mest værdifulde AI-infrastruktur de næste år ikke er den næste generation af modeller. Det er arkitekturen omkring dem. Hvordan du kobler en model til dine data, hvilke værktøjer den kan kalde, hvordan du validerer dens output, hvordan du får den til at fejle pænt når den er i tvivl.
MCP — Model Context Protocol — er et eksempel. RAG-systemer er et eksempel. Agentic frameworks med typede værktøjer er et eksempel. Alt sammen er i bund og grund det samme mønster: modellen er ét komponent, koden er resten.
Hvor koden sætter rammen
Det interessante sker i grænsefladen. Modellen kan alt, men det kan ikke stoles på. Koden kan ingenting, men det kan stoles på. Hvad gør man?
Man skriver koden så den definerer hvad modellen overhovedet må forsøge. Et typet funktionskald med tre parametre. En valideret JSON-skemadefinition. En database-query hvor kolonnerne er kendt på forhånd. En permissionsmodel der siger nej til destruktive operationer uden bekræftelse.
Det er ikke begrænsninger på modellen. Det er stilladset rundt om den. Rammerne der gør at du kan stole på resultatet uden at stole på modellen.
Og modellen bliver faktisk bedre af at arbejde indenfor rammer. Et åbent spørgsmål giver vage svar. Et lukket spørgsmål med et typet funktionskald giver enten et korrekt kald eller en tydelig fejl. Begrænsninger er ikke modellens fjende — de er det der gør den brugbar.
Hvad det betyder i praksis
Jeg rådgiver virksomheder om AI, og jeg ser den samme fejl igen og igen. Nogen tror at AI-transformation handler om at finde den rigtige model. Eller den rigtige leverandør. Eller den rigtige chatbot.
Det gør det ikke. Det handler om hvilken kode du har omkring modellen. Hvilke data den kan tilgå. Hvilke værktøjer den kan kalde. Hvilke rammer du har sat for hvad der sker når den tager fejl.
En virksomhed med rodet data og ingen interne systemer får ingen glæde af verdens bedste sprogmodel. En virksomhed med ryddeligt datagrund, tydelige interne APIs og en kultur for at skrive ting ned, får enorm glæde af selv en middelmådig model.
Symbiosen er asymmetrisk. Modellen er kommerciel infrastruktur du kan købe adgang til. Koden er noget din organisation selv skal bygge — eller have bygget. Og det er koden der bestemmer hvor langt du kan komme.
Det det ikke handler om
Det handler ikke om at skrive mere kode. Det handler om at skrive den rigtige kode.
Det handler heller ikke om at modellen "forstår" din kode. Den forstår ingenting. Den er en probabilistisk tekstgenerator med ekstremt meget træningsdata. Men den er god nok til at være den fleksible del af et system, hvis du bygger den stive del ordentligt.
Det er symbiosen. Ikke en ny programmeringsparadigme. Ikke enden på software engineering. Bare en ny opdeling af arbejdet, hvor den del vi er dårligst til — at huske enorme mængder detaljer og formulere plausibel tekst — er outsourcet, og den del vi stadig er bedst til — at definere rammer, validere korrekthed, beslutte hvad der gælder — er hvor vi bruger vores energi.
Det er det der virker. Og det er det der vil virke de næste mange år.