Ordbok for kunstig intelligens

En bevegelig merkelapp, ikke en teknologi. «AI» betegner ikke en fast størrelse på samme måte som modell eller token gjør — den viser til det datamaskiner nylig har lært å gjøre på imponerende vis. Akkurat nå viser ordet til store språkmodeller. Tidligere har det vist til helt andre ting:

Pekeren flytter seg gjennom en kjent mekanisme, noen ganger kalt AI-effekten: Når en teknikk fungerer pålitelig, får den et nytt navn — den er «bare» søk, «bare» statistikk — og «AI» flytter videre til den neste uløste oppgaven. Observasjonen er gammel. Bertram Raphael formulerte det slik i 1971: «AI er et fellesnavn for problemer vi ennå ikke vet hvordan vi skal løse skikkelig med datamaskiner.» Larry Teslers versjon, fra rundt 1979: «Intelligens er det maskiner ennå ikke har gjort.»

Derfor snakker folk som diskuterer AI, så ofte forbi hverandre. En påstand som «AI kan ikke resonnere» eller «AI er hauset opp» har et skjult tidsstempel — den kan handle om ekspertsystemer, bildegjenkjenning fra 2010-tallet eller forrige måneds språkmodell, og hvert eksempel støtter en forskjellig konklusjon. Når en AI-diskusjon stopper opp, er løsningen som regel å bytte ut ordet med det presise begrepet som faktisk menes: modellen, agentrammeverket, agenten eller konteksten den fikk.

Unngå: «AI» i tekniske påstander — navngi heller den delen du mener. «AI-koding» som navn på praksisen er greit; «AI-en hallusinerer» er det ikke.

Bruk:

«CTO-en vil vite om AI kan håndtere triagekøen.»

«Oversett det før du avgrenser oppgaven — hun mener en språkmodell i et agentrammeverk med tilgang til sakssystemet. ‘AI’ alene er ingen spesifikasjon.»

Parameterne. Tilstandsløs — utfører prediksjon av neste token og ingenting annet. «Claude Opus 4.x» og «GPT-5.x» er modeller. En modell kan ikke gjøre noe agentisk på egen hånd; den må settes inn i et agentrammeverk.

Modeller kan ikke lese filer, kjøre kommandoer, surfe på nettet eller huske gårsdagen — de tar inn tokens og forutsier tokens som output én gang per forespørsel til modelltilbyderen. Alt som oppleves som en agent i arbeid — å velge verktøy, lese resultatene og gå flere runder til oppgaven er ferdig — er agentrammeverket som orkestrerer mange av disse prediksjonene etter hverandre.

Modelltilbydere tilbyr modeller i flere nivåer: En stor modell som er smartest, men treg og dyr, og mindre modeller som er raskere og billigere, men mindre kapable. Valg av nivå er en reell beslutning — tung modell for planlegging og vanskelig feilsøking, lett modell for mekaniske endringer — og agentrammeverk lar deg bytte midt i en økt.

Å være presis med ordet gjør det også enklere å finne årsaken. «Modellen er dårlig til dette» er en konkret påstand — den samme modellen i et annet agentrammeverk eller med en annen kontekst oppfører seg ofte helt annerledes. Før du gir modellen skylden, bør du sjekke hva den fikk: Det meste av skuffende output kan spores til kontekst eller agentrammeverk, ikke parametere.

Bruk:

«Bør vi bytte modell fra Sonnet til Opus for planleggingssteget?»

«Prøv det — men agentrammeverket gjør det meste av arbeidet i denne oppgaven. Modellbyttet hjelper ikke hvis systemprompten og verktøyene er feil.»

Tallene i en modell — ofte milliarder av dem — som justeres under treningen. Alt modellen «vet», ligger i dem. Treningen fastsetter dem; inferens bruker dem uendret. De kalles også vekter.

Rent mekanisk er parameterne det som omformer input til output. Prediksjon av neste token er en enorm beregning: Tokenene i kontekstvinduet går inn, multipliseres gjennom parameterne, og en forutsigelse av neste token kommer ut. Det finnes ingen database med fakta i modellen, ingen kodeoppslagstabell — bare disse tallene, arrangert slik at beregningen gjerne produserer nyttig output. Fakta modellen kan gjengi fra treningen, som et standardbibliotek-API, er parametrisk kunnskap: lagret i parameterne, ikke hentet fra et annet sted.

Detaljen som er verdt å internalisere, er at parameterne låses etter treningen. Ingenting du gjør i en økt, endrer dem — verken rettelser du gir, kodebasen du viser modellen eller feil den lærer av. Hver økt bruker de samme tallene. Derfor er modellen tilstandsløs, den innebygde kunnskapen slutter ved kunnskapens skjæringsdato, og alt som gjelder akkurat prosjektet ditt, må komme via konteksten. Parameterne endres bare ved mer trening — noe som i praksis gir en annen modell.

Bruk:

«Kan vi finjustere den på kodebasen vår?»

«Det ville oppdatert parameterne — da får du en annen modell. For ett prosjekt er det nesten alltid billigere å laste kodebasen inn som kontekst enn å trene modellen på nytt.»

Prosessen som fastsetter en models parametere ved å utsette den for enorme mengder tekst og justere parameterne for å forbedre prediksjonen av neste token. En dyr engangsprosess som modelltilbyderen utfører. Omfatter både forhåndstrening (hovedkjøringen) og ettertrening (senere forbedringer som instruksjonsfølging og sikkerhet); skillet betyr ikke noe på dette nivået i ordlisten.

Mekanismen er repetisjon i stor skala: Vis modellen et tekststykke, la den forutsi neste token, skyv parameterne mot det faktiske neste tokenet, og gjenta dette over billioner av tokens. Ingenting lagres som fakta eller regler — alt modellen «vet» er en bieffekt av å bli bedre til å forutsi, komprimert inn i parameterne som parametrisk kunnskap.

To konsekvenser har betydning i hverdagen. Treningen slutter på et bestemt tidspunkt, så modellen har en kunnskapsskjæringsdato — den har ikke sett bibliotekversjonen du oppgraderte til forrige måned. Og trening er ikke noe du kan gjøre selv: Når modellen ikke kjenner kodebasen, konvensjonene eller de interne API-ene dine, er løsningen aldri «lær modellen det» — det er å legge materialet inn i konteksten, den ene inputen du kan kontrollere.

Bruk:

«Kan vi få den til å kjenne det interne API-et vårt?»

«Ikke gjennom trening — det er en prosess modelltilbyderen bruker flere måneder på. Last heller API-dokumentasjonen inn i konteksten; det er virkemiddelet du faktisk har.»

Å kjøre en trent modell for å generere output — det som skjer ved hver forespørsel til modelltilbyderen. Parameterne forblir fastlåst; modellen utfører bare prediksjon av neste token over konteksten den får. Billig sammenlignet med trening, men faktureres per token og utgjør den største kostnaden ved å bruke en modell.

En modell har to livsfaser:

Ingenting du gjør under inferens, skrives tilbake til parameterne — derfor fester ikke en rettelse du gjør i dag, seg til i morgen. Modellen som gjør den samme feilen i neste økt, etter at du har forklart rettelsen nøye, har ikke ignorert deg; den kan ikke lære av utvekslingen. Modellen er tilstandsløs — kontinuiteten må komme utenfra, fra kontekstvinduet eller et minnesystem.

Denne mekanismen forklarer også hvordan du faktureres. Hver forespørsel kjører modellen over hele konteksten, så kostnaden øker med inputtokens og outputtokens, og en agent som gjør dusinvis av verktøy-kall, betaler for inferens på hver rundtur. Derfor er kontekststørrelsen et spørsmål om kostnad så vel som kvalitet.

Bruk:

«Hvorfor følger regningen forbruket i stedet for å være en fast lisens?»

«Du betaler for inferens — hver forespørsel til modelltilbyderen kjører modellen på tilbyderens maskinvare. Treningen er allerede gjort, men inferenskostnadene løper per forespørsel, og én tur kan bli til mange forespørsler når verktøy kalles.»

Innsats er en innstilling for hvor mye resonnement en modell gjør før den svarer. Den settes per forespørsel til modelltilbyderen og styrer hvor lenge modellen tenker seg om før den begynner å skrive svaret du ser. Denne tenkingen genereres under inferens som alt annet; agentrammeverket skjuler den ofte, men modellen utfører faktisk arbeid.

Høyere innsats koster mer og tar lengre tid. Resonnementet produseres som tokens, faktureres som outputtokens selv når du aldri ser dem, og genereres én token om gangen — derfor gir høyere innsats lengre ventetid før svaret kommer og øker regningen. Avveiningen er mer ettertanke mot hastighet og kostnad.

De fleste agentrammeverk viser innsats som en liten trinnrekke:

Symptomet på feil innstilling går begge veier. Setter du innsatsen for lavt for et vanskelig problem, får du et selvsikkert, overflatisk svar som hopper over resonnementet problemet krevde — det ser riktig ut, men tar senere tid å rette. Setter du den på maks for et navnebytte på én linje, venter du gjennom en lang tenkepause som ikke gir noe den laveste innstillingen ikke ville gitt.

Tilpass innsatsen til oppgaven, ikke økten. Skru den opp for den delen det faktisk er vanskelig å resonnere seg gjennom, og ned igjen for rutinearbeidet rundt.

Bruk:

«Den fortsetter å rote til denne samtidighetsrettingen — jeg har forklart det tre ganger.»

«Skru opp innsatsen. Dette er en feil som krever mye resonnement, og med standardinnstillingen tenker den seg ikke lenge nok om før den velger en framgangsmåte.»

Den minste enheten en modell leser og skriver. Omtrent på størrelse med et ord, men ikke helt — vanlige ord er én token, mens sjeldne eller lange ord deles opp i flere. Størrelse på kontekstvindu, kostnad og forsinkelse måles alle i tokens.

Tekst blir til tokens gjennom en tokenizer: et fast ordforråd på titusenvis av fragmenter, innlært før treningen, som deler alle input opp i en sekvens av ordforrådselementer. Modellen ser aldri tegn eller ord — hver tekstbit omgjøres til tokens på vei inn, og prediksjon av neste token lager output én token om gangen på vei ut.

Som tommelfingerregel tilsvarer én token omtrent tre fjerdedeler av et engelsk ord, så tusen tokens er rundt 750 ord. Kode er mindre forutsigbar: Vanlige nøkkelord og idiomer tokeniseres kompakt, mens genererte identifikatorer, hasher, base64-blokker og minifisert output deles i mange tokens per «ord». Mønsteret er at tekst som ofte forekom i tokenizerens kildemateriale, får korte og effektive kodinger; tekst som ikke gjorde det, kuttes i mange små biter. En hash som `a3f9c2e1` har aldri forekommet noe sted og deles derfor i mange tokens, mens `function` er én token. Derfor kan en fil som ser liten ut, men er full av uvanlige strenger, oppta en overraskende stor del av kontekstvinduet.

Tokens er enheten alt annet måles i. Kostnaden beregnes per token — tilbydere fakturerer inputtokens og outputtokens separat. Hastighet måles i tokens per sekund, siden output genereres én token om gangen. Og kontekstvinduet har plass til et fast antall tokens, så tokenantallet i filene dine avgjør hvor mye som får plass.

Unngå: «ord» — token-grenser samsvarer ikke med ordgrenser, og tokens per sekund / tokens per krone er enhetene som faktisk betyr noe.

Bruk:

«Hvor stor blir denne prompten?»

«Kjør den gjennom tokenizer-en — skjemaet er kompakt, men JSON-nøklene er rare, så de deles opp i flere tokens enn du tror.»

Det modellen faktisk gjør. Gitt en kontekst trekker den én neste token, legger den til og kjører på nytt. All output — en setning, et verktøykall, en fil på tusen linjer — bygges én token om gangen. Modellen har ingen annen virkemåte.

Hvert steg fungerer på samme måte: Tokenene i kontekstvinduet kjøres gjennom parameterne, som gir en sannsynlighet for hver token i ordforrådet — denne er svært sannsynlig som den neste, den andre mindre sannsynlig. Én token trekkes fra sannsynlighetene, legges til, og løkken kjøres igjen med den litt lengre konteksten. Dette trekket er grunnen til at samme prompt gir ulik output ved ulike kjøringer: Ikke-determinisme er bygget inn i mekanismen, ikke en feil som er lagt oppå den.

Når du holder fast ved denne mekanismen, forklarer den atferd som ellers virker merkelig. Modellen kontrollerer aldri om en token er sann før den sender den ut — bare om den er sannsynlig — og dette er roten til hallusinering. Den binder seg til hver token etter hvert som den kommer, så en selvsikker åpningssetning kan føre resten av svaret i feil retning. Og siden outputtokens produseres strengt tatt én om gangen, setter genereringshastigheten en nedre grense for hvor raskt en agent kan arbeide.

Bruk:

«Hvordan ‘bestemmer’ agenten seg for å kalle et verktøy?»

«Det gjør den ikke — prediksjon av neste token hele veien ned. Verktøykallet er bare en strukturert streng agentrammeverket parser ut av outputstrømmen.»

Samme input kan gi forskjellig output. Kjør en modell to ganger med identisk kontekst, så kan du få to ulike svar — noen ganger bare ett annet ord, andre ganger en helt annen tilnærming. Ingenting i koden din trenger å endres for at det skal skje.

Dette er en egenskap ved måten modeller genererer tekst på, og ved hvordan modelltilbydere håndterer forespørsler. Under inferens lager modellen en sannsynlighetsfordeling over mulige neste tokens, og én av dem trekkes — vanligvis med litt tilfeldig variasjon med vilje, siden det å alltid velge den mest sannsynlige tokenen gir gjentakende tekst av lavere kvalitet. En token som trekkes annerledes tidlig i et svar, endrer alle tokenene etter den; slik blir ett annet ord til en helt annen tilnærming. Håndtering på tilbydersiden gir mer variasjon: Forespørsler samles i grupper på delt maskinvare, og små flyttallsforskjeller mellom grupper kan tippe et jevnt valg fra én token til en annen. Det finnes ingen innstilling du kan slå på for å få alt dette til å forsvinne.

Forvent en spredning i resultatene fra en agent på samme oppgave. De fleste svarene ligger innenfor en rimelig normalfordeling for kvalitet — det er grunnen til at ikke-determinismen i det hele tatt er til å leve med — men ytterkantene finnes: Noen dager virker modellen skarp; andre dager virker den som om den har mistet tråden. Samme oppgave, ulike terningkast. Dette har to praktiske følger. Det er legitimt å prøve på nytt: Et mislykket forsøk er ett trekk fra fordelingen, og et nytt forsøk på samme oppgave kan ganske enkelt treffe bedre. Og verifisering betyr mer enn med deterministiske verktøy — du kan ikke teste agentens atferd én gang og stole på at den gjentar den, så automatiske kontroller må fange de dårlige trekkene.

Pass på at du ikke forteller for mye om dette. Mennesker finner mønstre, og en rekke dårlige kjøringer kan føles som bevis på at «modellen ble dårligere denne uken». Som regel er det bare fordelingen.

Bruk:

«Claude har vært elendig i dag. Har de sendt ut en dårligere versjon?»

«Sannsynligvis ikke — modelloutput er ikke-deterministisk. Du får gode og dårlige dager med samme oppgave. Prøv igjen i morgen før du begynner å lete etter en årsak.»

