Spring til indhold

Tidligere version (v4) (2026-06-10, "Anglicisme-pass")

Dette er en arkiveret tidligere udgave af denne post. Den aktuelle version kan være ændret. Læs den aktuelle version →

Opus-review 10. juni (score 72) pegede på engelske verber brugt som danske: 'cruncher' → 'kværner', 're-render' → 'genkører', 'klar til at queries' → 'klar til at blive forespurgt', 'sat i forhold til' → 'mod'. Plus omskrevet DAG-vendingens indledning så den flyder som dansk syntaks.

← Alle indlæg
v4

Hjernen bag

7.000 prompts, 88.000 tool-calls, 46.000 fil-ændringer — alt sammen liggende i ~/.claude/projects/ og aldrig læst igen. Pks brain er den stille kværn der gør vibe-kodet kaos til ADR'er, feature-specs og søgbare wikis. Det startede som en aften i maj og blev til en DAG.

Jeg har 7.000 prompts, 88.000 tool-calls og 46.000 fil-ændringer liggende i ~/.claude/projects/ lige nu. Jeg læser aldrig nogen af dem igen. Det irriterede mig nok til at jeg byggede en hjerne der gør det for mig.

Det startede ikke som et produkt. Det startede som en sætning jeg skrev ned 14. maj fordi jeg blev træt af at glemme mine egne projekter — og fordi Andrej Karpathy lige havde postet om sit eget "second brain"-koncept og jeg ville bygge noget i den retning, bare baseret på det jeg allerede havde liggende: mine Claude Code-sessioner.

human prompt
10 lines
I have this idea that i wrote down: Jeg tror rigtig meget på den her "start vibe" => "go professionel" - og jeg har mange af mine projekter jeg starter uden noget som helst. Men jeg vil også gerne have alt det nince engineering ned af vejen men jeg gider ikke betale overhead i starten hvis jeg ikke ved om projektet bliver til noget. (sådan tænkte jeg også før ai). Så jeg leger meget med tanken at (default er at man har alt session files i claude 30dage, kan extendes) but at jeg bare kan have en background agent der står og cruncher det for at så på bagsiden faktisk bygge ADR, feature besrkivelser og whatnot op automatisk løbende uden jeg behøver at tænkte over det, jeg viber bare der ud af. Så stille og roligt converger det og helt automatisk kommer man over i at køre som L4. samme concept, jeg vil gerne have en agent til at stå og snore over "hvad kan jeg opsamle af bad habbits fra poul og give ham gode råd" This was postet some time ago: https://x.com/karpathy/status/2039805659525644595 (ignore the tooling used but understand the concept) I would like to build something like this and we can do it over a few phases. but i imagine it starts out by "pks-cli brain init"

Det var det. Ingen API. Ingen schema. Ingen graf. Bare en idé om at den måde jeg faktisk arbejder på — vibe-kodet, halv-ufærdig, ti projekter åbne på én gang — kunne være input til en proces der løbende destillerede det til den slags artefakter som rigtige projekter har: ADR'er, feature-specs, en wiki, en bad-habits-rapport om mig selv.

Start vibe, go pro

Alle der har vibet sig gennem et halvt års AI-assisteret udvikling ved det godt: man starter ALT for mange ting. De fleste dør. De få der overlever vokser fra "én aftens fjolleri" til "det her bruger jeg hver dag" uden et formelt øjeblik hvor man besluttede det.

Problemet er ikke at man mangler dokumentation. Problemet er at man har skrevet den — i Claude-sessioner, i commit messages, i halv-redigerede markdown-filer — uden at det nogensinde samles. Det bliver liggende i ~/.claude/projects/ som JSONL fra hver session, hver prompt og hvert tool-call, men i en form ingen kommer til at læse igen.

Pks brain er det forsøg på at høste den dokumentation uden at man behøver opføre sig som om man laver et "rigtigt" projekt. Du viber. AI-hjernen kværner i baggrunden. Når jeg åbner et projekt igen tre uger senere er der faktisk noget jeg kan læse — uden at jeg har lavet det selv.

Hvad pks brain blev til

