AI-agenter: Fra lekebinge til utviklingsteam

Når du starter med AI-kodingverktøy som Claude eller agent-rammeverk, er det fristende å sette opp barrierer overalt. Det har reddet mange fra katastrofer, som en agent som sletter hele filsystemet ditt.

Containerisering fikset det verste. Agenter kunne eksperimentere fritt uten å rote til dine filer. Men så skjedde noe: Folk oppdaget at disse verktøyene faktisk taklet ekte jobb. Ikke bare lek, men kode som går i produksjon.

Da raknet ideen om én agent som gjør alt.

Problemet med parallell kjøring

Tenk deg disse oppgavene:

• Refaktorere et API-endepunkt
• Fikse feilende tester
• Sjekke Docker-oppsett
• Forbedre frontenden

Du kunne stille dem i kø. Agenten gjør én, du sjekker, så neste. Men da sitter du bare og passer på – motsatt av poenget med autonomi.

Prøv flere agenter samtidig. Da blir det kaos.

Git havner i krise. To agenter som pusser på samme repo og branch? Konflikter overalt. Plutselig forstår du hvorfor code review finnes.

Filsystemet krangler. Prosjekter har node_modules, cache-filer, generert kode, SQLite-db-er og .env-filer som lekker hemmeligheter. Ingenting er i Git. Flere prosesser som tukler med det samme? Kollisjon.

Docker Compose dreper alt. Begge vil ha port 5432. Samme container-navn. Samme volume. Parallell fremgang blir en container-død.

Git worktrees er ikke nok

Mange sier: Bruk Git worktrees!

Det løser ett problem – flere checkouts på ulike brancher med én .git-mappe. Bra for mennesker. For agenter? Bare 15 % av løsningen, pluss masse manuell oppsett.

Ingen egen node_modules. Ingen isolert .env. Ingen Docker Compose med eget navneområde. Du må installere deps, bygge cache, endre porter – og håpe på at ingen har hardkodet paths.

Som å gi en ansatt et skrivebord uten verktøy.

Tenk på agenter som ekte utviklere

Skiftet er dette: Se på agenter som teammedlemmer, ikke verktøy.

Du gir ikke nyutvikler Alice en worktree. Du sier: Klon repoet, sett opp miljøet, kjør appen lokalt, push branch når ferdig.

Du fork ikke branchen. Du fork utviklerens hele kontekst.

For parallell jobb trenger agenter: Eget miljø. Egen repo-klone, deps, .env. Null delte filer.

Uavhengig infra. Separat Docker Compose med eget navneområde. Agent As Postgres krangler ikke med Agent Bs Redis.

Rett autentisering. SSH for Git. Scoped GitHub-tokener. Ikke én felles nøkkel.

Kontekstforståelse. Hvilken branch? Hva er oppgaven? Hva er suksess?

Asynk samarbeid. De jobber alene, legger fra seg reviewbar kode. Du bestemmer merge.

Slik ser det ut i praksis

Hos NameOcean ser vi team bygge dette. Flere agent-instanser med:

• Containeriserte workspaces (som yolobox)
• Egen DB eller fixtures
• Separat Docker Compose
• Manifests med prosjektkontekst
• Clipboard og SSH for integrasjon

Flyten går sånn:

1. Agent Alpha starter i workspace A, fikser autentisering
2. Agent Beta i B, lager API-dok
3. Agent Gamma i C, skriver tester
4. Alle pusher til feature-brancher
5. Du reviewer parallelt, merger smart

Ingen kø. Ingen tilsyn. Ingen container-kræsj.

Infra-måten

Dette krever ny tenkning rundt dev-miljøer. Cloud-plattformer henger med – IaC blir must. Docker, Kubernetes og container-dev (som NameOcean Vibe Hosting tester) er essensielt.

Templater teller: Dockerfile-snutter, compose-varianter, bootstrap-scripts. Det er agentenes spec.

Hvorfor nå?

AI-agenter er flinke nok til å være farlige – og verd investering. Team som organiserer dem som software-team vinner fart.

Det handler ikke bare om hastighet. Det handler om å multiplisere kapasitet, ikke bare automatisere tastetrykk.

Neste steg

Eksperimenterer du med AI-agenter?

1. Design for flere fra start. Ikke optimaliser for én.
2. Sats på miljø-templater. Docker og IaC er agentenes OS.
3. Sett grenser på tilgang. Frihet skaper kaos.
4. Prioriter provisioning. Rask spawn = høy produktivitet.
5. Versionér agent-miljøer. Som kode.

Fremtiden er orkestrerte team av mennesker og agenter i isolerte kontekster. Mot samme mål.

Da slippes ekte produktivitet løs.