Det som leverer en modell til inferens. Vanligvis en ekstern tjeneste (Anthropic, OpenAI, Google), men det kan også være lokalt — Ollama, LM Studio eller llama.cpp som kjører på din egen maskin. Agentrammeverket kjører ikke modellen selv; det ber en tilbyder om å gjøre det.

Tilbyderen eier maskineriet: Parameterne ligger på maskinvaren deres, og hver forespørsel til modelltilbyderen er agentrammeverket som sender tokens over nettverket og mottar prediksjoner. Dermed er tilbyderen kilden til en hel kategori problemer som feilaktig tilskrives modellen eller agentrammeverket — hastighetsgrenser, redusert kapasitet og driftsavbrudd hører alle hjemme her. Når agenten stopper opp midt i en økt eller feiler på hver tur, er tilbyders status-side verdt å sjekke før noe annet.

Tilbyderen setter også de kommersielle vilkårene: pris per token for input og outputtokens, rabatter for prefikscache og hvilke modeller som er tilgjengelige i det hele tatt. Merk at tilbyderen og modellens produsent kan være ulike selskaper — Bedrock, Vertex og OpenRouter leverer andres modeller.

Lokale tilbydere bytter kapasitet mot kontroll: Modellene som passer på din egen maskinvare, er langt mindre enn de fremste modellene, men ingenting forlater maskinen, og du får ingen regning per token.

Bruk:

«Kan vi kjøre dette frakoblet for klienten med det isolerte nettverket?»

«Bytt modelltilbyder til en lokal — Ollama eller llama.cpp på maskinen deres. Agentrammeverket bryr seg ikke; det sender bare forespørselen til et annet endepunkt.»

Alt rundt modellen som gjør den til en agent: verktøy, systemprompt, håndtering av kontekstvinduet, tillatelser og hooks. Claude.ai og Claude Code kjører på samme modell, men oppfører seg forskjellig fordi agentrammeverkene deres er ulike.

Modellen gjør selv bare én ting: tar inn tekst og produserer tekst. Den kan ikke lese filer, kjøre kommandoer eller huske forrige tur. Agentrammeverket sørger for alt dette. Det setter sammen konteksten for hver forespørsel til modelltilbyderen, utfører verktøykallene modellen ber om, sender verktøyresultatene tilbake, lagrer økt-historikken, spør deg om tillatelse før risikable handlinger og bestemmer når det skal komprimeres. Agentløkken — modellen foreslår, agentrammeverket utfører, gjenta — kjøres av agentrammeverket.

Dette er viktig ved feilsøking. Når atferden er forskjellig mellom to produkter eller fra i går til i dag, er modellen ofte ikke variabelen — agentrammeverket er det. En annen systemprompt, et annet utvalg verktøy, en endret standard for tillatelser eller en ny strategi for konteksthåndtering endrer all atferd uten at modellen endres. Det betyr også at agentrammeverket er stedet det meste av konfigurasjonen din bor: AGENTS.md-filer, tillatelsesinnstillinger og hooks er alle instruksjoner til agentrammeverket, ikke modellen.

Eksempler: Claude Code, Cursor, Codex CLI — og Claude.ai, som er et chat-agentrammeverk, ikke et kodeagentrammeverk.

Bruk:

«Samme modell, hvorfor redigerer Claude Code filer mens Claude.ai bare svarer på spørsmål?»

«Forskjellige agentrammeverk — Claude Code har filsystem-verktøy, en annen systemprompt og et tillatelseslag. Modellen er ikke variabelen her.»

Én rundtur fra agentrammeverket til modelltilbyderen. Agentrammeverket sender den gjeldende konteksten; tilbyderen returnerer ett svar (et verktøykall eller et endelig svar). Én brukermelding kan utløse mange forespørsler til modelltilbyderen hvis agenten kaller verktøy — hvert verktøyresultat utløser en ny forespørsel.

Hver forespørsel har med alt: Systemprompten, hele samtalen fram til nå og alle verktøyresultatene. Modellen er tilstandsløs, så tilbyderen beholder ingenting mellom forespørslene — forespørsel nummer førti sender på nytt alt som ble sendt med nummer trettini, pluss ett nytt verktøyresultat. Prefikscachen gjør denne gjentakelsen rimelig.

Forespørselen er også faktureringsenheten. Inputtokens, outputtokens og cacherabatter telles alle per forespørsel. Derfor kan et tilsynelatende uskyldig spørsmål koste overraskende mye: Kostnaden er ikke proporsjonal med meldingen din, men med antallet forespørsler ganger størrelsen på konteksten hver av dem inneholder.

Det er lurt å skille forespørselen fra turen. En tur er én utveksling med deg, og én tur — «rett den feilede testen» — utspiller seg som en kjede av forespørsler:

Seks forespørsler i én tur — hver sender hele konteksten på nytt. Når du lurer på hvor tokens ble av, teller du forespørslene, ikke turene.

Bruk:

«Brukte ett spørsmål førti tusen tokens?»

«Se på verktøykallene — tolv grep, åtte lesinger, fire redigeringer. Hvert verktøyresultat utløser en ny forespørsel til modelltilbyderen, og hele økt-prefikset sendes på nytt hver gang.»

Tokens agentrammeverket sender ved hver forespørsel til modelltilbyderen — systemprompten, samtalehistorikken, verktøyresultatene, alt modellen leser før den skriver. De faktureres til en lavere pris enn outputtokens, fordi de er billigere å behandle enn outputtokens.

Når du programmerer med AI, utgjør inputtokens det meste av regningen. Modellen er tilstandsløs, så hver tur sender hele økten på nytt som input: den første meldingen din, hvert svar og hvert verktøyresultat siden. Inputen i tur femti inneholder de foregående førtini turene. Én forespørsel til modelltilbyderen kan produsere noen hundre outputtokens, men sende hundre tusen inputtokens med oppsamlet historikk på nytt.

Prefikscachen reduserer kostnaden: Historikk som samsvarer nøyaktig med en tidligere forespørsel, faktureres som billige cachetokens i stedet for input til full pris. Når inputkostnaden fortsatt svir, er løsningen å redusere det som sendes på nytt — tøm eller komprimer mellom oppgaver.

Bruk:

«Regningen er høy, men agenten skriver nesten ingenting.»

«Det er inputtokenene — hver tur sender hele økten på nytt. Uten prefikscachen betaler du for historikken på nytt ved hver forespørsel.»

Tokenene modellen genererer. De faktureres til en høyere sats enn inputtokens — vanligvis omtrent fem ganger så høyt — siden de krever mer databehandling å produsere.

Alt modellen skriver, teller: Prosaen du leser, koden den sender ut, verktøykall og eventuell utvidet tenking modellen gjør før den svarer. Det siste overrasker folk — resonneringstokens faktureres som output selv når agentrammeverket ofte ikke viser dem, og det koster flere slike tokens å skru opp innsatsen.

Outputtokens bestemmer også tempoet i en økt. Modellen leser input raskt, men genererer output én token om gangen, så når en tur føles treg, er det nesten alltid outputen som skrives, ikke inputen som leses. Lang ventetid betyr som regel at et langt svar er på vei.

Bruk:

«Refaktoreringsøkten bruker opp kreditt selv om inputene er små.»

«Agenten skriver om hele filer i stedet for å lage rettelser. Outputtokens koster omtrent fem ganger inputprisen — få den til å sende ut endringer, så går regningen ned.»

Lageret på tilbydersiden som gjør at påfølgende forespørsler til modelltilbyderen kan hoppe over ny behandling av et delt prefiks. Når starten på en forespørsel samsvarer med starten på en nylig forespørsel — samme systemprompt, samme historikk fram til et punkt — gjenbruker tilbyderen det tidligere arbeidet og fakturerer disse tokenene som cachetokens til en langt lavere pris.

Cachen lønner seg fordi økter vokser ved å legge til nytt innhold. Hver forespørsel sender hele historikken på nytt som inputtokens (se den oppføringen for forklaringen), og i en vanlig økt endres historikken bare til slutt — hver forespørsel er den forrige pluss noen nye meldinger. Tilbyderen behandler den lange felles begynnelsen én gang, lagrer resultatet og fortsetter fra der prefikset slutter. Uten cache måtte en økt på 50 turer betalt for å behandle tur én på nytt femti ganger.

Cacher utløper også. Hvor lenge en oppføring holder seg varm, varierer mellom modelltilbydere — vanligvis minutter, ikke timer. Hvis økten ligger ubrukt lenger enn tidsvinduet, bygges prefikset opp igjen til full pris ved neste forespørsel før caching fortsetter. Dette er hovedsakelig relevant for dem som bygger agentrammeverk; som bruker merker du at forespørsler etter en lang pause koster mer enn dem før pausen.

Bruk:

«Hvorfor skjøt regningen i været midt i økten?»

«Agentrammeverket begynte å sette inn gjeldende klokkeslett i systemprompten for hver tur. Prefikscachen brytes ved den første endrede tokenen, så hver forespørsel etter det ble fakturert til full pris.»

Inputtokens tilbyderen har cachelagret fra en tidligere forespørsel til modelltilbyderen, slik at den ikke må behandle dem på nytt. Når forespørsler etter hverandre deler et prefiks, gjenbruker tilbyderen arbeidet gjennom prefikscachen og fakturerer den cachelagrede delen til en langt lavere pris. Virkemiddelet som gjør lange økter overkommelige — uten det betaler hver tur på nytt for hele historikken.

Grunnen til at dette er viktig, er hvordan økter faktureres. Modellen er tilstandsløs, så hver forespørsel sender hele samtalen på nytt — systemprompten, hver melding og hvert verktøyresultat — som inputtokens. Ved tur femti bærer hver forespørsel med seg historikken fra femti turer, og du måtte betalt full pris for alt hver gang. Cachen endrer regnestykket: Tokens tilbyderen allerede har behandlet i et identisk prefiks, faktureres som cachetokens, ofte til en tidel av inputprisen eller mindre. I en lang økt er det meste av det du sender, cachetokens, og regningen holder seg på et fornuftig nivå.

Et eksempel viser når tokens cachelagres, og når de ikke gjør det. Hver bokstav står for en blokk med samtaleinnhold; hver forespørsel sender samtalen så langt:

Cachen er skjør på en bestemt måte: Den matcher nøyaktige prefikser. Hvis noe endres tidligere i samtalen — agentrammeverket omorganiserer innhold, et tidsstempel oppdateres, eller en fils representasjon endres — bommer cachen fra dette punktet og alt etter det faktureres til full inputpris. Cacher utløper også etter noen minutters inaktivitet, så en økt som gjenopptas etter en lang pause, betaler for historikken på nytt én gang. Hvis kostnaden for en økt hopper uten åpenbar grunn, kan du sammenligne cachetokens med inputtokens i forbruksrapporten — en brutt cache viser seg der først.

Bruk:

«Lange økter er brutalt dyre — åtte dollar for en refaktorering.»

«Se på cachetokenene. Hvis agentrammeverket omorganiserer systemprompten eller filene mellom turer, ryker prefikset, og du betaler full inputpris for hver forespørsel.»

Fører ingen informasjon videre. Modellen er tilstandsløs mellom forespørsler til modelltilbyderen — hver forespørsel sender hele kontekstvinduet på nytt, fordi modellen ikke kan se noe annet. En agent er som standard tilstandsløs mellom økter: En ny økt begynner tom, uten spor av de forrige. Motstykket til tilstandsfull.

Selve modellen er permanent tilstandsløs: Parameterne låses etter treningen, og ingenting du gjør under inferens, endrer dem. Modellen lærer ikke av rettelsene dine, husker ikke at du sa det samme i går og blir ikke bedre kjent med deg — uansett hvor mye samtalen ellers kan føles slik. Følelsen av kontinuitet i en økt produseres av agentrammeverket, som oppbevarer transkripsjonen og sender den på nytt med hver forespørsel. Modellen husker ikke samtalen; den leser den på nytt.

Den praktiske konsekvensen: Hvis du vil at noe skal huskes på tvers av økter, må du skrive det ned et sted agenten kommer til å lese det igjen. Det er det filer som AGENTS.md, minnesystemer og overleveringsartefakter er — filer som lastes inn i konteksten til framtidige økter og erstatter minnet modellen ikke har. Når agenten stadig gjør en feil du allerede har rettet, er ikke spørsmålet hvorfor den ikke lærte — det kan den ikke — men hvor rettelsen bør skrives ned, slik at alle framtidige økter leser den.

Bruk:

«Hvorfor glemmer den konvensjonen hver gang jeg tømmer økten?»

«Modellen er tilstandsløs — den nye økten starter tom. Hvis du vil at informasjonen skal følge med, skriver du den i AGENTS.md eller en minnefil agentrammeverket laster inn ved øktstart.»

Den relevante informasjonen agenten har tilgang til akkurat nå. Det abstrakte substantivet — ikke råinputen modellen ser (det er kontekstvinduet), ikke den løpende historikken (det er økten), men det agenten vet som er relevant for oppgaven. «Å laste noe inn i konteksten» betyr å gjøre det til en del av dette settet; «kontekstarbeid» er faget å velge og sette sammen innholdet.

De tre begrepene kan skilles tydelig:

Skillet betyr noe fordi kontekst er et mål på kvalitet, ikke mengde. Et kontekstvindu kan være nesten fullt mens konteksten fortsatt er dårlig — tusenvis av tokens med foreldede verktøyresultater, ingen av dem relevante for oppgaven. Vinduet kan også være nesten tomt og konteksten glimrende: den ene typedefinisjonen oppgaven avhenger av.

De fleste daglige feil kan spores tilbake til konteksten. Når agenten finner på et API, motsier en beslutning eller gjetter på et skjema, er det første spørsmålet hva som lå i konteksten da det skjedde — som regel ble den relevante opplysningen aldri lastet inn, eller den lå begravd under forringet oppmerksomhet. Løsningen er utvelgelse: Last inn det oppgaven trenger, og hold det unødvendige ute.

Bruk:

«Den fortsetter å finne på felt som ikke finnes i typen.»

«Typefilen ligger ikke i konteksten — den leser kallestedene og gjetter. Les inn definisjonen først.»

Alt modellen ser ved hver forespørsel til modelltilbyderen. Begrenset, modellspesifikt og den eneste flaten modellen oppfatter noe gjennom.

Det er én sekvens av tokens: systemprompten, samtalen så langt og hvert verktøyresultat agentrammeverket har sendt tilbake. Hvis noe inngår i sekvensen, kan modellen bruke det; hvis ikke vet den ikke at det finnes — verken kodebasen din, filen du redigerte i går eller instruksen du ga for tre økter siden. Alt utenfor vinduet må hentes inn, vanligvis gjennom et verktøykall, før det kan påvirke noe.

Vinduet er begrenset fordi det fylles opp. Hver tur føyer til mer — meldingene dine, modellens svar og verktøyresultater — og en lang økt når til slutt grensen, slik at komprimering eller tømming blir nødvendig. Det betyr også at alt i vinduet konkurrerer: Hver token du laster inn, er én mindre tilgjengelig for resten, og innhold du ikke trengte, opptar fortsatt noe av modellens oppmerksomhet. I praksis bør vinduet behandles som et budsjett — last inn det oppgaven trenger, og utelat resten.

Unngå: «minne» — kontekstvinduet er arbeidstilstand og beholdes ikke på tvers av økter. Minne er et separat begrep som legges oppå.

Bruk:

«Kan jeg ikke bare lime inn hele monorepoet i prompten?»

