Multi-agent koding fungerer best med tre til fem agenter

Nøkkelpunkter per 21. september 2026:

• Tre til fem agenter er det optimale antallet i et agent-team, og tre fokuserte agenter slår konsekvent en generalist som jobber tre ganger så lenge (addyosmani.com, 2026).
• Delegeringsgapet er stort: utviklere bruker AI i rundt 60 % av arbeidet, men kan fullt delegere bare 0-20 % av oppgavene (Anthropic, 2026).
• Betaen har harde grenser: trådene i Claude Code Projects kjører i skyen og når ennå ikke filer eller verktøy på utviklerens maskin eller interne nettverk (VentureBeat).
• Risikoen er reell: et estimat tilsier at mer enn 40 prosent av dagens agentiske AI-prosjekter kan bli kansellert innen 2027 (Deloitte, 2026).
• Kontekstfiler er ikke gratis: LLM-genererte AGENTS.md ga lavere suksessrate og over 20 % høyere inferenskostnader enn utvikler-skrevne filer (addyosmani.com, 2026).

---

Hva multi-agent koding betyr i praksis

Multi-agent koding betyr at flere AI-agenter arbeider på ulike deler av samme kodebase samtidig, med et lag over seg som fordeler oppgaver, holder oversikt og rydder opp når arbeidet overlapper. Det er ikke det samme som å ha tre chat-vinduer åpne ved siden av hverandre. Skillet ligger i at agentene deler mål, kontekst og en felles oppgaveliste, og at noe eller noen avgjør hvem som gjør hva. Utviklere har gått fra å jobbe med en AI-assistent synkront til å koordinere flere agenter asynkront (addyosmani.com, 2026).

Skiftet handler mindre om modellkvalitet enn om arbeidsform. Anthropics egen trendrapport beskriver at utviklerrollen forskyves fra å skrive kode til å orkestrere agenter, mens menneskelig vurdering forblir sentralt (Anthropic, 2026). Samtidig viser den samme forskningen at utviklere bruker AI i omtrent 60 % av arbeidet, men bare kan fullt delegere 0-20 % av oppgavene. Det gapet er hele poenget: assistanse er utbredt, full delegering er fortsatt unntaket.

Fra en assistent til flere parallelle tråder

Den enkle arbeidsformen er kjent for de fleste team: du beskriver en oppgave, assistenten foreslår kode, du leser og godkjenner. Alt skjer i sanntid, og du er selv flaskehalsen. I en multi-agent-oppsetning skjer arbeidet i tråder som lever videre etter at du har sluppet tastaturet. Du beskriver et mål, koordineringslaget splitter det i deloppgaver, og hver tråd jobber på sin egen gren og sin egen kopi av repoet (The Verge).

Varigheten er det som gjør formen ny. Anthropic forutser at agenter i 2026 kan jobbe i dager sammenhengende og bygge hele applikasjoner med minimal menneskelig inngripen (Anthropic, 2026). Et konkret eksempel: Rakuten satte Claude Code på en oppgave i vLLM-biblioteket, som består av 12,5 millioner kodelinjer, og agenten fullførte jobben på syv timer autonomt og med svært høy numerisk nøyaktighet. Det er ikke representativt for hverdagen i en norsk SMB, men det viser hva formen tåler når oppgaven er godt avgrenset og testbar.

Poenget for en teamleder er ikke at agenter kan jobbe lenge. Poenget er hva som skjer med arbeidsflyten når fire ting skjer samtidig og ingen av dem er ferdig lest av et menneske. Da blir køen foran deg, ikke bak deg.

Hva som skiller et agent-team fra flere åpne faner

Tre parallelle assistenter uten felles kontekst gir tre ulike tolkninger av samme kodebase. De gjenbruker ikke hverandres funn, de vet ikke hva de andre rører ved, og de oppdager konflikten først når noen prøver å merge. Et agent-team legger til koordineringsprimitiver: delt oppgaveliste, peer-to-peer meldinger mellom agentene og fillåsing som hindrer at to agenter skriver i samme fil (addyosmani.com, 2026).

Det er denne forskjellen som avgjør om multi-agent koding gir gevinst eller bare gir mer rot. Uten koordinering skalerer du antall utkast. Med koordinering skalerer du gjennomstrømning. Erfaringene fra bredere AI-utrullinger i utviklingsarbeid peker samme vei: gevinsten kommer av struktur rundt verktøyet, ikke av verktøyet alene, noe vi har skrevet om i sammenheng med vibe coding.

Claude Code Projects og det nye koordineringslaget

