Ordbog for AI

Et mærkat i bevægelse, ikke en teknologi. "AI" betegner ikke en fast ting på samme måde som model eller token — det peger på det, computere netop nu kan gøre på en ny og imponerende måde. Lige nu peger det på store sprogmodeller. Tidligere har det peget på helt andre ting:

Mærkatet flytter sig gennem en kendt mekanisme, som nogle gange kaldes AI-effekten: Når en teknik virker pålideligt, får den et nyt navn — det er "bare" søgning, "bare" statistik — og "AI" glider videre til det næste uløste problem. Iagttagelsen er gammel. Bertram Raphael formulerede det sådan i 1971: "AI er en fællesbetegnelse for problemer, som vi endnu ikke ved, hvordan man løser ordentligt med en computer." Larry Teslers version fra omkring 1979: "Intelligens er alt det, maskiner endnu ikke har gjort."

Det er derfor, samtaler om AI så ofte går forbi hinanden. En påstand som "AI kan ikke ræsonnere" eller "AI er hypet for meget" har et skjult tidsstempel — den kan handle om ekspertsystemer, billedklassifikatorer fra 2010'erne eller sidste måneds LLM, og hvert eksempel støtter en forskellig konklusion. Når en samtale om AI går i stå, er løsningen som regel at erstatte ordet med det præcise begreb, der menes: modellen, agentrammen, agenten, den kontekst, den fik.

Undgå: "AI" i tekniske påstande — nævn den del, du mener. "AI-kodning" som navn på praksissen er fint; "AI'en hallucinerer" er ikke.

Brug:

"CTO'en vil vide, om AI kan håndtere triagekøen."

"Oversæt det, før du afgrænser opgaven — hun mener en LLM i en agentramme med adgang til ticketsystemet. 'AI' alene er ikke en specifikation."

Parametrene. Tilstandsløs — foretager forudsigelse af næste token og intet andet. "Claude Opus 4.x" og "GPT-5.x" er modeller. En model kan ikke i sig selv handle som en agent; den skal have en agentramme.

Modeller kan ikke læse filer, køre kommandoer, søge på nettet eller huske i går — de modtager tokens og forudsiger tokens som output én gang pr. forespørgsel til modeludbyderen. Alt det, der føles som en agent, der arbejder — vælger værktøjer, læser resultater og gentager processen, indtil opgaven er løst — er agentrammen, der orkestrerer mange sådanne forudsigelser efter hinanden.

Modeludbydere tilbyder modeller i forskellige størrelser: en stor, der er klogest, men langsom og dyr, og mindre, der er hurtigere og billigere, men mindre kapable. Valget af størrelse er en reel beslutning — den tunge model til planlægning og vanskelig fejlsøgning, den lette til mekaniske ændringer — og agentrammer lader dig skifte midt i en session.

En præcis brug af ordet gør det også lettere at finde årsagen. "Modellen er dårlig til det her" er en konkret påstand — den samme model i en anden agentramme eller med en anden kontekst opfører sig ofte helt anderledes. Før du giver modellen skylden, så undersøg, hvad den fik at arbejde med: Det meste skuffende output skyldes konteksten eller agentrammen, ikke parametrene.

Brug:

"Skal vi skifte modellen fra Sonnet til Opus til planlægningen?"

"Prøv det — men agentrammen gør det meste af arbejdet i den her opgave. Et modelskifte hjælper ikke, hvis systemprompten og værktøjerne er forkerte."

Tallene inde i en model — ofte milliarder af dem — som justeres under træningen. Alt det, modellen "ved", ligger i dem. Træningen fastlægger dem; inferens bruger dem uændret. De kaldes også vægte.

Mekanisk set er det parametrene, der omdanner input til output. Forudsigelse af næste token er en enorm beregning: tokens i kontekstvinduet sendes ind, multipliceres gennem parametrene, og der kommer en forudsigelse af det næste token ud. Der ligger ingen database med fakta inde i modellen og ingen opslagstabel med kode — kun disse tal, arrangeret sådan, at beregningen som regel frembringer nyttigt output. Fakta, modellen kan gengive fra træningen, som et API til et standardbibliotek, er parametrisk viden: lagret i parametrene, ikke hentet nogetsteds fra.

Den detalje, der er værd at huske, er, at parametrene er låst efter træningen. Intet, du gør i en session, ændrer dem — hverken en rettelse, du giver, en kodebase, du viser modellen, eller en fejl, den lærer af. Hver session bruger de samme tal. Derfor er modellen tilstandsløs, dens indbyggede viden stopper ved vidensskæringsdatoen, og alt projektspecifikt skal komme ind via konteksten. Parametrene ændres kun ved mere træning — hvilket i praksis giver en anden model.

Brug:

"Kan vi finjustere den på vores kodebase?"

"Det ville opdatere parametrene — bagefter har du en anden model. Til ét projekt er det næsten altid billigere at indlæse kodebasen som kontekst end at træne modellen igen."

Den proces, der fastlægger en models parametre, ved at udsætte den for enorme mængder tekst og justere parametrene, så forudsigelsen af næste token bliver bedre. En dyr proces, der udføres én gang af modeludbyderen. Den omfatter både fortræning (hovedforløbet) og eftertræning (senere forbedringer som instruktionsefterfølgning og sikkerhed); den forskel er ikke vigtig på dette ordlistes niveau.

Mekanismen er gentagelse i stor skala: Vis modellen et tekststykke, få den til at forudsige det næste token, skub parametrene i retning af det faktiske næste token, og gentag processen på tværs af billioner af tokens. Intet gemmes som fakta eller regler — alt det, modellen "ved", er en følge af, at den er blevet bedre til at forudsige, og er komprimeret ind i parametrene som parametrisk viden.

To konsekvenser har betydning i hverdagen. Træningen slutter på et bestemt tidspunkt, så modellen har en vidensskæringsdato — den har ikke set den biblioteksversion, du opgraderede til i sidste måned. Og du kan ikke selv træne den: Når modellen ikke kender din kodebase, dine konventioner eller dine interne API'er, er løsningen aldrig "lær modellen det" — materialet skal i stedet ind i konteksten, det eneste input, du kan styre.

Brug:

"Kan vi få den til at kende vores interne API?"

"Ikke gennem træning — det er en proces, der tager modeludbyderen flere måneder. Indlæs API-dokumentationen i konteksten i stedet; det er det håndtag, du faktisk har."

At køre en trænet model for at generere output — det, der sker ved hver forespørgsel til modeludbyderen. Parametrene forbliver uændrede; modellen laver blot forudsigelse af næste token ud fra den kontekst, den får. Det er billigt sammenlignet med træning, men afregnes pr. token og udgør den største omkostning ved at bruge en model.

En models levetid falder i to faser:

Intet af det, du gør under inferens, skrives tilbage til parametrene — derfor hænger en rettelse, du giver i dag, ikke ved i morgen. Modellen, der begår den samme fejl i næste session, efter at du omhyggeligt forklarede rettelsen, har ikke overhørt dig; den kan ikke lære af udvekslingen. Modellen er tilstandsløs — kontinuiteten skal komme udefra, fra kontekstvinduet eller et hukommelsessystem.

Denne mekanisme forklarer også din regning. Hver forespørgsel kører modellen på hele konteksten, så prisen vokser med inputtokens og outputtokens, og en agent, der laver snesevis af værktøj-kald, betaler for inferens ved hver rundtur. Derfor er kontekststørrelsen både et spørgsmål om pris og kvalitet.

Brug:

"Hvorfor følger regningen forbruget i stedet for at være en fast licens?"

"Du betaler for inferens — hver forespørgsel til modeludbyderen kører modellen på udbyderens hardware. Træningen er allerede udført, men inferensomkostningerne løber pr. forespørgsel, og én tur kan blive til mange forespørgsler, når der kaldes på værktøjer."

Effort er en skala for, hvor meget ræsonnering en model udfører, før den svarer. Indstillingen gælder per modeludbyderforespørgsel og styrer, hvor længe modellen tænker, før den begynder at skrive det svar, du ser. Tænkningen genereres under inference ligesom alt andet; agentrammen skjuler den ofte, men det er reelt arbejde, modellen udfører.

Højere effort koster mere og tager længere tid. Ræsonneringen afgives som tokens, faktureres som outputtokens, selvom du aldrig ser dem, og produceres én token ad gangen — så højere effort forlænger ventetiden og øger regningen. Det er en afvejning mellem mere overvejelse, hastighed og pris.

De fleste agentrammer viser effort som en kort skala:

Det går galt på begge måder. Sæt effort for lavt på et svært problem, og du får et selvsikkert, overfladisk svar, der sprang den nødvendige ræsonnering over — det ser fint ud, men er forkert på en måde, der koster dig senere. Sæt det på max til en omdøbning på én linje, og du venter længe på tænkning, der ikke giver noget, laveste niveau ikke kunne have leveret.

Tilpas effort til opgaven, ikke sessionen. Skru op for den del, der virkelig er svær at ræsonnere over, og ned igen for rutinearbejdet omkring den.

Brug:

"Den bliver ved med at ødelægge denne concurrency-rettelse — jeg har forklaret det tre gange."

"Skru effort op. Det er en fejl, der kræver meget ræsonnering, og på standardniveauet tænker den ikke længe nok, før den vælger en tilgang."

Den mindste enhed, en model læser og skriver. Den svarer nogenlunde til et ord, men ikke helt — almindelige ord er ét token, mens sjældne eller lange ord deles i flere. Størrelsen på kontekstvinduet, prisen og forsinkelsen måles alle i tokens.

Tekst bliver til tokens gennem en tokenizer: et fast ordforråd på titusindvis af fragmenter, indlært før træningen, som deler ethvert input op i en sekvens af ordforrådets elementer. Modellen ser aldrig tegn eller ord — al tekst omdannes til tokens på vej ind, og forudsigelse af næste token frembringer output ét token ad gangen på vej ud.

En tommelfingerregel er, at et token svarer til omtrent tre fjerdedele af et engelsk ord, så tusind tokens er cirka 750 ord. Kode er mindre forudsigelig: almindelige nøgleord og idiomer tokeniseres kompakt, mens genererede identifikatorer, hasher, base64-blokke og minificeret output deles i mange tokens pr. "ord". Mønsteret er, at tekst, der ofte forekom i tokenizerens kildemateriale, får korte, effektive kodninger; tekst, der ikke gjorde, skæres i mange små dele. En hash som `a3f9c2e1` har aldrig optrådt nogen steder og deles derfor i mange tokens, mens `function` er ét. Derfor kan en fil, der ser lille ud, men er fuld af usædvanlige strenge, optage en overraskende stor del af kontekstvinduet.

Tokens er den enhed, alt andet måles i. Prisen er pr. token — udbyderne afregner inputtokens og outputtokens hver for sig. Hastighed måles i tokens pr. sekund, fordi output genereres ét token ad gangen. Og kontekstvinduet har plads til et fast antal tokens, så tokenantallet i dine filer afgør, hvor meget der kan være der.

Undgå: "ord" — token-grænser følger ikke ordgrænser, og tokens pr. sekund / tokens pr. krone er de relevante måleenheder.

Brug:

"Hvor stort bliver den her prompt?"

"Kør den gennem tokenizer'en — skemaet er kompakt, men JSON-nøglerne er mærkelige, så de deles i flere tokens, end du tror."

Det, modellen faktisk gør. Givet en kontekst udvælger den ét næste token, føjer det til og kører igen. Alt output — en sætning, et værktøjskald, en fil på tusind linjer — bygges ét token ad gangen. Modellen har ingen anden måde at fungere på.

Hvert trin foregår på samme måde: Tokens i kontekstvinduet køres gennem parametrene, som giver en sandsynlighed for hvert token i ordforrådet — dette token er meget sandsynligt som det næste, et andet mindre sandsynligt. Ét token udvælges blandt sandsynlighederne, føjes til, og løkken kører igen med den lidt længere kontekst. Udvælgelsen er årsagen til, at den samme prompt giver forskelligt output fra gang til gang: Ikke-determinisme er indbygget i mekanismen, ikke en fejl ovenpå den.

Når man holder fast i denne mekanisme, giver adfærd, der ellers virker mærkelig, mening. Modellen kontrollerer aldrig, om et token er sandt, før den udsender det — kun om det er sandsynligt — og det er roden til hallucinationer. Den binder sig til hvert token, efterhånden som det kommer, så en selvsikker indledende sætning kan føre resten af svaret i den forkerte retning. Og fordi outputtokens produceres strengt ét ad gangen, sætter genereringshastigheden en nedre grænse for, hvor hurtigt en agent kan arbejde.

Brug:

"Hvordan 'beslutter' agenten sig for at kalde et værktøj?"

"Det gør den ikke — det er forudsigelse af næste token hele vejen ned. Værktøjskaldet er blot en struktureret streng, som agentrammen parser ud af outputstrømmen."

Det samme input kan give forskelligt output. Kør en model to gange med identisk kontekst, og du kan få to forskellige svar — nogle gange et enkelt ord, andre gange en helt anden fremgangsmåde. For at det kan ske, behøver der ikke at blive ændret noget i din kode.

Det er en egenskab ved den måde, modeller genererer tekst på, og den måde, modeludbydere håndterer forespørgsler på. Under inferens danner modellen en sandsynlighedsfordeling over mulige næste tokens, og ét af dem udvælges — som regel med en vis tilfældighed med vilje, for altid at vælge det mest sandsynlige token giver gentagende tekst af lavere kvalitet. Ét token, der udvælges anderledes tidligt i et svar, ændrer hvert efterfølgende token; sådan kan ét andet ord blive til en helt anden fremgangsmåde. Håndteringen på udbydersiden bidrager også med variation: Forespørgsler samles i batches på delt hardware, og små flydende kommaforskelle mellem batches kan tippe et tæt valg fra ét token til et andet. Der findes ingen indstilling, du kan slå til for at få det hele til at forsvinde.

Forvent variation i agentens svar på den samme opgave. De fleste svar ligger inden for en rimelig normalfordeling for kvalitet — derfor er den manglende determinisme overhovedet til at leve med — men yderpunkterne findes: Nogle dage virker modellen skarp; andre dage virker det, som om den har mistet overblikket. Samme opgave, forskellige terningkast. Det har to praktiske konsekvenser. Det er en legitim strategi at prøve igen: Et mislykket forsøg er ét træk fra fordelingen, og et nyt forsøg på samme opgave kan ganske enkelt ramme bedre. Og verifikation betyder mere end med deterministiske værktøjer — du kan ikke teste en agents adfærd én gang og regne med, at den gentager den, så automatiske kontroller må fange de dårlige udfald.

Pas på med at lægge for meget fortælling i det. Mennesker er mønstergenkendende væsner, og en række dårlige kørsler kan føles som bevis på, at "modellen blev dårligere i denne uge". Som regel skyldes det bare fordelingen.

Brug:

"Claude har været elendig i dag. Har de udgivet en dårligere version?"