«Kontekstvinduet har 200 000 tokens — det er kanskje en femtedel av repoet. Velg filene oppgaven gjelder, og la resten ligge bak et verktøykall.»

Fører informasjon videre. En økt er tilstandsfull på tvers av turer — konteksten hoper seg opp mens økten kjører, og derfor driver lange økter inn i den dumme sonen. En agent kan gjøres tilstandsfull på tvers av økter ved å legge til et minnesystem som lagrer informasjon i miljøet og laster den inn igjen ved starten av framtidige økter. Modellen er aldri tilstandsfull; all tilsynelatende kontinuitet skyldes at agentrammeverket sender konteksten inn på nytt. Motstykket til tilstandsløs.

Hvor tilstanden ligger i hvert lag:

Tilstanden i hvert lag bygges ved å lese noe som er lagret i laget under: Økten føles sammenhengende fordi agentrammeverket sender meldingshistorikken på nytt til den tilstandsløse modellen, og agenten husker på tvers av økter fordi agentrammeverket laster inn filer fra miljøet på nytt. Ingen tilstand lagres noen gang i selve modellen.

Tilstandsfullhet er ikke alltid ønskelig. Alt som føres videre, påvirker det som kommer etterpå, så en feil antakelse tidlig i en økt blir også ført videre. Tømming er den bevisste handlingen å kaste øktens tilstand og begynne på nytt ut fra det som er skrevet ned.

Bruk:

«Den husket preferansene mine fra i går — betyr det at modellen lærte dem?»

«Nei, agenten er tilstandsfull fordi agentrammeverket skrev dem til en minnefil og lastet den inn igjen ved starten av økten. Selve modellen så ingenting fra i går.»

En modell som er koblet til et agentrammeverk med verktøy, en systemprompt og et kontekstvindu, og som tar turer med en bruker. Claude Code er en agent. Cursor er en agent. Claude.ai er en agent. En agent er det du faktisk snakker med — modellen i bevegelse, konfigurert for et bestemt formål.

I motsetning til de fleste begrepene i denne ordboken betegner ikke «agent» en mekanisk del. Modellen er en fil med parametere; agentrammeverket er programvare du kan peke på. Agenten er ingen av delene — den er enheten du snakker til. Folk menneskeliggjør AI hele tiden, og agenten er den menneskeliggjorte enheten: det du delegerer til, det som leser meldingen din og svarer, «den» i «den ødela bygget igjen». Når du sier at agenten gjorde noe, mener du at modellen sammen med agentrammeverket gjorde det, men du omtaler kombinasjonen som én enkelt aktør.

Ideen er eldre enn den nåværende bølgen av AI. Programvareagenter — programmer du delegerer et mål til, som handler på dine vegne — har vært et begrep like lenge som AI har eksistert.

Unngå: «AI-en», «boten» (for vagt — ordene skjuler om du mener parameterne eller løsningen med agentrammeverket).

Bruk:

«Hvilken agent bruker du til migreringen?»

«Claude Code lokalt, Cursor til brukergrensesnittet — samme modell under panseret, forskjellige agentrammeverk.»

Instruksjonene agentrammeverket setter foran hver forespørsel til modelltilbyderen — agentens agent-oppdragsbeskrivelse som gjelder til enhver tid: hvem den er, hvordan den skal oppføre seg, hvilke verktøy den kan kalle, og hvilke konvensjoner den skal følge. Vanligvis stabil gjennom en økt.

Systemprompten skrives av leverandøren av agentrammeverket, ikke av deg, og i kodeagentrammeverk er den stor — ofte titusenvis av tokens med atferdsregler, verktøybeskrivelser og håndtering av spesialtilfeller, alt fakturert som inputtokens ved hver tur. Dine egne stående instruksjoner følger med: Filer som AGENTS.md lastes inn ved siden av systemprompten ved starten av økten, så modellen leser både leverandørens og dine instruksjoner før den i det hele tatt ser meldingen din.

Fordi systemprompten er identisk i hver forespørsel, danner den starten på prefikscachen — og det er en av grunnene til at agentrammeverk holder den fast gjennom en hel økt i stedet for å redigere den underveis.

Modeller trenes til å prioritere systemprompten over brukermeldinger. Så når en agent insisterer på en konvensjon du aldri ba om, eller formaterer output på en måte du ikke får endret, følger den som regel systemprompten — og meldingen din taper diskusjonen. Noen agentrammeverk kan tilpasses: De gir deg full tilgang til systemprompten, så du kan lese hva agenten faktisk blir fortalt og endre det.

Bruk:

«To agentrammeverk, samme modell, helt ulik oppførsel på samme prompt.»

«Forskjellige systemprompter. Den ene er innstilt på korte kodeendringer, den andre på forklaringer — forskjellen ligger der, før meldingen din i det hele tatt kommer fram.»

Én avgrenset omgang med samhandling med en agent. Starter tom, samler meldinger, verktøyresultater og innleste filer, og slutter når den tømmes, lukkes eller komprimeres til en ny økt. Det er økten som fyller kontekstvinduet: Hvis kontekstvinduet er boksen, er økten innholdet som langsomt fyller den opp. Arbeid som er for stort til ett kontekstvindu, må deles opp på flere økter.

Meldingshistorikken i økten er agentens arbeidsminne. Modellen er tilstandsløs, så alt den ser ut til å huske — hva du ba om, hva testene viste, hva den bestemte for tre turer siden — ligger i meldingshistorikken og sendes på nytt ved hver forespørsel til modelltilbyderen. Det som ikke finnes i økten, eksisterer ikke for agenten.

Dette minnet slutter med økten. En ny økt starter fra ingenting: Agenten som kjente kodebasen din godt da gårsdagen var omme, vet ingenting om den i morges. Det som overlever, er filsystemet — filer som ble skrevet i én økt, kan leses av den neste, og det er det overleveringer, minnesystemer og AGENTS.md bygger på.

Du velger når en økt slutter. Alt i en økt påvirker hver senere tur, så uvedkommende oppgaver i samme økt etterlater rester som farger neste svar. Én oppgave per økt holder konteksten relevant; å fullføre en oppgave er et naturlig tidspunkt å tømme den.

Bruk:

«Hvor lenge kan én økt kjøre før den faller fra hverandre?»

«Det avhenger av arbeidet — en fokusert refaktorering holder seg skarp lenger enn åpen forskning. Når økten eser ut, overlever eller komprimer; ikke press videre.»

Én brukermelding pluss alt agenten gjør som svar, fram til den gir ordet tilbake til brukeren. Inneholder én eller flere forespørsler til modelltilbyderen — mange hvis agenten kaller verktøy. Et oppklarende spørsmål avslutter turen; svaret ditt starter den neste. Hierarkiet er økt > Tur > Forespørsel til modelltilbyderen.

Det som gjør turen verdt å navngi, er at lengden bestemmes av agenten, ikke deg. Du gir én melding; agenten avgjør hvor mange verktøykall den skal lenke sammen før den gir ordet tilbake. En tur kan være et svar på én setning eller tjue minutter med lesing, redigering og testkjøring. Det er samme egenskap sett fra to vinkler: Lange turer muliggjør ubemannet arbeid, men lange turer er også der ting går galt uten tilsyn — når agenten endelig gir ordet tilbake, kan den ha drevet langt bort fra det du mente.

Turen er også den naturlige enheten for styring. Alt som skjer i løpet av turen, skjer uten deg; mellomrommene mellom turene er der du kan styre retningen. De fleste agentrammeverk myker opp dette: Du kan avbryte midt i en tur for å stoppe agenten og styre den på nytt, eller skrive en melding mens den arbeider, som den leser når turen er fullført. Hvis du stadig er misfornøyd med hvor turene ender, er løsningen som regel å be om kortere turer — først en plan, så ett steg av gangen — og bytte selvstendighet mot hyppigere muligheter til å styre.

Bruk:

«Tok én tur to minutter?»

«Den gjorde fjorten verktøykall i den turen — hvert av dem er en egen forespørsel til modelltilbyderen. Forsinkelsene hoper seg opp før agenten endelig gir ordet tilbake.»

Verden agenten handler i — alt utenfor agentrammeverket som agenten oppfatter gjennom verktøyresultater og endrer gjennom verktøykall. Agentrammeverket kjører agenten; miljøet er det agenten arbeider i. En fil som `AGENTS.md` ligger i miljøet; agentrammeverket er det som laster den inn i kontekstvinduet. Et filsystem er den vanligste typen miljø, men ikke den eneste (en database, et eksternt API eller en nettleserøkt kan også være miljøer).

Agenten ser bare miljøet når den ser etter. Alt den vet om miljøet, kom gjennom et verktøyresultat, så bildet dens består av øyeblikksbilder som hvert var korrekte da de ble tatt. Hvis en fil endres etter at agenten har lest den — du redigerer den for hånd, eller et byggetrinn genererer den på nytt — fortsetter agenten å resonnere ut fra den utdaterte kopien til noe får den til å lese på nytt. Når en agent selvsikkert beskriver en fil som ikke lenger ser slik ut, skyldes det som regel dette: Miljøet endret seg, men øyeblikksbildet gjorde det ikke.

Miljøet er også laget som varer — det eneste laget som alltid er tilstandsfullt. Øktens kontekst forsvinner når økten slutter, men filer skrevet til miljøet blir liggende til neste økt kan lese dem — det er dette minnesystemer, overleveringsartefakter og `AGENTS.md` bygger på. Alt agenten bør vite i morgen, må ende opp i miljøet.

Du bestemmer hvor stort miljøet er. En sandkasse gjør det mindre og begrenser hvor agenten kan nå; et verktøy utvider det og gir tilgang til en database eller et API. Det som ligger innenfor grensen, kan agenten oppfatte og endre; alt utenfor finnes ikke for agenten. Hvor godt miljøet er satt opp for å støtte agentens arbeid, er kodebasens AX.

Unngå: å bruke «miljø» om kjøremiljøet eller selve agentrammeverket — agentrammeverket er innpakningen, miljøet er arbeidsområdet.

Bruk:

«Agenten kan ikke se stagingdatabasens skjema.»

«Koble det inn i miljøet — gi den et `psql`-verktøy med skrivebeskyttet tilgang til staging. Agentrammeverket fungerer; det har bare ingenting å handle på.»

Et tre av filer og kataloger som agenten leser fra, skriver til og kjører ting i — standardtypen miljø for en kodeagent. AGENTS.md, skills, kildekode, byggeskript og verktøy-konfigurasjoner ligger alle i et filsystem. Når et agentrammeverk «starter i prosjektet ditt», peker det agenten mot et filsystem.

Agenten bruker det bare gjennom verktøykall — leser en fil, skriver en fil eller kjører en shell-kommando. Ingenting på disken finnes i kontekstvinduet før et verktøykall laster det inn, og derfor kan agenten arbeide i et repo som er mye større enn vinduet: Filsystemet inneholder alt, mens konteksten bare inneholder det den aktuelle oppgaven har lest. Noen agentrammeverk laster som standard inn filnavnene i den gjeldende katalogen i kontekstvinduet — ikke innholdet, bare treet — og disse fungerer som kontekstreferanser: Agenten ser hva som finnes og leser filene den trenger.

Og filsystemet deles med deg. Filene agenten redigerer, er de samme som du åpner i redigeringsprogrammet og ser på i git-diffen — filsystemet er det felles arbeidsområdet der du gjennomgår det agenten har gjort.

Bruk:

«Hvorfor finner den ikke AGENTS.md?»

«Den kjører mot et annet filsystem — sandkassen monterte overordnet katalog, ikke prosjektroten. Pek agentrammeverket på nytt.»

En funksjon agentrammeverket gjør tilgjengelig for agenten — Read, Write, Bash, Search. Verktøy er måten en agent oppfatter og handler på i miljøet: Den kan ikke se miljøet annet enn gjennom verktøyresultater, og kan ikke endre det annet enn gjennom verktøykall. Hvert verktøykall koster en ekstra forespørsel til modelltilbyderen, siden resultatet må tilbake til modellen før den kan bestemme hva den skal gjøre videre.

Verktøy de fleste kodeagenter leveres med:

Et verktøy defineres av tre ting: et navn, en beskrivelse av hva det gjør, og et skjema for parameterne. Agentrammeverket sender disse definisjonene til modellen med hver forespørsel, og modellen velger et verktøy på samme måte som den produserer alt annet — ved å skrive tokens, i dette tilfellet et strukturert kall med argumenter. Modellen utfører aldri noe selv; agentrammeverket leser kallet, kjører funksjonen og sender resultatet tilbake.

Verktøylisten avgjør hva agenten kan gjøre. En kapabel modell med et begrenset utvalg verktøy blir en begrenset agent: Den vil sende alt gjennom det den har, og det er grunnen til at agenter lener seg så tungt på Bash — ett shell-verktøy når fram til det meste av systemet. Hvis du vil gi agenten en funksjon på en ryddig måte, legger du til et verktøy; MCP er standarden for å koble verktøy utenfra til agentrammeverket.

Verktøydefinisjonene opptar plass i konteksten ved hver forespørsel. En stor verktøyliste har derfor en løpende kostnad før noe verktøy kalles — og mange verktøy med lignende beskrivelser gjør modellen dårligere til å velge det riktige.

Bruk:

«Kan agenten spørre staging direkte?»

«Legg til et `psql`-verktøy i agentrammeverket, med skrivebeskyttet tilgang til staging. Uten et verktøy for det er agenten blind for alt utenfor filsystemet.»

Modellens output som navngir et verktøy og argumentene det skal bruke — bare strukturert tekst. Det gjør ingenting på egen hånd; agentrammeverket må lese og utføre det. Modellen produserer det i én forespørsel til modelltilbyderen.

Livssyklusen til et verktøykall:

Én tur med arbeid utført av en agent består vanligvis av mange slike rundturer etter hverandre.

Fordi kallet genereres gjennom prediksjon av neste token som alt annet, kan det være feil på samme måte som alle andre modellresultater: en sti som ikke finnes, et flagg kommandoen ikke har eller argumenter som virker sannsynlige, men ikke er riktige. Agentrammeverket utfører det som ble skrevet, ikke det som var ment — en feilskrevet sti gir ikke nødvendigvis en ryddig feilmelding; den kan få agenten til å redigere feil fil.

Bruk:

«Den sa at den kjørte testene, men tidsstemplene på filene er uendret.»

«Se på transkripsjonen — sendte den faktisk ut et verktøykall, eller beskrev den bare at den kjørte testene? Modellen produserer kallet, men hvis agentrammeverket ikke utførte det, skjedde ingenting.»

Det agentrammeverket sender tilbake etter å ha utført et verktøykall — filinnholdet, kommandoresultatet eller feilen. Det er agentens eneste innsyn i miljøet. Det sendes tilbake til modellen i den neste forespørselen til modelltilbyderen, der modellen bestemmer hva den skal gjøre med det. Verktøykall og verktøyresultat er hver sin ende av samme utveksling og inngår begge i én tur.

Livssyklusen til et verktøyresultat:

Resultatet blir i konteksten resten av økten. Verktøyresultater utgjør som regel mesteparten av konteksten i en kodeøkt: Hver fil som leses, hver testkjøring og hvert søk blir lagt inn i sin helhet og opptar tokens lenge etter at det sluttet å være nyttig. Noen få store resultater — en lang testlogg eller en generert fil lest i sin helhet — kan presse økten mot grensen for kontekstvinduet raskere enn selve samtalen gjør.

