Hvorfor må jeg forklare det samme til Claude hver eneste dag?

Publisert:

18/6/26

Sist oppdatert:

18/6/26 15:29

Kategori:

Digital Produktutvikling

På vår interne konferanse CapraCon hørte jeg Magnus Rødseth holde et foredrag om et konsept jeg ikke hadde kjennskap til: "Second brains".

Tiago Forte lanserte ideen i boka Building a Second Brain (2022), og handler om å flytte kunnskap ut av hodet og inn i et eksternt system, slik at hjernen kan bruke mer tid på å tenke enn å huske. I mars 2026 oppdaterte Forte rammeverket. Med KI trenger ikke kunnskapslaget lenger å være et passivt arkiv, men noe du og agenten selv kan lese, koble sammen og handle på.

Dette virker å være en del av en større bølge. Andrej Karpathy beskrev i et innlegg på X fra april 2026 hvordan han lar en LLM bygge og vedlikeholde markdown-wikier i Obsidian, som agenten selv kompilerer, kobler og rydder i. Innlegget har i dag 21,4 millioner visninger. Selv Meta har på under tre måneder rullet ut et liknende kontekstlag til over 63 000 ansatte.

*Claude er nå blitt populær som personlig bibliotekar. Kilde: Nano Banana 2*

"Second brain"-konseptet fikk meg til å tenke på en irritasjon jeg levde med daglig ute i prosjekt hos kunden: ikke at jeg glemmer ting, men at agenten min gjør det. Hver nye Claude-økt starter relativt blankt, så den samme konteksten må stadig forklares, prompt etter prompt. Vi har som mange andre CLAUDE.md-filer rundt om i kodebasen, men de er statiske, og kan ikke romme for mye uten å "bloate" kontekstvinduet.

Prosjektet jeg jobber på har hatt en eksplosiv vekst med mange utviklere inn og ut, og dette danner sannsynligvis grunnlaget for irritasjonen. Domenet er i tillegg ganske komplekst, så samme konsept kan hete forskjellige ting avhengig av hvilket repo og kontekst du jobber i: ett navn i grensesnittet, et annet i den UI-en, et tredje i koden, og en egen nøkkel i oversettelsesfilene. Hver gang jeg satt Claude på en ny, men beslektet oppgave, har jeg måttet skrive den samme forklaringen på nytt: "Case" kalles faktisk Task i backenden, ja, det er det samme som "sak", og faktisk kan det også kalles en "construction activity". Samme kontekst, om og om igjen. Det måtte finnes et bedre sted for konteksten å bo enn i hodet mitt og i hver nye Claude-session.

Så ideen formet seg: hva om jeg bygde noe i samme ånd som en second brain, men ikke for meg selv, for agenten som jobber i kodebasen, på tvers av repoene? Altså ikke en second brain i streng forstand, men noe nært beslektet: en selv-utviklende, Claude-vedlikeholdt kunnskapsbase. Et repo med små, atomiske notater som agenten både kan slå opp i og skrive til, og som automatisk holdes oppdatert og deles via git. Et minne agenten selv fyller mens den utforsker og løser oppgaver, og som lever videre på tvers av økter og utviklere. Og fordi minnet beskriver kode, får det én egenskap en second brain ikke har:

Koden er fasit, så hver oppføring kan etterprøves og korrigeres over tid.

Hukommelsesproblemet på tvers av repoer

Hos oss er problemet ekstra akutt: kodebasen er ikke ett enkelt repo, men et titalls separate repoer samlet som git-submoduler under ett felles paraply-repo. Mye av konteksten agenten trenger lever i sprekkene mellom dem, i koblinger hverken README eller CLAUDE.md-filene eier, slik som hvordan to tjenester i hver sin submodul spiller sammen. Og de vanlige verktøyene fyller ikke gapet: READMEs drifter per repo, chat-historikk er hverken søkbar eller delt, og CLAUDE.md er for kort til å samle alt. En kunnskapsbase fyller dette gapet: et delt, prosjekt-internt lag som både mennesker og agenten kan lese og skrive.

Så hva har vi gjort?

Kunnskapsbasen vi har bygget er en Obsidian-lesbar, Claude-vedlikeholdt samling med atomiske notater, som selv lever som en git-submodul inne i paraply-repoet. Løsningen består av fire deler:

et lagringsformat (Obsidian-notater)
en regelbok (skills som styrer atferd)
en automatisert flyt (hooks som fjerner friksjon)
kvalitetssikring som holder det sant over tid (verifikasjon + confidence-score)

Det som virkelig skiller dette fra andre løsninger handler mye om hvor kunnskapen kommer fra: den inneholder ikke dokumentasjon noen skriver i forkant, men hukommelse agenten selv fanger gjennom utforsking. Midt i en oppgave oppdager den noe vedvarende om koden, noe "det er verdt å huske", og skriver det ned der og da. Det den ene økten lærer, arver den neste, og de andre utviklerne på teamet får også den nye kunnskapen på sine økter. Å fylle basen manuelt ville gitt mye bloat, så vi lar agenten lagre kun det den selv oppdager over tid, litt som om en menneskelig utvikler skulle lært seg kodebasen.