Den oprindelige idé satte sig som fem faser, hver med sin egen kommando og sit eget checkpoint, så enhver fase kan køres for sig:

Faserne er bevidst splittet. Den deterministiske ingest er billig og kører på 1–2 sekunder; de AI-drevne faser koster tokens og kører kun når man beder om det. pks brain refresh kæder dem sammen; resten af tiden genkører man bare den fase man har brug for.

Resultatet ligger to steder:

I dette repo har jeg lige nu omkring 7.000 prompts, 88.000 tool-calls og 46.000 fil-ændringer i firehose'en, mod 2.940 AI-genererede session-extracts. Det er et halvt års vibe-arbejde, klar til at blive læst af en model der ikke er mig.

Vendingen: det blev en DAG

Det vidste jeg ikke 14. maj. Først sidst i maj — efter en uges arbejde med product-cli, hvor en typed DAG (Feature, ADR, TC, kilde-fil) bandt arkitekturen sammen — gik det op for mig at AI-hjernen i forvejen havde produceret noget næsten identisk. Bare uden at jeg kaldte det en graf.

Hver række i files.jsonl er en edge: (session_id, tool_name, file_path, timestamp). Hver række i prompts.jsonl er en node — den brugerprompt der drev de edges der kom lige bagefter. Bruger man timestamps som join-akse mellem de to firehoses, har man en File↔Session-DAG med Prompt-attribution. Gratis. Færdig udregnet. Klar til at blive forespurgt.

Drafting-illustration af pks brain DAG'en: Session contains Prompt, Prompt drove ToolCall, ToolCall wrote/edited/read File — arrangeret som et rektangel, med en margin-callout der viser den reverse query: File → ToolCalls → Prompts → Sessions

Forward er trivielt — Session indeholder en serie Prompts, hver Prompt driver et antal ToolCalls, hver ToolCall skriver/redigerer/læser en fil. Det interessante er den modsatte retning: jeg har en fil, og jeg vil vide hvad der skete med den. Reverse-queryen — File → ToolCalls → Prompts → Sessions — er hvad pks brain commit-plan kører hver gang den skal forklare en commit. Tag de staged filer, slå dem op i files.jsonl, find de prompts der drev ændringerne, returnér den grupperede plan. Det fortæller commit-message-skriveren hvorfor ændringerne skete — ikke kun hvad der er ændret.

Det 4. indlæg handler om netop det skifte: hvordan vi tog graf-laget — som lå der hele tiden, ingest-fasen byggede det på to sekunder — og brugte det til at skrive commit-messages der ved hvorfor. Da vi flyttede pks brain commit-plan fra at re-scanne rå JSONL pr. fil til at læse firehose'en direkte, blev skillet pludselig hurtigt nok til at køre på hver commit. Hele den her serie kom ud af det skifte.

De fire indlæg

  1. Hjernen bag — det her indlæg. Hvorfor AI-hjernen eksisterer, hvad den består af, og hvordan DAG'en dukkede op.
  2. En wiki skrevet af vores AI-hjerne — en turné gennem wiki-output. Hvad ser de auto-genererede sider ud som, og hvor præcise er de når man stiller en wiki-side op mod kildekoden den syntetiserer fra.
  3. Grafen var der hele tiden — arkitekturen i detaljer. Hvilke nodes findes der (Session, Prompt, ToolCall, File), hvilke edges forbinder dem, hvad lagres deterministisk og hvad lagres AI-genereret.
  4. Fra ændrede filer til commit messages — hvordan vi joiner staged filer mod grafen for at finde de prompts der drev hver ændring, og hvordan vi bruger dem til at skrive feat(blog): publish coolify-destinations-pr post-niveau-commit-messages automatisk. Inklusive hvorfor det først blev brugbart da grafen erstattede scanneren.

Hvem er det her for

Hvis du:

… så er det her for dig. Der er ikke noget magisk over AI-hjernen. Den høster det du i forvejen har lavet, gør det søgbart, og kommer tilbage en gang om dagen og spørger om der er sket noget nyt.

Hvad har du selv liggende i ~/.claude/projects/ som du aldrig får læst igen?