"Sandsynligvis ikke — modeloutput er ikke-deterministisk. Du vil opleve gode og dårlige dage med den samme opgave. Prøv igen i morgen, før du leder efter en årsag."

Det, der leverer en model til inferens. Som regel en ekstern tjeneste (Anthropic, OpenAI, Google), men det kan også være lokalt — Ollama, LM Studio eller llama.cpp på din egen maskine. Agentrammen kører ikke selv modellen; den beder en udbyder om at gøre det.

Udbyderen ejer maskineriet: Parametrene ligger på dens hardware, og hver forespørgsel til modeludbyderen er agentrammen, der sender tokens over netværket og modtager forudsigelser retur. Derfor er udbyderen kilden til en hel kategori problemer, der ofte fejlagtigt tilskrives modellen eller agentrammen — hastighedsgrænser, nedsat kapacitet og driftsafbrydelser hører alle til her. Når agenten går i stå midt i en session eller fejler på hver tur, bør udbyderens statusside være noget af det første, du kontrollerer.

Udbyderen fastlægger også de kommercielle vilkår: prisen pr. token for input og outputtokens, rabatter via præfikscachen, og hvilke modeller der overhovedet er tilgængelige. Bemærk, at udbyderen og modellens producent kan være forskellige virksomheder — Bedrock, Vertex og OpenRouter leverer andres modeller.

Lokale udbydere bytter kapacitet for kontrol: Modellerne, der kan køre på din egen hardware, er langt mindre end de førende modeller, men intet forlader maskinen, og der er ingen regning pr. token.

Brug:

"Kan vi køre det her offline for klienten med et isoleret netværk?"

"Skift til en lokal modeludbyder — Ollama eller llama.cpp på deres maskine. Agentrammen er ligeglad; den sender bare forespørgslen til et andet endepunkt."

Alt omkring modellen, der gør den til en agent: værktøjer, systemprompt, styring af kontekstvinduet, rettigheder, hooks. Claude.ai og Claude Code bruger samme model, men opfører sig forskelligt, fordi deres agentrammer er forskellige.

Modellen gør kun én ting: tager tekst ind og giver tekst ud. Den kan ikke læse en fil, køre en kommando eller huske sidste tur. Agentrammen leverer alt det. Den samler konteksten til hver modeludbyderforespørgsel, udfører de værktøjskald, modellen beder om, sender værktøjsresultaterne tilbage, gemmer sessionens historik, spørger dig om tilladelse før risikable handlinger og beslutter, hvornår der skal kompakteres. Agentløkken — modellen foreslår, agentrammen udfører, gentag — drives af agentrammen.

Dette er vigtigt for fejlsøgning. Når adfærden er forskellig mellem to produkter eller fra i går til i dag, er modellen ofte ikke variablen — agentrammen er. En anden systemprompt, andre værktøjer, ændret standard for rettigheder eller en ny strategi for kontekststyring ændrer alt sammen adfærden uden at ændre modellen. Det betyder også, at det meste af din konfiguration ligger i agentrammen: AGENTS.md-filer, rettighedsindstillinger og hooks er instruktioner til agentrammen, ikke modellen.

Eksempler: Claude Code, Cursor, Codex CLI — og Claude.ai, der er en chat-agentramme, ikke en coding-agentramme.

Brug:

"Samme model, hvorfor redigerer Claude Code filer, mens Claude.ai bare besvarer spørgsmål?"

"Forskellige agentrammer — Claude Code har filsystem-værktøjer, en anden systemprompt og et rettighedslag. Modellen er ikke variablen her."

Én rundtur fra agentrammen til modeludbyderen. Agentrammen sender den aktuelle kontekst; udbyderen returnerer ét svar (et værktøjskald eller et endeligt svar). En enkelt brugerbesked kan udløse mange forespørgsler til modeludbyderen, hvis agenten kalder på værktøjer — hvert værktøjsresultat udløser endnu en forespørgsel.

Hver forespørgsel indeholder det hele: systemprompten, hele samtalen indtil nu og alle værktøjsresultater. Modellen er tilstandsløs, så udbyderen gemmer intet mellem forespørgslerne — forespørgsel fyrre sender det, der blev sendt i forespørgsel niogtredive, igen sammen med endnu et værktøjsresultat. Præfikscachen gør denne gentagelse billigere.

Forespørgslen er også afregningsenheden. Inputtokens, outputtokens og cacherabatter tælles alle pr. forespørgsel. Derfor kan et tilsyneladende uskyldigt spørgsmål koste overraskende meget: Prisen er ikke proportional med din besked, men med antallet af forespørgsler gange størrelsen på den kontekst, hver af dem indeholder.

Det er værd at holde forespørgslen adskilt fra turen. En tur er én udveksling med dig, og en enkelt tur — "ret den fejlslagne test" — udfolder sig som en kæde af forespørgsler:

Seks forespørgsler i én tur — hver enkelt sender hele konteksten igen. Når du undrer dig over, hvor tokens blev af, så tæl forespørgslerne, ikke turene.

Brug:

"Brændte ét spørgsmål fyrre tusind tokens?"

"Se på værktøjskaldene — tolv grep, otte læsninger, fire ændringer. Hvert værktøjsresultat udløser endnu en forespørgsel til modeludbyderen, og hele sessionens præfiks sendes igen hver gang."

Tokens, som agentrammen sender ved hver forespørgsel til modeludbyderen — systemprompten, samtalehistorikken, værktøjsresultaterne, alt det, modellen læser, før den skriver. De faktureres til en lavere pris end outputtokens, fordi de er billigere at behandle end outputtokens.

Når du koder med AI, udgør inputtokens det meste af regningen. Modellen er tilstandsløs, så hver tur sender hele sessionen igen som input: din første besked, hvert svar og hvert værktøjsresultat siden. Inputtet for tur halvtreds indeholder de foregående niogfyrre ture. Én forespørgsel til modeludbyderen kan producere nogle få hundrede outputtokens, men sende hundrede tusind inputtokens med den ophobede historik igen.

Præfikscachen sænker prisen: Historik, der matcher en tidligere forespørgsel nøjagtigt, faktureres som billige cachetokens i stedet for input til fuld pris. Når input stadig er dyrt, er løsningen at mindske det, der sendes igen — ryd eller komprimér mellem opgaverne.

Brug:

"Regningen er høj, men agenten skriver næsten ingenting."

"Det er inputtokens — hver tur sender hele sessionen igen. Uden præfikscachen betaler du for historikken igen ved hver forespørgsel."

Tokens, som modellen genererer. De faktureres til en højere pris end inputtokens — typisk omkring fem gange så højt — fordi de kræver mere regnekraft at producere.

Alt det, modellen skriver, tæller: Prosaen, du læser, koden, den udsender, værktøjskald og eventuelle udvidede ræsonnementer, modellen foretager, før den svarer. Det sidste overrasker folk — ræsonnementstokens faktureres som output, selv når agentrammen ofte ikke viser dem, og en højere indsats bruger flere af dem.

Outputtokens sætter også tempoet for en session. Modellen læser input hurtigt, men genererer output ét token ad gangen, så når en tur føles langsom, skyldes det næsten altid, at outputtet bliver skrevet, ikke at inputtet bliver læst. En lang ventetid betyder som regel, at et langt svar er på vej.

Brug:

"Refaktoreringssessionen bruger kredit, selvom inputtene er små."

"Agenten omskriver hele filer i stedet for at lave rettelser. Outputtokens koster omtrent fem gange inputprisen — få den til at udsende redigeringer, så falder regningen."

Lageret på udbydersiden, der gør det muligt for efterfølgende forespørgsler til modeludbyderen at springe over genbehandlingen af et fælles præfiks. Når begyndelsen af en forespørgsel matcher begyndelsen af en nyere forespørgsel — samme systemprompt, samme historik frem til et bestemt punkt — genbruger udbyderen det tidligere arbejde og afregner de tokens til en meget lavere pris som cachetokens.

Cachen kan betale sig, fordi sessioner vokser ved at føje nyt til. Hver forespørgsel sender hele historikken igen som inputtokens (se den post for forklaringen), og i en normal session ændres historikken kun til sidst — hver forespørgsel består af den forrige plus nogle få nye beskeder. Udbyderen behandler den lange fælles begyndelse én gang, gemmer resultatet og fortsætter fra dér, hvor præfikset slutter. Uden cachen skulle en session på 50 ture betale for at genbehandle første tur halvtreds gange.

Cacher udløber også. Hvor længe en post forbliver varm, varierer mellem modeludbydere — typisk minutter, ikke timer. Hvis sessionen står stille længere end vinduet, genopbygges præfikset til fuld pris ved næste forespørgsel, før cachelagringen genoptages. Det er først og fremmest relevant for dem, der bygger agentrammer; som bruger mærker du, at forespørgsler efter en lang pause koster mere end dem før pausen.

Brug:

"Hvorfor steg regningen pludselig midt i sessionen?"

"Agentrammen begyndte at føje det aktuelle klokkeslæt til systemprompten ved hver tur. Præfikscachen bryder ved det første ændrede token, så alle efterfølgende forespørgsler blev afregnet til fuld pris."

Inputtokens, som udbyderen har cachelagret fra en tidligere forespørgsel til modeludbyderen, så den ikke behøver at behandle dem igen. Når to forespørgsler efter hinanden deler et præfiks, genbruger udbyderen arbejdet via sin præfikscache og afregner den cachelagrede del til en meget lavere pris. Det er håndtaget, der gør lange sessioner overkommelige — uden det betaler hver tur igen for hele historikken.

Det er vigtigt på grund af måden, sessioner faktureres på. Modellen er tilstandsløs, så hver forespørgsel sender hele samtalen igen — systemprompten, hver besked og hvert værktøjsresultat — som inputtokens. Ved tur halvtreds indeholder hver forespørgsel historik fra halvtreds ture, og du ville betale fuld pris for det hele hver gang. Cachen ændrer regnestykket: Tokens, som udbyderen allerede har behandlet i et identisk præfiks, faktureres som cachetokens, ofte til en tiendedel af inputprisen eller mindre. I en lang session er det meste af det, du sender, cachetokens, og regningen forbliver til at betale.

Et eksempel viser, hvornår tokens cachelagres, og hvornår de ikke gør. Hvert bogstav repræsenterer en blok samtaleindhold; hver forespørgsel sender samtalen indtil da:

Cachen er skrøbelig på én bestemt måde: Den matcher nøjagtige præfikser. Hvis noget ændres tidligere i samtalen — agentrammen omrokerer indhold, et tidsstempel opdateres, eller en fils repræsentation ændres — misser cachen fra det punkt og frem, og alt efter det faktureres til fuld inputpris. Cacher udløber også efter nogle få minutters inaktivitet, så en session, der genoptages efter en lang pause, betaler for historikken igen én gang. Når prisen for en session stiger uden nogen åbenlys grund, kan du sammenligne cachetokens med inputtokens i forbrugsrapporten — en cache, der er brudt, kan ses dér først.

Brug:

"Lange sessioner er brutalt dyre — otte dollar for en refaktorering."

"Kontrollér cachetokens. Hvis agentrammen omrokerer systemprompten eller filerne mellem ture, brydes præfikset, og du betaler fuld inputpris igen ved hver forespørgsel."

Fører ingen information videre. Modellen er stateless på tværs af modeludbyderforespørgsler — hver forespørgsel sender hele kontekstvinduet igen, fordi modellen ikke kan se noget andet. En agent er som standard stateless på tværs af sessioner: En ny session starter tom uden spor af tidligere sessioner. Modstykke til stateful.

Modellen selv er permanent stateless: Dens parametre er fastlåst efter træning, og intet, du gør under inference, ændrer dem. Modellen lærer ikke af dine rettelser, husker ikke, at den fik samme besked i går, og lærer dig ikke at kende — uanset hvor meget samtalen ellers føles sådan. Følelsen af kontinuitet i en session skabes af agentrammen, der gemmer transskriptionen og sender den igen med hver forespørgsel. Modellen husker ikke samtalen; den læser den igen.

Den praktiske konsekvens: Hvis du vil have noget husket på tværs af sessioner, skal du skrive det ned et sted, agenten læser igen. Det er, hvad AGENTS.md-filer, hukommelsessystemer og overdragelsesartefakter er — filer, der indlæses i fremtidige sessioners kontekst og udfylder den hukommelse, modellen ikke har. Bliver agenten ved med at lave en fejl, du tidligere har rettet, er spørgsmålet ikke, hvorfor den ikke lærte — det kan den ikke — men hvor rettelsen skal skrives, så hver fremtidig session læser den.

Brug:

"Hvorfor glemmer den konventionen, hver gang jeg rydder?"

"Modellen er stateless — den nye session starter tom. Hvis konventionen skal med videre, så skriv den i AGENTS.md eller en hukommelsesfil, som agentrammen indlæser ved sessionsstart."

De relevante oplysninger, som agenten har adgang til lige nu. Det abstrakte navneord — ikke det rå input, modellen ser (det er kontekstvinduet), ikke den løbende historik (det er sessionen), men det, agenten ved, og som er relevant for opgaven. "At indlæse noget i konteksten" betyder at føje det til denne mængde; "kontekstarbejde" er disciplinen med at udvælge og organisere den.

De tre begreber kan adskilles klart:

Skellet er vigtigt, fordi kontekst måler kvalitet, ikke mængde. Et kontekstvindue kan være næsten fuldt, mens konteksten stadig er dårlig — tusindvis af tokens med forældede værktøjsresultater, hvoraf ingen handler om den aktuelle opgave. Det kan også være næsten tomt og samtidig have fremragende kontekst: den ene typedefinition, som opgaven afhænger af.

De fleste daglige fejl kan spores tilbage til konteksten. Når agenten finder på et API, modsiger en beslutning eller gætter på et skema, er det første spørgsmål, hvad der var i konteksten, da den gjorde det — som regel blev den relevante oplysning aldrig indlæst eller lå begravet under forringelse af opmærksomheden. Løsningen er udvælgelse: Indlæs det, opgaven kræver, og hold resten ude.

Brug:

"Den bliver ved med at finde på felter, som ikke findes i typen."

"Typefilen er ikke i konteksten — den læser kaldestederne og gætter. Læs definitionen ind først."

Alt, hvad modellen ser ved hver forespørgsel til modeludbyderen. Begrænset, modelspecifikt og den eneste flade, hvorigennem modellen opfatter noget.

Det er én enkelt sekvens af tokens: systemprompten, samtalen indtil nu og hvert værktøjsresultat, som agentrammen har sendt tilbage. Hvis noget indgår i sekvensen, kan modellen bruge det; hvis ikke, ved modellen ikke, at det findes — hverken din kodebase, filen, du redigerede i går, eller instruktionen fra tre sessioner siden. Alt uden for vinduet skal bringes ind, som regel via et værktøjskald, før det kan få betydning.