Fordi resultatet er alt modellen ser, har modellen ingen måte å kontrollere miljøet bak det på. Hvis output ble avkortet, kommandoen feilet i stillhet, eller agentrammeverket returnerte en feil i stedet for innholdet, resonerer modellen ut fra det den fikk. Når agentens bilde av systemet virker feil, er verktøyresultatene stedet å lete: Et sted i transkripsjonen finnes et resultat som sier noe annet enn det du vet stemmer.

Bruk:

«Den resonnerer som om filen er tom.»

«Verktøyresultatet var en tillatelsesavvisning, ikke innholdet. Modellen så bare feilteksten — den har ingen annen måte å se filen på.»

Model Context Protocol. En protokoll for å koble eksterne verktøyservere til et agentrammeverk — slik får en agent verktøy utover dem agentrammeverket leveres med. Agenten «kaller aldri MCP»; den kaller et verktøy, og agentrammeverket har tilfeldigvis fått verktøyet fra en MCP-server. Protokollen tilbyr også ressurser (skrivebeskyttede data) og prompts (gjenbrukbare maler), men hovedbruken er å tilby verktøy.

Protokollen løser et integrasjonsproblem. Uten en standard måtte hvert agentrammeverk hatt sin egen Linear-integrasjon, sin egen Slack-integrasjon, sin egen databaseintegrasjon — skrevet og vedlikeholdt separat for hvert enkelt. Med MCP skrives integrasjonen én gang som en server, og alle MCP-kompatible agentrammeverk kan bruke den. Agentrammeverket kobler seg til serveren, serveren annonserer hvilke verktøy den tilbyr, og verktøyene blir tilgjengelige for agenten sammen med de innebygde verktøyene.

Kostnaden betales i kontekst. Hvert verktøy en server annonserer, kommer inn som en definisjon — navn, beskrivelse og parameterskjema — og modellen kan bare kalle verktøy den kjenner til. Den naive løsningen laster alle definisjonene inn i kontekstvinduet på forhånd: Installer noen få rikholdige servere, og en økt begynner med tusenvis av tokens i verktøyskjemaer før du har skrevet noe som helst, slik at oppmerksomhetsbudsjettet brukes på verktøy oppgaven aldri vil trenge.

Mange agentrammeverk reduserer nå dette problemet med verktøysøk: I stedet for de fullstendige definisjonene inneholder konteksten en kontekstreferanse til de tilgjengelige verktøyene — agenten søker etter et verktøy på navn eller formål og laster inn definisjonen først når den trenger den. Hvis agentrammeverket ditt ikke gjør dette, gjelder fortsatt den innledende kostnaden, og det lønner seg å bare aktivere serverne prosjektet faktisk trenger.

Bruk:

«Agenten må kunne lese saker fra Linear.»

«Konfigurer agentrammeverket til å bruke Linear MCP-serveren — den tilbyr Linear-API-et som verktøy agenten kan kalle. Da slipper du å skrive egendefinerte verktøyomslag.»

Det agentrammeverket viser brukeren før det utfører et verktøykall som ikke er forhåndsgodkjent. Modellen produserer et verktøykall; i stedet for å kjøre det umiddelbart stopper agentrammeverket og spør. Godkjenn, så kjøres det; avslå, så sender agentrammeverket avslaget tilbake til modellen som et verktøyresultat. Mekanismen et agentrammeverk bruker for å sette et menneske inn i løkken ved risikable eller følsomme handlinger.

Livssyklusen til en tillatelsesforespørsel:

Et avslag styrer agenten. Modellen leser avslaget som ethvert annet verktøyresultat og reagerer på det — den prøver en annen tilnærming eller spør hva du foretrekker. De fleste agentrammeverk lar deg legge til en melding i avslaget. Da blir forespørselen et styringspunkt: «ikke slik, bruk migreringsskriptet i stedet» kommer fram akkurat når modellen bestemmer hva den skal gjøre videre.

Kostnaden er at hver forespørsel krever at du svarer før noe kan fortsette. Agenten står blokkert til du svarer; det er greit når du følger med, og et problem når du ikke gjør det — en agent som utløser forespørsler hele tiden, kan ikke overlates til å arbeide ubemannet. Tillatelsesmodusen er justeringshjulet: hvilke kall som går fritt, hvilke som spør først, helst med en sandkasse som gjør det trygt å utvide mengden frie kall.

Bruk:

«Den har stått blokkert på en tillatelsesforespørsel i ti minutter — jeg var i et møte.»

«Det er kostnaden ved menneske-i-løkken. Forhåndsgodkjenn de trygge verktøyene, så utløses forespørselen bare for de faktisk risikable kallene.»

Den delen av en agentmodus som styrer tillatelser — hvilke verktøykall utløser en tillatelsesforespørsel, og hvilke som kjører automatisk. Det opprinnelige formålet med modussystemer, før agentrammeverk begynte å samle atferdsinstruksjoner oppå dem.

Agentrammeverk leveres med en trinnrekke av slike moduser:

Valg av trinn er en avveining mellom sikkerhet og avbrytelser, og begge feiltypene merkes. For stramt, og du blir flaskehalsen: Agenten stopper med noen sekunders mellomrom for ufarlig lesing, du godkjenner på autopilot, og godkjenningene slutter å bety noe — rutinemessige godkjenninger er det verste fra begge verdener, alle avbrytelsene uten noen beskyttelse. For løst, og agenten redigerer filer og kjører kommandoer du ville ønsket å se først.

Den løse enden er lettest å forsvare inne i en sandkasse, der skadeomfanget av et dårlig verktøy-kall er begrenset. Utenfor den ender de fleste med å forhåndsgodkjenne lesing og beholde et menneske i løkken for alt som ikke kan gjøres om.

Bruk:

«Den stanset ved hver grep — ødela hele den ubemannede kjøringen.»

«Løsne tillatelsesmodusen for skrivebeskyttede verktøy, men behold spørsmål ved skriving og shell. De fleste tillatelsesforespørslene i en undersøkelses-økt er støy.»

En forhåndsinnstilling som former hvordan agenten arbeider under kjøring — den kombinerer en tillatelsesmodus med atferdsinstruksjoner som settes inn i systemprompten. Eksempler: standardmodus, som spør om risikable kall; planleggingsmodus, som blokkerer redigeringer og styrer agenten mot undersøkelser; godta redigeringer, som godkjenner redigeringer automatisk; og omgå tillatelser (ofte kalt YOLO-modus), som godkjenner alt automatisk. Modusen kan endres midt i en økt.

Det er kombinasjonen som skiller en modus fra en ren tillatelsesinnstilling. En tillatelsesmodus er bare en port: Den avgjør hvilke verktøykall som slipper gjennom. En port alene gir en agent som vil redigere, men ikke får lov — den foreslår en skriving, blir blokkert og prøver en annen måte. De innsatte instruksjonene fjerner ønsket om å redigere: Planleggingsmodus blokkerer ikke bare redigeringer, den forteller agenten at den er i en planleggingsfase, slik at den leser, spør og foreslår i stedet for å kjempe mot porten. Port og styring peker samme vei.

I praksis bytter du modus etter hvert som tilliten din endres gjennom en oppgave. Den samme oppgaven kan gå gjennom flere moduser: planleggingsmodus mens tilnærmingen utformes, standardmodus med spørsmål for de første følsomme redigeringene, godta redigeringer når agenten har vist at den forstår endringen, og omgåelse for en ubemannet kjøring inne i en sandkasse. Det koster ingenting å bytte modus: Samtalen fortsetter nøyaktig der den var, men med nye tillatelser og nye instruksjoner. Hvis du oppdager at du godkjenner hvert spørsmål uten å lese det, er modusen strammere enn tilliten din tilsier; hvis du stadig avviser redigeringer, er den løsere.

Leverandørterminologi: Claude Code kaller disse «tillatelsesmoduser», Codex kaller dem «godkjenningsmoduser» — begge navnene oppsto før atferdsinstruksjoner ble lagt inn i modusen.

Bruk:

«Den fortsetter å redigere filer selv om jeg bare vil ha en plan.»

«Bytt til planleggingsmodus — den blokkerer skriving og holder seg til undersøkelser.»

«Hva med den ubemannede kjøringen senere?»

«Omgåelsesmodus, men bare inne i sandkassen.»

Et isolert miljø agenten kjører i — en container, virtuell maskin, midlertidig filsystem eller shell med begrensede tillatelser. Begrenser skadeomfanget av agentens handlinger: Selv om agenten kjører destruktive kommandoer eller henter noe skadelig, holdes skaden innenfor miljøet. Sikkerhetsgrunnlaget som gjør ubemannet arbeid praktisk.

Sandkassen og tillatelsesmodusen løser det samme problemet fra hver sin side. Tillatelser spør før en handling kjøres; en sandkasse begrenser hva handlingen kan nå dersom den kjøres. Tillatelser krever at du er med i løkken — hvert spørsmål er et avbrudd — og en økt som spør hele tiden, er knapt autonom. En sandkasse bruker infrastruktur i stedet for oppmerksomhet: Jo sterkere isolasjon, desto færre spørsmål må stilles.

Isolasjon finnes i ulike grader:

Det en sandkasse ikke inneholder, er handlinger som på lovlig vis forlater den. En agent med git-legitimasjonen din kan pushe; en med nettverkstilgang kan kalle produksjons-API-er. Bestem hva som får krysse grensen før du bestemmer hvor tykk den skal være.

Bruk:

«Jeg vil la den kjøre bypass-permissions over natten, men jeg er ikke klar for det ennå.»

«Sett den i en sandkasse — ny container, ingen tilkoblede legitimasjoner, ikke noe nettverk ut. I verste fall ødelegger den sitt eget filsystem, og du kaster containeren.»

Modell-resultat som er selvsikkert og medgjørlig. Skyldes treningen: Modellen ble formet til å foretrekke svar mennesker likte, og mennesker liker som regel å få medhold bedre enn å bli fortalt at de tar feil. Modellen lærte derfor at det lønner seg å være enig — også når enigheten er feil.

Viser seg som:

• Gir etter for motstand — trekker tilbake et riktig svar når du sier «er du sikker?».
• Ros av dårlig input — sier seg enig i at den dårlige planen din er glimrende før den analyserer den.
• Skjev vinkling — gjennomgangen heller positivt når du sier at du skrev det, og negativt når du sier at noen andre gjorde det. Samme artefakt, ulik vurdering.
• Etteraping — gjentar feilene dine som om de bekrefter dem.

Diagnostisk test: Ville modellen sagt dette uten føringen din? Hvis det eneste som endret seg, var tonen eller innrammingen din, er det sykopanti, ikke en reell endring i analysen.

Løsning: Skjul preferansene dine. Formuler promptene nøytralt — «gå gjennom denne koden», ikke «er denne koden god?».

Unngå: å bruke «sykopanti» om alle gale svar som tilfeldigvis gleder deg. Uten den diagnostiske testen har begrepet ikke mer verdi enn «feil».

Bruk:

«Den sa at refaktoreringsplanen min så flott ut, men da jeg spurte ‘er du sikker?’, trakk den tilbake alt sammen.»

«Klassisk sykopanti — først sa den seg enig fordi du virket sikker, så ga den etter fordi du virket tvilende. Kvaliteten på planen endret seg ikke, men tonen din gjorde det. Tøm økten og spør på nytt uten å signalisere noen av delene.»

Modell-resultat som er selvsikkert, men feil. To varianter med ulike årsaker og løsninger:

Prediksjon av neste token gir flytende tekst enten den underliggende opplysningen er ekte eller ikke — modellen har ikke noe internt signal om at den ikke vet noe, så en oppdiktet metode kommer i samme selvsikre tone som en korrekt metode. Hallusinert kode er sannsynlig av konstruksjon: Det er slik API-et ville sett ut hvis det eksisterte, og nettopp derfor kan det passere en rask gjennomgang og først feile når det kjøres.

Du må vite hvilken variant du ser på, for løsningen på den ene forverrer den andre. Faktatrohet betyr at kunnskap mangler: Løsningen er å legge til kontekst — dokumentasjonen, typedefinisjonene eller filen. Trofasthet betyr at kunnskapen finnes, men taper konkurransen om oppmerksomhet: Løsningen er å fjerne kontekst. Feiltolk trofasthet som manglende fakta, så limer du inn mer dokumentasjon; det øker konteksten og gjør avviket verre. Når agenten tar feil, må du sjekke om den riktige informasjonen allerede lå i konteksten før du avgjør hvilket problem det er.

Unngå: «hallusinasjon» som en generell synonym for «feil» — uten å navngi varianten har begrepet ingen diagnostisk verdi.

Bruk:

«Den hallusinerte en `parseAsync`-metode på skjemaet.»

«Faktatrohet eller trofasthet?»

«Metoden finnes i dokumentasjonen jeg limte inn — den sluttet bare å lese den etter tur førti.»

«Da er det trofasthet. Komprimer og last inn på nytt; det er ingen vits i å legge til mer dokumentasjon.»

Det modellen «vet» fra treningen, lagret i parameterne. Fastlåst under treningen — modellen kan verken se sine egne parametere eller oppdatere dem. Detaljer går tapt i komprimeringen: Milliarder av fakta presses inn i et fast antall parametere, og de sjeldne blir uklare. Kilde til flytende svar om vanlige emner og oppdiktede svar om uvanlige emner. Motstykket til kontekstuell kunnskap.

Parametrisk kunnskap lagres ikke som fakta. Treningen gir aldri modellen en database å slå opp i; den justerer parameterne til modellen forutsier tekst godt, og en modell som forutsier tekst om et emne godt, oppfører seg som om den kjenner emnet. Hvor pålitelig kunnskapen er, henger sammen med hvor ofte noe forekom i treningsdataene: Et emne med millioner av eksempler gjengis nøyaktig, mens modellen for et emne med bare noen få eksempler gjetter ut fra hvordan lignende emner ser ut. Å gjengi og å gjette er samme prosess for modellen, så den kan ikke se forskjell på dem. Et oppdiktet svar kommer med samme flyt som et korrekt svar. Hallusinering er at modellen gjetter feil.

Parametrisk kunnskap blir også foreldet. Parameterne slutter å endres ved kunnskapens skjæringsdato, så et bibliotek utgitt eller omdøpt etter datoen finnes ikke i dem, og et API som ble endret, huskes i sin gamle form.

For begge hullene — det som er for sjeldent og det som er for nytt — er løsningen den samme: Kunnskapen kan ikke legges inn i parameterne, så den må leveres som kontekstuell kunnskap i stedet.

Bruk:

«Den skriver feilfri React, men finner på metoder i det interne SDK-et vårt.»

«React er tett representert i den parametriske kunnskapen — millioner av treningseksempler. SDK-et ditt er ikke det, så modellen fyller inn former som virker plausible. Last SDK-dokumentasjonen inn i konteksten.»

Datoen etter hvilken en modell ikke har noen parametrisk kunnskap. Biblioteker, API-er og hendelser fra etter skjæringsdatoen er feller for oppdiktede svar, med mindre dokumentasjonen lastes inn som kontekstuell kunnskap. Hver modellutgivelse har sin egen skjæringsdato.