Den 17. september lanserte Anthropic Claude Code Projects, beskrevet som en alltid-på AI-koordineringsagent for utviklere (VentureBeat). Funksjonen tar utviklerens instruksjoner på naturlig språk, deler dem opp i parallelle tråder, koordinerer dem over tid og holder et delt minne om prosjektet mens arbeidet skrider frem. Anthropic sammenligner selv interaksjonen med å briefe en stabssjef.

Navnet skaper forvirring, og det er verdt å rydde opp i med en gang: Anthropic har fra før en separat funksjon som heter Claude Projects, introdusert i juni 2024. Claude Code Projects er noe annet. Det er et koordineringslag for utviklingsarbeid, ikke en mappe med dokumenter.

Tråder, grener og merge-konflikter

Hvert prosjekt inneholder tråder som kjører ulike oppgaver parallelt, med en koordinator som styrer helheten (The Verge). Hver tråd er en egen Claude Code-skyøkt som jobber på sin egen gren og sin egen kopi av repoet. Trådene deler minne, mål og et bibliotek av filer og artefakter, slik at de trekker på samme forståelse av prosjektet.

Konflikthåndteringen er bevisst kjedelig, og det er en styrke. Overlappende arbeid mellom tråder løses som en merge-konflikt, akkurat som i en vanlig pull request. Det betyr at teamet ikke trenger å lære en ny konfliktmodell, bare å tåle flere konflikter enn før. Hver tråd kan dessuten dele opp arbeidet sitt videre ved hjelp av subagenter, løkker og arbeidsflyter for å fullføre store oppgaver raskere.

Du kan snakke med hver tråd individuelt eller følge med via prosjektets hovedchat. I praksis betyr det to tilsynsmodi: detaljert oppfølging av en enkelt agent, eller overblikk over alle. De fleste team vil trenge begge, og bør bestemme på forhånd hvem som bruker hvilken.

Hva betaen ikke gjør ennå

Den viktigste begrensningen står tydelig i lanseringsdekningen: skytrådene kan ennå ikke få tilgang til filer eller verktøy på utviklerens datamaskin eller interne nettverk (VentureBeat). Støtte for lokale verktøy og kode kommer «veldig snart» ifølge Anthropic (The Verge). For et team med interne API-er, lokale databaser og egne byggeverktøy er dette ikke en detalj. Det avgjør hvilke oppgaver som i det hele tatt kan gis bort.

Egenskap	Status i betaen	Konsekvens for piloten
Tilgang	Utvalgte Claude Pro- og Max-abonnenter med skyøkter	Planlegg piloten rundt de som faktisk har tilgang, ikke hele teamet
Kjøremiljø	Hver tråd er en egen skyøkt på egen gren og kopi av repoet	Repoet må kunne ligge i skyen uten at det bryter med interne krav
Lokale verktøy	Ingen tilgang til filer, verktøy eller internt nettverk	Oppgaver som krever intern integrasjon holdes utenfor piloten
Konflikter	Overlapp løses som merge-konflikt i PR	Kjent arbeidsflyt, men flere konflikter enn teamet er vant til
Videre utrulling	Utvides senere til Pro, Max, Team og Enterprise	Forvent at oppsettet må gjøres om når bredere tilgang kommer

Tabellen er ikke en advarsel mot å prøve. Den er en liste over hva som må være avklart før noen i teamet setter i gang på egen hånd en fredag ettermiddag.

Hvorfor koordineringslaget er den egentlige nyheten

Modellene har kunnet skrive kode i årevis. Det som har manglet er et sted der flere agenter kan dele mål og status uten at et menneske må kopiere kontekst mellom dem. Et delt prosjektminne som overlever den enkelte økten flytter arbeidet fra «prompt» til «prosjekt». Det er derfor Deloitte peker på orkestrering, ikke rå modellkapasitet, som det som avgjør om multiagent-systemer gir verdi (Deloitte, 2026).

For norske team betyr det at innkjøpsspørsmålet endrer seg. Det er ikke lenger «hvilken kodeassistent er best», men «hvem eier koordineringslaget vårt, og hvor lett er det å bytte det ut».

---

Les også: Vibe coding på AWS lover 80 prosent raskere utvikling. AWS satser tungt på vibe coding med Q Developer og Kiro.

---

Fra subagenter til agent-team: en modenhetsmodell

De fleste team hopper rett fra en assistent til drømmen om et autonomt utviklingsteam. Mellomstegene er der gevinsten faktisk ligger. Addy Osmani, som oppsummerte et foredrag fra O'Reilly AI CodeCon 26. mars 2026, plasserer de fleste utviklere på nivå 3-4 av AI-assistert koding, mens reell orkestrering starter på nivå 6 (addyosmani.com, 2026). Det er to nivåer med arbeid mellom der du er og der multi-agent koding begynner å lønne seg.