Vinduet er begrænset, fordi det bliver fyldt op. Hver tur føjer mere til — dine beskeder, modellens svar og værktøjsresultater — og en lang session rammer til sidst grænsen, så komprimering eller rydning bliver nødvendig. Det betyder også, at alt i vinduet konkurrerer: Hvert token, du indlæser, efterlader ét mindre til resten, og indhold, du ikke havde brug for, optager stadig noget af modellens opmærksomhedsbudget. I praksis bør vinduet behandles som et budget: Indlæs det, opgaven kræver, og udelad resten.

Undgå: "hukommelse" — kontekstvinduet er arbejdsstatus og bevares ikke på tværs af sessioner. Hukommelse er et separat begreb, der ligger ovenpå.

Brug:

"Kan jeg ikke bare indsætte hele monorepoet i prompten?"

"Kontekstvinduet rummer 200.000 tokens — måske en femtedel af repoet. Vælg de filer, opgaven berører, og lad resten ligge bag et værktøjskald."

Fører information videre. En session er stateful på tværs af ture — konteksten ophobes, mens sessionen kører, og derfor glider lange sessioner ind i den dumme zone. En agent kan gøres stateful på tværs af sessioner ved at tilføje et hukommelsessystem, der gemmer oplysninger i miljøet og indlæser dem igen ved starten af fremtidige sessioner. Modellen er aldrig stateful; enhver tilsyneladende kontinuitet skyldes, at agentrammen sender konteksten igen. Modstykke til stateless.

Hvor state findes på hvert lag:

Hvert lags statefulness skabes ved at læse noget igen, der er gemt et lag nedenunder: Sessionen føles sammenhængende, fordi agentrammen sender beskedhistorikken til den stateless model igen; agenten husker på tværs af sessioner, fordi agentrammen genindlæser filer fra miljøet. Der gemmes aldrig state i modellen selv.

State er ikke altid ønsket. Alt, der føres videre, påvirker det næste, så en forkert antagelse tidligt i sessionen føres også videre. Rydning er den bevidste handling at smide sessionens state væk og starte fra det, der er skrevet ned.

Brug:

"Den huskede mine præferencer fra i går — betyder det, at modellen lærte dem?"

"Nej, agenten er stateful, fordi agentrammen skrev dem i en hukommelsesfil og indlæste den igen ved sessionens start. Modellen selv så intet fra i går."

En model, der er sat i en agentramme med værktøjer, en systemprompt og et kontekstvindue, og som tager ture med en bruger. Claude Code er en agent. Cursor er en agent. Claude.ai er en agent. En agent er den, du faktisk taler med — modellen i arbejde, konfigureret til et formål.

I modsætning til de fleste begreber i denne ordbog betegner "agent" ikke en mekanisk del. Modellen er en fil med parametre; agentrammen er software, du kan pege på noget. Agenten er ingen af delene — det er enheden, du taler med. Folk menneskeliggør AI hele tiden, og agenten er den menneskeliggjorte enhed: den, du uddelegerer til, den, der læser din besked og svarer, "den" i "den ødelagde builden igen". Når du siger, at agenten gjorde noget, mener du, at modellen sammen med agentrammen gjorde det, men du omtaler kombinationen som én aktør.

Idéen er ældre end denne bølge af AI. Softwareagenter — programmer, man uddelegerer et mål til, og som handler på ens vegne — har været et begreb lige så længe som AI.

Undgå: "AI'en", "botten" (for uklart — det skjuler, om du mener parametrene eller den indrammede model).

Brug:

"Hvilken agent bruger du til migreringen?"

"Claude Code lokalt, Cursor til UI-arbejdet — samme model nedenunder, forskellige agentrammer."

De instruktioner, agentrammen føjer foran hver forespørgsel til modeludbyderen — agentens stående opgavebeskrivelse: hvem den er, hvordan den skal opføre sig, hvilke værktøjer den må kalde, og hvilke konventioner den skal følge. Den er som regel stabil gennem en session.

Systemprompten skrives af leverandøren af agentrammen, ikke af dig, og i kode-agentrammer er den stor — ofte titusindvis af tokens med adfærdsregler, værktøjsbeskrivelser og håndtering af særlige tilfælde, alt sammen afregnet som inputtokens ved hver tur. Dine egne stående instruktioner følger med: Filer som AGENTS.md indlæses ved siden af systemprompten ved sessionens start, så modellen læser både leverandørens og dine instruktioner, før den overhovedet ser din besked.

Fordi systemprompten er identisk i hver forespørgsel, danner den begyndelsen på præfikscachen — blandt andet derfor holder agentrammer den fast gennem en hel session i stedet for at redigere den løbende.

Modeller trænes til at prioritere systemprompten over brugerbeskeder. Så når en agent insisterer på en konvention, du aldrig har bedt om, eller bliver ved med at formatere output på en bestemt måde, skyldes det som regel, at den følger sin systemprompt — og at din besked taber diskussionen. Nogle agentrammer kan tilpasses: De giver dig fuld adgang til systemprompten, så du kan læse, hvad agenten faktisk får besked på, og ændre det.

Brug:

"To agentrammer, samme model, helt forskellig adfærd på samme prompt."

"Forskellige systemprompter. Den ene er indstillet til korte kodeændringer, den anden til forklaringer — forskellen opstår dér, før din besked overhovedet kommer frem."

Én afgrænset omgang interaktion med en agent. Den begynder tom, samler beskeder, værktøjsresultater og indlæste filer og slutter, når den bliver ryddet, lukket eller komprimeret til en ny session. Det er sessionen, der fylder kontekstvinduet: Hvis kontekstvinduet er kassen, er sessionen det, der langsomt fylder den. Arbejde, der er for stort til ét kontekstvindue, må deles op på flere sessioner.

Sessionens beskedhistorik er agentens arbejdshukommelse. Modellen er tilstandsløs, så alt det, den ser ud til at huske — hvad du bad om, hvad testene viste, og hvad den besluttede for tre ture siden — ligger i beskedhistorikken, som sendes igen ved hver forespørgsel til modeludbyderen. Det, der ikke er i sessionen, findes ikke for agenten.

Den hukommelse ophører med sessionen. En ny session starter fra nul: Agenten, der kendte din kodebase godt ved gårsdagens slutning, kender intet til den her til morgen. Det, der overlever, er filsystemet — filer, der skrives i én session, kan læses i den næste, og det er det, overleveringer, hukommelsessystemer og AGENTS.md bygger på.

Du vælger, hvor en session slutter. Alt i en session påvirker alle senere ture, så uvedkommende opgaver i samme session efterlader rester, der farver det næste svar. Én opgave pr. session holder konteksten relevant; når en opgave er afsluttet, er det naturligt at rydde den.

Brug:

"Hvor længe kan én session køre, før den falder fra hinanden?"

"Det afhænger af arbejdet — en fokuseret refaktorering holder sig skarp længere end åben forskning. Når sessionen svulmer op, så lav en overlevering eller komprimér den; pres ikke bare videre."

Én brugerbesked plus alt det, agenten gør som svar, indtil den giver ordet tilbage til dig. Den indeholder én eller flere forespørgsler til modeludbyderen — mange, hvis agenten kalder på værktøjer. Et opklarende spørgsmål afslutter turen; dit svar åbner den næste. Hierarkiet er session > Tur > Forespørgsel til modeludbyderen.

Det særlige ved turen er, at dens længde bestemmes af agenten, ikke af dig. Du giver én besked; agenten beslutter, hvor mange værktøjskald den kæder sammen, før den giver ordet tilbage. En tur kan være et svar på én sætning eller tyve minutters læsning, redigering og testkørsel. Det er samme egenskab set fra to vinkler: Lange ture gør AFK-arbejde muligt, og lange ture er også dér, ting går galt uden opsyn — når agenten til sidst giver ordet tilbage, kan den være drevet langt væk fra det, du mente.

Turen er også den naturlige enhed til at styre arbejdet. Alt inden for en tur sker uden dig; pauserne mellem turene er dér, du kan ændre retning. De fleste agentrammer gør det mindre stift: Du kan afbryde midt i en tur for at standse agenten og give den nye instruktioner, eller skrive en besked, mens den arbejder, som den læser, når turen er slut. Hvis du gentagne gange er utilfreds med, hvor turene ender, er løsningen som regel at bede om kortere ture — først en plan, derefter ét skridt ad gangen — så du bytter selvstændighed for hyppigere muligheder for at styre.

Brug:

"Tog én tur to minutter?"

"Den lavede fjorten værktøjskald i løbet af turen — hvert af dem er en separat forespørgsel til modeludbyderen. Forsinkelserne lægger sig oven i hinanden, før agenten endelig giver ordet tilbage til dig."

Den verden, agenten handler i — alt uden for agentrammen, som agenten opfatter gennem værktøjsresultater og ændrer gennem værktøjskald. Agentrammen kører agenten; miljøet er det, agenten arbejder i. En fil som `AGENTS.md` befinder sig i miljøet; agentrammen indlæser den i kontekstvinduet. Et filsystem er den mest almindelige type miljø, men ikke den eneste (en database, et eksternt API eller en browsersession kan også være miljøer).

Agenten ser kun miljøet, når den kigger. Alt, hvad den ved om miljøet, er kommet gennem et værktøjsresultat, så dens billede er en samling øjebliksbilleder, der hver især var korrekte på det tidspunkt, de blev taget. Hvis en fil ændres, efter agenten har læst den — du redigerer den i hånden, eller et byggetrin genererer den igen — fortsætter agenten med at ræsonnere ud fra den forældede kopi, indtil noget får den til at læse filen igen. En agent, der selvsikkert beskriver en fil, som ikke længere ser sådan ud, skyldes som regel dette: Miljøet har ændret sig, men øjebliksbilledet har ikke.

Miljøet er også det lag, der bevares — det eneste lag, der altid er tilstandsfuldt. Sessionens kontekst er væk, når sessionen slutter, men filer skrevet til miljøet ligger der stadig, så den næste session kan læse dem — det er det, hukommelsessystemer, overleveringsartefakter og `AGENTS.md` bygger på. Alt, en agent stadig skal vide i morgen, skal ende i miljøet.

Du bestemmer miljøets størrelse. En sandkasse gør det mindre og begrænser, hvor agenten kan nå hen; et værktøj udvider det og giver adgang til en database eller et API. Det, der ligger inden for grænsen, kan agenten opfatte og ændre; alt udenfor findes ikke for agenten. Hvor godt miljøet er indrettet til at understøtte agentens arbejde, er kodebasens AX.

Undgå: at bruge "miljø" om selve runtime-miljøet eller agentrammen — agentrammen er indpakningen, miljøet er arbejdsområdet.

Brug:

"Agenten kan ikke se stagingdatabasens skema."

"Kobl den på miljøet — giv den et `psql`-værktøj med skrivebeskyttet adgang til staging. Agentrammen fungerer fint; den har bare intet at arbejde på."

Et træ af filer og mapper, som agenten læser fra, skriver til og kører kommandoer i — standardtypen af miljø for en coding-agent. AGENTS.md, skills, kildekode, buildscripts og værktøjs-konfigurationer ligger alle i et filsystem. Når en agentramme "starter i dit projekt", peger den agenten mod et filsystem.

Agenten rører kun ved det gennem værktøjskald — læser en fil, skriver en fil eller kører en shellkommando. Intet på disken er i kontekstvinduet, før et værktøjskald indlæser det. Det gør det muligt for agenten at arbejde i et repo, der er langt større end vinduet: filsystemet rummer alt, konteksten kun det, den aktuelle opgave har læst. Nogle agentrammer indlæser som standard filnavnene i den aktuelle mappe i kontekstvinduet — ikke indholdet, kun træet — som kontekshenvisninger: agenten ser, hvad der findes, og læser de filer, den har brug for.

Og filsystemet deles med dig. De filer, agenten redigerer, er de samme, du åbner i din editor og sammenligner med git — filsystemet er det fælles arbejdsområde, hvor du gennemgår agentens arbejde.

Brug:

"Hvorfor finder den ikke min AGENTS.md?"

"Den arbejder mod et andet filsystem — sandboxen monterede den overordnede mappe, ikke projektroden. Peg agentrammen et andet sted hen."

En funktion, som agentrammen stiller til rådighed for agenten — Read, Write, Bash, Search. Værktøjer er agentens måde at opfatte og handle i miljøet på: den kan kun se miljøet gennem værktøjsresultater og kun ændre det gennem værktøjskald. Hvert værktøjskald koster en ekstra modeludbyderforespørgsel, fordi resultatet skal tilbage til modellen, før den kan beslutte, hvad den gør derefter.

Værktøjer, som de fleste coding-agenter leveres med:

Et værktøj defineres af tre ting: et navn, en beskrivelse af hvad det gør og et skema for dets parametre. Agentrammen sender disse definitioner til modellen ved hver forespørgsel, og modellen vælger værktøj på samme måde som den producerer alt andet — ved at skrive tokens, her som et struktureret kald med argumenter. Modellen udfører aldrig noget selv; agentrammen læser kaldet, kører funktionen og sender resultatet tilbage.

Værktøjslisten sætter grænsen for, hvad agenten kan gøre. En kapabel model med få værktøjer er en begrænset agent: den vil løse alt gennem de værktøjer, den har, og derfor bruger agenter Bash så meget — én shell kan nå det meste af systemet. Vil du give agenten en evne på en ordentlig måde, så tilføj et værktøj til den; MCP er standarden for at tilslutte værktøjer udefra agentrammen.

Værktøjsdefinitioner fylder kontekst ved hver forespørgsel, så en stor værktøjsmængde koster allerede, før noget værktøj kaldes. Mange værktøjer med lignende beskrivelser gør også modellen dårligere til at vælge.

Brug:

"Kan agenten forespørge staging direkte?"

"Tilføj et `psql`-værktøj til agentrammen, med skrivebeskyttet adgang til staging. Uden et værktøj til det kan agenten ikke se noget uden for filsystemet."

Output fra modellen, der angiver et værktøj og dets argumenter — blot struktureret tekst. Det udfører ikke noget i sig selv; agentrammen skal læse og udføre det. Modellen producerer det i én forespørgsel til modeludbyderen.

Et værktøjskalds livscyklus:

Én tur med agent-arbejde består som regel af mange sådanne rundture, der kædes sammen.

Fordi kaldet genereres med forudsigelse af næste token ligesom alt andet, kan det være forkert på samme måde som ethvert andet modeloutput: en sti, der ikke findes, et flag, kommandoen ikke understøtter, eller argumenter, der virker sandsynlige uden at være korrekte. Agentrammen udfører det, der blev skrevet, ikke det, der var meningen — en forkert stavet sti giver ikke nødvendigvis en pæn fejl; den kan få den til at redigere den forkerte fil.

Brug:

"Den sagde, at den kørte testene, men filernes tidsstempler er ikke ændret."

"Se i udskriften — udsendte den faktisk et værktøjskald eller beskrev den bare, at den kørte testene? Modellen producerer kaldet, men hvis agentrammen ikke udførte det, skete der ingenting."