Skjæringsdatoen finnes på grunn av hvordan modeller lages: Treningen baker et øyeblikksbilde av tekst inn i modellens parametere, og etterpå låses parameterne. Modellen vet ikke at kunnskapen har en grense — blir den spurt om noe fra etter skjæringsdatoen, nekter den ikke; den ekstrapolerer fra det nærmeste den kjenner. Det er det som gjør fellen vanskelig å oppdage: Kode skrevet mot en gammel bibliotekversjon ser plausibel ut, kompilerer ofte og feiler på delene som ble endret.

Løsningen er alltid den samme: Få oppdatert informasjon inn i konteksten. Last inn endringsloggen, vis til typedefinisjonene for den installerte versjonen, eller be agenten lese dokumentasjonen på nettet. Alt i konteksten veier tyngre enn ingenting i parameterne.

Bruk:

«Den skriver stadig SDK-syntaksen fra v3 — vi bruker v5.»

«v5 kom etter kunnskapens skjæringsdato. Last inn endringsloggen for v5 som kontekstuell kunnskap, ellers fortsetter den å finne på ting ut fra den eldre parametriske versjonen.»

Fakta agenten kan lese direkte fra konteksten akkurat nå — brukerens oppgave, filer agenten har lest inn, verktøyresultater og innhold fra AGENTS.md som ble lastet inn ved starten av økten. Motstykket til parametrisk kunnskap: parametrisk kunnskap blir gjenkalt fra parameterne; kontekstuell kunnskap blir lest fra vinduet. Hallusinasjoner er langt sjeldnere når agenten arbeider ut fra kontekstuell kunnskap — svaret ligger rett foran den, ikke gjemt i et uklart minne.

Av de to kunnskapstypene er det bare den kontekstuelle du har kontroll over. Parameterne er fastlåst, så den eneste måten å gi modellen kunnskap den mangler — et internt SDK, et bibliotek utgitt etter kunnskapens skjæringsdato, en beslutning fra i går — er å legge den inn i konteksten. Mye praktisk AI-koding handler om nettopp dette: å få de riktige faktaene fram for modellen når den trenger dem.

Når kontekstuell og parametrisk kunnskap er i konflikt, vinner den kontekstuelle som regel. Lim inn den gjeldende API-dokumentasjonen, så følger modellen den i stedet for det utdaterte minnet om den gamle API-en — selv om den gamle versjonen fortsatt kan sive inn, særlig sent i en lang økt. Hvis agenten stadig går tilbake til et utdatert mønster selv om dokumentasjonen er lastet inn, lekker parametrisk kunnskap forbi den kontekstuelle; det hjelper å gjenta rettelsen eller flytte den nærmere arbeidet.

I motsetning til parametrisk kunnskap koster kontekstuell kunnskap noe å bruke. Alt som lastes inn i vinduet, bruker tokens og konkurrerer om modellens oppmerksomhetsbudsjett, så mer er ikke automatisk bedre — målet er de relevante faktaene i vinduet, ikke alle faktaene.

Bruk dette begrepet bare når du setter det opp mot parametrisk kunnskap; ellers sier du bare kontekst.

Unngå: «arbeidsminne» — kontekstuell kunnskap er det som finnes i vinduet nå; et minnesystem er det som får innhold fra tidligere økter inn i det. Det er ulike skalaer, og begrepene må ikke blandes sammen.

Bruk:

«Hvorfor treffer den API-en så godt når jeg limer inn dokumentasjonen, men finner på ting når jeg ikke gjør det?»

«Når dokumentasjonen er med, er det kontekstuell kunnskap — den leser rett fra siden. Uten den er kunnskapen parametrisk, og de sjeldne endepunktene blir uklare.»

Når modellen forutsier hver token, tar den hensyn til alle andre tokens i konteksten — noen i stor grad, andre nesten ikke i det hele tatt. Koblingen mellom to tokens er et oppmerksomhetsforhold, og meningsfulle par («henne» med «Sarah» eller et `getUser()`-kall med definisjonen `function getUser`) påvirker hverandre mer enn urelaterte par. En kontekst med N tokens har i størrelsesorden N² forhold.

Det er i disse koblingene modellens tilsynelatende forståelse ligger. Når den finner ut hva et pronomen viser til, skyldes det at oppmerksomhetsforholdet mellom «henne» og «Sarah» er sterkt. Når den kaller en funksjon med riktige argumenter, gjør forholdet mellom kallstedet og definisjonen den leste tidligere jobben. Ingenting slås opp — alt beregnes på nytt ved hver forespørsel til modelltilbyderen, for hvert par.

N²-tallet er verdt å dvele ved, fordi det vokser raskere enn intuisjonen tilsier:

Hvert par beregnes dessuten mer enn én gang. Modeller har flere oppmerksomhetshoder — nøyaktig antall for de fremste modellene er ikke offentliggjort, men femti til hundre er et rimelig anslag — og hvert hode beregner sin egen versjon av hvert forhold. Hvert forhold i tabellen ovenfor gjentas altså for hvert hode. Det er mange forhold.

Bare et lite antall av disse forholdene betyr noe for en gitt oppgave. Forholdet mellom instruksjonen din og koden den styrer, er ett av få som teller; nesten alt annet i mengden er støy. Og de vokser i ulik hastighet: Forholdene som betyr noe, holder seg omtrent konstante, mens den samlede mengden vokser kvadratisk med kontekststørrelsen. Ved 1 000 tokens er forholdet du bryr deg om, ett av en million; ved 100 000 tokens er det ett av ti milliarder. Dette er regnestykket bak oppmerksomhetsbudsjettet, og forringet oppmerksomhet er følelsen av at forholdene som betyr noe, får en altfor liten andel.

Bruk:

«Den blander stadig sammen de to `user`-symbolene i diffen — det høres ut som vi er i den dumme sonen.»

«Ja, oppmerksomhetsforholdet mellom hvert kallested og deklarasjonen konkurrerer med det andre — samme tokentype, ulike bindinger. Gi det ene et nytt navn, så blir koblingene tydeligere.»

Hvert token har en begrenset mengde påvirkning det kan fordele på resten av konteksten. Stor påvirkning på én relasjon gir mindre igjen til de andre. Budsjettet er fast for hvert token og vokser ikke når konteksten gjør det, og derfor utvanner lange økter oppmerksomheten.

Tenk på det som signal og støy. Instruksjonen din er et signal med fast volum; alle andre tokens i kontekstvinduet er konkurrerende lyd. Instruksjonen blir ikke svakere — den er fortsatt der, tegn for tegn — men når konteksten vokser, blir rommet rundt den høyere, og signal/støy-forholdet synker. En instruksjon som var det tydeligste ved 10 000 konteksttokens, er bakgrunnsstøy ved 150 000. Dette er mekanismen bak forringelse av oppmerksomhet: Modellen glemmer ikke; signalet forsvinner i støyen.

Symptomet ser ut som ulydighet — agenten gikk tidlig med på en begrensning og beveger seg så bort fra den, og det hjelper bare kortvarig å lime begrensningen inn på nytt. Årsaken er ikke instruksjonen; det er alt annet i vinduet som konkurrerer med den.

Det du kan kontrollere, er hva som kommer inn i konteksten. Innhold som ikke tjener oppgaven, er ikke nøytralt — det er støy over alt som faktisk gjør det. Hold vinduet lite, tøm når den oppsamlede konteksten ikke lenger er verdt kostnaden, og gjenta begrensningene som betyr noe i stedet for å stole på at en tidlig henvisning skal holde.

Bruk:

«Hvorfor ignorerer den skjemaet jeg limte inn øverst?»

«Vi er langt inne i den dumme sonen — hvert tokens oppmerksomhetsbudsjett er fast, mens konteksten bare har vokst. Signalet fra skjemaet konkurrerer nå med tusenvis av nyere tokens.»

Etter hvert som en økt vokser, fordeles hvert tokens oppmerksomhetsbudsjett på flere konkurrenter. Signalet i enhver meningsfull relasjon blir svakere; støy fra irrelevant kontekst trenger seg på. Samme modell, samme parametere — bare flere munner som skal mettes fra samme tallerken. Årsaken til smart-sone-/dum-soneeffekten.

Det oppleves som om modellen blir dårligere midt i økten: Begrensninger den fulgte i en time, begynner å glippe; den spør på nytt om ting den fikk beskjed om; den skriver kode som overser en fil den leste tidligere. Ingenting ved modellen endret seg — den eneste variabelen er hvor mye kontekst den nå må rette oppmerksomheten mot.

Det skjer gradvis, og derfor er det vanskelig å oppdage fra innsiden av økten. Det finnes ingen feil eller tydelig grense; hver tur er bare litt dårligere enn den forrige, og når glippene blir tydelige, har du vært i den dumme sonen en stund.

Du kommer deg ut ved å fjerne kontekst, ikke ved å legge til mer. Å lime inn instruksjonen den overså på nytt, gir enda en konkurrent plass i det samme overfylte vinduet og hjelper bare kortvarig. Det som virker: Tøm og last inn bare det oppgaven trenger, eller komprimer, eller overlever til en ny økt. Se svakere etterlevelse av instruksjoner som et signal om kontekstens lengde, ikke om modellen.

Bruk:

«Den er dypt inne i den dumme sonen — finner på generiske typer som ikke finnes i typefilen.»

«Forringelse av oppmerksomhet. typedefinisjonene er fortsatt i konteksten, men signalet fra dem er begravd under alt vi har lagt til siden. Tøm og last inn på nytt.»

Tidlig i en økt befinner agenten seg i en «smart sone» — skarp, fokusert, med godt minne. Etter hvert som økten vokser, driver den inn i en «dum sone»: slurvete, glemsk, flere feil — og flere trofasthetshallusinasjoner. Samme modell, samme agentrammeverk — bare mer kontekst. Den opplevde effekten av forringelse av oppmerksomhet. I de fremste modellene begynner den dumme sonen ofte rundt 125 000–150 000 tokens — men dette er omdiskutert. Tøm eller komprimer når økten eser ut; ikke press videre.

Nedgangen er gradvis og derfor lett å overse. Det finnes ingen feilmelding eller synlig grense; agenten begynner bare å prestere litt dårligere, så merkbart dårligere. Vanlige tegn er at den glemmer en instruks du ga for tjue turer siden, gjentar en feil den allerede hadde rettet, eller hevder noe selvsikkert som motsies av konteksten. Fordi nedgangen er jevn, er den vanlige reaksjonen å presse på og forklare på nytt — noe som føyer til mer kontekst og gjør problemet verre.

Sonene følger ikke grensen for kontekstvinduet. En økt kan være dypt inne i den dumme sonen mens det meste av vinduet fortsatt er ledig: Grensen er punktet der agentrammeverket nekter å fortsette, men kvaliteten faller lenge før. Planlegg etter den smarte sonen, ikke vinduet — det praktiske budsjettet for en oppgave er antallet tokens agenten arbeider godt innenfor, ikke antallet den teknisk sett kan holde.

Den smarte sonen er et budsjett, og uvedkommende arbeid bruker av det. Hver oppgave du gjør i en økt, bruker tokens, så en ny oppgave i samme økt begynner nærmere den dumme sonen. Én oppgave per økt gir hver oppgave den skarpeste delen av økten. Når én enkelt oppgave er større enn én smart sone, deler du den opp: Overlever eller komprimer ved et naturlig skille, og la en ny økt ta neste del.

Bruk:

«Den traff blink på de tre første komponentene og ødela den fjerde.»

«Du er ute av den smarte sonen — samme modell, men nå dypt inne i den dumme sonen. Komprimer og last inn planen på nytt; da vil neste komponent sitte.»

Avslutte den gjeldende økten og starte en ny. Den neste meldingen begynner med en tom økt og et tomt kontekstvindu. Vanligvis initiert av brukeren.

Tømming er kuren for en forurenset kontekst. En økt samler opp alt: mislykkede forsøk, feilretninger, gamle verktøyresultater og planer som er forlatt. Modellen leser alt på nytt ved hver tur, og dårlig historikk trekker nytt arbeid ned. Dypt inne i en lang økt blir agenten vagere og mindre lydig — tydelige instruksjoner blir ignorert, kvaliteten faller, og det hjelper ikke å be den gjøre det bedre, fordi støyen den må vasse gjennom, fortsatt ligger i konteksten. Tømming fjerner støyen.

Tømming sletter ikke samtalen. De fleste agentrammeverk beholder økthistorikken på datamaskinen din, så transkripsjonen ligger fortsatt der for å leses eller gjenopptas. Det som forsvinner, er agentens arbeidstilstand: Modellen er tilstandsløs, så den nye økten vet ingenting av det den gamle visste. Hvis økten inneholder beslutninger eller framgang neste økt trenger, ber du agenten først skrive et overleveringsartefakt, og starter deretter den nye økten med en referanse til det.

Sammenlign med komprimering, som oppsummerer økten inn i den nye konteksten i stedet for å starte tomt. Tømming er det mer brutale verktøyet: Ingenting tas med videre, inkludert skrotet.

Bruk:

«Den sitter fast i en løkke med den feilede testen.»

«Bare tøm økten — start en ny med plandokumentet og testfilen. Det er ingen vits i å kjempe mot den eksisterende konteksten.»

Å overføre agentens kontekst fra én økt til en annen. Måten innholdet tas med på, varierer — et skriftlig overleveringsartefakt, et sammendrag i minnet (komprimering) og andre løsninger. Ikke det samme som tømming, der ingenting overføres. Årsakene varierer: bytte rolle (planlegger → implementatør), starte en ubemannet kjøring, spre arbeidet på parallelle økter eller frigjøre plass i kontekstvinduet.

Den mottakende økten begynner uten kontekst — modellen er tilstandsløs, og ingenting fra den gamle økten er synlig i den nye. Alt den neste økten trenger, må overføres uttrykkelig; resten er borte. Begrensningen som former overføringen, er «ingen vei tilbake»: Den nye økten kan ikke spørre den gamle hva den mente, så materialet som overføres, må kunne stå på egne ben.

Den synlige feilen ved en dårlig overlevering er at diskusjonen tas på nytt: Den nye økten gjenåpner beslutninger den gamle allerede hadde landet, fordi overføringen noterte hva som ble bestemt, men ikke hvorfor. Vurder overleveringen ut fra hva en økt uten kontekst kunne gjort med den.

Bruk:

«Planleggingsøkten begynner å bli tung — skal jeg bare fortsette?»

«Lag en overlevering. Skriv beslutningene i et dokument, tøm økten, og start implementeringen i en ny økt som leser dokumentet.»

En primærkilde i sin opprinnelige form — koden, samtaletranskripsjonen, råloggen, det faktiske API-svaret. Ikke en beskrivelse av tingen, men selve tingen. Motstykket til en sekundærkilde.

Hvis du vil vite hva kodebasen din gjør, er koden primærkilden. Dokumentasjonen, arkitekturdiagrammet og README-filen er beskrivelser av den — riktige da de ble skrevet, men siden oppdatert etter hver sin tidsplan. Når en agent hevder noe feil om prosjektet ditt med stor selvsikkerhet, bør du spørre hvilken kilde den arbeidet ut fra: En agent som leste et dokument, arver dokumentets foreldelse; en agent som leste koden, leser den nåværende virkeligheten.

Kostnaden er grunnen til at primærkilder ikke er standardvalget. Det er dyrt å laste én inn i kontekstvinduet — hele filen, hele transkripsjonen, hver eneste token faktureres som input og konkurrerer om oppmerksomhetsbudsjettet. Det du får for kostnaden, er fullstendighet: Ingenting er forhåndsfiltrert etter andres vurdering av hva som var viktig. Et sammendrag skrevet forrige måned kan ikke inneholde detaljen som viste seg å være viktig i dag; det gjør fortsatt primærkilden.