Subagenter løser kontekst, ikke koordinering

Subagenter er det første steget opp. De løser to reelle problemer: kontekstoverbelastning, ved at hver subagent bare ser sin del av oppgaven, og manglende spesialisering, ved at hver subagent får en tydelig rolle. Det de ikke løser er koordinering (addyosmani.com, 2026). Subagentene vet ikke hva de andre gjør, og resultatet må settes sammen av hovedagenten eller av deg.

Kostnaden er heller ikke ubetydelig. En demo med subagenter lå på omtrent 220 000 tokens. Det er et tall verdt å ha i bakhodet før noen konkluderer med at parallellitet er gratis.

Mønster	Løser	Løser ikke	Passer når
En assistent, synkront	Rask hjelp i kjent kode	Parallellitet og varighet	Teamet er på nivå 3-4 og mangler rutiner
Subagenter	Kontekstoverbelastning og spesialisering	Koordinering mellom agentene	Oppgaven kan deles rent i uavhengige biter
Agent Teams	Delt oppgaveliste, meldinger mellom agenter, fillåsing	Verifisering av det som produseres	Flere agenter må røre samme kodebase
Skyagenter	Lange, parallelle kjøringer uten at maskinen står på	Tilgang til lokale verktøy og internt nettverk	Repoet tåler å kjøre utenfor egne systemer

Hva som må være på plass før du går opp et nivå

Nivåstigen er ikke en ambisjon, den er en forutsetning. Et team som ikke har automatiserte tester, tydelig eierskap til kodeområder og en fungerende PR-rutine vil ikke få orden på fire parallelle agenter. De vil få fire parallelle kilder til teknisk gjeld. Deloittes tall peker i samme retning: 80 prosent av respondentene i deres 2025 Tech Value Survey mente organisasjonen har modne kapabiliteter innen grunnleggende automatisering, mens bare 28 prosent mente det samme når AI-agenter kom inn i bildet (Deloitte, 2026).

Undersøkelsen omfattet nesten 550 amerikanske ledere på tvers av bransjer, så den beskriver ikke norske SMB-er direkte. Men retningen er tydelig nok: modenhet i automatisering overføres ikke automatisk til modenhet i agentarbeid. Det er to ulike ferdigheter.

Tre til fem agenter og hvorfor teamstørrelsen avgjør resultatet

Det mest nyttige enkeltfunnet i litteraturen om agentisk koding handler ikke om modeller, men om antall. Tre til fem teammedlemmer er det optimale antallet for Agent Teams, og tre fokuserte agenter presterer konsekvent bedre enn en generalist som jobber tre ganger så lenge (addyosmani.com, 2026). Parallelle agenter gir opp mot 3x gjennomstrømning i denne størrelsesordenen.

Hvorfor fokus slår utholdenhet

En generalistagent som jobber lenge drar med seg hele kontekstvinduet sitt gjennom alle faser av oppgaven. Jo lenger den jobber, jo mer irrelevant kontekst konkurrerer med det som faktisk er viktig akkurat nå. Tre agenter med hver sin avgrensede rolle har hver for seg et renere utgangspunkt, og de kan jobbe samtidig. Gevinsten kommer altså fra to hold: mindre kontekststøy per agent, og faktisk parallellitet.

Dette er også grunnen til at rollebeskrivelsene betyr mer enn antallet i seg selv. En agent som eier frontend, en som eier backend og en som eier tester er tre roller med lite overlapp. Tre agenter som alle «hjelper til med funksjonen» er en generalist i tre eksemplarer.

Hva som ryker når du skalerer opp for tidlig

Over den anbefalte størrelsen begynner tre ting å gi etter samtidig. Koordineringskostnaden stiger fordi flere agenter må enes om hvem som eier hvilke filer. Antall merge-konflikter stiger fordi flere grener rører de samme områdene. Og tilsynsbyrden stiger raskest av alt, fordi hver ekstra agent produserer arbeid som et menneske til slutt må lese. Den siste kurven er den som knekker team.

Det er verdt å merke at de store referansetallene i markedet kommer fra organisasjoner med helt annen kapasitet. Zapier oppgir 89 prosent AI-adopsjon på tvers av organisasjonen med over 800 AI-agenter internt (Anthropic, 2026). Det er et endepunkt, ikke et startpunkt, og det ble bygget over tid med egne folk på styring og drift.

Aluras posisjon: start smalt