Det, agentrammen sender tilbage efter at have udført et værktøjskald — filindholdet, kommandoens output eller fejlen. Det er agentens eneste indblik i miljøet. Resultatet sendes tilbage til modellen i den næste forespørgsel til modeludbyderen, hvor modellen beslutter, hvad den skal gøre med det. Værktøjskald og værktøjsresultat er hver sin ende af den samme udveksling og indgår begge i én tur.

Et værktøjsresultats livscyklus:

Resultatet bliver i konteksten resten af sessionen. Værktøjsresultater udgør som regel størstedelen af konteksten i en kodningssession: Hver fil, der læses, hver testkørsel og hver søgning lander i fuld længde og bliver ved med at optage tokens, længe efter at det holdt op med at være nyttigt. Et par store resultater — en udførlig testlog eller en hel genereret fil — kan presse en session mod kontekstvinduets grænse hurtigere end selve samtalen.

Fordi resultatet er alt, modellen ser, har den ingen mulighed for at kontrollere miljøet bag det. Hvis outputtet blev afkortet, kommandoen fejlede i det skjulte, eller agentrammen returnerede en fejl i stedet for indholdet, ræsonnerer modellen ud fra det, den fik. Når agentens billede af systemet virker forkert, er værktøjsresultaterne stedet at lede: Et sted i udskriften er der et resultat, som siger noget andet end det, du ved er sandt.

Brug:

"Den ræsonnerer, som om filen er tom."

"Værktøjsresultatet var en afvisning på grund af tilladelser, ikke filens indhold. Modellen så kun fejlteksten — den har ingen anden måde at se filen på."

Model Context Protocol. En protokol til at koble eksterne værktøjsservere til en agentramme — sådan får en agent værktøjer ud over dem, agentrammen leverer. Agenten "kalder aldrig MCP"; den kalder et værktøj, og agentrammen har tilfældigvis fået værktøjet fra en MCP-server. Protokollen udstiller også ressourcer (data kun til læsning) og prompts (genanvendelige skabeloner), men værktøjer er dens primære anvendelse.

Protokollen løser et integrationsproblem. Uden en standard skulle hver agentramme have sin egen Linear-integration, sin egen Slack-integration, sin egen databaseintegration — skrevet og vedligeholdt separat til hver enkelt. Med MCP skrives integrationen én gang som en server, og alle MCP-kompatible agentrammer kan bruge den. Agentrammen forbinder til serveren, serveren annoncerer sine værktøjer, og de bliver tilgængelige for agenten sammen med de indbyggede.

Prisen betales i kontekst. Hvert værktøj, en server annoncerer, kommer som en definition — navn, beskrivelse, parameterskema — og modellen kan kun kalde værktøjer, den kender. Den naive løsning indlæser alle definitionerne i kontekstvinduet på forhånd: installér nogle få gavmilde servere, og en session starter med tusinder af tokens i værktøjsskemaer, før du har skrevet noget. Dermed bruger den opmærksomhedsbudget på værktøjer, opgaven aldrig får brug for.

Mange agentrammer afhjælper nu dette med værktøjssøgning: i stedet for de fulde definitioner indeholder konteksten en kontekshenvisning til de tilgængelige værktøjer. Agenten søger efter et værktøj ud fra navn eller formål og indlæser først definitionen, når den skal bruges. Hvis din agentramme ikke gør dette, gælder den indledende omkostning stadig, og det kan betale sig kun at aktivere de servere, projektet faktisk har brug for.

Brug:

"Agenten skal læse tickets fra Linear."

"Konfigurér agentrammen til at bruge Linear MCP-serveren — den udstiller Linear-API'et som værktøjer, agenten kan kalde. Så slipper du for at skrive dine egne værktøjsindpakninger."

Det, agentrammen viser brugeren, før den udfører et værktøjskald, der ikke er forhåndsgodkendt. Modellen producerer et værktøjskald; i stedet for at køre det med det samme standser agentrammen og spørger. Godkend, så bliver det udført; afvis, så sender agentrammen afslaget tilbage til modellen som et værktøjsresultat. Det er den mekanisme, en agentramme bruger til at sætte et menneske ind i løkken ved risikable eller følsomme handlinger.

En tilladelsesanmodnings livscyklus:

Et afslag styrer agenten. Modellen læser afslaget som ethvert andet værktøjsresultat og reagerer på det — den prøver en anden fremgangsmåde eller spørger, hvad du foretrækker. De fleste agentrammer lader dig føje en besked til afslaget, så det bliver et styringspunkt: "ikke sådan, brug migrationsscriptet i stedet" når frem præcis, mens modellen beslutter, hvad den skal gøre som det næste.

Omkostningen er, at hver anmodning kræver, at du svarer, før arbejdet kan fortsætte. Agenten er blokeret, indtil du svarer; det er fint, når du følger med, og et problem, når du ikke gør — en agent, der udløser anmodninger hele tiden, kan ikke efterlades til at arbejde AFK. Tilladelsestilstanden er reguleringsknappen: hvilke kald der frit kan køre, og hvilke der først spørger, helst med en sandkasse, så det bliver sikkert at udvide mængden af frie kald.

Brug:

"Den har ventet på en tilladelsesanmodning i ti minutter — jeg var til møde."

"Det er prisen for at have et menneske i løkken. Forhåndsgodkend de sikre værktøjer, så anmodningen kun udløses ved de reelt risikable kald."

Den del af en agenttilstand, der styrer tilladelser — hvilke værktøjskald der udløser en tilladelsesanmodning, og hvilke der kører automatisk. Det oprindelige formål med tilstandssystemer, før agentrammer begyndte at lægge adfærdsinstruktioner ovenpå.

Agentrammer tilbyder en række sådanne tilstande:

Valget af niveau er en afvejning mellem sikkerhed og afbrydelser, og begge typer fejl mærkes. For stram styring gør dig til flaskehals: Agenten stopper hvert par sekunder for harmløse læsninger, du godkender på autopilot, og godkendelserne mister deres betydning — rutinemæssige godkendelser giver det værste fra begge verdener: alle afbrydelserne uden beskyttelsen. For løs styring betyder, at agenten redigerer filer og kører kommandoer, du ville have ønsket at se først.

Den løse ende kan bedst forsvares i en sandkasse, hvor skadeomfanget af et dårligt værktøj-kald er begrænset. Udenfor ender de fleste med at godkende læsninger automatisk og holde et menneske i løkken ved alt uigenkaldeligt.

Brug:

"Den standsede ved hvert grep — det ødelagde hele AFK-kørslen."

"Gør tilladelsestilstanden mindre stram for skrivebeskyttede værktøjer, men behold forespørgsler ved skrivning og shell. De fleste tilladelsesanmodninger i en research-session er støj."

En forudindstilling, der former, hvordan agenten arbejder under kørsel — den samler en permission mode med adfærdsinstruktioner, der indsættes i systemprompten. Eksempler: en standard, der spørger ved risikable kald; en plan mode, der blokerer redigeringer og styrer agenten mod research; en accept-edits-tilstand, der automatisk godkender redigeringer; en bypass permissions-tilstand (uformelt YOLO mode), der godkender alt automatisk. Kan skiftes midt i en session.

Det er kombinationen, der adskiller en mode fra en ren rettighedsindstilling. En permission mode er kun en port: den afgør, hvilke værktøjskald der får lov at gå igennem. En port alene giver en agent, der vil redigere, men ikke kan — den foreslår en skrivning, bliver blokeret og prøver en anden vej. De indsatte instruktioner fjerner lysten: plan mode blokerer ikke kun redigeringer, den fortæller også agenten, at den er i en planlægningsfase, så den læser, spørger og foreslår i stedet for at presse mod porten. Port og styring peger samme vej.

I praksis skifter du mode, efterhånden som din tillid ændrer sig under opgaven. Den samme opgave kan gå gennem flere modes: plan mode, mens tilgangen formes; standarden med tilladelsesspørgsmål til de første følsomme redigeringer; accept-edits, når agenten har vist, at den forstår ændringen; bypass til en AFK-kørsel i en sandbox. Det koster intet at skifte mode: samtalen fortsætter præcis dér, hvor den var, med nye rettigheder og instruktioner. Hvis du godkender hver prompt uden at læse den, er moden strammere end din faktiske tillid; hvis du hele tiden afviser redigeringer, er den løsere.

Leverandørtermer: Claude Code kalder dem "permission modes", Codex kalder dem "approval modes" — begge termer er ældre end adfærdskombinationen.

Brug:

"Den bliver ved med at redigere filer, når jeg kun vil have en plan."

"Skift til plan mode — den blokerer skrivninger og holder sig til research."

"Hvad med den senere AFK-kørsel?"

"Bypass mode, men kun inde i sandboxen."

Et isoleret miljø, som agenten kører i — en container, VM, midlertidigt filsystem eller shell med begrænsede rettigheder. Begrænser skadeomfanget af agentens handlinger: Selv hvis agenten kører destruktive kommandoer eller henter noget ondsindet, holdes skaden inden for grænsen. Sikkerhedsgrundlaget, der gør AFK praktisk.

Sandboxen og permission mode løser det samme problem fra hver sin ende. Rettigheder spørger, før en handling kører; en sandbox begrænser, hvad handlingen kan nå, hvis den kører. Rettigheder kræver, at du er med i løkken — hver prompt er en afbrydelse — og en session, der spørger hele tiden, er knap nok autonom. En sandbox bruger infrastruktur i stedet for opmærksomhed: Jo stærkere isoleringen er, desto færre spørgsmål skal stilles.

Isolering findes i flere grader:

Det, ingen sandbox kan begrænse: handlinger, der med rette forlader den. En agent med dine git-legitimationsoplysninger kan pushe; en med netværksadgang kan kalde produktions-API'er. Beslut, hvad der må krydse grænsen, før du bestemmer, hvor tyk den skal være.

Brug:

"Jeg vil lade den køre bypass-permissions natten over, men jeg er ikke klar til det endnu."

"Sæt den i en sandbox — frisk container, ingen monterede legitimationsoplysninger, ingen udgående netværk. I værste fald smadrer den sit eget filsystem, og så kasserer du containeren."

Selvsikkert enig model-output. Skyldes træningen: Modellen blev formet til at foretrække svar, mennesker kunne lide, og mennesker kan bedre lide enighed end at få at vide, at de tager fejl. Modellen lærte derfor, at enighed belønnes — også når den er forkert.

Kommer til udtryk som:

• At give efter ved modsigelse — trækker et korrekt svar tilbage, når du spørger "er du sikker?".
• At rose dårligt input — kalder din mangelfulde plan genial, før den analyseres.
• Farvet vurdering — review er positivt, når du siger, at du skrev det; negativt, når du siger, at en anden gjorde det. Samme artefakt, forskellig dom.
• Efterligning — gentager dine fejl som bekræftelse.

Diagnostisk test: Ville modellen have sagt dette uden din styring? Hvis det eneste, der ændrede sig, var din tone eller indramning, er det sycophancy, ikke en reel ændring i analysen.

Løsning: skjul dine præferencer. Formulér prompts neutralt — "gennemgå denne kode" i stedet for "er denne kode god?".

Undgå: at bruge "sycophancy" om ethvert forkert svar, der tilfældigvis behager dig. Uden den diagnostiske test er termen ikke mere værd end "forkert".

Brug:

"Den sagde, at min refaktorplan så fantastisk ud, men da jeg spurgte 'er du sikker?', trak den det hele tilbage."

"Klassisk sycophancy — den var først enig, fordi du lød sikker, og gav så efter, fordi du lød tvivlende. Planens kvalitet ændrede sig ikke, det gjorde din tone. Ryd og spørg igen uden at antyde et svar."

Selvsikkert forkert model-output. To varianter med forskellige årsager og løsninger:

Forudsigelse af næste token skaber flydende output, uanset om den underliggende oplysning er sand — modellen har intet indre signal om, at den ikke ved noget. Derfor kommer en opdigtet metode i samme sikre tone som en korrekt. Hallucineret kode virker plausibel af natur: sådan ville API'et se ud, hvis det fandtes. Netop derfor slipper den gennem en overfladisk gennemgang og fejler først, når den køres.

Du skal vide, hvilken variant du ser, fordi løsningen på den ene gør den anden værre. Faktuel ukorrekthed betyder manglende viden: Løsningen er at tilføje kontekst — dokumenterne, typedefinitionerne, filen. Manglende troskab betyder, at viden er til stede, men taber kampen om opmærksomheden: Løsningen er at fjerne kontekst. Fejldiagnosticér troskab som manglende fakta, og du indsætter mere dokumentation, som vokser konteksten og forværrer afvigelsen. Når agenten tager fejl, så kontrollér, om den korrekte information allerede var i konteksten, før du beslutter, hvilket problem du har.

Undgå: "hallucination" som rent synonym for "forkert" — uden at nævne varianten har ordet ingen diagnostisk værdi.

Brug:

"Den hallucinerede en `parseAsync`-metode på schemaet."

"Faktuel korrekthed eller troskab?"

"Metoden står i dokumentationen, jeg indsatte — den holdt bare op med at læse efter tur fyrre."

"Så er det troskab. Kompaktér og indlæs igen; lad være med at tilføje mere dokumentation."

Det, en model "ved" fra træningen, lagret i dens parametre. Viden, der er fastlåst på træningstidspunktet — modellen kan hverken se sine egne parametre eller opdatere dem. Detaljer går tabt under komprimeringen: Milliarder af fakta presses ind i et fast antal parametre, og de sjældne fakta bliver uklare. Kilden til flydende svar om almindelige emner og til opdigtede svar om sjældne emner. Modstykket er kontekstuel viden.

Parametrisk viden lagres ikke som fakta. Træningen giver aldrig modellen en database, den kan slå ting op i; den justerer parametrene, indtil modellen forudsiger tekst godt, og en model, der forudsiger tekst om et emne godt, opfører sig, som om den kender emnet. Hvor pålidelig viden er, afhænger af, hvor ofte noget optrådte i træningsdataene: Et emne med millioner af eksempler gengives præcist, mens modellen ved et emne med kun en håndfuld eksempler gætter ud fra, hvordan lignende emner ser ud. At gengive og at gætte er den samme proces for modellen, så den kan ikke se forskel på dem. Et opdigtet svar fremføres lige så flydende som et korrekt svar. Hallucination er, når modellen gætter forkert.

Parametrisk viden bliver også forældet. Parametrene holder op med at ændre sig ved vidensskæringsdatoen, så et bibliotek, der udgives eller omdøbes efter datoen, ikke findes i dem, og et API, der er blevet ændret, huskes i sin gamle form.

Ved begge huller — det, der er for sjældent, og det, der er for nyt — er løsningen den samme: Viden kan ikke føjes til parametrene, så den må i stedet leveres som kontekstuel viden.

Brug:

"Den skriver fejlfri React, men finder på metoder i vores interne SDK."

"React fylder meget i den parametriske viden — millioner af træningseksempler. Dit SDK gør ikke, så modellen finder på former, der ser sandsynlige ud. Indlæs SDK-dokumentationen i konteksten."

