LLM'en bor i mit shell — og det ændrer alt

Jeg har bygget et lille Nushell-modul der hedder yolay.nu. Det er omkring 470 linjer kode. Det er det mest produktivitetsforøgende jeg har skrevet i år, og jeg tror det peger på noget bredere om hvordan AI bør integreres i en arbejdsdag — ikke kun min.

Modulet gør én ting: det loader en LLM-samtale som en overlay i mit shell. Samtalen lever i to miljøvariabler — $env.YO_CTX indeholder selve konteksten, $env.YO_CFG provider, model og tools. Jeg starter en samtale med say "...", fortsætter med , (komma — det vigtigste tegn på mit tastatur nu), ser sidste svar med reply, og kan til hver en tid trække svaret ud i en pipeline: reply | save -f udkast.md.

Det lyder banalt. Det er ikke banalt.

Friktionen jeg ikke længere har

Den klassiske AI-arbejdsgang er at man skifter kontekst. Man har sin terminal hvor det rigtige arbejde foregår, og så har man en chat-fane et andet sted hvor man spørger AI'en til råds. Hver gang man skifter, mister man noget. Man skal kopiere terminaludgangen ind i chat-feltet. Man skal limen svaret tilbage. Man skal tænke i to formater på samme tid: shell-data på den ene side, prosa på den anden.

Med yolay forsvinder det skifte. Mine egne nushell-kommandoer og LLM'en lever i samme proces, taler samme sprog (data), og kan piperes ind i hinanden:

ls **/*.md | where size > 10kb | get name | to text | say "hvilke af disse bør jeg flette sammen?"

Der er ingen copy-paste. Der er ingen fane-skift. LLM'en er bare endnu en kommando i pipelinen — ligesom where, sort-by eller save. Og dens svar er bare endnu en streng som jeg kan sende videre med reply | ....

Det betyder at mine skræddersyede nushell-moduler — email, drupal, linkedin, iwe, alt det jeg har bygget gennem måneder — kan tale med en LLM uden at jeg skal lave en eneste integration mere. De er allerede integreret. Pipelinen er integrationen.

Hvorfor det holder mig i førersædet

Det her er ikke en agent der overtager. Det er det modsatte.

I de sædvanlige agent-rammer afgiver man kontrollen for at få hastigheden. Man fortæller agenten et mål, så går den i gang og rapporterer tilbage når den er færdig. Det fungerer for nogle ting. Men jeg sidder ikke længere i førersædet — jeg sidder på bagsædet og håber på det bedste.

yolay vender det om. Hver tur er én kommando. Jeg ser stream'et live: assistent-tekst grøn, tool-kald magenta, output dæmpet. Når et turn er færdigt, er jeg tilbage ved prompten. Jeg kan:

• skrive , og fortsætte samtalen
• skrive pop og slette sidste exchange hvis den gik galt
• skrive tools none for at fjerne værktøjsadgangen for næste turn
• skrive tools bash read_file for at give præcis det jeg vil
• skrive model claude-sonnet-4-6 for at skifte til en stærkere model
• skrive snap session.jsonl for at gemme konteksten til senere
• skrive en almindelig nushell-kommando, fordi det stadig er mit shell

Jeg er i loopet. Jeg afgiver ikke kontrollen — jeg uddelegerer enkelte træk. Forskellen er stor. En agent der kører autonomt i tyve minutter og kommer tilbage med en mappe fuld af ændringer, er svær at gennemskue. En LLM der gør én ting, viser mig resultatet, og venter på næste instruktion, er let at gennemskue.

Human in the loop er ikke et compliance-buzzword her. Det er hvordan modulet er bygget. Loopet er bogstaveligt: prompt → svar → prompt. Min hjerne sidder mellem hvert led.

Hastighed uden at miste klarheden

Det paradoksale er at den her form for tæt menneskelig kontrol ikke er langsommere. Den er hurtigere.

Når jeg arbejder med en autonom agent, bruger jeg meget tid på at læse efter — gennemgå hvad den har lavet, finde fejlene, rette dem op. Når jeg arbejder med yolay, ser jeg hvert træk i det øjeblik det sker. Fejl bliver fanget mens de stadig er små. Jeg taber ikke ti minutter på en forkert antagelse jeg burde have stoppet efter ti sekunder.

Og fordi konteksten bliver i mit shell, kan jeg lade samtalen vokse over en hel arbejdsdag. Jeg starter en yolay-overlay om morgenen, og den er stadig der ved frokost — med al historikken intakt. Jeg kan blande deterministiske kommandoer ind imellem (læse en fil, køre et iwe retrieve, åbne min email) uden at miste samtaletråden.

Det er den samme kontekst som agenter i baggrunden bruger — men jeg er den der bestemmer hvornår der er brug for et nyt turn, og hvad det turn skal handle om.

Hvad det fortæller om AI-værktøjer generelt

Jeg tror grundpræmissen i de fleste AI-produkter er forkert. De forsøger at være destinationen — chat-vinduet, IDE'en, app'en hvor man "går ind for at bruge AI". Men det rigtige sted for AI er ikke en destination. Det er et lag i det værktøj man allerede bruger.

For en udvikler er det shellet. For en jurist er det dokumentredigeringen. For en analytiker er det regnearket. AI'en bør være tilgængelig hvor arbejdet allerede foregår, og den bør tale samme sprog som de andre værktøjer på det sted. Når den ikke gør det, betaler man en friktionsskat på hvert eneste turn.

yolay er ikke unikt på den måde. Det er bare en illustration af et princip jeg gerne vil insistere på i min rådgivning: AI skal indlejres i arbejdsstrømmen, ikke leve ved siden af den. Den der bygger AI ind i sit shell, sin email, sit CRM eller sit notatesystem, får mere ud af det end den der starter en fane op og kopierer ind og ud.

Den korte version

yolay.nu er 470 linjer Nushell der gør én ting: den lader en LLM bo som en overlay i mit shell, så den taler det samme sprog som mine egne kommandoer og kan piperes ind og ud uden friktion. Den fjerner kontekst-skiftet til chatten. Den giver mig hastigheden fra LLM'en og værktøjerne uden at tage førersædet fra mig.

Det er ikke noget særligt teknisk. Det er en holdning til hvordan AI skal integreres: tæt på arbejdet, under min kontrol, ét turn ad gangen. Den holdning kan implementeres i mange værktøjer — den behøver ikke være Nushell. Men den er sjældent default. Det er den værd at insistere på.