## [Nushell og kunsten at sætte AI i bur](/da/node/191) *Indsendt af Lennart den ons, 15 apr 2026 - 11:57* ![Nushell og kunsten at sætte AI i bur](/sites/default/files/styles/wide/public/2026-04/composite_1.png.webp?itok=6yjfc8Em) Jeg skrev for nylig om hvordan jeg automatiserer mine blogudgivelser i én kommando — tekst ind, artikel med billede ud. Det flow kører i et shell de fleste aldrig har hørt om: Nushell. Og det er ikke et tilfældigt valg. Når jeg bygger det jeg kalder *compound AI systems* — altså systemer hvor eksempelvis sprogmodeller og billedmodeller er sat sammen med andre komponenter til at løse en rigtig opgave — så er langt det vigtigste spørgsmål ikke "hvilken model bruger vi?". Det er "hvad omgiver vi modellen med?". Og det er dér Nushell kommer ind. ## Problemet med kun at have AI En sprogmodel er probabilistisk. Den gætter kvalificeret. Giv den den samme prompt to gange og du kan få to forskellige svar\*. Det er ikke en fejl — det er designet. Kreativitet kommer ud af usikkerhed. Det er også grunden til at AI alene aldrig kan være et produktionssystem. Et produktionssystem skal kunne regne med at trin 3 faktisk sker hvis trin 2 lykkedes, og at trin 4 får de data den forventer fra trin 3. Det kræver determinisme på rørene — også selvom indholdet der flyder gennem dem er probabilistisk. Det mønster har et navn i forskningslitteraturen: *compound AI systems*. Det er systemer hvor AI-komponenter er omkranset af klassisk, logisk kode der styrer kontrol-flowet, validerer output, håndterer fejl og binder trinene sammen. Berkeley-laboratoriet BAIR skrev om mønsteret allerede i 2024, og det er reelt den eneste måde at få AI til at virke pålideligt i produktion. Kort sagt: AI'en er hjernen, men skeletet skal være determinisme. ## Hvad Nushell er — og hvorfor det passer Nushell er et shell — altså et kommandolinjeværktøj på samme måde som bash eller PowerShell — men med en afgørende forskel: det arbejder med *strukturerede data*, ikke med tekst-strømme. I bash sender du linjer med tekst gennem pipes. Hver kommando skal selv parse teksten og selv producere tekst der kan parses af den næste. Det er en uendelig øvelse i `awk`, `sed`, `cut` og skjulte antagelser om whitespace. I Nushell sender du tabeller, records, lister og primitive typer. Et pipe-trin ved *hvad* det modtager — ikke bare at det er tekst der ligner noget. Og vigtigst af alt: Nushell taler stort set alle de dataformater du støder på i moderne AI-arbejde, direkte og indbygget. ``` open data.json # parses til records open report.csv # parses til en tabel open config.toml # parses til en record open notes.md # åbnes som tekst, og fra nushell 0.112.1 faktisk som data http get https://api.../ # returnerer parsed JSON direkte ``` Alt sammen er det samme: strukturerede data du kan filtrere, transformere, joine og sende videre med samme syntaks. Og modsat i bash behøver du ikke engang en parser — formatet bliver tolket for dig. ## Hvorfor det her betyder noget for AI-systemer Et typisk compound AI-system består af tre slags trin: 1. **Datahentning** — hent noget fra en API, en database, en fil. 2. **AI-kald** — send det til en model og få noget tilbage. 3. **Efterbehandling** — valider, routs, gem, post videre. Hvert af disse trin leverer data i forskellige formater. API'et returnerer JSON. Databasen returnerer rækker. Modellen returnerer JSON eller markdown. Destinations-API'et vil have JSON i sit eget format. I bash ville det være en labyrint af `jq`, midlertidige filer og håndlavede parsere. I Nushell er det: ``` http get $api_url | where status == "pending" | each { |row| $row | llm "sammenfat sagen i 2 sætninger" | merge { case_id: $row.id } } | to json | http post $destination ``` Læg mærke til hvad der sker: en AI-model er sat midt ind i et pipeline, hvor inputtet er strukturerede rækker fra et API, og outputtet bliver merget tilbage med den originale `case_id`. Det sikrer at AI'ens output *kobles korrekt* til de data det hører til — ingen hallucineret ID, ingen forvekslet række. Den logiske limning er deterministisk. Kun den ene specifikke opgave — sammenfatningen — er AI. ## Kontrol-instanser rundt om modellen Det her er pointen jeg vil have frem: **AI skal sjældent være det yderste lag.** Det skal være et indre organ. Kontrol-instanserne rundt om modellen skal typisk: - **Validere input** før det når modellen. Er det faktisk den type data vi forventer? Er det for langt? Indeholder det følsomme data der skal maskeres? - **Strukturere output** fra modellen. Matcher svaret det skema vi forventer? Hvis ikke, prøv igen eller fejl hurtigt. - **Routere afhængigt af resultater**. Hvis konfidensen er lav, send til menneske. Hvis output er tomt, log og spring over. - **Logge alt**. Både input, prompt, output og beslutninger — så man kan debugge hvorfor systemet valgte som det gjorde. I Nushell skriver du den slags logik som let læsbare rør, tættere på engelsk end på kode: ``` let svar = $input | llm $prompt if ($svar | str length) < 10 { log warn "for kort svar, bruger fallback" $fallback } else if ($svar | from json | get confidence) < 0.7 { $svar | route-to-human } else { $svar | save-and-notify } ``` Det er ikke glamourøst. Det er præcis det sproget prøver at være — pragmatisk limning mellem systemer. ## Det vigtige princip: hvor er der AI, og hvor er der ikke? Når jeg hjælper en virksomhed med at designe et compound AI-system, er det første tavleøvelse altid den samme. Vi tegner alle trinene op. Og så sætter jeg et kryds ved hvert trin der *skal* være AI. Og et andet tegn ved hvert trin der *kan* være deterministisk kode. Næsten altid er der mange flere af den sidste slags end folk troede. Klassificering baseret på regler? Kode. Tjek om feltet er tomt? Kode. Formatér datoen om? Kode. Send resultatet til den rigtige afdeling baseret på en lookup-tabel? Kode. AI'en skal bruges dér hvor opgaven er sproglig, kreativ eller mønster-baseret på en måde der er for kompleks til regler. Alt andet er dyrere, langsommere og mindre pålideligt hvis AI får lov at gøre det. Nushell gør det nemt at have den arbejdsdeling, fordi det ikke føles som to forskellige verdener at sende data ind i en model og at filtrere en liste. Det er de samme pipes, de samme data-typer, det samme mentale model. ## Hvorfor ledere skal bryde sig om det her Det her er et teknisk valg på overfladen. Men det har direkte konsekvenser for tre ting ledelser bekymrer sig om: **Pålidelighed.** Et system hvor AI er indkapslet i deterministisk kode fejler forudsigeligt. Et system hvor AI er limen mellem komponenter fejler mystisk. Pålidelighed i produktion er altid et spørgsmål om hvor determinismen sidder. **Omkostninger.** Hvert AI-kald koster tokens. Et system der kalder AI ti gange om dagen er billigt. Et system der kalder AI ti gange per opgave fordi det gør *alt* med AI — også det deterministiske — er dyrt. Den økonomiske forskel mellem de to mønstre er ofte 10-100× på driftsomkostninger. **Reviderbarhed.** Kan I efter en fejl forklare hvorfor systemet gjorde som det gjorde? Hvis AI kun sidder ét sted i pipelinen, og resten er kode, kan I. Hvis AI sidder i hvert hjørne, kan I ikke. ## Hvad I skal spørge om Næste gang nogen præsenterer et AI-system for jer — intern udvikling eller ekstern leverandør — så stil det her spørgsmål: **"Hvilken del af det her er AI, og hvilken del er almindelig kode?"** Hvis svaret er vagt, er det fordi arkitekturen er vag. Hvis svaret er "alt er AI" eller "det er en ende-til-ende-model", så ved I at pålideligheden, omkostningerne og reviderbarheden er dårligere end de behøver være. Og hvis svaret er "AI sidder her, her og her, og resten er deterministisk kode med validering" — så står I sandsynligvis foran nogen der har bygget det slags system før. Shellet de bruger betyder mindre end princippet. Men princippet er vigtigere end modellen. --- \*Under meget kontrollerede forhold kan sprogmodeller sættes op så deres output bliver mere "deterministisk" og ens ved ens input, men selve processen undervejs bygger stadig på next token prediction ud fra sandsynlighed og ikke logik. LLM'er er induktive og ikke deduktive. ### Tags - [nushell](/taxonomy/term/3)