.avif){kind=logo}
De nye AI-agentene kan bygge, teste og levere kode på egen hånd, i timevis. Men hva skal til for at arbeidsflyten din, og teamet ditt, faktisk er rigget for det?
Den 9. juni 2026 slapp Anthropic Fable 5, en modell bygget for lange, sammenhengende oppgaver. Dette forsterker noe vi har sett nærme seg en stund: En agent kan nå jobbe selvstendig i timevis og komme tilbake med ferdig arbeid. En gren som bygger, tester grønt og venter på review, i stedet for et utkast du må reparere. Du gir den et mål, og den arbeider mot det på egen hånd.
Men når agenten kan løpe så langt på egen hånd, bommer de fleste av oss i én av to retninger. Den første er autopilot: overlat alt, godkjenn alt, og våkn opp tre uker senere i en kodebase ingen forstår. Den andre er mikrostyring: stol på ingenting, les hver diff linje for linje, og bli sittende som flaskehals i ditt eget verktøy.
Middelveien er verken mer tillit eller mer kontroll. Den handler om design av utviklingsprosess. Jo lenger agenten kan løpe på egen hånd, desto mer avhenger resultatet av miljøet den løper i, ikke av den enkelte prompten du skriver. Du rigger arbeidsflyten, koder prosessen inn som skills og regler, og lar agenten løpe på skinnene du har lagt. Det er det jeg kaller å rigge kodebasen din for suksess.
Og her ligger spenningen dette innlegget skal løse opp i. Nesten alle utviklere jeg snakker med har nå et personlig oppsett: en AGENTS.md her, et par skills der, en lokal vane for hvordan de prompter. Mange har også begynt å løfte deler av det til teamnivå, i ulik grad. Det er der dette innlegget kommer inn, som en sjekkliste for hvor langt oppsettet ditt faktisk rekker.
Dette innlegget er et personlig forsøk på å fortelle om skinnene: fra spec via rigg og byggesløyfe til review og parallellitet, og til slutt det viktigste steget, fra solo til team.
Før vi bygger noe som helst, må vi forstå én grunnsetning. Alt annet i dette innlegget er konsekvenser av den.
Hands-off rekker nøyaktig så langt som agenten kan verifisere seg selv.
Hvorfor? Fordi modellen som vurderer om arbeidet er ferdig, bare ser det som havner i samtalekontekst. Den ser ikke skjermen din (før det havner i kontekst), ikke intensjonen din, ikke det du "egentlig mente". Hvis testresultatet, typesjekken eller skjermbildet ikke finnes i konteksten, finnes det ikke for agenten.
Konsekvensen er at "ferdig" må være noe en maskin kan observere. En vag følelse som "brukeropplevelsen er bra" holder ikke alene, men det betyr ikke at opplevelse er umålbar. Definerer du akseptkriterier (acceptance criteria) for hva "bra" faktisk betyr, og gir agenten verktøy til å sjekke dem, for eksempel skjermbilder eller Playwright-snapshots i nettleseren, blir også det observerbart. "Føles bra" blir til "skjermbildet matcher designet og testene som dekker flyten passerer", og det kan en maskin faktisk verifisere.
Alt som følger i dette innlegget kan leses som svar på ett spørsmål: hvordan flytter vi den grensen lenger ut? Spec-en gjør målet observerbart. Riggen gir agenten øyne og hender. Reviewsløyfen fanger det agenten ikke ser selv. Og teamsteget gjør at grensen flyttes for alle, ikke bare for deg.
Det første skinnesporet legges før agenten i det hele tatt starter. En god oppgave er definert av verifiserbare akseptkriterier (acceptance criteria): konkrete betingelser agenten selv kan sjekke, som "testene i auth/ passerer og endepunktet returnerer 401 uten gyldig token". Hele disiplinen rundt dette dekket vi i Spec-Driven Development, så her nøyer jeg meg med det som er nytt.
Min mest verdifulle vane er det jeg kaller grill-me-fasen: en egen modus der agenten nekter å skrive kode og i stedet intervjuer deg. Den stiller spørsmålene du ikke har tenkt på. Dette er noe annet enn å be agenten "still meg noen spørsmål". Claude Code har et innebygd "Ask User"-verktøy, men det er bare en primitiv for å stille et spørsmål. Grill-me er grundig og uttømmende: den jobber seg gjennom hele beslutningstreet og gir seg ikke før dere har en delt forståelse. Den kan gjerne bruke Ask User-verktøyet underveis, det er ikke enten eller, men i praksis sier jeg alltid "grill meg" heller enn "still meg spørsmål".
Ti minutter med grundige spørsmål før koding tvinger meg til å være mentalt påskrudd, og sparer timer med feilrettet arbeid etterpå. Det er billigere å finne hullene i spec-en mens den fortsatt er tekst. Den samme øvelsen er minst like nyttig sammen med teamet: bruk grillingen til å samkjøre dere om edge-casene før noen setter i gang med implementeringen.
En oppgave som bare finnes i en chat-melding er flyktig. Den forsvinner når kontekstvinduet komprimeres, og den kan ikke deles. Trekk i stedet oppgaven fra en issue i prosjektstyringsverktøyet ditt, enten det er GitHub Issues, Jira eller noe annet: der ligger kravene, diskusjonen og akseptkriteriene på ett varig, delbart sted. Agenten leser issuen, du leser den samme issuen, og "hva var det vi egentlig ble enige om?" har alltid et svar.
Gi agenten CLI-en til verktøyet, og "skillify" hvordan dere bruker det. Hos kunden jeg jobber for nå, har vi kodet inn som skills hvordan vi vil at issues skal opprettes, hvordan pull requests skrives, og hvordan en agent administrerer kanban-tavlen vår i GitHub Projects. Det samme lar seg gjøre i Jira; prinsippet er uavhengig av verktøy.
Gevinsten er delt kontekst. Spec, diskusjon, akseptkriterier og ferske funn dokumenteres som kommentarer på issuen, slik at hele teamet kan lese dem i sanntid og mate dem inn i sin egen agent. Tatt helt til det ekstreme: når designerne og forretningsutviklerne også har agenter koblet til de samme verktøyene, får de den samme rike konteksten som deg. Det er en fordel for hele teamet.
Skills er kodifisert prosess: små, navngitte instruksjonsfiler som beskriver hvordan en bestemt type oppgave skal gjøres i akkurat dette prosjektet.
Mekanismen som gjør dette levende er en skill kalt /write-a-skill, en av skillsene i Matt Pococks skill-sett jeg bruker daglig. Tanken bak er at når du finner ut av noe, fikser du det ikke bare én gang. Du koder oppdagelsen inn som en skill, slik at den blir permanent for deg og resten av teamet.
En kort merknad: mange har hørt om Anthropics Skill Creator, men færre kjenner Matt Pococks /write-a-skill. For meg er dette ren personlig preferanse, men Matt har bygget seg et godt rykte med skarpe, presise og konsise skills, og det smitter over på write-a-skill. Bruk gjerne den du selv foretrekker; begge gjør jobben.
I konteksten av skills er det dette som er den mentale modellen: institusjonaliser arbeidsflyten du gjentar igjen og igjen. Hold øye med hva du retter på agenten for, uke etter uke. Og vær oppmerksom på det du vet du kommer til å gjøre mange ganger: opprette en issue, kartlegge hvordan data flyter fra klient til server til database og tilbake, eller slå opp intern dokumentasjon i en enterprise-kontekst. Dette er gode kandidater for write-a-skill.
Spec-en sier hvor agenten skal. Riggen avgjør om den kommer frem. En agent er aldri bedre enn miljøet den jobber i, og miljøet har fire lag.
Raske tester, tydelige scripts (pnpm test, pnpm typecheck, pnpm lint) og en god AGENTS.md som forklarer konvensjonene gir agenten en tilbakemeldingssløyfe den kan stole på.
Et nyansert poeng om tester: det er ingenting i veien for å ha et stort, grundig sett med enhetstester på tvers av hele kodebasen, tvert imot gir det en grad av trygghet. Det viktige er å fortelle agenten hvordan den kjører et relevant utvalg. Dersom hele testsuiten tar to minutter å kjøre og agenten endrer én fil i backend, holder det å kjøre testene som dekker akkurat den koden underveis, og la hele suiten kjøre i CI. Slik beholder du både rask iterasjon lokalt og full dekning på GitHub.
Et ord om AGENTS.md: du kan ha flere av dem, én i roten og egne i undermapper. Men ikke fyll den med alt. Dagens modeller er blitt veldig gode til å utforske en kodebase på egen hånd, så det agenten kan finne selv, bør du la den finne selv; det sparer tokens. Hold AGENTS.md slank, og bruk den til det agenten ikke enkelt kan slå opp ved å lese koden: hva er dette produktet, og hvorfor bygger vi det? Den slags kontekst hører hjemme der.
Prøv så godt du kan å gi agenten færrest mulig rettigheter (least privilege), altså akkurat de tilgangene oppgaven krever for å gjøre jobben. Dette er sikkerhetsarbeidet fra Alle bruker AI-agenter. Hvem passer på sikkerheten?, anvendt på riggen.
Samtidig bør ikke agenten møte stadige hindre der den må stoppe og be om tilgang. Det dreper hele poenget med langløpende agenter. Husk at disse modellene i stor grad er trent til å være handlekraftige; med godt definerte mål, og tydelige kriterier for hva den ikke skal gjøre, følger de føringene dine godt. Du kan aldri være helt sikker, men det er en god tommelfingerregel.
Hooks er håndhevelse. Et hook er en kommando som kjører automatisk på en hendelse: etter hver filendring, før en commit, eller når et bestemt verktøy kalles. Endrer agenten en komponent under frontend/ui/, kan et hook kjøre formattering og lint på den med en gang. Mangler en commit tester, kan et hook stoppe den. Reglene håndheves av maskinen, ikke av agentens hukommelse.
Path-baserte regler tar dette videre på instruksjonssiden. Med .claude/rules/ legger du instruksjoner i egne filer som bare lastes inn når agenten jobber med filer som matcher et mønster. En regel scopet til backend-API-et dukker bare opp når agenten åpner en fil der, og fyller ikke kontekstvinduet resten av tiden:
---
paths:
-- "apps/backend/api/**/*.ts"
---
# Regler for API-laget
- Alle endepunkter validerer input.
- Bruk standard feilresponsformat.
- All datatilgang går gjennom repository-laget, aldri rå SQL i handlers.
Poenget er at konvensjonene møter agenten akkurat når de er relevante. En frontend-regel trigger på frontend-filer, en API-regel på API-filer, og agenten kan ikke trampe ned arkitekturen i et hjørne av kodebasen den sjelden ser. Du kan lese mer i Claudes dokumentasjon om rules.
Disse mekanismene har sin plass, men det er ikke åpenbart at du trenger dem fra dag én. Start enkelt, og legg til håndhevelse først der du faktisk ser agenten gjøre samme feil om igjen.
Jeg holder oppsettet mitt ganske lite og enkelt. Her er MCP-ene og CLI-ene jeg bruker hver dag, ment som et utgangspunkt: de nødvendige byggeklossene de fleste som vil jobbe agentisk bør kjenne til og vurdere mot egen arbeidsmåte.
/tmp på maskinen sin for å utforske det, smak og behag.playwright-cli i prosjektet ditt.
Et viktig poeng kobler dette tilbake til skills: en skill er oppskriften som beskriver hvordan du bruker en MCP eller CLI, så agenten ikke trenger å lære det på nytt hver gang. Ta det å opprette en GitHub-issue. Du har enten GitHub-MCP-en eller GitHub-CLI-en, men måten dere oppretter, oppdaterer og lukker issues på, koder du inn som en skill. Da gjør agenten det likt hver gang, uten at du må forklare verktøyet på nytt.
Legg merke til mønsteret: alle disse flytter verifiseringsgrensen fra loven over. Med Playwright i riggen blir "knappen er synlig og klikkbar" observerbart av en maskin.
Isolasjon kommer i trinn, og du trenger sjelden alle. Git worktree løser isolasjon på fil-laget: hver agent får sin egen arbeidskopi av repoet, så to agenter aldri skriver i samme fil. Docker løser isolasjon ved kjøretid: egen prosess, eget filsystem, eget nettverk.
Og her møter du fort et problem, nemlig portkonflikter. Fem parallelle agenter med hver sin dev-server vil alle ha port 3000. Et verktøy som løser nettopp dette er portless fra Vercel. I stedet for at du sjonglerer portnumre, gir det hver app en stabil adresse som myapp.localhost, og en lokal proxy ruter trafikken til riktig prosess bak kulissene.
Selve verktøyet er mindre viktig enn prinsippet det illustrerer: alt som kan kollidere mellom parallelle agenter, må håndteres på forhånd. Porten er bare et håndfast eksempel.
Med spec og rigg på plass kan vi endelig slippe agenten løs, på ordentlig. Sløyfen ser slik ut: agenten implementerer, kjører testene, leser feilene, retter, og gjentar til fullføringsbetingelsen fra issuen din er observert oppfylt i konteksten.
De fleste ganger trenger du ikke mer seremoni enn å peke på en godt spesifisert issue. Lim inn URL-en, og hele oppgaven, krav, diskusjon og akseptkriterier, lastes inn i konteksten agenten jobber mot. Da er det ofte nok å si "implementer denne".
/goal hører hjemme i det tøffere tilfellet: et underspesifisert mål, der du vil at agenten selv trekker opp en verifiserbar fullføringsbetingelse før den begynner, kjører i auto-modus og verifiserer seg selv hele veien. Det er power-user-varianten.
For det repetitive finnes /loop: samme oppgave anvendt på mange tilfeller, som eksempelvis "migrér én og én komponent til det nye designsystemet, kjør testene mellom hver". Kjedelig for et menneske, perfekt for en agent med riktig rigg rundt seg.
Modellen som skrev koden er for tett på den til å se sine egne feil. Den vil bekrefte sine egne antagelser, akkurat som vi gjør når vi korrekturleser vår egen tekst.
Løsningen er "adversarial review": en egen review-agent med ett oppdrag, å finne feil i arbeidet.
Tre regler gjør sløyfen effektiv:
Det kan også lønne seg å kjøre sløyfen flere ganger. Én review-runde har en blindsone, akkurat som én testkjøring av et ikke-deterministisk system sier lite. To eller tre uavhengige gjennomganger kan fange merkbart mer.
Selve sløyfen kan du i tillegg gjøre om til en skill, eller "skillifye", som jeg stadig oftere finner meg selv i å si. Claude shipper en /loop-skill som kjører en kommando om og om igjen, og samme idé lar deg bygge en loop som går gjennom reviewerens anbefalinger og adresserer, forkaster eller implementerer hver enkelt, før et menneske i det hele tatt ser på det. Revieweren kan være Claude i CI, Greptile, GitHub Copilot i CI, eller noe helt annet. Da blir den første review-runden enda mer autonom. For å være ærlig er dette et utpreget power-user-tilfelle, og passer ikke nødvendigvis enhver arbeidsflyt eller enhver oppgave, men det kan være lurt å være klar over at det er mulig.
Men det finnes en grense reviewen aldri kan flytte:
Reviewsløyfen fanger implementasjonsfeil, ikke kravfeil. Hvis spec-en er gal, vil to agenter i skjønn enighet bygge feil ting, grundig verifisert.
Det er derfor innlegget startet i den menneskelige enden. Ingen mengde automatisert review redder en dårlig spec. Din viktigste jobb ligger før koden.
Når én agent på skinner fungerer, er fristelsen å kjøre flere på en gang. Det går fint, men med noen klare begrensninger du må kjenne til.
Kjernen er git worktrees. Conductor, cmux og OpenCode Workspaces er alle praktiske innpakninger rundt det samme primitivet: én git worktree per agent, hver med sin egen arbeidskopi av repoet. Det er worktreet som gjør parallelliteten mulig; verktøyene gir deg bare et hyggeligere grensesnitt mot det.
Taket er fortsatt deg. Erfaringsmessig klarer du å holde styr på 2-4 parallelle agenter før du blir flaskehalsen i review. Hver agent produserer arbeid som fortjener et kritisk blikk, og blikket ditt skalerer ikke. Mer parallellitet uten mer review-kapasitet er bare en raskere vei ned i autopilot-grøfta.
Under lokal utvikling er det noen ting som er særlig viktig å være bevisst på før du parallelliserer dem:
pnpm-lock.yaml og venner): parallelt arbeid som endrer avhengigheter samtidig, gir konflikter i selve lockfilen.
Og den siste grensen, uansett hvor mange agenter du kjører: alt stopper ved PR-en. Aldri auto-merge. Agenten åpner pull requesten; et menneske trykker på knappen. Den menneskelige godkjenningen er kontrollpunktet som gjør resten av autonomien forsvarlig.
Det er her alt vi har bygget skal knyttes sammen. Riggen for AI-agentene, AGENTS.md, skills, MCP-konfigurasjon og egne agent-definisjoner, hører til i versjonskontroll, ikke bare på din egen maskin. Det er det som gjør den tilgjengelig for resten av teamet: den ene som finner ut noe smart, deler det med en commit, og dagen etter gjør agentene hos alle utviklere det på samme måte.
repo/
├── AGENTS.md # Konvensjoner, arkitektur, hva og hvorfor vi bygger
├── .mcp.json # MCP- og verktøyoppsett
└── .claude/
├── agents/ # Egne agent-definisjoner
└── skills/ # Oppskrifter, ett domene per skill
Verken autopilot eller mikrostyring, altså. Men ingeniøren som går fra å legge hver stein selv til å designe skinnene agenten løper på, koder prosessen inn som skills og regler, og lar agenten løpe.
Retningen videre er tydelig: mer parallellitet, lengre kjøringer, "fabrikker av agenter". Men jo mer av hvordan som automatiseres, desto mer verdifullt blir det som ikke flytter seg: menneskelig dømmekraft over hva som skal bygges, og hvorfor det skal bygges.
Det bringer oss tilbake til der vi startet. Når agentene kan løpe så langt på egen hånd, er det ikke nok å gi dem en god prompt; vi må rigge både kodebasene og måten vi jobber på rundt dem, uten å gi slipp på verifisering, akseptkriterier, testing og menneskelig smak. Dette innlegget har vært mitt forsøk på å destillere hvordan jeg selv jobber, alene og i team, i hobbyprosjekter og i enterprise, ned til en slags sjekkliste. Les den gjerne med en penn i hånden: kryss av det du allerede gjør godt, og finn det ene stedet, lite eller stort, der du eller teamet ditt kan ta neste steg.
/write-a-skill
Magnus bygger AI i Capra, nå på Gjensidiges «Hei, huset!». Han er opptatt av AI som fungerer i praksis og av å rigge tverrfaglige team for en AI-first arbeidsform. Det skriver han om og holder foredrag om.
