Nøkkelinnsikt

• Domeneeierskap, regler for hvilke filer hver agent kan endre, er det som gjør full agentautonomi trygt på store kodebaser. Uten grenser betyr flere agenter bare mer risiko.
• Mentale modeller som vokser mellom sesjoner gir sammensatte fordeler over tid. Det er forskjellen mellom å bruke AI og å bygge AI-systemer som blir smartere av seg selv.
• Tokenprisen faller mens intelligensen øker. Ingeniører som optimerer for tokenkostnad i dag, optimerer for gårsdagens priser.
• Disler bygger bevisst utover det en enkelt Claude Code-instans kan gjøre. Hans Pi-baserte system med tre lag, domeneeierskap og vedvarende hukommelse viser hvor langt multi-agent orkestrering kan tas.

Kort fortalt

Dan Disler, kjent på YouTube som IndyDevDan, demonstrerer et multi-agent kodingssystem der én melding setter i gang 9 spesialiserte agenter fordelt på 3 team. Agentene planlegger, bygger og validerer kode uten at du trenger å koordinere dem manuelt. Kjernen i systemet er tre prinsipper: teamhierarki med tre lag, domeneeierskap (regler for hvilke filer hvert agent-team kan endre), og mentale modeller som vokser mellom sesjoner. Han bygger på Pi, en tilpassbar agent-plattform, og viser hva som blir mulig når du går utover det en enkelt Claude Code-instans kan gjøre alene.

---

Taket du ikke visste du hadde truffet

«Én agent er ikke nok» er Dislers utgangspunkt. Poenget er enkelt: hvis du sitter i terminalen og manuelt vidersender resultater fra én AI-agent til neste steg, er du selv den som koordinerer alt. Du er flaskehalsen.

Det løser seg ikke ved å gi agenten en mer presis prompt. Det løser seg ved å la agenter koordinere andre agenter.

Disler vil vise noe som går lenger enn det du får med ett enkelt AI-verktøy: spesialiserte team med vedvarende hukommelse og klare grenser for hvem som får gjøre hva.

---

Tre lag, ni agenter

Systemet han demonstrerer er bygget rundt tre lag:

Koordinatoren er toppen. Den tar imot meldingen din og bestemmer hvem som skal gjøre hva.

Teamlederne er midtlaget. Hvert team har en leder som bryter ned oppgaven og delegerer til sine arbeidere.

Arbeiderne er bunnen. De utfører det faktiske arbeidet, skriver kode, kjører tester, sjekker sikkerhet.

I demoen har han tre team: planlegging, utvikling og validering. Hvert team har en leder og to arbeidere. Totalt ni agenter. En enkelt melding setter alle i gang. Forskjellen fra å jobbe med én agent er at du ikke lenger er den som ruter oppgaver mellom verktøy. Koordinatoren gjør det for deg. Det er forskjellen mellom å styre én assistent og å lede et lite, selvorganiserende team.

Det interessante skjer når du ber alle team om en felles vurdering. Koordinatoren sender samme spørsmål til alle tre teamene, de vurderer det uavhengig fra sine faglige perspektiver, og du får ett samlet svar tilbake. Enighet betyr høy tillit. Uenighet betyr at noe fortjener nærmere analyse.

---

Spesialisering slår generalisme

En generalist-agent gir gjennomsnittlige resultater. En spesialisert agent, konfigurert med egne instruksjoner og ekspertfiler, gir ekspertsvar. Planleggeren vet hvordan den skal bryte ned et problem. Backendutvikleren kjenner arkitekturen i kodebasen. Hver agent er bygget for én ting.

---

Felles samtalelogg

Alle agenter deler samme samtalelogg. Hver agent kan se hva alle andre har sagt og gjort. Det betyr at agentene kan koordinere seg uten at noen eksplisitt forteller dem hva de andre driver med. Koordinatoren gir alle team den samme oppgaven, alle jobber parallelt, og svarene samles til én felles vurdering. Denne delte konteksten er limet som holder teamet sammen.

---

Hukommelse som vokser

Den egenskapen som skiller systemet mest fra vanlig Claude Code-bruk er mentale modeller (filer der agenten lagrer det den har lært). Hver agent har en fil der den lagrer hva den har lært: mønstre i kodebasen, beslutninger som ble tatt, risikoer den har lagt merke til. Filen vokser mellom sesjoner.

Koordinatorens mentale modell kan vokse til 10 000 linjer. Agentene laster den ved oppstart av hver sesjon ved hjelp av Claudes kontekstvindu på 1 million tokens. Neste gang agenten starter opp, er den ikke nullstilt. Den er en ekspert som husker hva som skjedde sist. Teamet blir smartere for hver gang du bruker det, uten ekstra innsats fra deg.