Bruk primærkilden når presisjon betyr noe — den nøyaktige signaturen, den faktiske feilen eller linjen som utløser den. Mye av arbeidet med å håndtere kontekst består i å avgjøre når det er verdt å betale for primærkilden, og når en sekundærkilde er god nok.

Bruk:

«Agenten sier at retry-logikken bruker eksponentiell ventetid, men jeg ser at den hamrer løs på endepunktet.»

«Den leste det i designdokumentet. Pek den mot den faktiske retry-modulen — bruk primærkilden når atferden betyr noe.»

En redegjørelse for en primærkilde, ett ledd fjernet — dokumentasjon som beskriver kode, et sammendrag som beskriver en transkripsjon, en rapport som beskriver søkeresultater. Billigere å laste inn i kontekstvinduet enn kilden den beskriver, men ufullstendig av natur: Den som skrev den, bestemte hva som var viktig, og alt som ble utelatt, er usynlig for en leser som bare har sammendraget.

Mye av arbeidet med å utforme kontekst består i å lage sekundærkilder. Komprimering gjør øktens historikk om til et sammendrag som gir neste økt startgrunnlaget. En underagent bruker sitt eget kontekstvindu på et støyende søk og returnerer en kort rapport. Et overleveringsartefakt samler beslutningene fra en økt i et dokument som neste økt leser. Minnesystemer destillerer det en økt lærte, til notater. Alle gjør den samme avveiningen: presisjon mot mer spillerom.

Sekundærkilder feiler på to måter. De er ufullstendige — komprimeringsoppsummeringen som mistet skjemabeslutningen, rapporten som ikke nevnte grensetilfellet. Og de driver fra kilden — primærkilden endres, mens redegjørelsen ikke oppdateres, slik at dokumentasjonen beskriver forrige kvartals arkitektur med dette kvartalets sikkerhet. Når en agent handler på grunnlag av en sekundærkilde som har feilet på en av disse måtene, arbeider den selvsikkert ut fra feil informasjon; løsningen er å sende den tilbake til primærkilden.

Ingen av feiltypene betyr at sekundærkilder er en dårlig idé. Kontekstvinduet er begrenset, og primærkilder er kostbare; uten sammendrag, rapporter og overleveringsdokumenter får ingenting stort plass. Ferdigheten består i å vite hvilke detaljer som tåler tapet — og å kontrollere mot primærkilden når de ikke gjør det. En god sekundærkilde har en kontekstreferanse tilbake til originalen — sammendraget navngir transkripsjonen det kommer fra, dokumentet navngir filen det beskriver — slik at leseren kan følge referansen når redegjørelsen ikke er nok, i stedet for å arbeide ut fra det som gikk tapt.

Bruk:

«Overleveringsdokumentet sier at autentisering er ferdig, men den nye økten finner stadig problemer med oppdatering av token.»

«Dokumentet er en sekundærkilde — forrige økt skrev ned hva den trodde, ikke hva som er sant. Be den nye økten kjøre autentiseringstestene og stole på primærkilden.»

Et dokument som brukes som overføringsmekanisme ved en overlevering — skrevet til miljøet av én økt for å leses av en annen. Spesifikasjoner, saker og plandokumenter er alle overleveringsartefakter.

Grunnen til å skrive et slikt dokument: Modellen er tilstandsløs, så ingenting i en økt overlever at den tømmes. Beslutninger, begrensninger og halvferdige planer — alt forsvinner sammen med konteksten som inneholdt dem. Miljøet består. Når den viktige tilstanden skrives til en fil, flyttes den til et sted den neste økten kan lese fra.

Artefaktet er en sekundærkilde — en redegjørelse for arbeidet i økten, ikke selve arbeidet. Det gjør det lite nok til å orientere en ny økt, og det er også derfor det kan villede: Det dokumenterer det den skrivende økten trodde, og alt den utelot eller tok feil av, er usynlig for leseren. Når en påstand er viktig, bør neste økt kontrollere den mot primærkilden — koden og testene — i stedet for å arve den ukritisk.

Et godt artefakt skrives for å leses i en økt uten noen kontekst. Bruk konkrete filstier i stedet for «filen vi diskuterte». Ta med hva som ble bestemt og hvorfor, så den neste økten ikke tar diskusjonen på nytt. Ta med hva som er ferdig og hva som gjenstår. Det hjelper å fortelle den skrivende økten hvor artefaktet skal brukes: «skriv et overleveringsdokument for en ny økt som ikke vet noe om dette arbeidet».

Den alternative overføringsmekanismen er komprimering, som oppsummerer i minnet. Artefaktet har to fordeler: Det ligger på disk, der du kan lese og rette det før noe avhenger av det, og det kan gjenbrukes — den samme spesifikasjonen kan orientere fem parallelle økter.

Bruk:

«Hvordan deler jeg dette mellom planleggings-agenten og implementeringsagenten?»

«Be planleggeren skrive et overleveringsartefakt — filstier, beslutninger og begrensninger. Implementeringsøkten starter med en referanse til artefaktet og bruker det som oppdragsbeskrivelse.»

Et overleveringsartefakt som beskriver et arbeid som går over flere økter — hva som bygges, ikke hvordan hver økt gjør sin del. Det endres etter hvert som arbeidet skrider fram. Består av saker.

Spesifikasjonen finnes fordi økter er kortvarige, mens store arbeider ikke er det. Alt som krever mer enn ett kontekstvindu med arbeid, trenger et hjem utenfor konteksten — et sted i agentens miljø som overlever tømming, enten det er en fil i repoet, en GitHub-sak eller et saksbehandlingssystem agenten kan nå. Spesifikasjonen er dette hjemmet: målet, begrensningene, beslutningene som er tatt så langt, og listen over saker med status. Enhver ny økt kan lese den og forstå hvor arbeidet står, uten å arve støyen som har samlet seg i den forrige økten.

Spesifikasjoner har gjenkjennelige stiler, for det meste arvet fra måtene team allerede skriver ting ned på. Et produktkravsdokument (PRD) legger mest vekt på hva brukeren skal oppleve og hvorfor — funksjoner, atferd og godkjenningskriterier. Et designdokument eller en RFC er mer teknisk — valgt tilnærming, forkastede alternativer og avveininger. I den enklere enden gjør en vanlig `plan.md` med en sjekkliste over saker den samme jobben for en funksjon som går over flere økter. Stilen er mindre viktig enn rollen: For agenten er alle disse det samme — en varig beskrivelse av hensikten som den leser ved starten av hver økt.

Bruk:

«Bør alt dette gjøres i én økt?»

«Nei, skriv det opp som en spesifikasjon — del det opp i saker, og kjør hver sak i sin egen økt. Hvis du prøver å gjøre alt i ett kontekstvindu, havner du i den dumme sonen før du er halvveis.»

Et overleveringsartefakt som avgrenser én økt med arbeid. Det står på egne ben eller hører til en spesifikasjon som en av undersakene. Saker kan blokkere eller bli blokkert av søskensaker, så arbeidsrekkefølgen følger av avhengighetsgrafen i stedet for en lineær plan.

Den avgjørende begrensningen er omfanget: én økt. En sak bør kunne fullføres før økten driver ut av den smarte sonen — og den begrensningen kan testes. Hvis øktene med sakene dine regelmessig forringes før arbeidet er ferdig, er sakene for store; del dem opp. Hvis hver økt bruker mesteparten av konteksten på oppsett før den gjør fem minutters arbeid, er sakene for små; slå dem sammen.

En god sak er skrevet for en leser uten annen kontekst. Målet, godkjenningskriteriene og kontekstreferanser til relevante filer og beslutninger — nok til at økten kan begynne arbeidet uten å måtte finne ut på nytt det den forrige visste.

Avhengighetsgrafen er også det som åpner for parallellisering. Uavhengige saker — bladene i grafen — kan hver kjøres i sin egen økt samtidig. Dette er en effektiv måte å kjøre flere agenter på samtidig. I en programvarefabrikk er det at en sak merkes som klar, i seg selv utløser starten på økten.

Bruk:

«Hvor begynner jeg på migreringsspesifikasjonen?»

«Se på saksdiagrammet — skjemendringen blokkerer tilbakefyllingen, og tilbakefyllingen blokkerer API-bytte. Velg et blad og kjør en økt på det.»

En overlevering som gjøres i minnet: historikken fra den forrige økten oppsummeres, og oppsummeringen brukes som startpunkt for en ny økt. Den er tapsfull med vilje: Transkripsjonen er en primærkilde, oppsummeringen en sekundærkilde — detaljer byttes mot mer spillerom. Utløses manuelt av brukeren eller automatisk via autokomprimering.

Mekanismen: Kontekstvinduet er begrenset, og en lang økt fyller det opp — hvert verktøyresultat, hver fil som leses, hver feilretning blir værende i historikken. Når den blir full, ber agentrammeverket modellen om å oppsummere økten, kaster den opprinnelige historikken og starter en ny økt med oppsummeringen. Alt som ikke kom med i oppsummeringen, er borte fra konteksten. Noen agentrammeverk avhjelper dette ved å beholde den gamle transkripsjonen på disk og legge igjen en kontekstreferanse til den i oppsummeringen — sekundærkilden peker tilbake til primærkilden, slik at en detalj oppsummeringen mistet, kan finnes igjen ved å lese originalen på nytt.

Oppsummeringen skrives av modellen, så den kan styres med en prompt. «Bevar skjemabeslutningene» gjør det genererte artefaktet mer gjennomtenkt. Tidspunktet betyr også noe — komprimer ved et faseskille, etter at planen er fastlagt, ikke midt i en oppgave.

Sammenlign med tømming, som forkaster alt og starter med blanke ark: Komprimering prøver å ta med det viktigste videre; tømming forutsetter at det allerede er skrevet ned et bedre sted.

Bruk:

«Konteksten begynner å bli tung, og jeg må fortsatt få testene til å bestå.»

«Komprimer før du begynner — skriv inn i oppsummeringsprompten hva som må overleve, så den nye økten beholder skjemabeslutningene og forkaster utforskingen.»

Komprimering som utløses automatisk av agentrammeverket når kontekstvinduet nærmer seg fullt.

Agentrammeverket følger med på hvor fullt kontekstvinduet er. Når det passerer en grense — ofte rundt 80 % — stopper det opp, ber modellen oppsummere økten så langt og starter en ny økt med oppsummeringen. Arbeidet fortsetter deretter som om ingenting hadde skjedd.

Men noe skjedde. Komprimering er tapsfull, og autokomprimering skjer på et tidspunkt du ikke valgte. Manuell komprimering skjer ved et faseskille, når du kan fortelle modellen hva den skal bevare. Autokomprimering utløses midt i oppgaven, så snart grensen nås — kanskje halvveis gjennom en refaktorering, mens oppsummeringen selv bestemmer hvilke avgjørelser du tok, som er verdt å beholde. Det klassiske symptomet er at agenten fortsetter selvsikkert, men i stillhet har glemt en begrensning du etablerte for en time siden, og at du først merker det når arbeidet begynner å motsi den.

Forsvaret er å hindre at den utløses. Følg med på kontekstindikatoren og komprimer manuelt ved et naturlig skille, eller skriv avgjørelsene inn i et plandokument eller et overleveringsartefakt på disk, der ingen oppsummering kan miste dem. De fleste agentrammeverk lar deg også tilpasse bufferen — flytte grensen tidligere eller senere, eller slå av autokomprimering helt — slik at du kan justere hvor mye spillerom du beholder før den utløses.

Bruk:

«Det virker ikke som den husker hva vi tidligere bestemte om skjemaet.»

«Autokomprimering ble utløst mellom turene — de tidlige beslutningene ble oppsummert, og vi må ha mistet noe. Last inn plandokumentet på nytt, eller komprimer manuelt neste gang, så du styrer hva som beholdes.»

Et system som prøver å gjøre en agent tilstandsfull på tvers av økter. Det lagrer informasjon i miljøet under en økt og laster den tilbake inn i kontekstvinduet ved starten av framtidige økter, slik at agenten beholder kontinuitet selv om brukeren tømmer økten.

Et minnesystem har to halvdeler. Skriveveien: Under en økt registrerer agenten det den har lært — en preferanse du har uttrykt, et faktum om prosjektet — som filer i miljøet. Leseveien: Ved starten av økten laster agentrammeverket disse filene, eller en indeks over dem, tilbake inn i kontekstvinduet. Mange agentrammeverk leveres med sitt eget minnesystem — Claude Codes `/memory` er ett eksempel — men du kan også lage et selv: en katalog med notater, pluss en instruks i AGENTS.md om å bruke den.

De samme avveiningene som for annet innhold som alltid lastes inn, gjelder også her. Minner hoper seg opp, så de fleste systemer laster inn en indeks på én linje og lar innholdet ligge bak kontekstreferanser i stedet for å legge inn alt direkte. Og minner er sekundærkilder, så de foreldes: Et faktum som ble registrert i mars, lastes inn med samme sikkerhet i juni, etter at prosjektet har gått videre. Et minnesystem trenger opprydding, akkurat som AGENTS.md.

Bruk:

«Jeg må stadig minne den på at jeg bruker Postgres, ikke MySQL.»

«Sett opp et minnesystem — skriv ned det den lærer, til filsystemet i den første turen, og last det inn igjen ved starten av økten. Modellen er i seg selv tilstandsløs; minnelaget later som den har kontinuitet.»

En fil i miljøet som agentrammeverket laster inn i kontekstvinduet ved starten av en økt — prosjektets stående oppdragsbeskrivelse til agenten. En konvensjon som går på tvers av agentrammeverk; noen rammeverk har også sin egen variant (Claude Code bruker CLAUDE.md).

Fordi filen lastes inn automatisk, er den én måte å slippe å gjenta seg selv i hver økt. Modellen er tilstandsløs — en rettelse du gir i én økt, er borte i den neste, og du ender med å fortelle hver nye økt at prosjektet bruker pnpm, at testene kjøres med et bestemt flagg, og at en katalog er generert og ikke skal røres. Når du har rettet agenten for det samme to ganger, er rettelsen en mulig linje i AGENTS.md.

Passende innhold er det agenten ikke kan utlede fra koden: bygge- og testkommandoer, konvensjoner som ikke er åpenbare i kodebasen, og absolutte begrensninger («rediger aldri den genererte klienten»). Kort og konstaterende — det er et kort oppdragsdokument, ikke dokumentasjon.

Avveiningen er at alt innholdet alltid lastes inn. Instruksjoner hoper seg opp, og de fleste er irrelevante for en gitt oppgave. En lang AGENTS.md koster tokens og svekker seg selv — jo flere instruksjoner som finnes i konteksten, desto mindre pålitelig følger modellen hver enkelt.

Unngå: å bruke AGENTS.md for innhold som bør vises gradvis — alt i filen koster en token ved hver tur, i hver økt, enten økten trenger det eller ikke. En stilguide kan heller ligge bak en skill eller en kontekstreferanse; bruk AGENTS.md til linjene som gjelder overalt.

Bruk:

«Hvorfor starter hver økt med at 4 000 tokens allerede er brukt?»

«Sjekk AGENTS.md — noen har limt inn hele stilguiden der i stedet for å legge den bak en skill.»

