Det tyvende projekt starter med de første nitten

Det tyvende projekt starter med erfaringerne fra de første nitten. Det er den egentlige gevinst ved mit workspace — ikke, at en kodeagent kan finde alle mine repos.

Erfaringerne samler sig i stedet for at fordampe, når jeg starter på noget nyt.

Jeg tænkte over det, da Kasper Juunge skrev om sit meta-repo. Han beskrev forskellen mellem et monorepo og et meta-repo: Et monorepo samler kode, som hører sammen. Et meta-repo kan samle mange forskellige repos og al den kontekst, agenten skal bruge for at arbejde på tværs af dem.

Det ligner det setup, jeg selv er endt med. Men jeg tror ikke længere, at meta-repo helt dækker, hvad jeg bruger det til.

Det er både repo, værksted og hukommelse

Mit workspace indeholder agentics.dk, blogindlæg, fælles dokumentation, eksterne repos og en projects-mappe fuld af produkter og eksperimenter.

Nogle projekter er små POC'er, der stadig ligger direkte i workspace'et. Andre er blevet til selvstændige, private GitHub-repos og er kommet tilbage som submodules. De får deres egen historik og udgivelsesrytme, men agenten kan stadig se dem sammen med resten.

Mit typiske flow er efterhånden:

Jeg får en idé og starter den i projects.
Agenten kan fra begyndelsen se de mønstre, værktøjer og beslutninger, der allerede findes i workspace'et.
Hvis projektet viser sig at have sit eget liv, opretter jeg et privat GitHub-repo og flytter det derover.
Jeg tilføjer repoet som submodule, så det stadig er en del af det samlede arbejdsrum.

På den måde kan projektet blive selvstændigt uden at glemme, hvor det kom fra.

Projekterne er begyndt at ligne en portefølje

Det seneste halve år er projects vokset til blandt andet:

pks-agent-inbox, pks-agent-share, pks-agent-coach og pks-agent-booking
pks-agent-registry, pks-agent-git, pks-agent-tunnel og pks-agent-gateway
pks-agent-release, pks-agent-otel, pks-agent-domain og pks-aspire-coolify
pks-agent-ftp, pks-agent-photogrammetry, DronePoul og HeyPoul

Alene siden marts har jeg tilføjet 18 projekter som submodules i workspace'et.

Listen er ikke interessant, fordi den er lang. Den er interessant, fordi projekterne ikke længere udvikler sig uafhængigt af hinanden.

Mailfunktionalitet fra booking-projektet er blevet genbrugt på agentics.dk. Coachens håndtering af push-beskeder er flyttet ind i platformen. Release- og containeropsætningen fra registry-projektet er blevet den reference, de andre produkter bliver sammenlignet med.

Det er almindeligt genbrug af kode. Men det er også genbrug af beslutninger: Hvad virkede? Hvad var irriterende? Hvilken struktur kunne agenten faktisk navigere i? Hvilke release-fejl skal vi ikke gentage?

Sessionfilerne er det vigtige

Jeg starter typisk Claude-sessionen i roden af workspace'et, også når opgaven ender med at ligge i et submodule. Sessionen kan derfor bevæge sig mellem projektet, agentics.dk, blogmaterialet og de fælles noter uden at jeg skal bygge konteksten op fra bunden hver gang.

Men meta-repoet er kun halvdelen af setup'et. Sessionfilerne skal også overleve.

Jeg arbejder i en devcontainer, hvor hele Claudes konfigurationsmappe ligger på en Docker volume:

"mounts": [
  "source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
],
"remoteEnv": {
  "CLAUDE_CONFIG_DIR": "/home/node/.claude"
}

Det betyder, at sessionhistorikken ikke forsvinder, når containeren bliver genbygget. Claude gemmer sessionerne som JSONL-filer under ~/.claude/projects/, opdelt efter den mappe sessionen blev startet fra. Når jeg starter fra meta-repoets rod, gemmes sessionerne samme sted, uanset hvilke repos agenten redigerer undervejs.

Der er én indstilling mere, som er nem at overse. Claude rydder selv op i gamle sessioner efter sin retention-periode. En persistent volume hjælper ikke, hvis programmet bagefter sletter filerne inde i den. I min globale ~/.claude/settings.json har jeg derfor sat oprydningen til et år:

{
  "cleanupPeriodDays": 365
}