I stedet for Forte sitt PARA-mappeoppsett (Projects, Areas, Resources, Archives) bruker vi seks atomiske typer, valgt etter hva slags kunnskap vi mente vår agent faktisk trenger:

Type og hva den fanger

glossary/

Brukerord → kode-symbol → NO/EN-oversettelse

repos/

Én fil per submodul: hensikt, inngangspunkt, status (active, deprecated)

conventions/

"Sånn gjør vi det her"

decisions/

ADR-stil: kontekst, alternativer, valg, konsekvenser

recipes/

Ende-til-ende-oppskrifter for flerstegsoperasjoner

gotchas/

Ser riktig ut, men biter. Symptom → årsak → fiks

‍

På toppen av Obsidian-repoet har vi lagt en INDEX.md-fil, som fungerer som et kart som lastes inn i hver økt og som peker på hvor agenten skal lete videre. Resten av kunnskapsbasen leses kun når oppgaven agenten jobber på faktisk krever det.

Dette løser også skaleringen: INDEX.md vokser ikke med basen. Kartet lister typer og repoer, ikke enkeltoppføringer, så konteksten ved øktstart har tilnærmet konstant størrelse uansett antall notater. Agenten finner det den trenger slik et menneske ville gjort, med grep og målrettet lesning, i stedet for å laste alt inn samtidig. Den ene delen av INDEX.md som kan vokse, “Highlights”, kureres via bruksdata: et notat må fortjene plassen gjennom faktisk bruk.

Kunnskapsbasen tegnet som en graf i Obsidian. Hvert notat er en node, hver [[wikilink]] en kant.

Men en samling notater er fortsatt bare filer. Det som gjør kunnskapsbasen til et system, er maskineriet rundt: en LLM er av natur unøyaktig, og kunne like gjerne hoppet over kunnskapsbasen eller glemt å oppdatere den.

For å styre Claude Code inn i kunnskapsbasen har vi definert en custom skill, altså en instruks agenten kan laste inn som forteller når den skal lese/lagre kunnskap, hvordan den unngår duplikater, og hvordan den verifiserer mot koden. Og kanskje viktigst av alt: den definerer at agenten handler helt autonomt i kunnskapsbasen, og at den kan videreutvikle kunnskapsbasen som den selv mener er best.

Denne skillen virker likevel bare så lenge agenten husker å følge den. Vi har derfor koblet oss opp på Claude Code sine lifecycle hooks. Hookene gjør agent-flyten forutsigbar, og vi kan definere skript som kjører på faste punkter under agent-flyten: ved øktstart henter vi siste kunnskapsbase, underveis logger vi bruk, og ved stopp fanger/validerer/committer vi ny kunnskap. Helt konkret:

SessionStart → pull. Det eneste eventet før agenten har gjort noe som helst i økten. Her utfører vi en fast-forward-only pull av kunnskaps-submodulen, for å passe på at den har så oppdatert informasjon som mulig.
PostToolUse → logg. Skal vi vite hvilke oppføringer som faktisk blir brukt, må vi fange lesningen i det den skjer. PostToolUse er det eneste eventet som fyrer rett etter et verktøykall. Vi kobler den på Read-verktøyet til Claude slik at den kjører etter hver fil-lesning. Men: bare lesninger av en oppføring under knowledge/ blir logget.
Stop → fang og push. Stop fyrer når agenten har fullført en oppgave. To hooks kjører i rekkefølge: først en sjekk for hvorvidt agenten har skrevet noe informasjon, og som ber agenten ta én siste vurdering av om noe varig burde lagres. Deretter kjøres så commit + push.

I tillegg til skillen og hooksene, kjører vi en enkel validering med lefthook før hver commit for å passe på at notatene følger reglene vi har definert. Det er i tillegg verdt å merke seg at det kun er kunnskapen som automatisk pushes, det er fortsatt utvikleren som styrer resten.

Kunnskapsbasens kretsløp: agenten puller siste base ved øktstart, konsulterer og fanger kunnskap inne i loopen, og ved øktslutt valideres og pushes alt, klart for neste økt og neste utvikler. Read-verify mot koden ved hvert oppslag holder den ærlig og oppdatert.

Ettersom hver lesing logges, kan vi i tillegg etterprøve at kunnskapsbasen blir brukt, i stedet for å håpe på det. Den samme loggen gir også mulighet for selvkorrigering: det blir enklere å se sist gang kunnskap har blitt etterprøvd, så kunnskap som ikke er bekreftet på en stund mister agenten tillit til av seg selv.

Det som holder minnet riktig: koden er fasit

Mye av verdien ligger i at agenten slipper å utforske den samme koden på nytt hver økt. Men å bruke notatene som snarvei er bare verdt noe hvis den kan stoles på, og derfor verifiserer vi alltid mot koden.

