Clojurians Log v2

De fleste har byttet til "orkestrator"

Ja er ikke det bare Skatteetatens IT-avdeling? 😅

Har du husket å bruke en av de 64 andre titlene utviklere har? Om jeg ike husker feil, får du dårligst betalt når du kaller deg programmerer.

det ser ut som de har slått sammen et eller annet, får samme tall uansett hvilke av de 15-20 ulike titlene for utvikler

25 000 menn og 9000 kvinner har tittelen systemutvikler i den løsningen.

ah, hva er forskjellen på en systemutivkler og en programmerer, mon tro

Det ene er en gruppe som får dårligere betalt fordi de ikke har lært seg corporate speak

Hmm, i denne oversikten er det motsatt fra andre lønnsundersøkelser jeg har sett før.

Det var ikke så stor forskjell på de to i denne undersøkelsen. De fleste jeg har sett før har mye større forskjell basert på hvilken tittel du har prestert å få.

Tekna skiller kun på bransje, og der faller vi inn under "IKT (data/it)"

jeg er CTO nå, gleder meg til milliardene skal renne inn

egentlig litt kleint, har det i e-postsignaturen mest så folk vi snakker med vet hvem de skal hendvende seg til om tech-spørsmål

Ja, jeg er litt misfornøyd med Tekna der, for de er mer detaljert på ingeniørfag enn de er på IT.

Kode24 har mer detaljerte tall basert på rolle, men så er det jo et spørsmål om de har nok svar til at den er god. https://kodejobb.no/lonn

Nå er jeg i gang med å analysere hele Clojure repoet med toolet mitt som en større test. Hvis det funker, skal jeg kjøre toolet på Linux Kernel.

Jeg har fått ned token spend til et nivå hvor det faktisk er mulig.

Og jeg har nå implementert: 1. Et bedre CLI for Clojure-brukere (og AI-agenter) 2. En JAR-basert release pipeline for ikke-Clojure-brukere 3. En innebygget MCP server

Her går det unna!

Ja, hehe! Har også gjort en stor opprydning i koden, så nå ser det litt mindre jævlig ut, men fortsatt ganske slum…

Da gjenstår det "bare" masse manuell testing, bugfiksing og dokumentasjon.

Ser det er noen bugs i analysen av Clojure jeg må fikse.

Men har ordna sånn at hele oppleget er idempotent og kan kjøres på nytt for å analysere kun de bitene som feilet 🙂 Et av flere token-sparings-fikser.

kult!

hvordan fungerer analysen. Er det ved hjelp av clojure-verktøy?

Jeg skal dele hele repoet snart på GitHub 🙂 Men her er koden som gjør selve AI-analysen 🫣

@gar: Det er utrolig kult å se AI-agenten bruke REPL av seg selv for å teste/verifisere ting mens den utvikler. Veldig godt tips! Tusen takk.

Jeg har faktisk ikke testet dette selv. Bare fulgt med på ai-kanalen med nysgjerrige øyne. Det blir spennende å høre om erfaringene dine med dette fremover!

Dette begynner å bli et ganske voldsomt prosjekt, merker jeg 😅 Jeg la til en post-processing-jobb etter analysen, fordi AI-agenten ikke var i stand til å se på tvers av filer spesielt godt i store prosjekter. Så jeg har en jobb som kjører etterpå for å finne alle dependencies mellom filer og legge dem til i Datomic-modellen også.

Så nå er det 4 datakilder: • Git-historikk • Mappe/filstruktur på disk • AI-basert analyse per fil • Post-prosessering med language parsers Alt går inn i én Datomic database.

Tror jeg skal si vi er "feature complete" nå. Bare gjøre en ny runde med refactoring, bug-fiksing og testing, så går den ut som et "WIP/eksperiment-prosjekt" på GitHub.

Blir interessant å teste 🙂

Sånn går det når man sheller ut til claude via concurrent Clojure kode med custom sub-agenter for å analysere et Git repo med 90K linjer kode 😂

Men nå har jeg fått på plass GLM som en modell for utvikling for å spare Claude credits, samt fått på plass en del token-sparingsmekanismer. Så nå bør det går bedre neste gang 🤞

Hva er GLM?

Ah! Det er en annen LLM som jeg bruker fordi den er billigere og har ingen hard limits. Den går bare treigere hvis man bruker den for mye. https://z.ai/subscribe Men det er en open-source LLM som man også kan kjøre gratis lokalt da. Jeg har bare ikke rask nok maskin til å gjøre det via f.eks. https://ollama.com.