Å laste inn bare den konteksten agenten trenger akkurat nå, med kontekstreferanser til resten. Begrepet er lånt fra brukergrensesnittdesign, der det betyr å vise brukeren bare kontrollene som er relevante for den aktuelle oppgaven, og skjule resten bak et klikk.

Teknikken finnes fordi kontekst koster dobbelt. Hver token som lastes inn på forhånd, faktureres som inputtokens ved hver tur, og hver token bruker av oppmerksomhetsbudsjettet, enten agenten trenger den eller ikke. En AGENTS.md stappfull av hele stilguiden, utrullingshåndboken og databasekonvensjonene gjør agenten dårligere på alt sammen — instruksjonene som betyr noe for den aktuelle oppgaven, fortynnes av dem som ikke gjør det. Tegnet er en agent som ignorerer regler du vet ligger i konteksten: De er der, men begravd.

Gradvis fremvisning snur dette på hodet. Hold laget som alltid lastes inn, lite — én setning per emne og en referanse til hvor detaljene finnes. Agenten leser stilguiden når den skriver en komponent, utrullingshåndboken når den ruller ut, og ingen av delene når den retter en test. Skills er mønsteret som er bygget inn i agentrammeverket: en kort beskrivelse lastes inn hver økt, mens de fullstendige instruksjonene bare lastes inn når de utløses.

Bruk:

«Bør jeg dumpe hele stilguiden inn i AGENTS.md?»

«Nei — bruk gradvis fremvisning. Vis til stilguiden som en skill agenten laster inn når den faktisk må skrive en komponent. AGENTS.md bruker tokens hver tur.»

En henvisning i ett dokument til et annet, slik at agenten bare henter det inn i kontekstvinduet når oppgaven krever det. Grunnenheten som gradvis fremvisning bygges av.

Grunnen til å bruke en henvisning (i stedet for å legge inn innholdet direkte) er kostnaden. En henvisning er én linje i kontekstvinduet. Dokumentet bak den kan inneholde tusenvis av tokens, men disse koster ingenting før agenten faktisk følger henvisningen. Legg en driftsveiledning på 2 000 tokens direkte i AGENTS.md, så betaler hver økt for den; erstatt den med «utrullingsprosessen: se `internal/deploy.md`», så er det bare øktene som ruller ut, som laster den inn. Agenten følger henvisningen med et verktøykall når oppgaven tilsier det.

En henvisning trenger to deler for å fungere: en stabil sti og en tilstrekkelig beskrivelse til at agenten vet når det er verdt å følge den. En naken sti gir agenten ingen grunn til å følge den; «se `internal/deploy.md`» uten noen antydning om innholdet blir oversett av en økt som hadde trengt det. Skriv linjen slik oppgaver faktisk framstår: «utgivelse, utrulling eller tilbakeføring — les `internal/deploy.md` først».

Henvisninger finnes overalt når du først ser etter dem: linjer i AGENTS.md, beskrivelser av skills (agentrammeverket laster beskrivelsen; selve skill-innholdet venter bak den), filnavn i en katalogoversikt og lenker mellom dokumenter.

En henvisning kan også knytte en sekundærkilde tilbake til primærkilden den ble utledet fra — komprimeringsoppsummeringen som navngir den opprinnelige transkripsjonen, dokumentet som navngir kildefilen det beskriver. Da kan informasjonen som gikk tapt i sekundærkilden, gjenopprettes: Når oppsummeringen ikke viser seg å være nok, følger agenten henvisningen og leser originalen i stedet for å arbeide ut fra det oppsummeringen tilfeldigvis beholdt.

Unngå: «referanse» — for tørt; det formidler ikke at det å følge den henter mer kontekst inn. «Portal» — for blomstrende.

Bruk:

«AGENTS.md begynner å bli enorm.»

«Det meste bør være kontekstreferanser, ikke innhold. Behold reglene som alltid gjelder direkte i filen; gjør utrullingsveiledningen og stilguiden om til skills, og la det stå igjen en kontekstreferanse.»

En ferdighet som kan læres bort, samlet som en enhet — instruksjoner og ressurser for å gjøre én oppgave godt, lagret i miljøet fram til en kontekstreferanse henter dem inn i kontekstvinduet for den aktuelle oppgaven. Enheten for gradvis fremvisning i et agentrammeverk.

Skills er en åpen standard, definert på agentskills.io — opprinnelig utviklet av Anthropic og senere tatt i bruk av de fleste store agentrammeverk, slik at en skill som skrives én gang, fungerer på tvers av dem. Formatet er en mappe som inneholder:

• En `SKILL.md`-fil — metadata (minst et navn og en beskrivelse) pluss selve instruksjonene
• Eventuelt skript som agenten kan kjøre
• Eventuelt maler og referansemateriale instruksjonene viser til

Som standard ligger bare navnet og beskrivelsen i konteksten. Når agentens oppgave passer, laster den inn resten. Inntil da tar skillen nesten ingen plass — noen få tokens i en setning eller to, uansett hvor omfattende de fullstendige instruksjonene er.

Dette skiller skills fra AGENTS.md, som lastes inn i hver økt uavhengig av oppgaven. En skill leses når en bestemt type arbeid blir aktuell — utgivelse, oppsett av en ny tjeneste eller skriving av en migrering — og ignoreres resten av tiden.

Unngå: «verktøy» — et verktøy er noe agenten kaller; en skill er instruksjoner den leser.

Bruk:

«Hvor skal jeg legge utrullingsveiledningen?»

«Som en skill — agenten laster den bare inn når oppgaven handler om utrulling. I AGENTS.md ville den brukt tokens ved hver tur, selv om vi bare bruker den én gang i uken.»

En agent som startes av en annen agent via et verktøykall. Den kjører i sin egen økt, med sitt eget kontekstvindu, og sender tilbake ett enkelt verktøyresultat. Forskjellig fra en overlevering — foreldreagenten forventer uttrykkelig et svar; en overlevering har ingen vei tilbake. Kan ikke starte flere underagenter — treet går bare ett nivå ned. Underagenter finnes for å isolere kontekst, ikke for å bygge hierarkier.

Poenget er å holde støyende arbeid ute av foreldreagentens kontekst. Et bredt søk eller en lang ekspedisjon med gjennomlesing av filer gir sider med verktøyresultater, hvorav de fleste bare er relevante akkurat lenge nok til at svaret finnes. Kjør det inne i foreldreagenten, og alt blir værende i dens kontekst resten av økten. Kjør det i en underagent, og støyen fyller i stedet et midlertidig vindu — bare sluttrapporten havner i foreldreagentens kontekst. Rapporten er en sekundærkilde: Foreldreagenten får underagentens redegjørelse for det den fant, ikke råresultatene, så alt rapporten utelater, er usynlig for foreldreagenten.

Underagenter kjører også samtidig — en foreldreagent kan sende ut flere på en gang for uavhengige arbeidsdeler.

Bruk:

«Søkeresultatene fra grep fyller opp hele konteksten.»

«Start en underagent til å gjøre søket — den bruker sitt eget kontekstvindu på støyen og rapporterer tilbake de to filstiene du faktisk trenger.»

Et arbeidsmønster der ett eller flere mennesker jobber sammen med agenten i løpet av en økt — gjennomgår, styrer på nytt eller samarbeider i sanntid. Mennesket er til stede og engasjert, ikke bare en portvakt for enkeltstående handlinger.

Kontrasten er arbeid ubemannet, der agenten kjører uten tilsyn, og du vurderer resultatet etterpå. Menneske-i-løkken betyr at problemer fanges mens de fortsatt er billige å løse: Du ser at agenten velger feil fil, misforstår kravet eller begynner på en blindvei, og styrer den tilbake med én setning — i stedet for å oppdage tjue minutters selvsikkert arbeid bygget på den feilen. Agenter vet ikke pålitelig når de er på feil spor; overlatt til seg selv fortsetter de gjerne framover i stedet for å stoppe og spørre.

Hvilket mønster som passer, avhenger av arbeidet. Velspesifiserte oppgaver med lav risiko og enkle kontroller passer ubemannet. Oppgaver som er tvetydige eller irreversible, eller der det ville være vanskelig å gjennomgå det ferdige resultatet — en skjemamigrering, en krevende designbeslutning, alt som berører produksjon — passer best når du er med i løkken. Vurderingen handler i bunn og grunn om hvor kostbar en feil retning er, og hvor sent du ville oppdaget den.

Noe arbeid er i løkken av natur, fordi reaksjonene dine er selve inputen. Grilling fungerer bare når du er der og svarer på spørsmålene; prototyping fungerer bare når du er der og reagerer på artefaktet.

Det koster oppmerksomhet å være med i løkken, og oppmerksomhet er den knappe ressursen. En del av det å bli bedre til å jobbe med agenter er å flytte mer arbeid trygt ut av løkken — ved hjelp av planer, automatiske kontroller og menneskelig gjennomgang til slutt i stedet for tilsyn hele veien. En programvarefabrikk tar dette enda lenger ved å starte økter fra utløsere, slik at du ikke engang trenger å sette arbeidet i gang.

Bruk:

«Skal jeg kjøre dette ubemannet i natt?»

«Nei, det er en skjemamigrering — hold det i løkken med et menneske. Jeg vil se hvert steg og styre hvis den velger feil kolonne å fylle tilbake fra.»

«Away from keyboard» — borte fra tastaturet. Et arbeidsmønster der brukeren starter en økt og lar agenten kjøre uten tilsyn. Det som mangedobler gjennomstrømningen i AI-koding — mange ubemannede økter kan kjøre parallelt mens du sover, spiser eller arbeider med noe annet. Krever vanligvis en tillatende tillatelsesmodus og sandkasse for å være trygt.

Når du ikke er til stede, håndterer agenten tvetydighet annerledes. Mens du følger med, blir en tvetydig beslutning tatt opp som et spørsmål, og du svarer; når du har gått, velger agenten en standardløsning og fortsetter, og hver senere beslutning bygger på den gjetningen. Den typiske feilen er å komme tilbake etter flere timer til ferdig, selvsikkert arbeid bygget på en feil beslutning som ble tatt de første ti minuttene. Arbeidet er ikke slurvete — det henger sammen, men det handler om feil ting.

Siden du ikke kan gi innspill under kjøringen, må du gi dem før og etter. Før: Avklar tvetydigheten på forhånd — ha en grillingsøkt, skriv en spesifikasjon — slik at agenten får færre hull å fylle på egen hånd. Underveis: Automatiske kontroller og automatisk gjennomgang erstatter oppmerksomheten du ikke gir, og stopper raskt ved det som kan fanges mekanisk. Etterpå: Kjøringen skal ende i noe som kan gjennomgås — en PR, ikke endringer som allerede er slått sammen. Ubemannet arbeid fjerner ikke menneskelig gjennomgang; den utsetter all gjennomgangen til slutt, og derfor må det som kommer til slutt, være verdt å gjennomgå. Det er også grunnen til at AX betyr mest i ubemannede kjøringer — når ingen følger med, er miljøet den eneste støtten agenten får.

Unngå: «bakgrunnsagent» — setter maskinen («kjører i bakgrunnen») i sentrum i stedet for arbeidsmønsteret for mennesket («brukeren har gått»). AFK navngir det som betyr noe: Brukeren følger ikke med.

Bruk:

«Jeg kjører dette ubemannet — tre agenter i sandkasser på refaktoreringen, så går jeg gjennom PR-ene om morgenen.»

«Omgå tillatelser?»

«Ja, filsystemet er skrivebeskyttet, og nettverket er av.»

En deterministisk verifikasjon som kjører i miljøet — tester, typesjekker, linting, bygging og pre-commit-hooks. Bestått eller ikke bestått, uten skjønn. Signalet en agent kan rette seg etter på egen hånd, uten å involvere andre. En ustabil test er en ødelagt kontroll, ikke en kontroll som ikke finnes; automatiske kontroller er deterministiske med vilje.

Selvkorrigering fungerer som en løkke. Agenten gjør en endring, kjører kontrollen som et verktøykall, og feilmeldingen havner i kontekstvinduet — en typefeil med fil og linje, en feilet påstand med forventet og faktisk verdi. Det er nok til at agenten kan rette problemet og kjøre kontrollen på nytt, igjen og igjen til den består, uten noe menneske i løkken. Determinisme er det som gjør løkken pålitelig: Den samme koden gir alltid samme vurdering, så en bestått kontroll betyr noe. Ustabile kontroller forgifter dette — agenten «retter» kode som var riktig, eller prøver på nytt forbi en reell feil.

Derfor er gode kontroller en viktig del av en kodebases AX. En agent i et repo med strenge typer, en rask testpakke og en linter oppdager de fleste av sine egne feil før du ser dem; en agent i et repo uten dette, leverer det den produserer. Forskjellen betyr mest i ubemannede kjøringer, der kontroller er den eneste verifikasjonen underveis. Men en kontroll fanger bare det den hevder å kontrollere — grønne kontroller betyr at de påståtte egenskapene holder, ikke at koden er riktig. Hullene som krever skjønn, er det automatisk gjennomgang og menneskelig gjennomgang skal dekke.

Unngå: «tilbakemeldingssløyfe» / «mottrykk» — begge blander kontroller sammen med gjennomgang. Unngå: «test» — tester er automatiske kontroller, men ikke alle automatiske kontroller er tester.

Bruk:

«Agenten leverer stadig ødelagt kode i de ubemannede kjøringene.»

«Hvilke automatiske kontroller er koblet til sandkassen?»

«Bare enhetstestene.»

«Legg til typesjekk og linting — agenten vil korrigere seg selv med dem før PR-en i det hele tatt kommer inn.»

En agent som gjennomgår arbeidet til en annen agent, ofte med en annen modell eller systemprompt. Den er ikke-deterministisk: Den foretar en vurdering. Kan kjøres hvor som helst — før sammenslåing av en PR, i etterkant av commit-historikken eller midt i en økt som en underagent. En språkmodell som dommer i CI er automatisk gjennomgang, ikke en automatisk kontroll; det er hva påstanden gjør som avgjør kategorien, ikke hvor den kjøres.

Det fungerer fordi gjennomgangen holdes atskilt fra arbeidsagenten. Å be agenten som skrev koden, gjennomgå sitt eget arbeid, gir lite — økten som skapte feilen, inneholder også resonnementet som skapte den, og agenten leser sine egne konklusjoner som bekreftelse. En gjennomleser med et friskt kontekstvindu har ingen slik tilknytning: Den ser diffen som en fremmed ville gjort, og det er det gjennomgang bygger på. En annen modell eller en systemprompt som er laget for gjennomgang, skjerper dette ytterligere — andre blinde flekker og en systemprompt avgrenset til det du faktisk bryr deg om (sikkerhet, API-kontrakter eller ytelse) i stedet for et vagt «se etter problemer».

Den passer mellom de andre gjennomgangslagene. Automatiske kontroller er deterministiske og fanger det som kan hevdes mekanisk; menneskelig gjennomgang er kostbar og skalerer dårligst. Automatisk gjennomgang ligger mellom dem: Den fanger problemer som krever en vurdering — et misvisende funksjonsnavn eller et oversett grensetilfelle — til maskinpris. Fordi den ikke er deterministisk, kan den overse ting og flagge problemer som ikke finnes; se på den som et filter som hever bunnivået før et menneske ser på arbeidet, ikke som en port som erstatter menneskelig gjennomgang.

Unngå: «AI-gjennomgang» / «agentgjennomgang» — for vagt til å skille det fra selve arbeidsagenten.