Alura mener at et team på tre til fem agenter gir mer enn å skalere opp antallet tidlig. Begrunnelsen er praktisk: i et lite team kan du fortsatt lese alt som produseres, du kan knytte hver PR til en rolle, og du kan avlyse forsøket uten å ha bygget avhengigheter du ikke forstår. Den læringen du får av tre agenter du følger tett, er mer verdt enn den du får av ti agenter du bare sampler fra.

Vår erfaring er at team som starter stort ender opp med å måle feil ting. De teller antall PR-er i stedet for antall PR-er som kom gjennom review uten omarbeiding. Det første tallet ser bra ut med en gang. Det andre er det som faktisk sier om arbeidsformen virker.

Mandag morgen: slik setter du opp det første agent-teamet

Et forsvarlig førsteforsøk tar en arbeidsuke og krever ingen omorganisering. Det krever at fire ting er bestemt på forhånd: hvilket repo, hvilke roller, hvilke kontekstfiler og hvem som verifiserer. Rekkefølgen er viktig, fordi den siste avgjørelsen er den som oftest blir utsatt og alltid er den dyreste å utsette.

Velg repo og oppgave før du velger verktøy

Alura mener pilotene bør kjøres på ikke-sensitive repoer så lenge skytrådene mangler tilgang til interne verktøy og nettverk. Begrensningen er dokumentert i lanseringen og gjelder fortsatt i betaen (VentureBeat). Et repo uten kundedata, uten produksjonshemmeligheter og uten avhengigheter til interne systemer gir deg reell læring uten å flytte risiko dit ledelsen ikke har godkjent den.

Oppgaven bør være kjedelig og godt avgrenset: en refaktorering, en testdekningsjobb, en oppgradering av avhengigheter, en migrering av et mønster gjennom mange filer. Slike oppgaver har et tydelig ferdigkriterium. Det gjør verifiseringen billig og gjør det mulig å se om parallelliteten faktisk hjalp.

Skriv kontekstfilene selv

Alura mener kontekstfiler bør skrives av utviklere selv, ikke genereres av modellen. Dette er ikke en prinsipiell holdning, det er et måleresultat. LLM-generert AGENTS.md ga en gjennomsnittlig reduksjon i suksessrate og økte inferenskostnadene med over 20 %, mens utvikler-skrevne kontekstfiler målte bedre på begge deler (addyosmani.com, 2026).

Forklaringen er banal. En modell som beskriver kodebasen din skriver det den kan utlede fra koden. Det agentene trenger er det som ikke står i koden: hvorfor et modul er som det er, hvilke mønstre som er forlatt, hvilke filer ingen skal røre uten å spørre, og hvilke tester som faktisk betyr noe. En kontekstfil på en side skrevet av en utvikler som kjenner historikken slår tjue sider generert tekst.

Roller, tokenbudsjetter og kjøreplan for første uke

Gi hver agent en rolle, et ansvarsområde og et tokenbudsjett. Budsjettene bør reflektere hvor tung konteksten faktisk er: i et dokumentert oppsett hadde Frontend-agenten 180 000 tokens og Backend-agenten 280 000 tokens, fordi backend-arbeidet drar med seg mer kontekst (addyosmani.com, 2026).

Rolle	Ansvar	Tokenbudsjett	Stoppsignal
Frontend	Komponenter, visning, tilstand i grensesnittet	180k tokens	Auto-pause ved 85 % av budsjettet
Backend	API, datamodell, forretningslogikk	280k tokens	Auto-pause ved 85 % av budsjettet
Test og verifisering	Testdekning, reproduksjon av feil, kjøring av suite	Settes av teamet, typisk lavere enn backend	Drepes og reassignes etter 3+ iterasjoner uten fremgang
Koordinator	Fordeler oppgaver, holder delt minne, løser overlapp	Settes av teamet	Eskalerer til menneske ved uavklart konflikt

Kjøreplanen for uken kan være enkel. Mandag: velg repo, skriv kontekstfilene, definer rollene. Tirsdag og onsdag: kjør teamet på en avgrenset oppgave med asynkrone sjekker hvert 5-10 minutt. Torsdag: la review-eieren gå gjennom alt som er produsert, uten hastverk. Fredag: skriv ned hva som faktisk tok tid, og bestem om dere fortsetter. Uten den siste dagen blir piloten en anekdote i stedet for en beslutning.

Verifisering er den nye flaskehalsen

Når generering blir billig, flytter kostnaden seg til det som må skje etterpå. Verifisering, ikke generering, er den nye flaskehalsen i agentisk koding (addyosmani.com, 2026). Det er en enkel setning med ubehagelige konsekvenser for hvordan et utviklingsteam er bemannet.