Datoen, efter hvilken en model ikke har nogen parametrisk viden. Biblioteker, API'er og begivenheder fra efter skæringsdatoen er fælder for opdigtede svar, medmindre deres dokumentation er indlæst som kontekstuel viden. Hver modeludgivelse har sin egen skæringsdato.

Skæringsdatoen skyldes, hvordan modeller bliver lavet: træning indlejrer et øjebliksbillede af tekst i modellens parametre, og derefter er parametrene låst. Modellen ved ikke, at dens viden har en grænse — bliver den spurgt om noget efter skæringsdatoen, afviser den ikke spørgsmålet, men ekstrapolerer fra det nærmeste, den kender. Det gør fælden svær at få øje på: Kode skrevet til en gammel version af et bibliotek ser sandsynlig ud, kan ofte kompileres og fejler så på de dele, der blev ændret.

Løsningen er altid den samme: Bring aktuelle oplysninger ind i konteksten. Indlæs ændringsloggen, henvis til typedefinitionerne for den installerede version, eller få agenten til at læse dokumentationen på nettet. Alt i konteksten vejer tungere end det, der ikke findes i parametrene.

Brug:

"Den bliver ved med at skrive syntaksen fra SDK v3 — vi bruger v5."

"v5 udkom efter vidensskæringsdatoen. Indlæs ændringsloggen for v5 som kontekstuel viden; ellers bliver den ved med at digte videre ud fra den ældre parametriske version."

Fakta, som agenten kan læse direkte fra konteksten lige nu — brugerens opgave, filer, agenten har læst ind, værktøjsresultater og indhold fra AGENTS.md, der blev indlæst ved sessionens start. Modstykket til parametrisk viden: parametrisk viden bliver genkaldt fra parametrene; kontekstuel viden bliver læst fra vinduet. Hallucinationer er langt sjældnere, når agenten arbejder ud fra kontekstuel viden — svaret står lige foran den og skal ikke graves frem fra en sløret hukommelse.

Af de to slags viden er det kun den kontekstuelle, du kan styre. Parametrene er låst, så den eneste måde at give modellen viden, den mangler — et internt SDK, et bibliotek udgivet efter vidensskæringsdatoen eller en beslutning fra i går — er at lægge det ind i konteksten. Meget praktisk AI-kodning handler om netop dette: at få de rigtige fakta foran modellen, når den skal bruge dem.

Når kontekstuel og parametrisk viden er i konflikt, vinder den kontekstuelle som regel. Indsæt den aktuelle API-dokumentation, så følger modellen den i stedet for sin forældede erindring om den gamle API — selvom den gamle version stadig kan skinne igennem, især sent i en lang session. Hvis agenten bliver ved med at gå tilbage til et forældet mønster, selvom dokumentationen er indlæst, siver den parametriske viden forbi den kontekstuelle; det hjælper at gentage rettelsen eller flytte den tættere på arbejdet.

I modsætning til parametrisk viden koster kontekstuel viden noget at bruge. Alt, der indlæses i vinduet, bruger tokens og konkurrerer om modellens opmærksomhedsbudget, så mere er ikke automatisk bedre — målet er de relevante fakta i vinduet, ikke alle fakta.

Grib kun til dette udtryk, når du sammenligner med parametrisk viden; ellers skal du bare sige kontekst.

Undgå: "arbejdshukommelse" — kontekstuel viden er det, der er i vinduet nu; et hukommelsessystem er det, der bringer indhold fra tidligere sessioner ind i det. Det er forskellige niveauer, som ikke bør blandes sammen.

Brug:

"Hvorfor rammer den API'et præcist, når jeg indsætter dokumentationen, men finder på ting, når jeg ikke gør?"

"Når dokumentationen er indlæst, er det kontekstuel viden — den læser direkte fra teksten. Ellers er den parametrisk, og de sjældne endepunkter bliver uklare."

Når modellen forudsiger hvert token, tager den højde for alle andre tokens i konteksten — nogle vægter den højt, andre næsten ikke. Forbindelsen mellem to tokens er en opmærksomhedsrelation, og meningsfulde par ("hende" sammen med "Sarah" eller et kald til `getUser()` sammen med definitionen `function getUser`) påvirker hinanden mere end uvedkommende par. En kontekst med N tokens har i størrelsesordenen N² relationer.

Det er i disse forbindelser, modellens tilsyneladende forståelse ligger. Når den finder frem til, hvem et stedord henviser til, skyldes det, at opmærksomhedsrelationen mellem "hende" og "Sarah" er stærk. Når den kalder en funktion med de rigtige argumenter, gør relationen mellem kaldestedet og definitionen, den tidligere læste, arbejdet. Intet bliver slået op — det beregnes på ny ved hver forespørgsel til modeludbyderen for hvert par.

Det er værd at dvæle ved N²-tallet, fordi det vokser hurtigere, end intuitionen tilsiger:

Hver forbindelse beregnes desuden mere end én gang. Modeller har flere opmærksomhedshoveder — de præcise antal for førende modeller er ikke offentliggjort, men halvtreds til hundrede er et rimeligt gæt — og hvert hoved beregner sin egen udgave af alle relationerne. Derfor gentages hver forbindelse i tabellen ovenfor for hvert hoved. Det er mange forbindelser.

Kun et lille antal af disse relationer betyder noget for en given opgave. Forbindelsen mellem din instruktion og den kode, den styrer, er en af de få, der tæller; næsten alt andet i puljen er støj. Og de vokser med forskellig hastighed: De vigtige relationer forbliver nogenlunde konstante, mens den samlede pulje vokser kvadratisk med kontekststørrelsen. Ved 1.000 tokens er den forbindelse, du bekymrer dig om, én ud af en million; ved 100.000 tokens er den én ud af ti milliarder. Det er regnestykket bag opmærksomhedsbudgettet, og forringelse af opmærksomheden er oplevelsen af, at de vigtige relationer får en alt for lille andel.

Brug:

"Den bliver ved med at forveksle de to `user`-symboler i diffen — det lyder, som om vi er i den dumme zone."

"Ja, opmærksomhedsrelationen mellem hvert kaldested og dets deklaration kæmper mod den anden — samme tokenform, forskellige bindinger. Omdøb det ene, så bliver forbindelserne tydeligere."

Hver token har en begrænset mængde indflydelse, der skal fordeles på resten af konteksten. Stor indflydelse på én relation efterlader mindre til de andre. Budgettet gælder per token og vokser ikke med konteksten; derfor udvander lange sessioner det.

Tænk på det som signal og støj. Din instruktion er et signal med fast lydstyrke; hver anden token i kontekstvinduet er konkurrerende lyd. Instruktionen bliver ikke lavere — den står stadig der, tegn for tegn — men efterhånden som konteksten vokser, larmer rummet mere omkring den, og signal-støj-forholdet falder. En instruktion, der var det højeste ved 10k konteksttokens, er baggrundssummen ved 150k. Det er mekanismen bag opmærksomhedsforringelse: Modellen glemmer ikke; signalet forsvinder i støjen.

Symptomet ligner ulydighed — agenten accepterede en begrænsning tidligt, men afviger senere fra den, og det hjælper kun kortvarigt at indsætte begrænsningen igen. Årsagen er ikke instruktionen; det er alt andet i vinduet, der konkurrerer med den.

Du kan styre, hvad der kommer ind i konteksten. Indhold, der ikke tjener opgaven, er ikke neutralt — det er støj oven på alt det, der gør. Hold vinduet lille, ryd, når den ophobede kontekst ikke længere er sin plads værd, og gentag de begrænsninger, der betyder noget, i stedet for at stole på, at den tidlige omtale holder.

Brug:

"Hvorfor ignorerer den hele tiden schemaet, jeg indsatte øverst?"

"Vi er langt inde i den dumme zone — hver tokens opmærksomhedsbudget er fast, men konteksten blev ved med at vokse. Schemaets signal konkurrerer nu med tusinder af nyere tokens."

Efterhånden som en session vokser, fordeles hver tokens opmærksomhedsbudget på flere konkurrenter. Signalet i hver meningsfuld relation bliver svagere; støj fra irrelevant kontekst trænger sig på. Samme model, samme parametre — bare flere munde at mætte fra den samme tallerken. Årsagen til smart-zone-/dum-zone-effekten.

Det viser sig ved, at modellen virker dårligere midt i en session: begrænsninger, den fulgte i en time, begynder at glide; den spørger igen om ting, den allerede har fået at vide; den skriver kode, der ignorerer en fil, den tidligere læste. Intet ved modellen ændrede sig — den eneste variabel er, hvor meget kontekst den nu skal rette opmærksomheden mod.

Det sker gradvist, og derfor er det svært at opdage indefra sessionen. Der er ingen fejl eller tærskel; hver tur er kun lidt dårligere end den forrige, og når afvigelserne bliver tydelige, har du været i den dumme zone et stykke tid.

Du kommer tilbage ved at fjerne kontekst, ikke ved at tilføje mere. At indsætte den ignorerede instruktion igen tilføjer endnu en konkurrent i det samme overfyldte vindue og hjælper kun kortvarigt. Det, der virker: ryd og indlæs kun det, opgaven behøver; kompaktér; eller lav en handoff til en frisk session. Se faldende instruktionsefterlevelse som et signal om kontekstlængden, ikke om modellen.

Brug:

"Den er dybt i den dumme zone — opfinder generiske typer, som ikke findes i typefilen."

"Opmærksomhedsforringelse. Typedefinitionerne er stadig i konteksten, men signalet drukner under alt det, vi har tilføjet siden. Ryd og indlæs igen."

Tidligt i en session er agenten i en "smart zone" — skarp, fokuseret, med god hukommelse. Efterhånden som sessionen vokser, glider den over i en "dum zone": mere sjusket, glemsom, med flere fejl — og flere troskabs-hallucinationer. Samme model, samme agentramme — bare mere kontekst. Den mærkbare virkning af opmærksomhedsforringelse. For frontier-modeller begynder den dumme zone ofte omkring 125K–150K tokens, selvom det diskuteres. Ryd eller kompaktér, når sessionen svulmer; pres ikke videre.

Faldet sker gradvist, så det er let at overse. Der er ingen fejlmeddelelse eller synlig grænse; agenten begynder blot at præstere lidt dårligere og derefter mærkbart dårligere. Typiske tegn: Den glemmer en instruktion fra tyve ture siden, gentager en fejl, den allerede har rettet, eller hævder selvsikkert noget, konteksten modsiger. Fordi faldet er jævnt, er den sædvanlige reaktion at fortsætte og forklare igen — det tilføjer mere kontekst og gør problemet værre.

Zonerne følger ikke kontekstvinduets grænse. En session kan være dybt i den dumme zone, selvom det meste af vinduet stadig er ledigt: Grænsen er det punkt, hvor agentrammen nægter at fortsætte, men kvaliteten falder længe før. Planlæg efter den smarte zone, ikke vinduet — det praktiske budget for en opgave er de tokens, agenten arbejder godt inden for, ikke dem, den teknisk kan rumme.

Den smarte zone er et budget, og uvedkommende arbejde bruger af det. Hver opgave, der udføres i en session, bruger tokens; at starte en anden opgave i samme session betyder derfor, at man begynder tættere på den dumme zone. Én opgave per session giver hver opgave den skarpeste del af sessionen. Er én opgave større end én smart zone, så del den op: lav en handoff eller kompaktér ved en naturlig grænse, og lad en frisk session tage næste del.

Brug:

"Den klarede de første tre komponenter perfekt og ødelagde den fjerde."

"Du er ude af den smarte zone — samme model, men nu dybt i den dumme zone. Kompaktér og indlæs planen igen; så lykkes den næste komponent."

Afslutte den aktuelle session og starte en ny. Den næste besked begynder med en tom session og et tomt kontekstvindue. Som regel er det brugerstyret.

Rydning er kuren mod forurenet kontekst. En session ophober alt: mislykkede forsøg, forkerte afstikkere, forældede værktøjsresultater, opgivne planer. Modellen læser det hele igen ved hver tur, og dårlig historik trækker nyt arbejde ned. Dybt inde i en lang session bliver agenten mere vag og mindre lydig — klare instruktioner ignoreres, kvaliteten falder, og det hjælper ikke at bede den gøre det bedre, fordi støjen stadig ligger i dens kontekst. Rydning fjerner støjen.

Rydning sletter ikke samtalen. De fleste agentrammer gemmer sessionshistorikken på din computer, så transskriptionen stadig kan læses eller genoptages. Det, der forsvinder, er agentens arbejdstilstand: Modellen er stateless, så den nye session ved intet af det, den gamle vidste. Rummer sessionen beslutninger eller fremskridt, som den næste skal bruge, så få agenten til først at skrive et overdragelsesartefakt, og start derefter den nye session ved at henvise til det.

Sammenlign med compaction, der opsummerer sessionen i den nye kontekst i stedet for at begynde tomt. Rydning er det grovere værktøj: Intet føres videre, heller ikke skramlet.

Brug:

"Den sidder fast i en løkke om den fejlede test."

"Ryd den bare — start en frisk session med plandokumentet og testfilen. Ingen grund til at kæmpe mod den eksisterende kontekst."

At overføre agentens kontekst fra én session til en anden. Overførselsmetoden varierer — et skriftligt overleveringsartefakt, et resumé i hukommelsen (komprimering) og andre muligheder. Det er noget andet end rydning, hvor intet overføres. Årsagerne varierer: skifte rolle (planlægger → implementør), starte en AFK-kørsel, fordele arbejdet på parallelle sessioner eller frigøre plads i kontekstvinduet.

Den modtagende session starter uden kontekst — modellen er tilstandsløs, og intet fra den gamle session er synligt i den nye. Alt, den næste session har brug for, skal overføres eksplicit; resten er væk. Begrænsningen, der former overførslen, er, at "der ikke er nogen vej tilbage": Den nye session kan ikke spørge den gamle, hvad den mente, så det overførte materiale skal kunne stå alene.

En dårlig overlevering viser sig ved, at diskussionen tages om: Den nye session genåbner beslutninger, den gamle havde truffet, fordi overførslen noterede, hvad der blev besluttet, men ikke hvorfor. Vurdér en overlevering ud fra, hvad en session uden nogen kontekst kan gøre med den.

Brug:

"Planlægningssessionen er ved at blive tung — skal jeg bare fortsætte?"

"Lav en overlevering. Skriv beslutningerne i et dokument, ryd sessionen, og begynd implementeringen i en ny session, der læser dokumentet."

En sandhedskilde i sin oprindelige form — koden, samtalens transskription, den rå log, det faktiske API-svar. Ikke en beretning om tingen; tingen selv. Modstykke til sekundær kilde.

Hvis du vil vide, hvad din kodebase gør, er koden den primære kilde. Dokumenterne, arkitekturdiagrammet og README'en er beskrivelser af den — korrekte, da de blev skrevet, og siden opdateret efter deres egen tidsplan. Når en agent med sikkerhed hævder noget forkert om dit projekt, så spørg, hvilken kilde den arbejdede ud fra: en agent, der læste et dokument, arver dokumentets forældelse; en agent, der læste koden, læser den aktuelle sandhed.