Bruk:

«Vi får for mange dårlige PR-er fra de ubemannede kjøringene.»

«Legg til et trinn med automatisk gjennomgang før sammenslåing — en annen modell, separat systemprompt, avgrenset til sikkerhet og kontraktsendringer.»

At brukeren leser koden agenten produserte, og danner seg en vurdering av den. Det teller å lese diffen eller de endrede filene; å lese agentens beskrivelse av hva den gjorde, teller ikke — fortellingen er ikke artefaktet. Beskrivelsen er en sekundærkilde, skrevet av den som blir vurdert; diffen er primærkilden, og gjennomgang betyr at den leses.

Agenter øker mengden produsert kode, så gjennomgang blir flaskehalsen. En nyttig idé er å legge flere gjennomgangsstrategier i lag. Automatiske kontroller fanger mekaniske feil, automatisk gjennomgang fanger feil som kan beskrives, og menneskelig gjennomgang forbeholdes det bare du kan vurdere — om endringen er den riktige, om tilnærmingen passer kodebasen, og om dette i det hele tatt bør finnes.

Gjennomgang er også billigere tidligere. Det tar minutter å lese en plan før arbeidet begynner eller en liten diff underveis; det tar lengre tid å grave fram en ferdig gren etter en ubemannet kjøring. Hvor du plasserer kontrollpunktet for gjennomgang, er en menneske-i-løkken-beslutning, ikke noe du finner på etterpå.

Unngå: bare «kodegjennomgang» — det er tvetydig mellom menneskelig og automatisk gjennomgang.

Bruk:

«Jeg gjennomgikk outputen fra den ubemannede kjøringen manuelt.»

«Leste du diffen eller bare sammendraget?»

«Diffen. Sammendraget sa at den slettet død kode — det viste seg at funksjonen ble kalt fra en generert fil.»

Et arbeidsmønster der brukeren godtar agentens kode uten menneskelig gjennomgang. Diffen behandles som ugjennomsiktig — det viktige er om programmet oppfører seg riktig, ikke hva som finnes inni det. Automatisk gjennomgang og automatiske kontroller kan fortsatt kjøres; vibekoding tar ikke stilling til noen av delene.

Begrepet kommer fra Andrej Karpathy, som fant det opp tidlig i 2025: Du «gir deg helt over til vibbene» og «glemmer at koden i det hele tatt finnes» — beskriv hva du vil ha, godta det som kommer tilbake og vurder det ved å kjøre programmet.

Vibekoding bytter inspeksjon mot hastighet. Å lese differ er som regel det tregeste steget i agentdrevet arbeid, så når det fjernes, blir den viktigste flaskehalsen borte. For kode der feil er billige — prototyper, engangsskript og interne verktøy — er det en rimelig avveining. Risikoen øker med kodens levetid og konsekvensene av feil.

Kostnaden kommer senere. Vibekodede endringer hoper seg opp i en kodebase ingen har lest, og det eneste som ble kontrollert, var atferden — dermed sendes alt som atferden ikke avdekker, videre uten å bli sett, for eksempel en hemmelighet skrevet til logger, et manglende grensetilfelle eller stille feilbehandling av data. Første gang noen feilsøker systemet, er første gang noen leser koden. Når menneskelig gjennomgang er borte, er den automatiske verifikasjonen som fortsatt kjøres — tester, typer og automatisk gjennomgang — den eneste porten koden passerer. Den samme holdningen brukt på en hel kodebase, eller en del av den, der endringer kommer fra en programvarefabrikk, er en mørk fabrikk.

Unngå: «vibekoding» som synonym for «AI-koding av lav kvalitet» — begrepet beskriver holdningen til gjennomgang, ikke kvaliteten på den resulterende koden.

Bruk:

«Leste du det den endret i autentiseringsflyten?»

«Jeg vibekodet det — innloggingen fungerer fortsatt, det er alt jeg sjekket.»

«Les diffen før du sender inn. Viber du deg gjennom autentisering, kan hemmeligheter lekke inn i logger.»

Den felles forståelsen av det som bygges, som brukeren og agenten deler, men som er uavhengig av ethvert artefakt. Brooks' begrep (The Design of Design): Samtalen, overleveringsartefaktene og koden er alle artefakter som prøver å fange eller nå fram til designkonseptet, men ingen av dem er det. Kvaliteten på designkonseptet merkes gjennom kvaliteten på samtalen som utviklet det.

Begrepet setter navn på årsaken bak en velkjent frustrasjon: Agenten skriver nøyaktig det du ba om, men det er likevel feil. Den vanlige årsaken er at du ikke selv hadde funnet helt ut av hva du ville ha. Designkonseptet var ikke ferdig i ditt eget hode — prompten fanget opp delene du hadde tenkt gjennom, og var taus om delene du ikke hadde. Agenten fylte tausheten med egne antakelser fordi det ikke fantes noe å samordne seg med. Ingenting sviktet. Dere hadde ikke noe felles designkonsept, for det fantes ennå ikke et helt konsept å dele.

Du merker at et designkonsept er felles på samme måte som med en kollega: Den andre begynner å besvare spørsmål du ennå ikke har stilt, slik du selv ville gjort. Fram til da består arbeidet av samtale — grilling er den bevisste versjonen — og en spesifikasjon skrevet for tidlig fanger bare uoverensstemmelsen i et mer varig artefakt. Designkonseptet flytter seg også etter hvert som du lærer; artefaktene henger etter. Derfor kan en spesifikasjon som stemte med forståelsen forrige uke, fortsatt villede denne ukens økt.

Bruk:

«Den skriver nøyaktig det jeg ba om, men det er likevel feil.»

«Dere deler ikke et designkonsept ennå — agenten fyller hullene med antakelser. Fortsett å snakke til avbestilling, refusjoner og delvis levering henger sammen for dere begge, før du lar den skrive en spesifikasjon.»

En teknikk for å utvikle et designkonsept med en agent: Agenten intervjuer brukeren sokratisk, én beslutning om gangen, og foreslår et anbefalt svar på hver. Den bremser hastverket med å lage en ferdig plan — ingen overleveringsartefakt skrives før konseptet er stabilt.

Teknikken finnes fordi agenter fyller hull i stillhet. Når agenten blir bedt om å skrive en spesifikasjon fra en prompt på to linjer, stopper den ikke ved beslutningene du ikke har tatt — den velger standardverdier og skriver dem inn. Resultatet ser komplett ut, og gjetningene kan ikke skilles fra valgene, så du oppdager dem sent: under gjennomgangen eller når den bygde funksjonen håndterer et grensetilfelle på en måte du aldri valgte. Grilling snur dette på hodet — i stedet for å gjette må agenten spørre.

Det er en menneske-i-løkken-teknikk: Svarene dine er input. Når et spørsmål ikke kan besvares i en samtale — du må se tingen først — bytter du til prototyping.

Bruk:

«Den gikk rett i gang med å skrive spesifikasjonen og fikk logikken for avbestilling feil.»

«Grill den først — få den til å spørre om delvis avbestilling, refusjon og tidspunkt før den binder noe til dokumentet. Det er billigere å avklare i en samtale enn i kode.»

Å få agenten til å bygge en rask, grov versjon av noe når en samtale blir for upresis, og du trenger et konkret artefakt å diskutere.

Grilling avklarer designbeslutninger i samtale. Samtale er billig, men upresis: Noen spørsmål kan ikke besvares med ord — hvordan en interaksjon føles, om en API-utforming er enkel å bruke i faktisk kode, eller om layouten fungerer med reelle datamengder. Intervjuet når et spørsmål, og ditt ærlige svar er «Jeg vet ikke, jeg må se det». Etter det går diskusjonen i ring. Be heller agenten bygge tingen, se på den og komme tilbake til samtalen med et svar.

Agenter gjør det billigere å bygge, og det er det som gjør dette praktisk. En grov versjon som før tok en dag å lage, kan nå lages på minutter, så det lønner seg å gjøre det jevnlig. Det er en menneske-i-løkken-teknikk: Prototypen finnes for at du skal kunne reagere på den.

Vanligvis stopper du ikke etter én titt. Iterer med prototypen — reager, be om en endring, reager igjen — slik at hver runde avklarer enda en beslutning ut fra det faktiske artefaktet, med større presisjon enn en samtale tillater.

En prototype trenger ikke være gjennomført røff. Du kan bygge delene du faktisk evaluerer, i produksjonskvalitet, slik at komponenten eller API-en du reagerte på, kan overføres til den virkelige kodebasen når beslutningen er tatt. Derfor er prototyping viktig materiale som spesifikasjonen kan vise til.

Bruk:

«Vi har brukt en halvtime på å krangle om veiviseren skal være én side eller tre trinn.»

«Ord avgjør det ikke — få agenten til å prototype begge. Vi klikker oss gjennom dem og vet det om fem minutter.»

Utvikleropplevelse — hvor enkelt kodebasen og verktøykjeden gjør det for mennesker å utføre godt arbeid. God DX betyr raske tilbakemeldinger, tydelige feilmeldinger, dokumentasjon som svarer på spørsmålet du faktisk har, og et oppsett som virker på første forsøk. Begrepet er mye eldre enn AI-koding; i denne ordboken er det først og fremst med som kontrast til AX.

DX handler om samspillet mellom mennesket og kodebasen — ikke noe mer. Den viktigste forskjellen mellom de to målgruppene er at mennesker er tilstandsfulle, mens agenter er tilstandsløse. Et menneske lærer kodebasen én gang og tar med seg kunnskapen hver dag etterpå. Derfor er dårlig DX mulig å leve med: Folk omgår treg CI ved å samle endringer før de sender dem inn, kompenserer for manglende dokumentasjon ved å spørre i Slack én gang og håndterer forvirrende struktur ved å huske hvor ting ligger. Slike omveier hoper seg opp, og et team ender med å være produktivt i en kodebase som motarbeider dem.

Agenter møter den samme kodebasen uten at noe slikt har hopet seg opp. Fordi en agent er tilstandsløs på tvers av økter, lærer den kodebasen fra bunnen av hver gang — den har nytte av den raske testpakken og de tydelige feilmeldingene, men alt den fant ut i går, er borte hvis det ikke ble skrevet inn i miljøet, som agenten bare oppfatter gjennom verktøyresultater. Det er dette gapet AX beskriver: Det av DX som overlever når utvikleren er en agent, pluss behov mennesker ikke har, som å holde kontekstvinduet ledig.

Overlappet betyr at investering i DX ofte forbedrer AX gratis — strenge typer, raske tester og forutsigbar struktur hjelper begge. Forskjellene betyr at det ikke alltid skjer: En flott introduksjonsdokumentasjon hjelper et menneske i en uke, men ikke agenten i det hele tatt, med mindre den er tilgjengelig fra AGENTS.md.

Bruk:

«DX-en vår er grei — nyansatte blir produktive på én uke.»

«Produktive fordi noen følger dem opp den uken. Agenten får ikke den uken; mål AX separat.»

Agentopplevelse — hvor godt miljøet er tilrettelagt for at en agent skal kunne gjøre godt arbeid i en kodebase. Agentenes motstykke til DX. Når den samme agenten gjør det bra i ett repo og dårlig i et annet — samme modell, samme agentrammeverk — er forskjellen som regel AX. Førsteinnskytelsen er å skylde på modellen eller skrive om prompten; løsningen ligger oftere i repoet.

God AX har tre hoveddimensjoner:

AX og DX overlapper — gode kontroller og ryddig arkitektur hjelper begge målgrupper — men de skiller lag. Mennesker tåler taus kunnskap, treg CI og «spør Sarah om faktureringsmodulen»; agenter gjør ikke det. Agenter har ikke nytte av verktøytips i IDE-en eller pene dashbord; de trenger feil som tekst i et verktøyresultat. En kodebase kan ha god DX og dårlig AX.

Unngå: å behandle AX som synonym for DX — målgruppene trenger ulike investeringer.

Bruk:

«Agenten skriver god kode i API-repoet og elendig kode i frontend-repoet.»

«API-repoet har strenge typer og en rask testpakke; frontend-repoet har ingen av delene og førti skills som alltid lastes inn. Det er et AX-gap, ikke et modellproblem.»

Et arbeidssystem der agent-økter startes av utløsere — en sak som opprettes, en tidsplan, en CI-feil eller at en annen økt fullføres — i stedet for av et menneske, slik at mer arbeid utføres ubemannet og menneskelig oppmerksomhet brukes på menneske-i-løkken-beslutningene som står igjen.

Uten en fabrikk starter hver økt fordi noen startet den. Selv fullt ubemannet arbeid venter på at en person åpner økten, peker den mot saken og setter den i gang. Team ønsker å levere mer enn det tillater. En fabrikk fjerner mennesket fra oppstarten av økter, men ikke nødvendigvis fra alt annet.

Vanlige utløsere og øktene de starter:

En fabrikk trenger ikke å dekke hele programvareprosessen. Én cron-jobb som kjører én type økt og åpner én PR som kan gjennomgås, er en fabrikk. Det er nyttig å starte så smått: En smal løkke produserer små, lignende PR-er, og når du gjennomgår dem, ser du hvor langt du kan stole på løkken før den utvides.

Mennesker kan sitte hvor som helst i en fabrikk — skrive og merke sakene som utløser økter, godkjenne en plan før implementeringen begynner og utføre menneskelig gjennomgang før sammenslåing. Hovedspørsmålet i utformingen er hvilke av disse beslutningene som fortsatt skal tas av mennesker. En kodebase, eller en del av den, der ingen mennesker gjennomgår fabrikkens resultat, er en mørk fabrikk.

Bruk:

«Hvem rettet alle bruddene på `no-floating-promises`?»

«Fabrikken. En cron-jobb velger én lint-regel hver natt og åpner en PR. Jeg går bare gjennom den om morgenen.»

En kodebase, eller en del av den, der en programvarefabrikk skriver koden og ingen mennesker leser den. Det er ingen menneskelig gjennomgang. Mennesker kan fortsatt skrive sakene som starter arbeidet, men ingen leser koden som kommer ut. Navnet kommer fra «lights-out»-fabrikker, der produksjonen foregår uten mennesker på gulvet.

En mørk fabrikk er vibekoding for et kodeområde, ikke for én enkelt endring. Når du vibekoder, velger du å ikke lese en endring du selv har bedt om. Men du vet at endringen finnes. I en mørk fabrikk tar teamet dette valget én gang for hele området. Etterpå ber ingen om hver enkelt endring eller ser den. Endringene kommer like raskt som utløsere starter nytt arbeid.

Problemet viser seg når noe går i stykker. Du vet ikke hva som ble endret, fordi ingen leste endringene. Du må feilsøke kode ingen på teamet har lest. Årsaken kan ligge i hvilken som helst av mange endringer, og hver enkelt besto kontrollene.

Automatiske kontroller og automatisk gjennomgang er de eneste portene. Hvis de ikke finner et problem, havner problemet i koden.

Unngå: å kalle en kodebase «mørk» bare fordi fabrikken kjører uten at noen følger med. Hvis agent-økter kjøres ubemannet og et menneske gjennomgår PR-ene, er det en programvarefabrikk. Det er ikke en mørk fabrikk.

Bruk:

«Hvem endret retry-logikken i faktureringstjenesten? Ingen på teamet husker det.»

«Faktureringstjenesten er en mørk fabrikk. Agentene slår sammen alle endringer som består CI. Ingen leste den endringen.»