Disler understreker at han ikke redigerer disse filene manuelt. Agenten vedlikeholder dem selv. Det er poenget: du gir retningslinjer for hvordan modellen skal oppdatere dem, men du styrer ikke innholdet. Det krever at du stoler på agenten din litt mer enn du kanskje er vant til.

---

Domeneeierskap: hvem får røre hva

Domeneeierskap er det tiltaket som gjør full agentautonomi trygt på store kodebaser. Tanken er enkel: hver agent har eksplisitte regler for hvilke mapper og filer den kan lese, og hvilke den kan endre.

Planleggeren kan lese alt, men kan ikke skrive til kildekoden. Den kan bare lage planer. Frontendutvikleren kan skrive til frontend-katalogen, men aldri til backend. Backendagenten er omvendt.

Når en agent prøver å bryte disse grensene, nektes den tilgang og delegerer heller til en kollega med riktige rettigheter. I demoen skjer dette helt automatisk: engingeringslederen prøver å lese filer den ikke har tilgang til, oppdager det, og sender oppgaven til riktig arbeider i stedet.

For en kodebase med tusenvis av filer betyr dette at du kan gi agenter mye frihet uten å frykte at de gjør endringer utenfor sitt eget område.

---

YAML-konfigurasjonen: alt på én plass

Hele systemet er definert i én YAML-fil. Koordinatoren, teamlederne, arbeiderne, hvilke modeller de bruker, hvilke ferdigheter de har, og hvilke filer de har tilgang til. YAML er et tekstformat for konfigurasjon som ligner en strukturert huskeliste: lesbart for mennesker, forståelig for maskiner.

Slik ser konfigurasjonsfilen ut (forenklet):

orchestrator:
  model: "claude-opus"
  system_prompt: "./prompts/orchestrator.md"

teams:
  planning:
    lead: { name: "Planning Lead", system_prompt: "./prompts/planning-lead.md" }
    members:
      - { name: "Architect", system_prompt: "./prompts/architect.md" }
      - { name: "Researcher", system_prompt: "./prompts/researcher.md" }
  engineering:
    lead: { name: "Engineering Lead", system_prompt: "./prompts/eng-lead.md" }
    members:
      - { name: "Frontend Dev", system_prompt: "./prompts/frontend.md" }
      - { name: "Backend Dev", system_prompt: "./prompts/backend.md" }

Det betyr at du kan legge til et nytt team, bytte ut en modell, eller fjerne en arbeider ved å endre noen linjer tekst og starte systemet på nytt. Disler demonstrerer dette live ved å slette valideringsteamet og starte med bare planlegging og utvikling.

Koordinatoren bruker de kraftigste modellene, som Claude Opus. Arbeiderne kjører på Sonnet. Det er et bevisst valg: tenkerne trenger høy intelligens, utøverne trenger bare å følge instruksjoner.

---

Hva med prisen?

«Jeg bruker ikke nok tokens. Du bruker ikke nok tokens.» er Dislers svar til alle som påpeker at dette koster penger. En full kjøring med alle ni agentene kostet ham omtrent 80 kroner (rundt 8 dollar). Backendagenten alene brukte over 100 000 tokens i én sesjon.

Reaksjonen hans på kostnadsskepsisen er at den er feil innrammet. Tokenprisen faller. Intelligensen øker. Ingeniørene som optimerer for å bruke færrest mulig tokens, optimerer for en virkelighet som allerede er i ferd med å forsvinne.

Det er ikke dermed sagt at alle bør starte med ni agenter. Men poenget er at kostnad ikke bør være det første argumentet mot å prøve.

---

Hvorfor det betyr noe

Det sterkeste argumentet handler om sammensatte fordeler. En enkelt agent nullstilles etter hver sesjon. Et agentteam med vedvarende hukommelse gjør det ikke. Hver sesjon legger til kunnskap. Etter ti sesjoner kjenner teamet kodebasen bedre enn en ny utvikler. Etter hundre vet det ting om kodebasen du selv har glemt.

Domeneeierskap snur risikoligningen. Den vanlige bekymringen med AI-agenter er at de kan endre feil fil. Domeneregeler gjør det umulig. En agent som ikke kan røre databasen, kan heller ikke ødelegge den ved et uhell. Flere agenter, mer autonomi, men innenfor definerte grenser.

Det Disler egentlig argumenterer for er et skifte i hva slags arbeid en utvikler gjør. Du går fra å være budbringer mellom AI-verktøy til å være arkitekten som designer systemet én gang, setter grenser, gir det hukommelse, og lar det jobbe.

---

Ordliste

---

Kilder og ressurser