Alura mener verifisering, ikke generering, er kapasiteten team må bygge først. Et team som tredobler mengden kode uten å endre hvordan kode leses, testes og godkjennes, har ikke økt kapasiteten sin. Det har flyttet køen.

Hvorfor delegeringsgapet ikke lukkes av flere agenter

Gapet mellom hvor mye AI brukes og hvor mye som kan delegeres fullt ut er det mest ærlige tallet i hele feltet. Utviklere bruker AI i store deler av arbeidet, men kan slippe taket helt på bare en liten andel av oppgavene (Anthropic, 2026). Flere agenter gjør ikke den andelen større. Bedre verifisering gjør det.

Det finnes en positiv side av samme mynt. Rapporten peker på at 27 % av det AI-assisterte arbeidet er oppgaver som ellers ikke ville blitt gjort i det hele tatt. Det er reell tilleggsverdi, men det er også ny kode som må vedlikeholdes av noen. Gratis er det ikke.

Bygg verifiseringskapasitet før volum

I praksis betyr dette tre konkrete grep. Utvid den automatiske testdekningen i de områdene agentene får lov til å røre, slik at maskinen tar førstelinjen. Innfør et krav om at hver agent-PR beskriver hva som er testet og hvordan, ikke bare hva som er endret. Og gi en navngitt person ansvar for godkjenning i pilotperioden, med tid satt av til det i kalenderen.

Pålitelighet må komme før hastighet når systemer begynner å jobbe uten kontinuerlig tilsyn, et mønster vi har beskrevet i forbindelse med selvforbedrende agenter. Rekkefølgen er den samme her: et team som kan verifisere raskt, kan trygt generere mer. Motsatt vei fungerer ikke.

Sjekkrutine når flere PR-er lander samtidig

Asynkrone sjekker hvert 5-10 minutt holder mennesket i loopen uten å gjøre det til en flaskehals i sanntid (addyosmani.com, 2026). Sjekken trenger ikke være dyp. Den skal svare på tre spørsmål: jobber agenten fortsatt på riktig problem, har den gått i loop, og har den brukt uforholdsmessig mye av budsjettet sitt.

For selve godkjenningen fungerer en enkel regel: ingen agent-PR merges uten at et menneske har lest diffen og kjørt testene lokalt eller i CI. Det høres selvfølgelig ut. Det er også den regelen som først ryker når teamet begynner å stole på agentene.

Hva tallene sier om markedet for autonome AI-agenter

Markedstallene er nyttige som kontekst og farlige som beslutningsgrunnlag. De sier noe om hvor investeringene går, ikke om hvorvidt din kodebase er klar. Les dem som temperaturmåling, ikke som anbefaling.

Prognosen og orkestreringspremien

Markedet for autonome AI-agenter er anslått til 8,5 milliarder dollar innen 2026 og 35 milliarder dollar innen 2030 (Deloitte, 2026). Deloitte forutser at bedre orkestrering alene kan løfte prognosen med 15 til 30 prosent, til opp mot 45 milliarder dollar innen 2030. Det er en påstand om at koordineringslaget, ikke modellene, er der den ekstra verdien ligger.

Måltall	Verdi	Kilde og horisont
Marked for autonome AI-agenter	8,5 milliarder dollar	Deloitte, innen 2026
Marked for autonome AI-agenter	35 milliarder dollar	Deloitte, innen 2030
Effekt av bedre orkestrering	15 til 30 prosent høyere prognose	Deloitte, mot 45 milliarder dollar innen 2030
Bedriftsprogramvare med agentisk AI	33 prosent	Gartner, innen 2028, opp fra et marginalt nivå i 2024
Agentiske AI-prosjekter som kan kanselleres	Mer enn 40 prosent	Estimat gjengitt av Deloitte, innen 2027

Gartner forutser at 33 prosent av bedriftsprogramvare vil inkludere agentisk AI innen 2028, opp fra et marginalt nivå i 2024. Kurven er bratt, men den beskriver programvare som leveres med agenter innebygget, ikke team som har lært seg å orkestrere dem selv. Det er to ulike ting, og de kommer ikke nødvendigvis samtidig.

Hva resultatene faktisk ser ut som

Kundeeksemplene i Anthropics rapport er de mest konkrete tallene som finnes offentlig. Hos TELUS laget team over 13 000 egne AI-løsninger og leverte kode 30 prosent raskere, med 500 000 timer spart (Anthropic, 2026). Fountain oppnådde 50 % raskere screening, 40 % raskere onboarding og doblet kandidatkonvertering med multi-agent orkestrering.