Ettersom kunnskapsbasen peker på levende kode, betyr det i praksis at en oppføring som var riktig da den ble skrevet, blir feil i det øyeblikket noen gir en modell nytt navn eller flytter en fil. Og fordi agenten skriver notater autonomt, er hver oppføring i utgangspunktet en hypotese, ikke et faktum. Dermed vil agenten aldri anbefale noe fra kunnskapsbasen uten å sjekke koden først.

Som eksempel på dette kan vi ta en titt på notatet agenten har laget rundt “case”-irritasjonen jeg nevnte i introduksjonen:

--- type: glossary title: Case aliases: [case, cases, sak, saker, Task] repos: [<backend-repo>, <frontend-repo>] tags: ["#area/cases", "#lang/ruby", "#lang/typescript"] confidence: observed verified_at: sources: ["<backend-repo>: app/models/task.rb"] created: 01.06.2026 updated: 01.06.2026 --- # Case The user word "case" maps to the `Task` model in [[<backend-repo>]] (`app/models/task.rb`). - Norwegian: "sak" (plural: "saker"). Backed by the `tasks` table. - The `cases` translation key resolves to "Saker" (NO) on the frontend. - The same `Task` model is relabeled "Aksjon" / [[action]] in meeting contexts. The English UI shows "Tasks" for both.

Legg merke til confidence: observed i frontmatteren. Hvert notat har en slik confidence-score, og “observed” betyr at notatet fortsatt er en hypotese. Et observed-notat rykkes opp til verified når et menneske bekrefter den, og agenten er da mindre skeptisk til notatet. Et verified-notat eldre enn 90 dager degraderes derimot tilbake til observed, for å passe på at kunnskapen holdes fersk. Et notat som motsies av koden og ikke lar seg rette, blir vist til brukeren som kan velge om det skal slettes. Men uansett confidence, grep-er agenten alltid den koden den peker på:

# Oppføringen peker på app/models/task.rb grep -n "class Task" app/models/task.rb

Ved bekreftelse av notatet→ oppføringen kan brukes, og den flagges eventuelt for opprykk til verified.
Ved motsigelse av notatet → oppføringen kan ikke brukes, foreslå en fiks, stol på koden.
Ved tvetydig notat → fortell det til brukeren, men stol på koden.

Konsekvensen er at notater i praksis kun er ‘tips med kilde’, ikke dokumentasjon. Agenten får lov til å bruke dem, men aldri uten å sjekke koden de peker på. Og det å sjekke koden er relativt billig sammenlignet med alternativet, ettersom agenten unngår å måtte lete gjennom koden for å finne riktig innhold. Det er denne mekanismen som skiller et kunnskapslag du kan stole på fra ett som fyller seg med tilsynelatende riktige løgner.

Dette verifikasjonssteget er i store trekk grunnmuren til at hele systemet fungerer: agenten observerer varig kunnskap, skriver den, før den pusher, og alt pulles ved neste økt. På grunn av verifikasjonen kan man stole på at alle notatene er up-to-date, i det minste til neste gang kunnskapen etterprøves. Dermed bygger notatene på hverandre på tvers av økter og utviklere i stedet for å forsvinne. Koden er alltid fasit; kunnskapsbasen får deg bare raskere dit.

Hvorfor, ikke hva

Bølgen jeg nevnte innledningsvis beveger seg også i andre retninger enn vår, og det er verdt å være tydelig på hva løsningen vår ikke er. Den fanger ikke strukturen i koden, da det finnes egne verktøy for nettopp det, slik som MCP-servere som parser kildekoden, og gjør den til en strukturell graf som er er mekanisk utledet og alltid regenererbar fra koden selv. Dette medfører et raskt, token-billig alternativ til grep. Slike verktøy fanger hva koden er. Vår kunnskapsbase fanger det motsatte, hvorfor koden er som den er: beslutninger, gotchas, navnekonvensjoner. Nettopp derfor utelukker de ikke hverandre: de er to lag som potensielt kan kjøre side om side.

Til slutt

Før du hopper på å implementere dette i egen kodebase er det viktig å understreke at dette fortsatt er et eksperiment. Vi har brukt kunnskapsbasen i snaue en måned, så vi har ikke nok fartstid til å vise til harde tall, og vi finjusterer fortsatt flyten mens vi jobber. Men så langt har det hjulpet oss med en konkret problemstilling: agenten bruker mindre tid på å finne opp hjulet på nytt, og teamet bruker mindre tid på å mate den med den samme konteksten, igjen og igjen.

Den viktigste læringen for meg er ikke at alle trenger et “minne” for agenten, men at små forbedringer i arbeidsflyten rundt agenten kan gi uventet stor effekt. Så hvis du vil eksperimentere: ikke start med “hva kan agenten lage?”. Start med “hvordan kan vi bruke dette verktøyet enda litt bedre?”.

Jeg og mange andre i Capra jobber for tiden på å forbedre agentiske arbeidsflyer, og er veldig interesserte i å høre om andre har erfaringer med lignende. Gjerne ta kontakt på LinkedIn om du har noe å tilføye!