Et år er mit minimum; længere hvis der er plads. Jeg tager stadig backup af ~/.claude. Vedvarende lager, opbevaringstid og backup løser tre forskellige problemer.

Oven på de rå sessionfiler har jeg bygget pks brain, et lille CLI-flow, der kan indlæse dem og gøre prompts, tool calls, berørte filer og fejl søgbare:

pks brain ingest
pks brain search "release workflow"

Det er ikke nødvendigt at bygge præcis den del på dag ét. Det første nyttige skridt er bare at beholde sessionfilerne og arbejde fra en fælles rod. Ellers har man samlet koden, men taber stadig en stor del af erfaringen mellem sessionerne.

Det, der viser sig værd at genbruge, kan bagefter løftes til wiki-noter, beslutninger, skills eller fælles instruktioner. Når jeg starter et nyt projekt, kan agenten dermed finde mere end en lignende implementering. Den kan også finde diskussionen om, hvorfor vi valgte den, og hvilke problemer der dukkede op bagefter.

Det er renters rente, bare med erfaring.

På tværs af isolerede repos kan jeg genbruge et bibliotek. Her kan jeg også genbruge ræsonnementet bag biblioteket.

Første gang koster problemet en lang session, et par blindgyder og nogle nye regler. Næste projekt arver løsningen. Hvis det projekt forbedrer mønstret, bliver forbedringen tilgængelig for det næste igen.

Efter nok omgange begynder projekterne at hænge sammen på en måde, jeg ikke havde planlagt fra starten.

AGENTS.md er mest et kort

Kasper nævnte også, at AGENTS.md får en anden rolle i et meta-repo. Det kan jeg genkende.

Den vigtigste instruktion i roden af mit workspace er ikke, om vi bruger tabs eller spaces. Den første linje sender agenten videre til et kort over workspace'et:

Read solution/repository-layout.md before choosing workspace scope, creating a top-level directory, or moving work between products, external repositories, or customer areas.

Kortet forklarer, hvor platformen bor, hvor selvstændige produkter ligger, hvilke mapper der tilhører kunder, og hvordan et submodule skal behandles uden at blande ejerskab sammen.

Reglerne inde i hvert repo er stadig repoets egne. Roden forklarer bare, hvordan agenten bevæger sig sikkert mellem dem.

Min AGENTS.md er næppe den rigtige fil for andre at kopiere. Mapperne og reglerne er specifikke for mit workspace. Pointen er mere beskeden: Giv agenten ét startsted og et kort, der hjælper den videre. Så kan samtalen begynde med problemet i stedet for en rundvisning i filsystemet.

Ulempen er, at alt kan smitte

Fælles kontekst er ikke kun en fordel.

Den samme effekt arbejder imod mig, hvis udgangspunktet er forkert. En hurtig workaround kan blive kopieret til fem projekter, før nogen opdager det. Og hvis ejerskabet mellem root-repoet og et submodule er uklart, kan agenten hurtigt komme til at committe i det forkerte repo.

Derfor prøver jeg at være ret streng med grænserne:

POC'er må gerne være rodede, mens vi lærer.
Et projekt får sit eget repo, når det får sin egen identitet og livscyklus.
Fælles viden løftes ud i dokumentation, skills og beslutninger i stedet for at blive kopieret blindt.
Workspace-instruktionerne handler først og fremmest om navigation og ejerskab.

Jeg vil stadig ikke lægge al kode i ét stort repo. Koden må gerne flytte hjemmefra. Jeg vil bare gerne kunne finde erfaringen igen.

Det næste projekt starter ikke fra nul

Jeg begyndte ikke med en plan om at bygge et meta-repo. Jeg blev bare ved med at starte små projekter samme sted, og når de modnede, gav jeg dem deres eget repo uden at sende dem helt væk.

Nu kan jeg se, at strukturen i sig selv er blevet et aktiv.

Hvert nyt projekt producerer selvfølgelig software. Men det producerer også kontekst, regler, skills, arbejdsgange for releases og en historik over beslutninger. Alt det bliver liggende og gør det næste projekt lidt billigere at tænke, lidt hurtigere at starte og lidt sværere at køre helt af sporet.

Det er den del af meta-repo-idéen, jeg synes er mest spændende: Agenten kan ikke bare se alle mapperne. Den kan også finde det, vi lærte i dem.