Jeg måtte le litt for meg selv her nå. Selv AI-en "klager" over "for mange parenteser." Det begynner å bli litt for realistisk når den ytrer samme klager som de fleste kollegaer 😂

Opus og Sonnet (av Anthropic) er mye raskere og produserer bedre resultater enn GLM, men de er også mye dyrere å bruke. Så jeg bruker GPT Codex (av OpenAI) og GLM (av Z.ai) til dev/testing, og sparer mine Opus tokens til produksjon.

Har du testet med clojure-mcp / clojure-mcp-light? De fikser balansering av parenteser.

Nei, det visste jeg ikke om! Takk for tips!

Ah, nice!

Det er skrevet opp og ned i mente om det i #ai-assisted-coding. Sikkert greit å gjøre et søk der inne på erfaringer (det har skiftet endel mellom clojure-mcp og clojure-mcp-light og av og til ingen av delene)

Jepp! Helt klart. Jeg har ikke fulgt med der på en stund.

En liten teaser fra prosjektet mitt: Command:

set -a && source .env && set +a && clj -M:run agent "How many files are in this repository and what are the largest ones?" ring --provider glm

{:answer "The repository contains **117 files** with a total size of **367,665 bytes** (~359 KB).\n\nHere are the largest files by byte size:\n\n1. `ring-jetty-adapter/test/ring/adapter/test/jetty.clj` — **44,292 bytes** (12.0% of total)\n2. `CHANGELOG.md` — **21,256 bytes** (5.8% of total)\n3. `ring-core/test/ring/middleware/test/cookies.clj` — **13,648 bytes** (3.7% of total)\n4. `ring-core/test/ring/middleware/test/multipart_params.clj` — **11,650 bytes** (3.2% of total)\n5. `ring-core/test/ring/util/test/response.clj` — **11,359 bytes** (3.1% of total)\n\nOther notable large files include:\n- `SPEC.md` — 11,664 bytes\n- `ring-core/test/ring/middleware/test/session.clj` — 9,416 bytes\n- `ring-core/src/ring/util/response.clj` — 10,989 bytes\n- `ring-core/src/ring/middleware/cookies.clj` — 6,950 bytes\n- `ring-core/src/ring/middleware/multipart_params.clj` — 8,321 bytes", :status :answered, :usage {:input-tokens 25127, :output-tokens 2777, :iterations 8}}

Kult!

Jeg lager en "søkemotor" for AI agenter som de kan bruke for å navigere og søke i store kodebaser mer effektivt.

ah, det er jo faktisk veldig kult

Den er bygget på Datomic.

Det begynte med at jeg ville slå rekorden på https://longbench2.github.io

Jeg har basically bygget en "knowledge graph" i Datomic ved å parse alle Git commits + analysert alle filer i repoet via LLM-er og putta det i samme Datomic database.

Og laget et "tool" som LLM-er kan bruke for å effektivt autogenerere Datalog queries på måfå for å mer effektivt lese/forstå kodebasen og svare på spørsmål.

hvordan bruker llm'en den? er det som en mcp?

Jeg fikk idéen etter å ha lest https://arxiv.org/pdf/2512.24601.

Nei, det er ikke en MCP (enda). Men god idé! Det kan jeg sikkert få til.

P.t. er det 100% "Clojure-basert integrasjon" via shell og HTTP.

Hovedproblemet er at det er satan så dyrt å analysere et stort repo 😅

Så jeg har holdt på med "token-optimalisering" nå i det siste.

kanskje verdt å ta en titt på nucleus fra Michael Whitford? Har ikke helt grep om hva det er han lager, men det er vel strengt tatt en slags context-compression.

Thanks! Det må jeg gjøre.

Hele prosjektet var egentlig en "test case" for https://github.com/leifericf/claude-code-toolkit.

Men det ser ut til å funke ganske bra! Overraskende nok.

Interessant!

Koden ser helt jævelig ut da.

Christian, Magnar og Erik vil banlyse meg.

Funker som jernet! Nå har AI-en tilgang til REPL.

Det jeg driver med nå er enten idiotisk eller genialt. Mest sannsynlig idiotisk.

Jeg gjorde en bug og brant alle Calude Code tokens på 5 min 😂🔥 Så da ble det bråstopp og ventetid.