De mest spektakulære eksemplene bør leses med skepsis. En kunde av Augment Code fullførte et prosjekt CTO-en hadde estimert til 4 til 8 måneder på to uker. Slike tall forteller sjelden hvor mye av estimatet som var konservativt, hvor mye arbeid som ble kuttet, eller hvor mye etterarbeid som kom i måneden etterpå. Bruk dem til å begrunne en pilot, ikke til å begrunne et budsjett. Bredden i agentbruk utenfor utviklingsarbeid beskrev vi nærmere i saken om agenter i CRM.

---

Les også: Tolv AI-agenter per bedrift endrer CRM for norske SMB-er. Organisasjoner kjorer i snitt tolv AI-agenter, og adopsjonen ventes a oke 67 prosent pa to ar.

---

Kostnadsbildet: tokenbudsjetter og når en agent bør stoppes

Parallelle agenter koster parallelt. Tre agenter som jobber samtidig bruker langt mer inferens enn en agent alene, og til forskjell fra en menneskelig utvikler stopper de ikke av seg selv når de går i sirkel. Derfor må stoppreglene settes før kjøringen starter, ikke underveis.

Budsjett per rolle, ikke per team

Et samlet tokenbudsjett for hele teamet gir feil insentiv, fordi den mest kontekst-sultne agenten spiser opp de andres rom. Per rolle blir budsjettet et styringsverktøy: backend får mer enn frontend fordi konteksten er tyngre, og forskjellen er synlig for alle (addyosmani.com, 2026).

Legg merke til at en subagent-demo alene lå på rundt 220 000 tokens. Et team med flere roller som hver har sitt eget budsjett i samme størrelsesorden er ikke en marginalkostnad. Det er en post som skal inn i regnearket før piloten, ikke etter.

Stoppregler som faktisk brukes

Regel	Terskel	Hva som skjer
Auto-pause på tokenbudsjett	85 prosent av budsjettet	Agenten stopper og venter på menneskelig avgjørelse
Loop-deteksjon	3+ iterasjoner uten fremgang	Agenten drepes og oppgaven reassignes
Asynkron sjekk	Hvert 5-10 minutt	Menneske vurderer retning, ikke detaljer
Kontekstfil-policy	LLM-generert AGENTS.md	Unngås: lavere suksessrate og merkbart høyere inferenskostnad

Terskelen på 85 prosent av tokenbudsjettet er valgt med vilje: den utløses mens det fortsatt er rom til å fullføre hvis mennesket sier ja. En pause ved 100 prosent er ingen pause, det er et sammenbrudd. Tilsvarende er regelen om å drepe og reassigne etter tre eller flere iterasjoner uten fremgang en erkjennelse av at agenter sjelden graver seg ut av et hull de har gravd selv.

Kostnaden som ikke står i fakturaen

Den største kostnadsposten i en multi-agent-pilot er ikke tokens. Det er tiden til de seniorutviklerne som må lese resultatet. Hvis fire agenter produserer arbeid gjennom en dag, og gjennomgangen tar en senior halve neste dag, er den reelle prisen per leveranse langt høyere enn inferenskostnaden antyder.

Dette er også grunnen til at gevinstberegninger bør gjøres på leveranser som faktisk kom i produksjon, ikke på antall genererte linjer. Et team som måler output i stedet for gjennomført arbeid vil alltid konkludere med at multi-agent koding lønner seg, uavhengig av om det gjør det.

Menneskelig tilsyn når agentene jobber parallelt

Tilsyn med en assistent er trivielt: du leser forslaget før du godtar det. Tilsyn med fem agenter som jobber asynkront over flere timer er en styringsoppgave. Den må designes, ikke improviseres.

Fra menneske i loopen til menneske over loopen

Deloitte forutser at virksomheter de neste 12 til 18 månedene vil akselerere eksperimentering og skalering av komplekse agent-orkestreringer med mennesker i loopen, og at de mest avanserte i 2026 begynner å legge grunnlaget for et skifte mot human-on-the-loop (Deloitte, 2026). Forskjellen er ikke kosmetisk. I loopen godkjenner du hver handling. Over loopen setter du rammene og griper inn ved avvik.

De fleste norske SMB-er hører hjemme i den første modellen en god stund til. Det er også der styringen er billigst: du trenger ingen egen overvåkingsplattform for tre agenter som leverer PR-er du leser selv. Samme rapport anslår at minst 15 prosent av daglige arbeidsbeslutninger kan bli tatt autonomt av AI-agenter, og at 86 prosent av CHRO-ene i en undersøkelse blant 200 HR-ledere ser integrering av digital arbeidskraft som sentralt i sin rolle. Styringsspørsmålet kommer uansett, det er bare et spørsmål om når.