Omkostningen er grunden til, at primære kilder ikke er standarden. Det er dyrt at indlæse en i kontekstvinduet — hele filen, hele transskriptionen, hver token faktureret som inputtoken og konkurrerende om opmærksomhedsbudgettet. Til gengæld får du fuldstændighed: intet er blevet forhåndsfiltreret af andres vurdering af, hvad der var vigtigt. En opsummering fra sidste måned kan ikke indeholde den detalje, der viste sig vigtig i dag; den primære kilde har den stadig.

Brug den primære kilde, når præcision betyder noget — den nøjagtige signatur, den faktiske fejl, linjen der kaster fejlen. Meget af arbejdet med at styre kontekst består i at beslutte, hvornår den primære kilde er prisen værd, og hvornår en sekundær kilde er nok.

Brug:

"Agenten siger, at retry-logikken venter eksponentielt, men jeg ser den hamre løs på endpointet."

"Den læste det i design-dokumentet. Peg på det faktiske retry-modul — arbejd ud fra den primære kilde, når adfærden betyder noget."

En beretning om en primær kilde, et led fra den — dokumentation, der beskriver kode; en opsummering, der beskriver en transskription; en rapport, der beskriver søgeresultater. Billigere at indlæse i kontekstvinduet end den kilde, den beskriver, men tabsfuld af natur: Forfatteren besluttede, hvad der var vigtigt, og det udeladte er usynligt for en læser, der kun har opsummeringen.

Meget arbejde med kontekst går ud på at fremstille sekundære kilder. Compaction omdanner sessionens historik til en opsummering, der forbereder den næste session. En subagent bruger sin egen kontekst på en støjende søgning og returnerer en kort rapport. Et overdragelsesartefakt samler en sessions beslutninger i et dokument, som den næste session læser. Hukommelsessystemer destillerer det, en session lærte, til noter. De foretager alle samme bytte: trofasthed for mere plads.

Sekundære kilder fejler på to måder. De mister information — compaction-opsummeringen, der mistede beslutningen om skemaet, rapporten, der ikke nævnte randtilfældet. Og de driver — den primære kilde ændrer sig, men beretningen følger ikke med, så dokumenter beskriver sidste kvartals arkitektur med dette kvartals sikkerhed. Når en agent handler på en sekundær kilde, der har fejlet på en af måderne, arbejder den sikkert ud fra forkerte oplysninger; løsningen er at sende den tilbage til den primære kilde.

Ingen af fejlene gør sekundære kilder til en fejltagelse. Kontekstvinduet er endeligt, og primære kilder er dyre; uden opsummeringer, rapporter og overdragelsesdokumenter passer intet stort ind. Kunsten er at vide, hvilke detaljer der kan overleve tabet — og at kontrollere mod den primære kilde, når de ikke kan. En god sekundær kilde har en kontekshenvisning tilbage til originalen — opsummeringen, der nævner transskriptionen, den kom fra, dokumentet, der nævner filen, det beskriver — så læseren kan følge henvisningen i stedet for at arbejde ud fra tabet, når beretningen ikke er nok.

Brug:

"Overdragelsesdokumentet siger, at auth er færdig, men den nye session finder stadig ødelagt tokenfornyelse."

"Dokumentet er en sekundær kilde — den sidste session skrev ned, hvad den troede, ikke hvad der er sandt. Få den nye session til at køre auth-testene og stole på den primære kilde."

Et dokument, der bruges som overdragelsesmiddel for en handoff — skrevet til miljøet af én session, så en anden kan læse det. Specifikationer, tickets og plandokumenter er alle handoff-artefakter.

Grunden til at skrive et: modellen er stateless, så intet fra en session overlever, når den ryddes. Beslutninger, begrænsninger, ufærdige planer — alt forsvinder sammen med den kontekst, der rummede dem. Miljøet består. Når vigtig status skrives i en fil, flyttes den til et sted, hvor den næste session kan læse den.

Artefaktet er en sekundær kilde — en beretning om sessionens arbejde, ikke selve arbejdet. Det gør det lille nok til at briefe en ny session, men også derfor kan det vildlede: det registrerer, hvad den skrivende session troede, og alt det, den udelod eller tog fejl af, er usynligt for læseren. Når en påstand betyder noget, bør den næste session efterprøve den mod den primære kilde — koden, testene — i stedet for at arve den.

Et godt artefakt er skrevet til en session, der begynder uden nogen kontekst. Konkrete filstier i stedet for "filen, vi talte om". Hvad der blev besluttet og hvorfor, så næste session ikke genåbner diskussionen. Hvad der er gjort, og hvad der mangler. Det hjælper at fortælle den skrivende session, hvad artefaktet skal bruges til: "skriv et overdragelsesdokument til en ny session, der intet ved om dette arbejde".

Det alternative overdragelsesmiddel er compaction, som opsummerer indhold i hukommelsen. Artefaktet har to fordele: det ligger på disken, hvor du kan læse og rette det, før nogen afhænger af det, og det kan genbruges — samme spec kan briefe fem parallelle sessioner.

Brug:

"Hvordan deler jeg det mellem planlægnings-agenten og den, der implementerer?"

"Lad planlæggeren skrive et handoff-artefakt — filstier, beslutninger, begrænsninger. Implementeringssessionen begynder med en henvisning til artefaktet og bruger det som briefing."

Et overdragelsesartefakt, der beskriver et stykke arbejde over flere sessioner — hvad der bygges, ikke hvordan hver session bidrager. Det ændrer sig, efterhånden som arbejdet skrider frem. Det består af tickets.

Specifikationen findes, fordi sessioner er midlertidige, mens stort arbejde ikke er det. Alt, der kræver mere end ét kontekstvindue med indsats, har brug for et hjem uden for konteksten — et sted i agentens miljø, der overlever rydning. Det kan være en fil i repoet, et GitHub-issue eller et issue-system, agenten kan tilgå. Specifikationen er det hjem: målet, begrænsningerne, beslutningerne indtil nu og listen over tickets med deres status. Enhver ny session kan læse den og vide, hvor arbejdet står, uden at arve den forrige sessions ophobede støj.

Specifikationer følger genkendelige formater, som oftest er arvet fra den måde, teams allerede skriver ting ned på. Et product requirements document (PRD) fokuserer på hvad og hvorfor set fra brugerens side — funktioner, adfærd, acceptkriterier. Et design doc eller en RFC fokuserer på det tekniske — den valgte tilgang, fravalgte alternativer og afvejninger. I den lille ende gør en enkel `plan.md` med en tjekliste over tickets det samme for en funktion over flere sessioner. Formatet betyder mindre end rollen: for agenten er de alle det samme — en varig beskrivelse af hensigten, som den læser ved starten af hver session.

Brug:

"Skal alt dette være én session?"

"Nej, skriv det op som en spec — del det op i tickets, og kør hver i sin egen session. Prøver du at gøre det hele i én kontekst, rammer du den dumme zone, før du er halvvejs."

Et overdragelsesartefakt, der afgrænser én session arbejde. Det kan stå alene eller være knyttet til en spec som et af dens underordnede elementer. Tickets kan blokere andre tickets eller selv være blokeret af søstertickets, så arbejdsrækkefølgen følger af afhængighedsgrafen i stedet for en lineær plan.

Den afgørende begrænsning er størrelsen: én session. En ticket bør kunne færdiggøres, før sessionen glider ud af den smarte zone — og det kan afprøves. Hvis sessionerne på dine tickets jævnligt forringes, før arbejdet er færdigt, er tickets for store; del dem op. Hvis hver session bruger det meste af sin kontekst på opsætning, før den udfører fem minutters arbejde, er de for små; slå dem sammen.

En god ticket er skrevet til en læser uden anden kontekst. Målet, acceptkriterierne og kontekshenvisninger til relevante filer og beslutninger — nok til, at sessionen kan gå i gang uden at udlede alt det, den forrige vidste, på ny.

Afhængighedsgrafen gør også parallelisering mulig. Uafhængige tickets — grafens blade — kan hver køre i deres egen session på samme tid. Det er en effektiv måde at køre flere agenter samtidig. I en softwarefabrik er markeringen af en ticket som klar selv den trigger, der starter dens session.

Brug:

"Hvor skal jeg begynde på migreringsspecifikationen?"

"Se på ticketgrafen — skemaændringen blokerer tilbagefyldningen, og den blokerer API-skiftet. Vælg et blad, og kør en session på det."

En overdragelse udført i hukommelsen: den forrige sessions historik opsummeres, og opsummeringen starter en ny session. Bevidst tabsfuld: transskriptionen er en primær kilde, opsummeringen en sekundær kilde — detaljer byttes for mere plads. Udløses manuelt af brugeren eller automatisk via autokompaktering.

Mekanismen er denne: kontekstvinduet er endeligt, og en lang session fylder det — hvert toolresultat, hver læst fil og hver forkert afstikker bliver i historikken. Når den bliver tung, beder agentrammen modellen om at opsummere sessionen, kasserer den oprindelige historik og starter en ny session med opsummeringen. Det, der ikke kom med i opsummeringen, er væk fra konteksten. Nogle agentrammer afbøder dette ved at beholde den gamle transskription på disk og indsætte en kontekshenvisning til den i opsummeringen — den sekundære kilde peger tilbage på sin primære kilde, så en detalje, opsummeringen mistede, kan genskabes ved at læse originalen igen.

Opsummeringen skrives af modellen, så den kan styres med instruktioner. "Bevar beslutningerne om skemaet" gør det genererede artefakt mere bevidst. Timingen betyder også noget — kompaktér ved en fasegrænse, efter planen er fastlagt, ikke midt i en opgave.

Sammenlign med rydning, der smider alt væk og starter forfra: kompaktering forsøger at bevare det væsentlige; rydning satser på, at det allerede er skrevet et bedre sted.

Brug:

"Konteksten bliver tung, og jeg mangler stadig at køre testene."

"Kompaktér, før du går i gang — skriv i opsummeringsprompten, hvad der skal overleve, så den nye session beholder beslutningerne om skemaet og dropper udforskningen."

Komprimering, som agentrammen udløser automatisk, når kontekstvinduet nærmer sig fuld kapacitet.

Agentrammen holder øje med, hvor fyldt kontekstvinduet er. Når det krydser en grænse — ofte omkring 80 % — holder den pause, beder modellen om at opsummere sessionen indtil nu og starter en ny session med opsummeringen. Arbejdet fortsætter derefter, som om intet var sket.

Men noget skete. Komprimering er tabsfuld, og automatisk komprimering sker på et tidspunkt, du ikke selv har valgt. Manuel komprimering sker ved et faseskifte, hvor du kan fortælle modellen, hvad den skal bevare. Automatisk komprimering udløses midt i opgaven, når grænsen nås — måske midt i en refaktorering, hvor opsummeringen selv afgør, hvilke af dine beslutninger der er værd at beholde. Det klassiske symptom er, at agenten fortsætter selvsikkert, men i det skjulte har glemt en begrænsning, du fastsatte for en time siden, og at du først opdager det, når arbejdet begynder at modsige den.

Forsvaret er at forhindre, at den udløses. Hold øje med kontekstindikatoren, og komprimér manuelt ved en naturlig overgang, eller skriv beslutningerne ind i et plandokument eller et overleveringsartefakt på disken, hvor ingen opsummering kan miste dem. De fleste agentrammer lader dig også tilpasse bufferen — flytte grænsen tidligere eller senere eller slå automatisk komprimering helt fra — så du kan justere, hvor meget luft du bevarer, inden den udløses.

Brug:

"Det virker ikke, som om den husker, hvad vi tidligere besluttede om skemaet."

"Automatisk komprimering blev udløst mellem turene — de tidlige beslutninger blev opsummeret, og vi må have mistet noget. Indlæs plandokumentet igen, eller komprimér manuelt næste gang, så du styrer, hvad der bevares."

Et system, der forsøger at gøre en agent stateful på tværs af sessioner. Det gemmer oplysninger i miljøet under en session og indlæser dem igen i kontekstvinduet ved starten af senere sessioner, så agenten bevarer kontinuitet, efter at brugeren har ryddet sessionen.

Et hukommelsessystem har to halvdele. Skrivevejen: under en session registrerer agenten det, den har lært — en præference, du nævnte, eller en projektoplysning — som filer i miljøet. Læsevejen: ved sessionens start indlæser agentrammen filerne eller et indeks over dem tilbage i kontekstvinduet. Mange agentrammer leveres med deres eget hukommelsessystem — Claude Codes `/memory` er ét — men du kan også bygge dit eget: en mappe med noter og en instruktion i AGENTS.md om at slå op i den.

De samme afvejninger som ved andet indhold, der altid indlæses, gælder her. Minder ophobes, så de fleste systemer indlæser et indeks på én linje og lader indholdet ligge bag kontekshenvisninger i stedet for at indsætte alt. Og minder er sekundære kilder, så de driver: En oplysning registreret i marts indlæses med samme sikkerhed i juni, selv efter projektet har ændret sig. Et hukommelsessystem skal beskæres, ligesom AGENTS.md.

Brug:

"Jeg skal hele tiden fortælle den, at jeg bruger Postgres, ikke MySQL."

"Sæt et hukommelsessystem op — skriv det, den lærer, til filsystemet på den første tur, og indlæs det igen ved sessionsstart. Modellen er stateless; hukommelseslaget efterligner kontinuitet."

En fil i miljøet, som agentrammen indlæser i kontekstvinduet, når en session starter — projektets stående briefing til agenten. En konvention på tværs af agentrammer; nogle har også deres egen variant (Claude Codes hedder CLAUDE.md).

Fordi den indlæses automatisk, er den en måde at undgå gentagelser på tværs af sessioner. Modellen er stateless — en rettelse, du giver i én session, er væk i den næste, og du ender med at fortælle hver ny session, at projektet bruger pnpm, at tests køres med en bestemt flag, eller at en mappe er genereret og ikke må røres. Når du har rettet agenten for det samme to gange, er rettelsen en mulig linje i AGENTS.md.

Egnet indhold er det, agenten ikke kan udlede af koden: build- og testkommandoer, konventioner, kodebasen ikke gør indlysende, hårde begrænsninger ("redigér aldrig den genererede klient"). Kort og deklarativt — det er en briefing, ikke dokumentation.

Afvejningen er, at alt i filen altid indlæses. Instruktioner hober sig op, og de fleste er irrelevante for en given opgave. En lang AGENTS.md koster tokens og udvander sig selv — jo flere instruktioner der er i konteksten, desto mindre pålideligt følger modellen hver enkelt.

Undgå: at bruge AGENTS.md til indhold, der bør vises gradvist — alt i filen koster tokens ved hver tur, i hver session, uanset om sessionen har brug for det. En stilguide kan ligge bag en skill eller en kontekshenvisning; behold kun de regler i AGENTS.md, der gælder overalt.

Brug:

"Hvorfor starter hver session med 4k tokens allerede brugt?"

"Se i AGENTS.md — nogen indsatte hele stilguiden dér i stedet for at placere den bag en skill."

At indlæse den kontekst, en agent har brug for lige nu, og bruge kontekshenvisninger til resten. Udtrykket stammer fra brugergrænsefladedesign, hvor det betyder kun at vise brugeren de kontroller, der er relevante for den aktuelle opgave, og gemme resten bag et klik.

Teknikken findes, fordi kontekst koster på to måder. Hvert token, der indlæses på forhånd, faktureres som inputtokens ved hver tur, og hvert token bruger af opmærksomhedsbudgettet, uanset om agenten har brug for det. En AGENTS.md fyldt med hele stilguiden, driftsvejledningen til udrulning og databasekonventionerne gør agenten dårligere til dem alle — instruktionerne, der betyder noget for den aktuelle opgave, drukner i dem, der ikke gør. Tegnet er en agent, der ignorerer regler, du ved, den har i sin kontekst: De er der, men begravet.

Progressiv fremvisning vender dette på hovedet. Hold det altid indlæste lag lille — én sætning pr. emne og en henvisning til, hvor detaljerne findes. Agenten læser stilguiden, når den skriver en komponent, driftsvejledningen, når den udruller, og ingen af delene, når den retter en test. Skills er mønsteret, der er indbygget i agentrammen: En kort beskrivelse indlæses ved hver session, mens hele vejledningen kun indlæses, når den bliver relevant.

Brug:

"Skal jeg lægge hele stilguiden ind i AGENTS.md?"

"Nej — brug progressiv fremvisning. Henvis til stilguiden som en skill, agenten indlæser, når den faktisk skal skrive en komponent. AGENTS.md koster tokens ved hver tur."

En omtale i ét dokument, der peger på et andet, så agenten kun kan hente det ind i kontekstvinduet, når opgaven kræver det. Det er den byggesten, progressiv visning består af.

Grunden til at bruge en henvisning i stedet for at indsætte indholdet er omkostningen. En henvisning fylder én linje i kontekstvinduet. Dokumentet bag den kan indeholde tusinder af tokens, men de koster intet, før agenten følger henvisningen. Indsæt et runbook på 2.000 tokens i AGENTS.md, og hver session betaler for det; erstat det med "deployproces: se `internal/deploy.md`", så indlæser kun sessions, der deployer, filen. Agenten følger henvisningen med et værktøjskald, når opgaven passer.

En henvisning skal have to ting for at virke: en stabil sti og nok beskrivelse til, at agenten ved, hvornår det kan betale sig at følge den. En nøgen sti giver ingen grund til at følge den; "se `internal/deploy.md`" uden antydning af indholdet bliver sprunget over af en session, der havde brug for den. Skriv linjen, så den matcher, hvordan opgaver formuleres: "release, deploy eller rollback — læs `internal/deploy.md` først".

Henvisninger er overalt, når man først lægger mærke til dem: linjer i AGENTS.md, beskrivelser af skills (agentrammen indlæser beskrivelsen; selve skillen ligger bag den), filnavne i en mappeliste, links mellem dokumenter.

En henvisning kan også forbinde en sekundær kilde tilbage til den primære kilde, den stammer fra — opsummeringen fra compaction, der nævner den oprindelige transskription, eller dokumentet, der nævner kildefilen, det beskriver. Dermed kan den sekundære kildes informationstab genskabes: når opsummeringen ikke er tilstrækkelig, følger agenten henvisningen og læser originalen i stedet for at arbejde ud fra det, opsummeringen bevarede.

Undgå: "reference" — for tørt; siger ikke, at det henter mere kontekst frem. "Portal" — for blomstrende.

Brug:

"AGENTS.md er ved at blive enorm."

"Det meste bør være kontekshenvisninger, ikke indhold. Behold reglerne, der altid gælder, direkte i filen; lav deploy-runbooken og stilguiden om til skills, og efterlad en kontekshenvisning."

En færdighed, der kan læres og er samlet som en enhed — instruktioner og ressourcer til at udføre én opgave godt. Den opbevares i miljøet, indtil en kontekshenvisning henter den ind i kontekstvinduet til den aktuelle opgave. Enheden for progressiv visning i en agentramme.

Skills er en åben standard, defineret på agentskills.io — oprindeligt udviklet af Anthropic og siden taget i brug af de fleste større agentrammer, så en skill, der skrives én gang, virker på tværs af dem. Formatet er en mappe med:

• En `SKILL.md`-fil — metadata (som minimum navn og beskrivelse) samt selve instruktionerne
• Eventuelt scripts, som agenten kan køre
• Eventuelt skabeloner og referencemateriale, som instruktionerne peger på

Som standard ligger kun navn og beskrivelse i konteksten. Når agentens opgave passer, indlæser den resten. Indtil da fylder skillen næsten intet — en sætning eller to med tokens, uanset hvor lange de fulde instruktioner er.

Det er forskellen på skills og AGENTS.md, der indlæses i hver session, uanset opgaven. En skill læses, når en bestemt type arbejde opstår — en release, oprettelse af en ny service, skrivning af en migrering — og ignoreres resten af tiden.

Undgå: "værktøj" — et værktøj er noget, agenten kalder; en skill er instruktioner, den læser.

Brug:

"Hvor skal jeg placere deploy-runbooken?"

"Som en skill — agenten indlæser den kun, når opgaven handler om deploy. I AGENTS.md ville den koste tokens ved hver tur for noget, vi bruger ugentligt."

En agent, der startes af en anden agent via et værktøjskald. Kører i sin egen session med sit eget kontekstvindue og sender ét værktøjsresultat tilbage. Forskellig fra en handoff — forælderagenten forventer specifikt et svar; en handoff har ingen returvej. Kan ikke starte flere subagenter — træet går kun ét niveau ned. Subagenter isolerer kontekst, ikke for at opbygge hierarkier.

Formålet er at holde støjende arbejde ude af forælderens kontekst. En bred søgning eller en lang læsetur gennem filer giver sider af værktøjsresultater, hvoraf de fleste kun er relevante, indtil svaret er fundet. Kører du det inde i forælderagenten, bliver det hele i dens kontekst resten af sessionen. Kører du det i en subagent, fylder støjen i stedet et vindue, der kan kasseres — kun slutrapporten lander i forælderens kontekst. Rapporten er en sekundær kilde: Forælderen får subagentens beretning om fundene, ikke de rå resultater, så alt rapporten udelader er usynligt for forælderen.

Subagenter kan også køre parallelt — en forælder kan sende flere af sted på én gang over uafhængige arbejdsområder.

Brug:

"Grep-resultaterne fylder hele min kontekst."

"Start en subagent til søgningen — den bruger sit eget kontekstvindue på støjen og rapporterer de to filstier, du faktisk har brug for."

Et arbejdsmønster, hvor et eller flere mennesker arbejder sammen med agenten under en session — gennemgår, omdirigerer eller samarbejder i realtid. Mennesket er til stede og engageret, ikke kun en port, der godkender enkelte handlinger.

Kontrasten er AFK-arbejde, hvor agenten kører uden opsyn, og du vurderer resultatet bagefter. Mennesket-i-løkken betyder, at problemer opdages, mens de stadig er billige at løse: Du ser agenten vælge den forkerte fil, misforstå kravet eller gå ned ad en blindgyde og kan styre den tilbage med én sætning — i stedet for at opdage tyve minutters selvsikkert arbejde, bygget på den fejl. Agenter ved ikke pålideligt, hvornår de er på afveje; alene fortsætter de ofte hellere end at stoppe og spørge.

Hvilket mønster der passer, afhænger af arbejdet. Velbeskrevne opgaver med lav risiko og et resultat, der er let at kontrollere, egner sig til AFK. Opgaver, der er tvetydige eller uigenkaldelige, eller hvor det færdige resultat er svært at gennemgå — en skemamigrering, et vanskeligt designvalg, alt der berører produktion — egner sig til at blive i løkken. Vurderingen er i bund og grund: Hvor dyr er en forkert afstikker, og hvor sent ville du opdage den?

Noget arbejde er i løkken af natur, fordi dine reaktioner er inputtet. Grilling virker kun, hvis du er til stede for at besvare spørgsmålene; prototyping virker kun, hvis du kan reagere på artefaktet.

At blive i løkken koster din opmærksomhed, som er den knappe ressource. At blive bedre til at bruge agenter handler delvist om at flytte mere arbejde sikkert ud af løkken — med planer, automatiske kontroller og menneskelig gennemgang til sidst i stedet for opsyn undervejs. En softwarefabrik går videre ved at starte sessioner fra triggere, så du ikke engang behøver sætte arbejdet i gang.

Brug:

"Skal den køre AFK natten over?"

"Nej, det er en skemamigrering — hold den med mennesket i løkken. Jeg vil se hvert trin og styre den, hvis den vælger den forkerte kolonne at fylde tilbage fra."

Away from keyboard. Et arbejdsmønster, hvor brugeren starter en session og lader agenten køre uden opsyn. En multiplikator for gennemløbet i AI-kodning — mange AFK-sessioner kan køre parallelt, mens du sover, spiser eller arbejder med noget andet. Kræver som regel en rummelig permission mode plus sandboxing for at være sikkert.

Når du ikke er der, håndterer agenten tvetydighed anderledes. Mens du ser på, bliver en tvetydig beslutning til et spørgsmål, som du besvarer; når du er gået, vælger agenten en standardløsning og fortsætter, og alle senere beslutninger bygger på det gæt. Den typiske fejl er at vende tilbage til timers færdigt, selvsikkert arbejde, der bygger på en forkert beslutning fra de første ti minutter. Arbejdet er ikke sjusket — det hænger sammen, bare om det forkerte.

Da du ikke kan give input under kørslen, skal du give det før og efter. Før: Afklar tvetydigheden på forhånd — en grilling-session, en skriftlig spec — så agenten får færre huller at udfylde alene. Under: Automatiske kontroller og automatisk gennemgang erstatter den opmærksomhed, du ikke giver, og fejler hurtigt på det, der kan fanges mekanisk. Efter: Kørslen ender i noget, der kan gennemgås — en PR, ikke ændringer, der allerede er merged. AFK fjerner ikke menneskelig gennemgang; den udsætter den til sidst. Derfor skal det, der kommer til sidst, være værd at gennemgå. Det er også derfor, AX betyder mest i AFK-kørsler — når ingen holder øje, er miljøet den eneste støtte, agenten har.

Undgå: "baggrundsagent" — det fremhæver maskinen ("kører i baggrunden") i stedet for det menneskelige mønster ("brugeren er gået"). AFK betegner det vigtige faktum: Brugeren kigger ikke med.

Brug:

"Jeg kører det AFK — tre agenter i sandbox arbejder på refactoren, og jeg gennemgår PR'erne om morgenen."

"Bypass permissions?"

"Ja, filsystem kun til læsning, intet netværk."

En deterministisk kontrol, der kører i miljøet — tests, typekontrol, lint, build, pre-commit-hooks. Bestået eller fejlet, uden vurdering. Det signal, en agent kan bruge til at rette sig selv uden at involvere andre. En ustabil test er en ødelagt kontrol, ikke fravær af kontrol; automatiske kontroller er deterministiske efter hensigten.

Selvkorrektion fungerer som en løkke. Agenten foretager en ændring, kører kontrollen som et tool call, og fejloutputtet lander i dens kontekstvindue — en typefejl med fil og linje, en fejlet påstand med forventet og faktisk værdi. Det er nok til, at agenten kan løse problemet og køre kontrollen igen, igen og igen indtil den består, uden menneskelig indgriben. Determinisme gør løkken pålidelig: den samme kode giver altid samme dom, så en bestået kontrol betyder noget. En ustabil kontrol forgifter dette — agenten "retter" kode, der var i orden, eller prøver igen efter en reel fejl, indtil den tilfældigvis går væk.

Derfor er gode kontroller en stor del af en kodebases AX. En agent i et repo med stramme typer, en hurtig testsuite og en linter fanger de fleste af sine egne fejl, før du ser dem; en agent i et repo uden nogen af delene afleverer det, den producerer. Forskellen betyder mest ved AFK-kørsler, hvor kontrollerne er den eneste verifikation under kørslen. Men en kontrol fanger kun det, den hævder at kontrollere — grønne kontroller betyder, at de hævdede egenskaber holder, ikke at koden er korrekt. Hullerne, der kræver vurdering, er det, automatisk gennemgang og menneskelig gennemgang skal dække.

Undgå: "feedback-loop" / "backpressure" — begge blander kontroller sammen med gennemgang. Undgå: "test" — tests er automatiske kontroller, men ikke alle automatiske kontroller er tests.

Brug:

"Agenten bliver ved med at aflevere ødelagt kode i AFK-kørslerne."

"Hvilke automatiske kontroller er koblet til sandboxen?"

"Kun unit-testene."

"Tilføj typekontrol og lint — så kan den rette sig selv ud fra dem, før PR'en overhovedet lander."

En agent, der gennemgår en anden agents arbejde, ofte med en anden model eller systemprompt. Ikke-deterministisk: den danner en vurdering. Kan køre hvor som helst — før merge på en PR, efterfølgende på commit-historik eller midt i en session som subagent. En LLM-as-judge i CI er automatisk gennemgang, ikke en automatisk kontrol; kategorien afgøres af, hvad påstanden gør, ikke hvor den kører.

Adskillelsen fra den arbejdende agent er det, der gør det effektivt. Beder du agenten, der skrev koden, om at gennemgå sit eget arbejde, får du meget lidt ud af det — sessionen, der skabte fejlen, indeholder også ræsonnementet bag den, og agenten læser sine egne konklusioner som bekræftelse. En reviewer med et friskt kontekstvindue har ikke den tilknytning: den ser diffen som en fremmed ville gøre, og det er grundlaget for gennemgang. En anden model eller en systemprompt målrettet review skærper dette yderligere — andre blinde vinkler og en prompt afgrænset til det, du faktisk går op i (sikkerhed, API-kontrakter, ydeevne) i stedet for et vagt "find problemer".

Den ligger mellem de andre gennemgangslag. Automatiske kontroller er deterministiske og fanger det, der kan påstås mekanisk; menneskelig gennemgang er dyr og skalerer dårligst. Automatisk gennemgang ligger i midten: Den fanger problemer, der kræver vurdering — et misvisende funktionsnavn, et overset randtilfælde — til maskinpris. Fordi den er ikke-deterministisk, kan den overse ting og flagge problemer, der ikke findes; brug den som et filter, der hæver bundniveauet før et menneske kigger, ikke som en port, der erstatter mennesket.

Undgå: "AI review" / "agent review" — for vagt til at skelne fra agenten, der udfører arbejdet.

Brug:

"Vi får for mange dårlige PR'er fra AFK-kørslerne."

"Tilføj et trin med automatisk gennemgang før merge — anden model, separat systemprompt, afgrænset til sikkerhed og kontraktændringer."

