Helge Sverre lager eget språk for KI: Sema

Jeg sendte kode24 en pinlig entusiastisk e-post her om dagen: jeg har laget en Lisp, slengt LLM-er oppå, og gjort den praktisk nok til at jeg faktisk gidder å bruke den selv.

Språket heter Sema. Det er en Scheme-aktig Lisp skrevet i Rust, der LLM-greiene er bygget rett inn i språket – ikke limt på utenpå.

Ja, det høres ut som en smal hobbygreie. Det er det også. 

Men ideen bak er litt mindre sprø enn den kan virke: Lisp kan faktisk være et av de beste språkene vi har for kodeagenter.

Grunnen er nesten dum i sin enkelhet: Lisp har knapt nok syntaks.

Ingen import eller rammeverk

Programmer er lister. Data er lister. Kode er data. Det er parenteser hele veien ned. 

Akkurat det er jo som regel det folk gjør narr av Lisp for – men for en språkmodell er det en superkraft. Jo mindre syntaks et språk har, jo færre dumme småting kan modellen surre til. 

Ingen import-magi, ingen rammeverk som har bytta API siden modellen sist ble trent, ingen prosjektstruktur den må gjette seg fram til.

En kodeagent trenger egentlig ikke et språk vi mennesker synes er pent. Den trenger et språk som er lett å produsere, lett å parse, lett å sjekke – og lett å reparere når noe går galt. 

Og der begynte Lisp plutselig å se interessant ut igjen.

Magnus gir agenter tilgang til Sparebank 1

– Jeg skrev ingenting av koden for hånd, forteller utvikler Magnus Rødseth. Han koblet bankkontoen til KI-agenten, fikk øl-råd og deler nå prosjektet.

Slipper kaoset

Vanligvis, når jeg vil prøve ut noe med en LLM, ber jeg Claude-en min om å skru det sammen i Python og LangChain. 

Så går det ti minutter med feiling: den plukker feil Python-versjon på Mac-en, jeg sitter og maser desperat om at den må bruke uv til venv-en, et eller annet pip-wheel-bygg kræsjer, en TensorFlow-versjon krangler med en annen pakke – og vips, så er vi nede i kaninhullet. 

Bytter jeg til JavaScript er det samme visa: det som funker i npm knekker i bun, eller omvendt, og et sted i kaoset ligger det et dusin rammeverk som alle løser nesten det samme problemet.

Og når det omsider funker, gjenstår fortsatt jobben med å bygge min egen retry-logikk, cache, kostnadskontroll, fallback mellom leverandører og tool-calling oppå det hele. Jeg ville se hva som skjedde hvis alt det der bare var en del av selve språket i stedet.

Sema er forsøket mitt på å ta den tanken helt ut.

Se selv

I Sema er ikke en prompt bare en streng du dytter inn i et SDK. 

En samtale er en verdi. Et verktøy er en funksjon med et schema. En agent er noe du definerer rett i språket. 

Budsjett, caching, fallback og strukturert output er ikke stillas du bygger rundt programmet – det er innebygde språkkonstruksjoner. Resultatet er at et lite AI-script kan handle om selve jobben, og ikke om alt rørleggerarbeidet rundt.

Et lite eksempel sier mer enn avsnittet over. Her er et verktøy, en agent, og en kjøring – alt i språket selv:

;; Et verktøy er en funksjon. En agent er en verdi. AI-en er innebygd.

(deftool get-weather
  "Hent været for en by"
  {:city {:type :string :description "Bynavn"}}
  (lambda (city)
    (http/get (str "https://wttr.in/" city "?format=3"))))

(defagent weather-bot
  {:system "Du er et kortfattet vær-orakel. Bruk verktøy."
   :tools [get-weather]
   :max-turns 5})

(agent/run weather-bot "Hva er været i Bergen nå?")

Absurd, men nyttig

Men skulle dette bli noe mer enn en gøy REPL, måtte resten av verktøykassa på plass også – det er liksom forventet av et språk i 2026. 

Så jeg har lagt ned overraskende mange timer, de fleste av dem ganske gøye, i formatter, LSP, debugger, CLI, dokumentasjon, en playground i nettleseren, editor-støtte, sandboxing og bygging av standalone executables. 

Sema er på 1.19.1 nå. Fortsatt ungt, men ikke bare en kodesnutt med parenteser.

Jeg har også bygget inn MCP-støtte. I praksis betyr det at Sema kan eksponere formattering, evaluering, bygging og dine egne deftool-verktøy rett til LLM-klienter som Claude Desktop, Cursor og Claude Code – og at en Sema-binær kan kjøres som en MCP-server. 

Det er litt absurd, men på en nyttig måte: du kan skrive et bittelite Lisp-verktøy, bygge det til én enkelt fil, og la en agent bruke det som et ekte verktøy.

– Staten tilbyr åpne API-er. Det vanskelige er å finne veien gjennom dem

Ole Fredrik Lie lagde Wenche for å sende inn tall til staten, og fikk hjelp av Claude Code til å navigere det komplekse landskapet. – Dette er kanskje den mest undervurderte KI-bruken.

Tror ideen holder vann

Så – kommer folk til å bruke Sema? Helt ærlig: jeg aner ikke.

Utviklere har allerede Python, TypeScript, Clojure, Racket, Bash, LangChain, notebooks, et hav av SDK-er og femten måter å lime sammen LLM-kall på. Og akkurat nå kan man jo få en agent til å generere nesten hva som helst uansett.

Men det er egentlig nettopp derfor jeg tror ideen holder vann. Når mer og mer kode blir generert av modeller, blir spørsmålet "hva er lett for et menneske å skrive for hånd?" litt mindre viktig. "Hva er lett for en agent å generere riktig, verifisere og kjøre trygt?" blir desto viktigere. Og i det lyset ser gamle Lisp plutselig ganske moderne ut igjen.

Ikke fordi vi alle skal sitte og telle parenteser for hånd, men fordi Lisp kan funke som et lite, stabilt og ekstremt maskinvennlig mål for LLM-er og kodeagenter.

Skulle det vise seg at ingen bruker det, så er det helt greit. Jeg hadde det gøy mens jeg bygde det. Men jeg har en mistanke om at "Lisp som agent-språk" er en bedre idé enn den egentlig har lov til å være.

Lenge leve parentesene.

Eriks prosjekt tok av på Reddit: – Veldig gøy

– Jeg gjorde det mange utviklere gjør når de irriterer seg over et problem lenge nok: Jeg begynte å bygge løsningen selv, skriver Erik Lange om Eventclock.org.