Sikkerhet, tilgang og regulatoriske hensyn

Så lenge trådene kjører i skyen på egne kopier av repoet, er tilgangsstyring den viktigste kontrollen du har. Hva ligger i repoet? Hemmeligheter i konfigfiler, kundedata i testfikstur, interne domenenavn i dokumentasjon? Et repo som er trygt for et menneske med tilgangsklarering er ikke nødvendigvis trygt å speile inn i et eksternt miljø. Sikkerhetsproblemene i agentutrullinger er godt dokumentert og handler oftere om tilgang enn om modellen selv, noe vi har gått gjennom i saken om sårbarheter i AI-agenter.

Regulatorisk er utviklingsverktøy et mildere område enn kundevendte systemer, men det forsvinner ikke. Autonome agenter som handler på vegne av en virksomhet er fortsatt et uavklart felt i regelverket, som vi har beskrevet i forbindelse med personlige AI-agenter og AI Act. For en kodepilot er det praktiske rådet enkelt: dokumenter hvilke repoer som er i scope, hvem som godkjente det, og hva som ble delt.

Markedsobservasjon: hva norske team bør følge med på

Betaperioden er en informasjonsinnhentingsfase, ikke en innkjøpsfase. Det er tre signaler som avgjør om multi-agent koding går fra interessant til investerbart for et vanlig norsk utviklingsteam, og alle tre er observerbare utenfra.

Tre signaler verdt å følge

Det første er lokal tilgang. Når skytrådene kan nå filer og verktøy på utviklerens maskin og i interne nettverk, utvides oppgavesettet dramatisk, fra isolerte oppgaver til reelt produktarbeid (VentureBeat). Frem til da er piloten begrenset til det som kan kjøres isolert.

Det andre er bredden i tilgang. Funksjonen er i beta for utvalgte Pro- og Max-abonnenter, med utvidelse til Pro, Max, Team og Enterprise senere (The Verge). Et team kan ikke standardisere på noe halve teamet ikke har. Det tredje er protokoller og plattformer for orkestrering på tvers av leverandører, som Deloitte peker på som en forutsetning for at verdien skal realiseres (Deloitte, 2026).

Hva som bør utløse en ny vurdering

Sett opp en dato, ikke en følelse. Et kvartalsvis sjekkpunkt der teamet går gjennom de tre signalene over og svarer ja eller nei på hvert, er nok. Hvis to av tre er på plass, er det på tide å utvide piloten. Hvis ingen har flyttet seg, er svaret å vente og bruke tiden på verifiseringskapasitet i stedet.

Vær også oppmerksom på det motsatte signalet. Estimatet om at mer enn 40 prosent av agentiske AI-prosjekter kan bli kansellert innen 2027 betyr at en del av det som ser ut som modning i markedet kommer til å reverseres (Deloitte, 2026). Et team som ikke har bundet seg for hardt, tåler den korreksjonen bedre.

Vanlige feil når team går fra en assistent til mange agenter

Feilene er forutsigbare, og de gjentar seg på tvers av team og bransjer. Det gode er at samtlige kan unngås med beslutninger tatt før piloten starter.

For mange agenter, for tidlig

Den vanligste feilen er å tro at antall agenter er det som skalerer gevinsten. Forskningen peker motsatt vei: et lite, fokusert team slår både en utholdende generalist og et stort, løst koordinert oppsett (addyosmani.com, 2026). Legg til agenter først når du har et konkret ansvarsområde som ingen av de eksisterende eier, ikke fordi kapasiteten finnes.

Ingen eier verifiseringen

Når review er «alles ansvar» i et team med parallelle agenter, blir det ingens. Resultatet er at PR-er hoper seg opp, at noen til slutt merger på tillit, og at den første alvorlige feilen kommer fra kode ingen faktisk leste. Sett navn på review-eieren og sett av tid i kalenderen. Dette er den enkleste og mest oversette kontrollen i hele oppsettet.

Modellen skriver sine egne instruksjoner

Å be modellen generere kontekstfilene sine selv føles effektivt og måler dårligere på begge akser som betyr noe: suksessrate ned, inferenskostnad opp (addyosmani.com, 2026). Den andre varianten av samme feil er kontekstfiler som aldri oppdateres. En fil som beskriver kodebasen slik den var for et halvt år siden, styrer agentene mot mønstre teamet har forlatt.

Ofte stilte spørsmål om multi-agent koding