At brugeren læser den kode, agenten har produceret, og danner sig en vurdering af den. Det tæller at læse diffen eller de ændrede filer; at læse agentens beskrivelse af, hvad den gjorde, tæller ikke — fortællingen er ikke artefaktet. Beskrivelsen er en sekundær kilde, skrevet af den part, der bliver gennemgået; diffen er den primære kilde, og gennemgang betyder, at man læser den.

Agenter øger mængden af produceret kode, så gennemgangen bliver flaskehalsen. En nyttig idé er at lægge forskellige gennemgangsstrategier i lag. Automatiske kontroller fanger mekaniske fejl, automatisk gennemgang fanger fejl, der kan beskrives, og menneskelig gennemgang forbeholdes det, kun du kan bedømme — om ændringen er den rigtige, om fremgangsmåden passer til kodebasen, og om det overhovedet bør findes.

Gennemgang er også billigere, når den sker tidligt. Det tager minutter at læse en plan, før arbejdet begynder, eller en lille diff undervejs; det tager længere tid at udgrave en færdig gren efter en AFK-kørsel. Hvor du placerer kontrolpunktet for gennemgangen, er en human-in-the-loop-beslutning, ikke en eftertanke.

Undgå: kun "kodegennemgang" — det er tvetydigt, fordi det både kan betyde menneskelig og automatisk gennemgang.

Brug:

"Jeg gennemgik AFK-outputtet manuelt."

"Læste du diffen eller kun opsummeringen?"

"Diffen. Opsummeringen sagde, at den slettede forældet kode — det viste sig, at funktionen blev kaldt fra en genereret fil."

Et arbejdsmønster, hvor brugeren accepterer agentens kode uden menneskelig gennemgang. Diffen behandles som uigennemsigtig — det afgørende er, om programmet opfører sig rigtigt, ikke hvad der står i den. Automatisk gennemgang og automatiske kontroller kan stadig køre; vibe-kodning siger ikke noget om nogen af delene.

Udtrykket kommer fra Andrej Karpathy, der opfandt det i begyndelsen af 2025: Du "overgiver dig fuldstændigt til stemningen" og "glemmer, at koden overhovedet findes" — beskriv, hvad du vil have, acceptér det, der kommer tilbage, og bedøm det ved at køre det.

Vibe-kodning bytter inspektion for hastighed. At læse diffs er som regel det langsomste trin i agentdrevet arbejde, så når det droppes, fjernes den største flaskehals. For kode, hvor fejl er billige — prototyper, engangsscripts, interne værktøjer — er det en rimelig handel. Risikoen vokser med kodens levetid og betydning.

Omkostningen viser sig senere. Vibe-kodede ændringer samler sig i en kodebase, ingen har læst, og kun adfærden blev kontrolleret. Derfor kan alt, adfærden ikke afslører — en hemmelighed skrevet i logs, et overset randtilfælde eller forkert datahåndtering uden synlige tegn — gå ubemærket i produktion. Første gang nogen fejlsøger systemet, er første gang nogen læser koden. Når menneskelig gennemgang er væk, er den automatiske verifikation, der stadig kører — tests, typer, automatisk gennemgang — den eneste port, koden passerer. Den samme tilgang anvendt på en hel kodebase eller del af en, hvor ændringerne kommer fra en softwarefabrik, er en dark factory.

Undgå: "vibe-kodning" som synonym for "AI-kodning af lav kvalitet" — udtrykket betegner gennemgangstilgangen, ikke den resulterende kode.

Brug:

"Læste du, hvad den ændrede i auth-flowet?"

"Jeg vibe-kodede det — login virker stadig, det var alt, jeg tjekkede."

"Læs diffen, før du pusher; vibe-kodning af auth er sådan, hemmeligheder lækker ind i logs."

Den fælles forståelse af det, der bliver bygget, som deles mellem brugeren og agenten, men som er uafhængig af ethvert artefakt. Brooks' begreb (The Design of Design): Samtalen, overleveringsartefakter og koden er alle artefakter, der forsøger at indfange eller nå frem til designkonceptet, men ingen af dem er det. Designkonceptets kvalitet mærkes gennem kvaliteten af den samtale, der formede det.

Begrebet sætter navn på årsagen til en velkendt frustration: Agenten skriver præcis det, du bad om, men resultatet er stadig forkert. Den sædvanlige årsag er, at du ikke selv havde fundet helt ud af, hvad du ønskede. Designkonceptet var ikke færdigt i dit eget hoved — prompten indfangede det, du havde afklaret, og sagde intet om det, du endnu ikke havde. Agenten udfyldte de tomrum med sine egne antagelser, fordi der ikke var noget fælles holdepunkt. Intet gik i stykker. I havde ikke et fælles designkoncept, for der var endnu ikke et helt koncept at dele.

Du kan se, at et designkoncept er fælles, på samme måde som med en kollega: Den anden begynder at besvare spørgsmål, du endnu ikke har stillet, på den måde, du selv ville have gjort. Indtil da er arbejdet en samtale — grilling er den bevidste udgave — og en specifikation skrevet for tidligt gør blot uoverensstemmelsen mere holdbar ved at indfange den i et artefakt. Designkonceptet ændrer sig også, efterhånden som du lærer mere; artefakterne halter efter, og derfor kan en specifikation, der var tro mod sidste uges forståelse, stadig vildlede denne uges session.

Brug:

"Den skriver præcis det, jeg bad om, men det er stadig forkert."

"I deler endnu ikke et designkoncept — agenten udfylder hullerne med antagelser. Bliv ved med at tale, indtil annulleringer, tilbagebetalinger og delvis ordreopfyldelse hænger sammen for jer begge, før du lader den skrive en specifikation."

En teknik til at udvikle et designkoncept sammen med en agent: Agenten interviewer brugeren sokratisk, én beslutning ad gangen, og foreslår et anbefalet svar til hver. Det bremser hastværket mod en færdig plan — der skrives ikke et overdragelsesartefakt, før konceptet er stabilt.

Teknikken findes, fordi agenter udfylder huller i stilhed. Bliver en agent bedt om at skrive en spec ud fra en prompt på to linjer, standser den ikke ved de beslutninger, du endnu ikke har truffet — den vælger standarder og skriver dem ind. Resultatet ser komplet ud, og gættene kan ikke skelnes fra dine valg. Derfor opdager du dem sent: under review, eller når den byggede funktion håndterer et randtilfælde på en måde, du aldrig valgte. Grilling vender dette om — i stedet for at gætte skal agenten spørge.

Det er en teknik med mennesket i løkken: dine svar er inputtet. Kan et spørgsmål ikke besvares i samtalen — fordi du er nødt til at se løsningen — så skift til prototyping.

Brug:

"Den gik direkte i gang med at skrive specifikationen og fik annulleringslogikken forkert."

"Grill den først — få den til at spørge om delvise annulleringer, refunderinger og timing, før den skriver noget ind i dokumentet. Billigere at afklare i samtalen end i kode."

At få agenten til at bygge en hurtig, grov udgave af noget, når en samtale er for upræcis, og du har brug for et konkret artefakt at tale ud fra.

Grilling afklarer designbeslutninger gennem samtale. Samtale er billig, men upræcis: Nogle spørgsmål kan ikke besvares med ord — hvordan en interaktion føles, om en API-form er behagelig at bruge i rigtig kaldende kode, eller om layoutet fungerer med realistiske datamængder. Interviewet når et spørgsmål, og dit ærlige svar er: "Det ved jeg ikke, jeg er nødt til at se det." Herefter kører diskussionen i ring. Få i stedet agenten til at bygge det, se på resultatet, og vend tilbage til samtalen med et svar.

Agenter sænker byggeomkostningen, og det er det, der gør metoden praktisk. En grov udgave, der før tog en dag at skitsere, kan nu laves på få minutter, så det er værd at gøre rutinemæssigt. Det er en human-in-the-loop-teknik: Prototypen er lavet, så du kan reagere på den.

Man stopper som regel ikke efter ét kig. Iterér med prototypen — reagér, bed om en ændring, reagér igen — så hver runde afklarer endnu en beslutning ud fra det konkrete artefakt med større præcision, end samtalen kan give.

En prototype behøver ikke være gennemført rå. Du kan bygge de dele, du faktisk evaluerer, i produktionskvalitet, så komponenten eller API'et, du reagerede på, kan overføres til den rigtige kodebase, når beslutningen er truffet. Derfor er prototyper vigtigt materiale, som specifikationen kan henvise til.

Brug:

"Vi har brugt en halv time på at diskutere, om guiden skal være én side eller tre trin."

"Ord afgør det ikke — få agenten til at prototype begge muligheder. Vi klikker os igennem dem og ved det om fem minutter."

Udvikleroplevelse — hvor let en kodebase og dens værktøjskæde gør det for mennesker at udføre godt arbejde. God DX er hurtig feedback, tydelige fejlmeddelelser, dokumentation, der besvarer det spørgsmål, man faktisk har, og opsætning, der virker første gang. Begrebet er meget ældre end AI-kodning; i denne ordbog bruges det især som kontrast til AX.

DX er samspillet mellem mennesket og kodebasen — ikke andet. Den største forskel mellem de to målgrupper er, at mennesker er stateful, og agenter er stateless. Et menneske lærer kodebasen én gang og bærer den viden med sig hver dag derefter. Derfor kan dårlig DX overleves: Man omgår langsom CI ved at samle sine pushes, manglende dokumentation ved at spørge én gang i Slack og forvirrende struktur ved at huske, hvor tingene ligger. Omvejene hober sig op, og et team bliver produktivt i en kodebase, der modarbejder det.

Agenter møder den samme kodebase uden nogen sådan ophobning. Stateless på tværs af sessioner lærer en agent kodebasen fra bunden hver gang — den har gavn af den hurtige testsuite og tydelige fejlmeddelelser, men alt, den fandt ud af i går, er væk, medmindre det blev skrevet ind i miljøet, som agenten kun opfatter gennem værktøjsresultater. Det er forskellen, AX sætter navn på: de dele af DX, der overlever, når udvikleren er en agent, samt forhold mennesker ikke har brug for at bekymre sig om, som at holde kontekstvinduet frit.

Overlap betyder, at investering i DX ofte forbedrer AX gratis — stramme typer, hurtige tests og forudsigelig struktur hjælper begge. Forskellene betyder, at det ikke altid gør: Et flot onboardingdokument hjælper et menneske i en uge og slet ikke en agent, medmindre det kan findes fra AGENTS.md.

Brug:

"Vores DX er fin — nye medarbejdere er produktive efter en uge."

"Produktive, fordi nogen sidder sammen med dem den uge. Agenten får ikke den uge; vurder AX særskilt."

Agentoplevelse — hvor godt miljøet er sat op til, at en agent kan udføre godt arbejde i en kodebase. Agentens pendant til DX. Når den samme agent klarer sig godt i ét repo og dårligt i et andet — samme model, samme agentramme — skyldes forskellen som regel AX. Man får lyst til at give modellen skylden eller skrive prompten om; løsningen findes oftere i repoet.

God AX har tre hoveddimensioner:

AX og DX overlapper — gode kontroller og ren arkitektur hjælper begge målgrupper — men de adskiller sig også. Mennesker kan leve med viden, der kun findes i teamet, langsom CI og "spørg Sarah om billing-modulet"; agenter kan ikke. Agenter har ikke gavn af IDE-værktøjstips eller flotte dashboards; de har brug for fejl som tekst i et værktøjsresultat. En kodebase kan have god DX og dårlig AX.

Undgå: at behandle AX som synonym for DX — målgrupperne kræver forskellige investeringer.

Brug:

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

"API-repoet har stramme typer og en hurtig testsuite; frontend har ingen af delene og fyrre skills, der altid indlæses. Det er et AX-efterslæb, ikke et modelproblem."

Et arbejdssystem, hvor agent-sessioner startes af triggere — et oprettet issue, en tidsplan, en CI-fejl eller en anden sessions afslutning — i stedet for af et menneske. Dermed kører mere arbejde AFK, og menneskelig opmærksomhed bruges på de tilbageværende beslutninger, hvor et menneske er med i løkken.

Uden en fabrik begynder hver session, fordi nogen startede den. Selv fuldt AFK-arbejde venter på, at en person åbner sessionen, peger den mod en ticket og sætter den i gang. Teams vil levere mere, end det tillader. En fabrik fjerner mennesket fra at starte sessioner, men ikke nødvendigvis fra noget andet.

Almindelige triggere og de sessioner, de starter:

En fabrik behøver ikke dække hele softwareprocessen. Ét cronjob, der kører én type session og åbner én PR, der kan gennemgås, er en fabrik. Det er nyttigt at begynde småt: En snæver løkke producerer små, ensartede PR'er, og gennemgang af dem viser, hvor meget man kan stole på løkken, før den udvides.

Mennesker kan være hvor som helst i fabrikken — skrive og mærke de issues, der udløser sessioner, godkende en plan før implementeringen starter, udføre menneskelig gennemgang før merge. At beslutte, hvilke af disse beslutninger der fortsat skal være menneskelige, er det vigtigste designspørgsmål. En kodebase eller del af en, hvor ingen mennesker gennemgår fabrikkens output, er en dark factory.

Brug:

"Hvem rettede alle overtrædelserne af `no-floating-promises`?"

"Fabrikken. Cronjobbet vælger én lintregel hver nat og åbner en PR. Jeg gennemgår den bare om morgenen."

En kodebase eller del af en, hvor en softwarefabrik skriver koden, og intet menneske læser den. Der er ingen menneskelig gennemgang. Mennesker kan stadig skrive de issues, der sætter arbejdet i gang. Men ingen læser koden, der kommer ud. Navnet kommer fra "lights-out"-fabrikker, hvor produktionen foregår uden mennesker på gulvet.

En dark factory er vibe-kodning for et område af koden, ikke for én ændring. Når du vibe-koder, vælger du ikke at læse en ændring, du selv har bedt om. Men du ved, at ændringen findes. I en dark factory træffer teamet det valg én gang for hele området. Derefter beder ingen om at se hver ændring, og ingen ser den. Ændringerne kommer lige så hurtigt, som triggers sætter nyt arbejde i gang.

Problemet viser sig, når noget går i stykker. Du ved ikke, hvad der blev ændret, for ingen læste ændringerne. Du skal fejlfinde kode, ingen på teamet har læst. Årsagen kan ligge i en hvilken som helst af de mange ændringer, og hver eneste bestod kontrollen.

Automatiske kontroller og automatisk gennemgang er de eneste porte. Finder de ikke et problem, ender problemet i koden.

Undgå: kun at kalde en kodebase "dark", fordi fabrikken kører uden opsyn. Hvis agent-sessioner kører AFK, og et menneske gennemgår deres PR'er, er det en softwarefabrik. Det er ikke en dark factory.

Brug:

"Hvem ændrede retry-logikken i billing-servicen? Ingen på teamet kan huske det."

"Billing-servicen er en dark factory. Agenterne merger alle ændringer, der består CI. Ingen læste den ændring."