· oppdatert
Slik jobber jeg med kodeagenter
Flere Claude Code-økter samtidig mot systemer i drift: reglene som hindrer at det går galt, og gjennomgangen som ga dem.
Alt jeg leverer er bygd med AI-kodeagenter (Claude Code), som regel flere økter samtidig, mot systemer som allerede kjører. Én økt kan redigere et dashbord, en annen lese loggene på en e-postserver, en tredje endre søket i et produkt. Personen som drifter resultatet eier hver endring. Dette notatet er arbeidsreglene, og hvor de kom fra.
Hvor reglene kom fra
I september 2026 gikk jeg gjennom 68 av mine egne agentøkter. De inneholdt 38 feilaktige påstander i 27 økter: en tjeneste meldt frisk ut fra en gammel status, et tall gitt uten nevner, en årsak slått fast fra én logglinje. I 29 av de 38 fanget agenten feilen selv, minutter senere, med én billig kommando. Problemet var ikke innsats, men rekkefølge: påstanden var allerede committet, sendt til en annen økt eller fortalt meg før sjekken kjørte. Rettingen er en regel om rekkefølge, ikke om omhu.
Regel 1: en konklusjon forlater økten først etter at den billigste motprøven har kjørt
«Forlater» betyr en commit, et overleveringsnotat, en melding til en annen økt, en anbefaling, en statusrapport. Agenten navngir kommandoen som ville vist at den tar feil, kjører den, og sier så resultatet. Inntil da er det en hypotese og kalles det. Fem spørsmål følger med: Leser jeg selve tingen eller en stedfortreder (en avslutningskode, en åpen port, siste logglinje)? Kunne denne kommandoen ha vist problemet om det fantes? Er sammenligningen samme objekt, vindu og nevner? Står svaret allerede skrevet et sted? Sjekket jeg effekten, eller bare at handlingen kjørte?
Regel 2: delte ting reserveres før bruk og frigis etterpå
Når flere økter berører samme maskin, database eller wiki, reserverer en økt ressursen først, med utløpstid, og spør innehaveren når den er tatt. En utløpt reservasjon er ikke en ledig en; den betyr spør. Status sjekkes med en spørring, aldri antatt fra hukommelsen.
Regel 3: commits stages per fil
Ingen git add -A. Hver økt stager filene den endret og ingenting annet, så to økter
i samme repo ikke kan sende hverandres halvferdige arbeid.
Regel 4: helse er en spørring, ikke en påstand
«Tjenesten er oppe» besvares av en sjekk som kjører nå og returnerer nåværende tilstand, inkludert ledig minne før en tung jobb. Et gammelt «det var i orden» godtas ikke fra en agent mer enn fra et menneske.
Regel 5: LLM-funksjoner leveres bak en test som er sett feile
Evalueringen for en modellbasert funksjon brytes med vilje før den stoles på. Saken som gjorde dette til regel er skrevet opp for seg (En test som kan feile).
Regel 6: hvert problem logges
Et klumsete verktøykall, en uklar melding, en falsk alarm går i en datert logg i repoet det gjelder. Loggene er slik reglene over blir revidert, og det er der tallene fra gjennomgangen kom fra.
Der en regel er en hook
To av reglene er delvis kode, ikke vane. En hook i Claude Code kjører når et svar avsluttes, og slår opp alt i svaret som ser ut som en commit-hash i git; en hash som ikke finnes i noe repo, sender svaret tilbake til retting. Det er regel 1 for den påstanden som er billigst å sjekke maskinelt, lagt til etter at et svar navnga en commit som aldri hadde eksistert. En annen hook kjører før hver skallkommando. Den advarer når en kommando rører en bryter en annen økt kan eie (regel 2), og den stopper tre kommandomønstre som har gjort skade før: å drepe terminalserveren, en bakgrunnsstart som mister sporet av sin egen prosess, og et prosessdrap som treffer sitt eget skall.
Hooker feiler åpent som standard: krasjer selve sjekken, går svaret eller kommandoen gjennom. Fra versjon 2.1.295 kan
Claude Code snu det per hook med onFailure: "block", og kommandovakten har det satt: en vakt med feil sti stopper
kommandoen i stedet for å slippe den forbi (testet med en vakt som peker på en fil som ikke finnes). På sjekken ved
slutten av svaret har innstillingen ingen effekt, så den feiler fortsatt åpent.
Regel 4 har ingen hook: om en tjeneste er frisk, avhenger av tjenesten, og det forblir en spørring agenten må kjøre.
Hvor MCP passer inn
MCP (Model Context Protocol) lar en agent kalle en ekstern verktøyserver direkte. Her er det unntaket. I øktloggene på maskinen min for 13. september til 14. oktober 2026 (615 transkripsjoner, 59 551 verktøykall) gikk 1 636 kall til MCP-servere, 2,7 %; skallkommandoer var 44 401, 75 %. Fire av fem MCP-kall (1 354) styrte en hodeløs nettleser: laste en side, publisert eller et lokalt bygg, måle den, ta et skjermbilde, den ene jobben en skallkommando gjør dårlig. Git, logger og utrulling går gjennom skallet, og nesten alt databasearbeid gjør det, der kommandoen står i transkripsjonen, kan kjøres på nytt for hånd og passerer kommandovakten over. Et MCP-kall gjør ikke det: vakten ser bare skallkommandoer.
Hva dette gir
Fart der det er trygt: et månedsprosjekt blir en ukesleveranse, og fakturaen følger med ned. Gjennomgangen legges der den betyr noe: på oppførsel (bygget, testene, evalueringene, det som faktisk kjører) heller enn på å lese hver generert linje. Og et spor: når noe går galt, viser journalen hvilken økt som gjorde hva, og rettingen er en regel, ikke en reprimande.
Hva det ikke gir
Agenter gjør fortsatt feilene gjennomgangen fant; reglene gjør dem billigere og tidligere. En falsk alarm koster fortsatt et menneskeminutt. Og personen som drifter resultatet må fortsatt forstå det, ellers er eierskapet fiksjon.