Spørsmålene under er de som oftest kommer opp når et ledergruppe eller et utviklingsteam vurderer et første forsøk.

Hvor mange agenter bør vi starte med?

Tre. Frontend, backend og test er en naturlig første deling i de fleste kodebaser, og tre fokuserte agenter presterer konsekvent bedre enn en utholdende generalist (addyosmani.com, 2026). Utvid til fire eller fem når dere har kjørt minst en full oppgave gjennom review uten å måtte gjøre om alt.

Trenger vi Claude Code Projects for å prøve dette?

Nei. Subagenter og enklere parallelle oppsett gir mye av læringen uten å kreve tilgang til en beta. Det Projects legger til er koordineringslaget: delt minne, en koordinator som løser overlapp, og tråder som lever over tid (The Verge). Hvis teamet ikke har rutiner for review av AI-generert kode ennå, er det arbeidet uansett viktigere enn verktøyvalget.

Hva koster et agent-team i tokens?

Det avhenger av rollene, men størrelsesordenen er kjent: budsjetter på 180 000 tokens for frontend og 280 000 tokens for backend er dokumentert i et fungerende oppsett, og en enkelt subagent-demo lå på rundt 220 000 tokens (addyosmani.com, 2026). Sett budsjett per rolle, og la auto-pause ved 85 prosent hindre at en agent bruker opp alt uten å levere.

Hvem godkjenner koden når flere agenter leverer samtidig?

Et menneske, med navn, i hele pilotperioden. Trådene jobber på egne grener, og overlapp løses som merge-konflikt i en vanlig PR (The Verge). Det betyr at godkjenningsrutinen dere allerede har fungerer teknisk. Det den ikke gjør, er å skalere av seg selv når volumet øker.

Er dette trygt å kjøre på vår egen kodebase?

I betaen kjører trådene i skyen uten tilgang til filer, verktøy eller interne nettverk hos dere (VentureBeat). Det begrenser hva agentene kan gjøre, men det fjerner ikke spørsmålet om hva som ligger i repoet dere gir dem. Start på et repo uten kundedata og uten produksjonshemmeligheter, og ta avgjørelsen om sensitive repoer på nytt når lokal tilgang faktisk er tilgjengelig.

Oppsummering og neste steg

Multi-agent koding er reelt, det er tilgjengelig i begrenset form, og det gir målbar gevinst i riktig størrelsesorden. Tre til fem agenter er der effekten er dokumentert, og parallelliteten i den størrelsen gir en markant høyere gjennomstrømning enn en enkelt agent (addyosmani.com, 2026). Alt over det krever styringskapasitet de færreste SMB-er har bygget ennå.

Det som avgjør utfallet er ikke modellen, men to ting teamet eier selv: kontekstfilene og verifiseringen. Kontekstfiler skrevet av utviklere måler bedre enn genererte på både treffsikkerhet og kostnad. Verifisering er der flaskehalsen faktisk ligger når generering blir billig, og det er kapasiteten som bør bygges først.

Markedet vil bevege seg raskere enn de fleste team klarer å følge. Prognosene for autonome agenter peker kraftig oppover, samtidig som en betydelig andel av dagens agentiske prosjekter kan bli avlyst før 2027 (Deloitte, 2026). Begge deler kan være sant samtidig, og begge deler taler for å lære raskt uten å binde seg hardt.

Neste steg denne uken: velg et ikke-sensitivt repo, skriv kontekstfilene selv, definer tre roller med hvert sitt tokenbudsjett, sett en navngitt review-eier, og kjør en avgrenset oppgave gjennom hele løpet inkludert godkjenning. Mål hvor mye som kom gjennom review uten omarbeiding. Det tallet, og ikke antall genererte linjer, forteller om teamet er klart for mer.

I Alura bygger vi AI-infrastruktur for norske virksomheter, fra dataplattformer til agentiske systemer i produksjon. Vi er ikke en SaaS-leverandør. Vi er håndverkere som setter sammen byggesteinene som faktisk fungerer for din situasjon.

Bestill en arkitektur-samtale: vi går gjennom din nåværende infrastruktur, identifiserer integrasjonspunkter, og foreslår en pragmatisk vei videre. Uforpliktende, 45 minutter.

Kilder

• addyosmani.com (2026). The Code Agent Orchestra - what makes multi-agent coding work | AddyOsmani.com
• Anthropic (2026). 2026 Agentic Coding Trends Report
• VentureBeat. Anthropic launches Claude Code Projects, an 'always ... - VentureBeat
• Deloitte (2026). Unlocking exponential value with AI agent orchestration
• The Verge. Claude Code relaunches Projects to manage multiple AI ...