Spring til indhold
← Alle indlæg
Serie

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.

min prompt1 prompt → plan → Phase 0
30 lines2026-05-14 05:19
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å stiller og rolig converger det og helt automatisk kommer man over i at køre som L4. Tror det kan hjælpe nogen i at gå fra L2->L4 hvor det er en agent der hjælper dem på vejen me nde skal bare i prompt i starten. 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" - det kan jo også være. "Poul gør det her hver dag, skal vi bygge et skill til ham og send næste gang du gør det der så prøv xxx" This was postet some time ago: https://x.com/karpathy/status/2039805659525644595?s=20 (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" "Ingest" Phase it should (similar to our pks claude usage or stats) start by getting an overview over all files with have with session files, plan files and such and put that into a index file / structure so we can start work on it. "Extract" Phase We want to have a good default prompt to run on each session file on what it should do. We set it up in a skill (use the make-skill skill) so we can edit it. but the idea would be that each file should be analyses for key outputs. 1. Brief output of what was worked on 2. Analysis of tool calls (i think pks-cli should deterministic extract all the tool calls into a compact format so its easy for ai to analyse so we dont waste tokens on reading everyhing) - we are interesting in finding all the bottlenecks, errors, problems. token usage , what else makes sense here 3. All user prompts (see our promptwall how it found user prompts) and also determinitisk extract and then analyse after for prompt techniqueues and improvements. 4. We will start working on feature, adr, specs more formal and as my idea we start out without but i think based on the history of the project we can reconstruct alot of feature descriptions and user stories of what things can do. we will iterate more on this, for now its the deterministic output we start before we run the ai stuff. we are building the tooling around this idea in small interations so we get it right, the project is big here with alot of sub projects. So we also what the output here when building the "wiki" will be able to smart detect different tools, projectss and such based on data. So i think we have all the session data that is the "raw" part, and what we are building above is not yet the "Wiki" part but more the "raw" => "ingests" which we will eventual build into features, specs, wiki elements. Can you start planning out how we could do this, make extensive planning / phases so we can start
Den fulde founding-prompt, verbatim — stavefejl og det hele.
65 værktøjer197K tok63 min

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?

Indlæg i denne serie

  1. 01Hjernen bag7.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.
  2. 02En wiki skrevet af vores AI-hjerne103 sessioner om auth blev til 84 linjers wiki-side. 73 sessioner om devcontainere fik en oversigt jeg aldrig selv ville have skrevet. Her er fire eksempler på hvad pks brain producerer når det får lov at læse mit eget halvår igennem.
  3. 03Grafen var der hele tidenPks brain ingest producerede ikke en log. Den producerede en graf. Fire nodes, tre edges, og en join-akse jeg ikke kunne se før product-cli viste mig hvordan en typed DAG ser ud andre steder. Det 3. indlæg om hvordan AI-hjernen er bygget op under motorhjelmen.
  4. 04Fra ændrede filer til commit messagesPks brain commit-plan kører grafens reverse query: tag staged filer, find de prompts der drev hver ændring, returnér grupperet plan. Det 4. og sidste indlæg i serien viser hvordan det blev til en /commit-message-skill — og hvorfor den var ubrugelig før vi flyttede planneren fra rå-JSONL-scanner til firehose-direct-read.