Ordlista över AI

En rörlig etikett, inte en teknik. ”AI” betecknar inte en fast sak på samma sätt som modell eller token gör — ordet pekar på vad datorer nyligen har börjat kunna göra på ett imponerande sätt. Just nu syftar det på stora språkmodeller. Tidigare har det pekat på helt andra saker:

Pekaren flyttas genom en känd mekanism, ibland kallad AI-effekten: när en teknik fungerar pålitligt får den ett nytt namn — den är ”bara” sökning, ”bara” statistik — och ”AI” glider vidare till nästa olösta sak. Observationen är gammal. Bertram Raphael uttryckte det så här 1971: ”AI är ett samlingsnamn för problem som vi ännu inte vet hur vi ska lösa ordentligt med datorer.” Larry Teslers version, från omkring 1979: ”Intelligens är det maskiner ännu inte har gjort.”

Därför pratar människor som diskuterar AI så ofta förbi varandra. Ett påstående som ”AI kan inte resonera” eller ”AI är överdrivet hajpat” bär på en dold tidsstämpel — det kan gälla expertsystem, bildklassificerare från 2010-talet eller förra månadens språkmodell, och varje hänvisning stöder en annan slutsats. När en diskussion om AI kör fast är lösningen oftast att byta ut ordet mot den exakta term som faktiskt avses: modellen, agentramverket, agenten eller kontexten den fick.

Undvik: ”AI” i tekniska påståenden — namnge den del du menar. ”AI-kodning” som benämning på arbetssättet går bra; ”AI:n hallucinerar” gör det inte.

Användning:

”CTO:n vill veta om AI kan hantera triagekön.”

”Översätt det innan ni avgränsar uppgiften — hon menar en LLM i ett agentramverk med åtkomst till ärendesystemet. ”AI” i sig är ingen specifikation.”

Parametrarna. Tillståndslös — utför nästa-token-prediktion och inget annat. ”Claude Opus 4.x” och ”GPT-5.x” är modeller. På egen hand kan en modell inte agera som en agent; den måste få en agentmiljö.

Modeller kan inte läsa filer, köra kommandon, surfa på webben eller minnas gårdagen — de tar in token och förutsäger utgående token, en gång per modell-leverantörsförfrågan. Allt som känns som att en agent arbetar — väljer verktyg, läser resultat och upprepar processen tills uppgiften är klar — är agentmiljön som samordnar många sådana förutsägelser efter varandra.

Modell-leverantörer erbjuder modeller i nivåer: en stor modell som är smartast men långsam och dyr, och mindre modeller som är snabbare och billigare men mindre kapabla. Att välja nivå är ett verkligt beslut — en tung modell för planering och svår felsökning, en lätt modell för mekaniska ändringar — och agentmiljöer låter dig byta mitt i en session.

Att vara noggrann med ordet gör också felsökningen bättre. ”Modellen är dålig på det här” är ett specifikt påstående — samma modell i en annan agentmiljö eller med en annan kontext beter sig ofta helt annorlunda. Innan du skyller på modellen bör du kontrollera vad den fick: de flesta besvikna svar beror på kontext eller agentmiljö, inte parametrar.

Användning:

”Ska vi byta modell från Sonnet till Opus i planeringssteget?”

”Prova — men agentmiljön gör det mesta av jobbet här. Modellbytet hjälper inte om systemprompten och verktygen är fel.”

Siffrorna inuti en modell — ofta miljarder stycken — som finjusteras under träningen. Allt modellen ”vet” finns i dem. Träningen bestämmer dem; inferensen använder dem oförändrade. Kallas även vikter.

Rent mekaniskt är parametrarna det som omvandlar indata till utdata. Nästa-token-prediktion är en enorm beräkning: token i kontextfönstret matas in, multipliceras genom parametrarna och ger en förutsägelse om nästa token. Det finns ingen faktadatabas inuti modellen och ingen koduppslagstabell — bara de här talen, ordnade så att beräkningen tenderar att ge användbara resultat. Fakta som modellen kan återge från träningen, som ett standardbiblioteks API, är parametrisk kunskap: den finns lagrad i parametrarna och hämtas inte någon annanstans ifrån.

Viktigast att förstå är att parametrarna fryses efter träningen. Ingenting du gör i en session ändrar dem — inga rättelser, inga kodbaser du visar och inga misstag den lär sig av. Varje session körs med samma tal. Därför är modellen tillståndslös, därför upphör dess inbyggda kunskap vid kunskapsgränsen, och därför måste projektspecifik information tillföras via kontext. Det enda sättet att ändra parametrarna är mer träning — vilket i praktiken skapar en annan modell.

Användning:

”Kan vi finjustera den på vår kodbas?”

”Det skulle uppdatera parametrarna — modellen skulle bli en annan efteråt. För ett enda projekt är det nästan alltid billigare att läsa in kodbasen som kontext än att träna om modellen.”

Processen som ställer in en modells parametrar genom att exponera den för stora mängder text och justera parametrarna för att förbättra nästa-token-prediktionen. En dyr engångsprocess som utförs av modell-leverantören. Omfattar både förträning (den stora körningen) och efterträning (senare förfiningar som instruktionsföljning och säkerhet); på den här ordlistans detaljnivå spelar skillnaden ingen roll.

Mekanismen bygger på upprepning i stor skala: visa modellen ett textstycke, låt den förutsäga nästa token, förskjut parametrarna mot den token som faktiskt kom och upprepa detta över biljoner token. Inga fakta eller regler lagras som sådana — allt modellen ”vet” är en bieffekt av att den blivit bättre på att förutsäga, komprimerad till parametrarna som parametrisk kunskap.

Två följder spelar roll i vardagen. Träningen avslutas vid en viss tidpunkt, så modellen har en kunskapsgräns — den har inte sett biblioteksversionen du uppgraderade till förra månaden. Och du kan inte själv träna modellen: när den inte känner till din kodbas, dina konventioner eller dina interna API:er är lösningen aldrig ”lär modellen” — lägg i stället in materialet i kontexten, den enda indata du kan styra.

Användning:

”Kan vi få den att känna till vårt interna API?”

”Inte genom träning — det är en process som tar månader och utförs av modell-leverantören. Läs i stället in API-dokumentationen i kontexten; det är den spak du faktiskt kan använda.”

Köra en tränad modell för att skapa utdata — det som händer vid varje modell-leverantörsförfrågan. Parametrarna förblir oförändrade; modellen utför bara nästa-token-prediktion över den kontext den fått. Billigt jämfört med träning, men debiteras per token och utgör den dominerande kostnaden för att använda en modell.

En modells liv delas in i två faser:

Inget du gör under inferensen skrivs tillbaka till parametrarna — därför fastnar inte en rättelse du gör i dag till i morgon. Modellen som gör samma misstag nästa session, trots att du noggrant förklarade lösningen, har inte ignorerat dig; den kan inte lära sig av utbytet. Modellen är tillståndslös — kontinuiteten måste komma utifrån, från kontextfönstret eller ett minnessystem.

Mekanismen förklarar också faktureringen. Varje förfrågan kör modellen över hela kontexten, så kostnaden skalar med indatatoken och utdatatoken, och en agent med dussintals verktygsanrop betalar för inferens vid varje rundresa. Därför är kontextens storlek en kostnadsfråga såväl som en kvalitetsfråga.

Användning:

”Varför ökar fakturan med användningen i stället för att vara en fast licensavgift?”

”Du betalar för inferens — varje modell-leverantörsförfrågan kör modellen på leverantörens maskinvara. Träningen är redan avklarad, men inferenskostnaden tillkommer per förfrågan, och en enda tur kan delas upp i många förfrågningar när verktyg anropas.”

Ansträngning är en ratt för hur mycket resonemang en modell använder innan den svarar. Den ställs in för varje modell-leverantörsförfrågan och styr hur länge modellen tänker innan den börjar skriva svaret du ser. Det tänkandet skapas vid inferens, precis som allt annat; agentmiljön döljer det ofta, men det är verkligt arbete som modellen utför.

Högre ansträngning kostar mer och tar längre tid. Resonemanget avges som token, faktureras som utdatatoken även när du aldrig ser dem och produceras en token i taget — därför förlänger högre ansträngning väntan innan svaret kommer och ökar kostnaden. Avvägningen står mellan mer eftertanke och hastighet och kostnad.

De flesta agentmiljöer visar ansträngning som en kort stege:

Det får konsekvenser åt båda hållen när nivån är fel. Ställ in för låg ansträngning för ett svårt problem och du får ett självsäkert, ytligt svar som hoppade över det resonemang problemet krävde — det ser bra ut men är fel på ett sätt som kostar dig senare. Välj max för ett namnbyte på en rad och du får vänta länge på en tanke som inte ger något som den lägsta nivån inte hade gett.

Anpassa ansträngningen efter uppgiften, inte sessionen. Höj den för den del som verkligen kräver svårt resonemang och sänk den igen för rutinjobbet runt omkring.

Användning:

”Den fortsätter att misslyckas med den här samtidighetsändringen — jag har förklarat den tre gånger.”

”Höj ansträngningen. Det här är en bugg som kräver mycket resonemang, och på standardnivån tänker den inte tillräckligt länge innan den bestämmer sig för en metod.”

Den minsta enhet en modell läser och skriver. Den är ungefär lika stor som ett ord, men inte exakt — vanliga ord är en token, medan ovanliga eller långa ord delas upp i flera. Storleken på kontextfönstret, kostnaden och fördröjningen räknas alla i token.

Text blir token genom en tokeniserare: ett fast ordförråd med tiotusentals fragment, inlärt före träningen, som delar upp alla indata i en följd av ordförrådsposter. Modellen ser aldrig tecken eller ord — varje textbit omvandlas till token på vägen in, och nästa-token-prediktion skapar utdata en token i taget på vägen ut.

Som tumregel motsvarar en token ungefär tre fjärdedelar av ett engelskt ord, så tusen token är ungefär 750 ord. Kod är mindre förutsägbar: vanliga nyckelord och uttryck tokeniseras kompakt, medan genererade identifierare, hashvärden, base64-strängar och minifierad utdata delas upp i många token per ”ord”. Mönstret är att text som förekommer ofta i tokeniserarens källmaterial får korta och effektiva kodningar; text som inte gör det hackas upp i många små delar. En hash som `a3f9c2e1` har aldrig förekommit någonstans och delas därför upp i många token, medan `function` är en enda. Därför kan en liten fil full av ovanliga strängar ta upp en förvånansvärt stor del av kontextfönstret.

Token är måttenheten för allt annat. Kostnaden är per token — leverantörer fakturerar indatatoken och utdatatoken separat. Hastigheten mäts i token per sekund eftersom utdata skapas en token i taget. Och kontextfönstret rymmer ett fast antal token, så tokenantalet i dina filer avgör hur mycket som får plats.

Undvik: ”ord” — token-gränser motsvarar inte ordgränser, och token per sekund respektive token per dollar är de enheter som faktiskt spelar roll.

Användning:

”Hur stor kommer den här prompten att bli?”

”Kör den genom tokeniseraren — schemat är kompakt men JSON-nycklarna är märkliga, så de delas upp i fler token än du tror.”

Vad modellen faktiskt gör. Givet en kontext samplar den en nästa token, lägger till den och kör igen. All utdata — en mening, ett verktygsanrop eller en fil på tusen rader — byggs en token i taget. Modellen har inget annat arbetssätt.

Varje steg fungerar likadant: token i kontextfönstret bearbetas genom parametrarna, som ger en sannolikhet för varje token i ordförrådet — den här är mycket sannolik som nästa, den där mindre sannolik. En token samplas från sannolikheterna, läggs till och loopen körs igen med en något längre kontext. Samplingssteget förklarar varför samma prompt ger olika utdata vid olika körningar: icke-determinism är inbyggd i mekanismen, inte en bugg som lagts ovanpå.

När du håller fast vid den här mekanismen blir beteenden som annars ser märkliga ut begripliga. Modellen kontrollerar aldrig om en token är sann innan den avger den — bara om den är sannolik — vilket är roten till hallucinationer. Den binder sig till varje token efter hand, så en självsäker inledningsmening kan styra resten av svaret åt fel håll. Och eftersom utdatatoken skapas strikt en i taget sätter genereringshastigheten en gräns för hur snabbt en agent kan arbeta.

Användning:

”Hur ’bestämmer’ agenten sig för att anropa ett verktyg?”

”Det gör den inte — allt bygger på nästa-token-prediktion. Verktygsanropet är bara en strukturerad sträng som agentmiljön tolkar ur utdataströmmen.”

Samma indata kan ge olika utdata. Kör en modell två gånger med identisk kontext, så kan du få två olika svar — ibland skiljer sig ett ord, ibland är tillvägagångssättet helt annorlunda. Ingenting i koden behöver ändras för att det ska hända.

Det beror på hur modeller skapar text och hur modell-leverantörer hanterar förfrågningar. Under inferensen skapar modellen en sannolikhetsfördelning över möjliga nästa token, och en av dem väljs genom sampling — vanligtvis med viss avsiktlig slumpmässighet, eftersom det ger repetitiv text av sämre kvalitet att alltid välja den mest sannolika token. En token som samplas annorlunda tidigt i ett svar ändrar alla efterföljande token, och på så sätt kan ett enda annorlunda ord leda till ett helt annat tillvägagångssätt. Hantering på leverantörssidan skapar ytterligare variation: förfrågningar grupperas på delad maskinvara, och små skillnader i flyttal mellan grupper kan avgöra ett jämnt val mellan två token. Det finns ingen inställning du kan slå om för att få allt detta att försvinna.

Räkna med variation i hur en agent hanterar samma uppgift. De flesta svar hamnar inom en rimlig normalfördelning av kvalitet — därför är variationen uthärdlig — men ytterkanterna finns på riktigt: vissa dagar känns modellen skarp, andra dagar verkar den ha tappat tråden. Samma uppgift, olika tärningskast. Det får två praktiska följder. Ett nytt försök är en legitim strategi: ett misslyckat försök är ett enda utfall från fördelningen, och ett nytt försök med samma uppgift kan helt enkelt lyckas bättre. Och verifiering är viktigare än med deterministiska verktyg — du kan inte testa agentens beteende en gång och lita på att det upprepas, så automatiska kontroller måste fånga de dåliga utfallen.

Var försiktig så att du inte bygger upp en överdriven berättelse kring detta. Människor är mönsterigenkännande varelser, och en rad dåliga körningar kan kännas som bevis för att ”modellen blev sämre den här veckan”. Oftast handlar det bara om fördelningen.

Användning:

”Claude har varit usel i dag. Har de släppt en sämre version?”

”Troligen inte — modellutdata är icke-deterministiska. Du kommer att ha bra och dåliga dagar med samma uppgift. Försök igen i morgon innan du börjar leta efter en orsak.”

Det som tillhandahåller en modell för inferens. Vanligtvis en fjärrtjänst (Anthropic, OpenAI, Google), men det kan också vara lokalt — Ollama, LM Studio eller llama.cpp på din egen dator. Agentmiljön kör inte modellen själv; den ber en leverantör göra det.

Leverantören äger maskineriet: parametrarna finns på dess maskinvara och varje modell-leverantörsförfrågan innebär att agentmiljön skickar token över nätverket och får förutsägelser tillbaka. Därför är leverantören källan till en hel kategori problem som felaktigt tillskrivs modellen eller agentmiljön — hastighetsbegränsningar, försämrad kapacitet och avbrott finns här. Om agenten stannar mitt i en session eller får fel vid varje tur är det värt att kontrollera leverantörens statussida först.

Leverantören bestämmer också de kommersiella villkoren: pris per token för indata och utdatatoken, rabatter för prefixcache och vilka modeller som alls finns tillgängliga. Observera att leverantören och modellens tillverkare kan vara olika företag — Bedrock, Vertex och OpenRouter tillhandahåller andras modeller.

Lokala leverantörer byter kapacitet mot kontroll: modellerna som ryms på din egen maskinvara är mycket mindre än de mest avancerade modellerna, men inget lämnar datorn och du får ingen faktura per token.

Användning:

”Kan vi köra detta offline för kunden med ett luftgap?”

”Byt modell-leverantör till en lokal — Ollama eller llama.cpp på kundens dator. Agentmiljön bryr sig inte; den anropar bara en annan slutpunkt.”

Allt runt modellen som gör den till en agent: verktyg, systemprompt, hantering av kontextfönstret, behörigheter, krokar. Claude.ai och Claude Code använder samma modell men beter sig olika eftersom deras agentmiljöer skiljer sig åt.

Modellen gör bara en sak: tar in text och producerar text. Den kan inte läsa en fil, köra ett kommando eller minnas den senaste turen. Agentmiljön tillhandahåller allt detta. Den sammanställer kontexten för varje modell-leverantörsförfrågan, kör de verktygsanrop modellen begär, skickar tillbaka verktygsresultaten, lagrar sessionshistoriken, frågar dig om tillstånd före riskabla åtgärder och avgör när den ska komprimera. Agentloopen — modellen föreslår, agentmiljön utför, och så vidare — körs av agentmiljön.

Detta är viktigt vid felsökning. När beteendet skiljer sig mellan två produkter eller mellan i går och i dag är modellen ofta inte den variabel som ändrats — agentmiljön är det. En annan systemprompt, en annan verktygsuppsättning, en ändrad standardbehörighet eller en ny strategi för kontexthantering förändrar beteendet utan att modellen ändras. Det betyder också att det mesta av din konfiguration finns i agentmiljön: AGENTS.md-filer, behörighetsinställningar och krokar är instruktioner till agentmiljön, inte modellen.

Exempel: Claude Code, Cursor, Codex CLI — och Claude.ai, som är en chattmiljö snarare än en kodningsmiljö.

Användning:

”Samma modell — varför redigerar Claude Code filer medan Claude.ai bara svarar på frågor?”

”Olika agentmiljöer — Claude Code har filsystem-verktyg, en annan systemprompt och ett behörighetslager. Modellen är inte variabeln här.”

En rundresa från agentmiljön till modell-leverantören. Agentmiljön skickar aktuell kontext; leverantören returnerar ett svar (verktygsanrop eller slutligt svar). Ett användarmeddelande kan ge upphov till många modell-leverantörsförfrågningar om agenten anropar verktyg — varje verktygsresultat utlöser ytterligare en förfrågan.

Varje förfrågan innehåller allt: systemprompten, hela samtalet hittills och samtliga verktygsresultat. Modellen är tillståndslös, så leverantören behåller inget mellan förfrågningarna — förfråga fyrtio skickar på nytt det som förfråga trettionio skickade, plus ytterligare ett verktygsresultat. Prefixcachen gör denna upprepning överkomlig.

Förfrågan är också faktureringsenheten. Indatatoken, utdatatoken och cacherabatter räknas per förfrågan, vilket förklarar varför en till synes harmlös fråga kan kosta förvånansvärt mycket: kostnaden är inte proportionell mot ditt meddelande utan mot antalet förfrågningar gånger storleken på kontexten de bär med sig.

Det är bra att skilja förfrågan från turen. En tur är ett utbyte med dig, och en enda tur — ”rätta det misslyckade testet” — kan spelas upp som en kedja av förfrågningar:

Sex förfrågningar i en tur — varje gång skickas hela kontexten på nytt. När du undrar vart token tog vägen ska du räkna förfrågningar, inte turer.

Användning:

”En fråga förbrukade fyrtiotusen token?”

”Titta på verktygsanropen — tolv grep, åtta läsningar och fyra ändringar. Varje verktygsresultat utlöser en ny modell-leverantörsförfrågan, och hela sessions-prefixet skickas på nytt varje gång.”

Token som agentmiljön skickar vid varje modell-leverantörsförfrågan — systemprompten, samtalshistoriken, verktygsresultat, allt modellen läser innan den skriver. Debiteras till en lägre taxa än utdatatoken, eftersom de är billigare att bearbeta än utdata.

Vid AI-kodning står indatatoken för den största delen av fakturan. Modellen är tillståndslös, så varje tur skickar hela sessionen på nytt som indata: ditt första meddelande, varje svar och varje verktygsresultat därefter. Indatan för tur femtio innehåller de föregående fyrtionio turerna. En enda modell-leverantörsförfrågan kan skapa några hundra utdata-token men skicka hundratusen indatatoken av ackumulerad historik igen.

Prefixcachen sänker kostnaden: historik som exakt matchar en tidigare förfrågan faktureras som billiga cachetoken i stället för indatatoken till fullpris. Om indatakostnaden ändå blir för hög är lösningen att minska det som skickas på nytt — rensa eller komprimera mellan uppgifter.

Användning:

”Fakturan är hög, men agenten skriver knappt något.”

”Det är indatatoken — varje tur skickar hela sessionen på nytt. Utan prefixcachen betalar du igen för historiken vid varje förfrågan.”

Token som modellen genererar. Debiteras till en högre taxa än indatatoken — ofta omkring fem gånger så hög — eftersom det krävs mer beräkningskraft för att skapa dem.

Allt modellen skriver räknas: texten du läser, koden den skapar, verktygsanrop och eventuellt utökat resonemang innan den svarar. Det sista överraskar folk — resonemangstoken faktureras som utdata även när agentmiljön ofta inte visar dem för dig, och högre ansträngning förbrukar fler av dem.

Utdatatrokar bestämmer också tempot i en session. Modellen läser indata snabbt men skapar utdata en token i taget, så när en tur känns långsam beror det nästan alltid på att utdata skrivs, inte på att indata läses. En lång väntan betyder oftast att ett långt svar är på väg.

Användning:

”Refaktoreringssessionen förbrukar krediter trots att indatan är liten.”

”Agenten skriver om hela filer i stället för att skapa patchar. Utdatatrokar kostar ungefär fem gånger indatatakstan — få den att skapa ändringar så sjunker fakturan.”

Lagring på leverantörens sida som gör att flera på varandra följande modell-leverantörsförfrågningar kan hoppa över att bearbeta ett gemensamt prefix igen. När början av en förfrågan matchar början av en nylig förfrågan — samma systemprompt, samma historik fram till en viss punkt — återanvänder leverantören det tidigare arbetet och debiterar de token som cachetoken till ett mycket lägre pris.

Cachen lönar sig eftersom sessioner växer genom att innehåll läggs till i slutet. Varje förfrågan skickar hela historiken på nytt som indatatoken (se den posten för varför), och under en normal session ändras historiken bara i slutet — varje förfrågan är den föregående plus några nya meddelanden. Leverantören bearbetar den långa gemensamma inledningen en gång, sparar resultatet och fortsätter där prefixet slutar. Utan cache skulle en session med 50 turer betala för att bearbeta tur ett femtio gånger.

Även cacheposter upphör att gälla. Hur länge en post förblir varm varierar mellan modell-leverantörer — oftast minuter, inte timmar. Om en session ligger oanvänd längre än tidsfönstret byggs prefixet i nästa förfrågan upp igen till full kostnad en gång innan cachningen återupptas. Detta är främst en angelägenhet för den som bygger agentmiljöer; som användare märker du att förfrågningar efter ett långt uppehåll kostar mer än de gjorde före det.

Användning:

”Varför sköt fakturan i höjden mitt i sessionen?”

”Agentmiljön började lägga in den aktuella tiden i systemprompten vid varje tur. Prefixcachen bryts vid den första ändrade token, så varje senare förfrågan debiterades till fullt pris.”

Indatatoken som leverantören har cachat från en tidigare modell-leverantörsförfrågan, så att den inte behöver bearbeta dem på nytt. När på varandra följande förfrågningar delar ett prefix återanvänder leverantören arbetet via sin prefixcache och fakturerar den cachade delen till en mycket lägre taxa. Det som gör långa sessioner överkomliga — utan den betalar varje tur på nytt för hela historiken.

Detta spelar roll på grund av hur sessioner faktureras. Modellen är tillståndslös, så varje förfrågan skickar hela samtalet igen — systemprompten, varje meddelande och varje verktygsresultat — som indatatoken. Vid tur femtio innehåller varje förfrågan femtio turers historik, och allt detta skulle debiteras till full taxa varje gång. Cachen ändrar kalkylen: token som leverantören redan bearbetat i ett identiskt prefix faktureras som cachetoken, ofta till en tiondel av indatataxan eller ännu mindre. Under en lång session är det mesta du skickar cachetoken och fakturan hålls på en rimlig nivå.

Ett exempel visar när token cachas och när de inte gör det. Varje bokstav står för ett block med samtalsinnehåll; varje förfrågan skickar samtalet hittills:

Cachen är skör på ett särskilt sätt: den matchar exakta prefix. Om något ändras tidigare i samtalet — agentmiljön ändrar ordningen på innehållet, en tidsstämpel uppdateras eller en fil får en annan representation — missar cachen från den punkten och allt efteråt debiteras till full indatataksa. Cacher upphör också att gälla efter några minuters inaktivitet, så en session som återupptas efter ett långt uppehåll får betala för historiken igen en gång. Om kostnaden för en session plötsligt ökar utan uppenbar anledning bör du jämföra cachetoken med indatatoken i användningsrapporten — en trasig cache syns där först.

Användning:

”Långa sessioner är brutalt dyra — åtta dollar för en refaktorering.”

”Kontrollera cachetokenen. Om agentmiljön ändrar ordningen på systemprompten eller filerna mellan turerna bryts prefixet, och varje förfrågan debiteras på nytt till full indatataksa.”

För inte med sig någon information. Modellen är tillståndslös mellan modell-leverantörsförfrågningar — varje förfrågan skickar hela kontextfönstret igen, eftersom modellen inte kan se något annat. En agent är som standard tillståndslös mellan sessioner: en ny session börjar tom, utan spår av tidigare sessioner. Motsatsen till tillståndsbevarande.

Själva modellen är permanent tillståndslös: dess parametrar är frysta efter träningen, och inget du gör vid inferens ändrar dem. Modellen lär sig inte av dina rättelser, minns inte att du sa samma sak i går och lär inte känna dig — hur mycket samtalet än känns så. Känslan av kontinuitet inom en session skapas av agentmiljön, som sparar utskriften och skickar den igen med varje förfrågan. Modellen minns inte samtalet; den läser det på nytt.

Den praktiska följden: om du vill att något ska kommas ihåg mellan sessioner måste du skriva ned det någonstans där agenten kan läsa det igen. Det är vad AGENTS.md-filer, minnessystem och överlämningsartefakter är — filer som läses in i kontexten för framtida sessioner och ersätter minnet modellen saknar. När agenten fortsätter göra ett misstag du redan rättat är frågan inte varför den inte lärde sig — det kan den inte — utan var rättelsen bör skrivas så att varje framtida session läser den.

Användning:

”Varför glömmer den konventionen varje gång jag rensar?”

”Modellen är tillståndslös — den nya sessionen börjar tom. Om du vill att det ska följa med, skriv det i AGENTS.md eller en minnesfil som agentmiljön läser in vid sessionsstart.”

Den relevanta information som agenten har tillgång till just nu. Det abstrakta substantivet — inte de råa indata modellen ser (det är kontextfönstret), inte den löpande historiken (det är sessionen), utan det agenten vet som är relevant för uppgiften. ”Läsa in något i kontexten” betyder att göra det till en del av denna mängd; ”kontextutformning” är arbetet med att välja och ordna den.

De tre begreppen skiljer sig tydligt åt:

Skillnaden spelar roll eftersom kontext mäter kvalitet, inte kvantitet. Ett kontextfönster kan nästan vara fullt och kontexten ändå dålig — tusentals token med inaktuella verktygsresultat, inget av dem relevant för uppgiften. Det kan också nästan vara tomt och kontexten utmärkt: den enda typdefinition som uppgiften hänger på.

De flesta vardagsproblem spårar tillbaka till kontexten. När agenten hittar på ett API, motsäger ett beslut eller gissar på ett schema är den första frågan vad som fanns i kontexten när den gjorde det — oftast lästes den relevanta uppgiften aldrig in eller begravdes under försämrad uppmärksamhet. Lösningen är urval: läs in det uppgiften behöver och uteslut resten.

Användning:

”Den hittar hela tiden på fält som inte finns i typen.”

”Typfilen finns inte i kontexten — den tittar på anropsställena och gissar. Läs in definitionen först.”

Allt som modellen ser vid varje modell-leverantörsförfrågan. Begränsat, modellspecifikt och den enda yta genom vilken modellen uppfattar något.

Det är en enda följd av token: systemprompten, samtalet hittills och varje verktygsresultat som agentmiljön har skickat tillbaka. Om något finns i följden kan modellen använda det; om det inte finns där vet modellen inte att det existerar — varken din kodbas, filen du redigerade i går eller instruktionen från tre sessioner sedan. Allt utanför fönstret måste hämtas in, vanligtvis genom ett verktygsanrop, innan det kan påverka något.

Det är begränsat, så det fylls. Varje tur lägger till mer — dina meddelanden, modellens svar och verktygsresultat — och en lång session når till slut gränsen, vilket tvingar fram komprimering eller rensning. Det innebär också att allt i fönstret konkurrerar: varje inläst token är en mindre tillgänglig för resten, och innehåll du inte behövde upptar ändå modellens uppmärksamhet. Se därför fönstret som en budget — ladda in det uppgiften kräver och lämna resten utanför.

Undvik: ”minne” — kontextfönstret är ett arbetsläge som inte består mellan sessioner. Minne är ett separat begrepp som läggs ovanpå.

Användning:

”Kan jag bara klistra in hela monorepot i prompten?”

”Kontextfönstret rymmer 200k token — kanske en femtedel av repot. Välj filerna som berörs av uppgiften och lämna resten bakom ett verktygsanrop.”

För information vidare. En session är tillståndsfull mellan turer — kontext samlas medan sessionen pågår, vilket är anledningen till att långa sessioner glider in i den dumma zonen. En agent kan göras tillståndsfull mellan sessioner genom att lägga till ett minnessystem som sparar information i miljön och läser in den igen när framtida sessioner börjar. Modellen är aldrig tillståndsfull; all skenbar kontinuitet beror på att agentramverket matar in kontexten igen. Motsatsen till tillståndslös.

Var tillståndet finns på varje lager:

Tillståndsfullheten i varje lager byggs upp genom att något lagrat i lagret under läses igen: sessionen känns sammanhängande eftersom agentramverket skickar meddelandehistoriken på nytt till den tillståndslösa modellen, och agenten minns mellan sessioner eftersom agentramverket läser in filer från miljön igen. Inget tillstånd lagras någonsin i själva modellen.

Tillstånd är inte alltid önskvärt. Allt som förs vidare påverkar det som kommer sedan, så ett felaktigt antagande tidigt i sessionen följer också med. Rensning är det medvetna valet att kasta bort sessionstillstånd och börja från det som skrivits ned.

Användning:

”Den mindes mina preferenser från i går — betyder det att modellen har lärt sig dem?”

”Nej, agenten är tillståndsfull eftersom agentramverket skrev dem till en minnesfil och läste in den vid sessionsstart. Själva modellen såg ingenting från i går.”

En modell som är kopplad till ett agentramverk med verktyg, en systemprompt och ett kontextfönster, och som tar turer med en användare. Claude Code är en agent. Cursor är en agent. Claude.ai är en agent. En agent är det du faktiskt pratar med — modellen i rörelse, konfigurerad för ett syfte.

Till skillnad från de flesta termer i den här ordlistan betecknar ”agent” inte en mekanisk del. Modellen är en fil med parametrar; agentramverket är programvara som går att peka på. Agenten är ingetdera — den är enheten du pratar med. Människor antropomorfiserar AI hela tiden, och agenten är den antropomorfiserade enheten: det du delegerar till, det som läser ditt meddelande och svarar, ”den” i ”den förstörde bygget igen”. När du säger att agenten gjorde något menar du att modellen plus agentramverket gjorde det, men du beskriver kombinationen som en enda aktör.

Idén är äldre än den här AI-vågen. Programvaruagenter — program som du delegerar ett mål till och som agerar för din räkning — har varit ett begrepp lika länge som AI har funnits.

Undvik: ”AI:n”, ”boten” (för vagt — det döljer om du menar parametrarna eller den agentanslutna enheten).

Användning:

”Vilken agent använder du för migreringen?”

”Claude Code lokalt, Cursor för gränssnittsjobbet — samma modell under huven, olika agentramverk.”

Instruktionerna som agentmiljön lägger till före varje modell-leverantörsförfrågan — agentens stående instruktioner: vem den är, hur den ska bete sig, vilka verktyg den kan anropa och vilka konventioner den ska följa. Vanligtvis oförändrade under en session.

Systemprompten skrivs av leverantören av agentmiljön, inte av dig, och i kodningsmiljöer är den omfattande — ofta tiotusentals token med beteenderegler, verktygsbeskrivningar och hantering av specialfall. Allt faktureras som indatatoken vid varje tur. Dina egna stående instruktioner följer med: filer som AGENTS.md läses in bredvid systemprompten när sessionen börjar, så modellen läser både leverantörens och dina instruktioner innan den ser ditt meddelande.

Eftersom prompten är identisk i varje förfrågan utgör den början på prefixcachen — det är en del av skälet till att agentmiljöer håller den fast under en hel session i stället för att redigera den efter hand.

Modeller tränas att prioritera systemprompten framför användarmeddelanden. Så när en agent insisterar på en konvention du aldrig bett om, eller formaterar utdata på ett sätt du inte kan få den att släppa, lyder den oftast sin systemprompt — och ditt meddelande förlorar argumentet. Vissa agentmiljöer går att anpassa: de ger dig full tillgång till systemprompten, så att du kan läsa vad agenten faktiskt får veta och ändra det.

Användning:

”Två agentmiljöer, samma modell, helt olika beteende på samma prompt.”

”Olika systemprompter. Den ena är inställd för kortfattade kodändringar och den andra för förklaringar — avvikelsen uppstår innan ditt meddelande ens kommer fram.”

En avgränsad omgång av interaktion med en agent. Den börjar tom, samlar på sig meddelanden, verktygsresultat och inlästa filer och avslutas när den rensas, stängs eller komprimeras till en ny session. Det är sessionen som fyller kontextfönstret: om kontextfönstret är lådan är sessionen innehållet som långsamt fyller den. Arbete som är för stort för ett enda kontextfönster måste delas upp mellan sessioner.

Sessionens meddelandehistorik är agentens arbetsminne. Modellen är tillståndslös, så allt den verkar minnas — vad du bad om, vad testerna visade och vad den bestämde för tre turer sedan — finns i meddelandehistoriken, som skickas på nytt med varje modell-leverantörsförfrågan. Det som inte finns i sessionen existerar inte för agenten.

Minnet upphör med sessionen. En ny session börjar från noll: agenten som kunde din kodbas utan och innan i slutet av gårdagens session vet ingenting om den i morse. Det som överlever är filsystemet — filer som skrivs under en session kan läsas av nästa, vilket är vad överlämningar, minnessystem och AGENTS.md bygger på.

Du bestämmer när en session tar slut. Allt i en session påverkar varje senare tur, så orelaterade uppgifter i samma session lämnar rester som färgar nästa svar. En uppgift per session håller kontexten relevant; när en uppgift är klar är det ett naturligt tillfälle att rensa.

Användning:

”Hur länge kan en session pågå innan den faller samman?”

”Det beror på arbetet — en fokuserad refaktorering håller skärpan längre än öppen research. När sessionen sväller, lämna över eller komprimera; kämpa inte vidare.”

Ett användarmeddelande plus allt agenten gör som svar, fram till dess att den lämnar tillbaka kontrollen till användaren. Innehåller en eller flera modell-leverantörsförfrågningar — många om agenten anropar verktyg. En klargörande fråga avslutar turen; ditt svar öppnar nästa. Hierarkin är session > Tur > Modell-leverantörsförfrågan.

Det som gör turen värd att namnge är att dess längd bestäms av agenten, inte dig. Du lämnar över ett meddelande; agenten avgör hur många verktygsanrop den ska kedja ihop innan den lämnar tillbaka kontrollen. En tur kan vara ett svar på en mening eller tjugo minuters läsning, redigering och testkörning. Det är samma egenskap sedd från två håll: långa turer möjliggör AFK-arbete, men det är också då saker kan gå fel utan tillsyn — när agenten till sist lämnar tillbaka kontrollen kan den ha glidit långt från vad du menade.

Turen är också den naturliga enheten för styrning. Allt inom en tur händer utan dig; mellan turerna kan du styra om. De flesta agentmiljöer mildrar detta: du kan avbryta mitt i turen för att stoppa agenten och styra om den, eller skriva ett meddelande medan den arbetar som läses när turen är klar. Om du upprepade gånger är missnöjd med var turerna landar är lösningen oftast att be om mindre turer — en plan först, ett steg i taget — och byta autonomi mot fler tillfällen att styra.

Användning:

”Tog en tur två minuter?”

”Den gjorde fjorton verktygsanrop under den turen — vart och ett är en separat modell-leverantörsförfrågan. Fördröjningarna staplas på varandra innan agenten till sist lämnar tillbaka kontrollen.”

Världen som agenten agerar i — allt utanför agentmiljön som agenten uppfattar genom verktygsresultat och förändrar genom verktygsanrop. Agentmiljön kör agenten; omgivningen är det agenten arbetar i. En fil som `AGENTS.md` finns i omgivningen; agentmiljön läser in den i kontextfönstret. Ett filsystem är den vanligaste typen av omgivning, men inte den enda (en databas, ett fjärr-API eller en webbläsarsession kan också vara omgivningar).

Agenten ser omgivningen bara när den tittar. Allt den vet om omgivningen kom via ett verktygsresultat, så dess bild består av ögonblicksbilder som var och en stämde när den togs. Om en fil ändras efter att agenten läst den — du redigerar den för hand eller ett byggsteg genererar om den — fortsätter agenten att resonera utifrån den inaktuella kopian tills något får den att läsa om. När en agent självsäkert beskriver en fil som inte längre ser ut så här är det oftast detta som hänt: omgivningen förändrades, men ögonblicksbilden gjorde det inte.

Omgivningen är också det lager som består — det enda som alltid är tillståndsbevarande. Sessionens kontext försvinner när sessionen avslutas, men filer som skrivs till omgivningen finns kvar så att nästa session kan läsa dem — vilket är vad minnessystem, överlämningsartefakter och `AGENTS.md` bygger på. Allt en agent fortfarande bör veta i morgon måste hamna i omgivningen.

Du avgör hur stor omgivningen är. En sandlåda krymper den genom att begränsa vad agenten når; ett verktyg utökar den genom att göra en databas eller ett API åtkomligt. Det som ligger innanför gränsen kan agenten uppfatta och ändra; allt utanför finns inte för agenten. Hur väl omgivningen är utformad för att stödja agentens arbete är kodbasens AX.

Undvik: att använda ”omgivning” om själva körtiden eller agentmiljön — agentmiljön är omslaget, omgivningen är arbetsytan.

Användning:

”Agenten kan inte se schemat för stagingdatabasen.”

”Koppla in det i omgivningen — ge agenten ett `psql`-verktyg med enbart läsbehörighet till staging. Agentmiljön fungerar, den har bara inget att agera på.”

Ett träd av filer och kataloger som agenten läser från, skriver till och kör kommandon i — den vanligaste typen av miljö för en kodagent. AGENTS.md, skills, källkod, byggskript och verktygs-konfigurationer finns alla i ett filsystem. När ett agentramverk ”startar i ditt projekt” pekar det agenten mot ett filsystem.

Agenten kommer åt det endast genom verktygsanrop — läsa en fil, skriva en fil eller köra ett shell-kommando. Inget på disk finns i kontextfönstret förrän ett verktygsanrop läser in det, vilket låter agenten arbeta i ett repo som är mycket större än fönstret: filsystemet innehåller allt, medan kontexten bara innehåller det den aktuella uppgiften har läst. Vissa agentramverk läser som standard in filnamnen i den aktuella katalogen i kontextfönstret — inte innehållet, bara trädet — vilket fungerar som kontexthänvisningar: agenten ser vad som finns och läser de filer den behöver.

Och filsystemet delas med dig. Filerna agenten redigerar är samma filer som du öppnar i din editor och granskar i git — filsystemet är den gemensamma arbetsyta där du går igenom det agenten gjort.

Användning:

”Varför hittar den inte min AGENTS.md?”

”Den kör mot ett annat filsystem — sandlådan monterade den överordnade katalogen, inte projektroten. Peka om agentramverket.”

En funktion som agentramverket exponerar för agenten att anropa — Read, Write, Bash, Search. Verktyg är hur en agent uppfattar och agerar i miljön: den kan inte se miljön på annat sätt än genom verktygsresultat, och kan inte ändra den på annat sätt än genom verktygsanrop. Varje verktygsanrop kostar en extra begäran till modellleverantören, eftersom resultatet måste tillbaka till modellen innan den kan bestämma vad den ska göra härnäst.

Verktyg som de flesta kodagenter levereras med:

Ett verktyg definieras av tre saker: ett namn, en beskrivning av vad det gör och ett schema för dess parametrar. Agentramverket skickar dessa definitioner till modellen vid varje begäran, och modellen väljer ett verktyg på samma sätt som den producerar allt annat — genom att skriva token, här ett strukturerat anrop med argument. Modellen utför aldrig något själv; agentramverket läser anropet, kör funktionen och skickar tillbaka resultatet.

Verktygslistan avgör vad agenten kan göra. En kapabel modell med få verktyg blir en begränsad agent: den leder allt genom det den har, vilket är anledningen till att agenter förlitar sig så mycket på Bash — ett shell-verktyg når det mesta av systemet. Om du vill ge agenten en förmåga på ett tydligt sätt lägger du till ett verktyg; MCP är standarden för att koppla in verktyg utifrån agentramverket.

Verktygsdefinitionerna tar upp kontext vid varje begäran, så en stor verktygsuppsättning har en löpande kostnad innan något verktyg ens anropas — och många verktyg med liknande beskrivningar gör modellen sämre på att välja rätt.

Användning:

”Kan agenten fråga staging direkt?”

”Lägg till ett `psql`-verktyg i agentramverket med skrivskyddad åtkomst till staging. Utan ett verktyg för det är agenten blind för allt utanför filsystemet.”

Modellens utdata som anger ett verktyg och dess argument — helt enkelt strukturerad text. De utför inget på egen hand; agentmiljön måste läsa anropet och verkställa det. Modellen skapar det i en modell-leverantörsförfrågan.

Ett verktygsanrops livscykel:

En tur med agent-arbete består oftast av många sådana rundresor i följd.

Eftersom anropet skapas genom nästa-token-prediktion, precis som allt annat, kan det bli fel på samma sätt som andra modellutdata: en sökväg som inte finns, en flagga kommandot saknar eller argument som verkar rimliga men är fel. Agentmiljön kör det som skrevs, inte det som avsågs — en felstavad sökväg misslyckas inte nödvändigtvis på ett säkert sätt utan kan redigera fel fil.

Användning:

”Den sa att den körde testerna, men filernas tidsstämplar har inte ändrats.”

”Titta i utskriften — skickade den faktiskt ett verktygsanrop eller beskrev den bara hur den körde dem? Modellen skapar anropet, men om agentmiljön inte verkställde det hände ingenting.”

Det agentmiljön skickar tillbaka efter att ha kört ett verktygsanrop — filinnehållet, kommandoutdata eller felet. Agentens enda inblick i omgivningen. Det skickas tillbaka till modellen i nästa modell-leverantörsförfrågan, där modellen avgör vad den ska göra med det. Verktygsanropet och verktygsresultatet är två ändar av samma utbyte, båda inom en tur.

Ett verktygsresultats livscykel:

Resultatet stannar i kontexten under resten av sessionen. Verktygsresultat utgör oftast merparten av en kodningssessions kontext: varje läst fil, varje testkörning och varje sökning kommer in i sin helhet och fortsätter att uppta token långt efter att den slutat vara användbar. Några stora resultat — en omständlig testlogg eller en helgenererad fil som läses in — kan föra sessionen mot gränsen för kontextfönstret snabbare än själva samtalet.

Eftersom resultatet är allt modellen ser kan den inte kontrollera omgivningen bakom det. Om utdata trunkerades, kommandot misslyckades utan meddelande eller agentmiljön returnerade ett fel i stället för innehållet resonerar modellen utifrån det den fick. När agentens bild av systemet verkar fel är verktygsresultaten rätt ställe att leta på: någonstans i utskriften finns ett resultat som säger något annat än det du vet stämmer.

Användning:

”Den resonerar som om filen vore tom.”

”Verktygsresultatet var ett avslag på grund av behörighet, inte filinnehållet. Modellen såg bara felmeddelandet — den har inget annat sätt att se filen.”

Model Context Protocol. Ett protokoll för att ansluta externa verktygsservrar till ett agentramverk — så får en agent verktyg utöver dem som följer med agentramverket. Agenten ”anropar aldrig MCP”; den anropar ett verktyg, och agentramverket råkar ha fått verktyget från en MCP-server. Protokollet tillhandahåller även resurser (skrivskyddade data) och promptar (återanvändbara mallar), men huvudsyftet är att tillhandahålla verktyg.

Protokollet löser ett integrationsproblem. Utan en standard skulle varje agentramverk behöva ha sin egen Linear-integration, sin egen Slack-integration, sin egen databasintegration — var och en separat utvecklad och underhållen. Med MCP skrivs integrationen en gång som en server, och alla MCP-kompatibla agentramverk kan använda den. Agentramverket ansluter till servern, servern annonserar vilka verktyg den erbjuder och dessa verktyg blir tillgängliga för agenten tillsammans med de inbyggda.

Kostnaden betalas i kontext. Varje verktyg som en server annonserar läggs till som en definition — namn, beskrivning och parameterschema — och modellen kan bara anropa verktyg den känner till. Den naiva metoden läser in alla definitioner i kontextfönstret på en gång: installera några generösa servrar, så börjar en session med tusentals token i verktygsscheman innan du har skrivit något, vilket förbrukar uppmärksamhetsbudgeten på verktyg uppgiften aldrig kommer att använda.

Många agentramverk begränsar nu detta med verktygssökning: I stället för de fullständiga definitionerna innehåller kontexten en kontexthänvisning till tillgängliga verktyg — agenten söker efter ett verktyg utifrån namn eller syfte och läser in definitionen först när den behövs. Om ditt agentramverk inte gör detta kvarstår den inledande kostnaden, och det är klokt att bara aktivera de servrar som projektet faktiskt behöver.

Användning:

”Agenten behöver läsa ärenden från Linear.”

”Konfigurera agentramverket att använda Linear MCP-servern — den exponerar Linear-API:t som verktyg agenten kan anropa. Då slipper du skriva egna verktygsomslag.”

Det agentmiljön visar användaren innan ett verktygsanrop som inte redan har godkänts körs. Modellen skapar ett verktygsanrop, men i stället för att köra det direkt pausar agentmiljön och frågar. Godkänn så körs det; neka så skickar agentmiljön avslaget tillbaka till modellen som ett verktygsresultat. Mekanismen genom vilken en agentmiljö tar in en människa i loopen vid riskfyllda eller känsliga åtgärder.

En behörighetsförfrågans livscykel:

Ett avslag styr agenten. Modellen läser avslaget som vilket verktygsresultat som helst och reagerar — den försöker på ett annat sätt eller frågar vad du föredrar. De flesta agentmiljöer låter dig lägga till ett meddelande vid avslaget, vilket gör förfrågan till ett tillfälle att styra: ”inte så, använd migreringsskriptet i stället” når modellen precis när den avgör vad den ska göra härnäst.

Kostnaden är att varje förfrågan kräver att du svarar innan arbetet kan fortsätta. Agenten står stilla tills du svarar, vilket fungerar när du tittar men blir ett problem när du inte gör det — en agent som utlöser förfrågningar hela tiden kan inte lämnas att arbeta AFK. Behörighetsläget är ratten: vilka anrop körs fritt och vilka frågar först, helst med en sandlåda som gör det säkert att utöka mängden som körs fritt.

Användning:

”Den har varit blockerad på en behörighetsförfrågan i tio minuter — jag satt i ett möte.”

”Det är kostnaden för att ha en människa i loopen. Förhandsgodkänn säkra verktyg, så att förfrågan bara utlöses för verkligt riskfyllda anrop.”

Den del av ett agentläge som styr behörigheterna — vilka verktygsanrop som utlöser en behörighetsförfrågan och vilka som körs automatiskt. Det var det ursprungliga syftet med lägessystem innan agentmiljöer började lägga beteendeinstruktioner ovanpå.

Agentmiljöer erbjuder en stege av sådana lägen:

Att välja nivå innebär en avvägning mellan säkerhet och avbrott, och båda felutfallen känns tydligt. För strängt och du blir flaskhalsen: agenten stannar med några sekunders mellanrum för harmlösa läsningar, du klickar godkänn på autopilot och godkännandena slutar betyda något — slentrianmässigt godkännande är det sämsta av två världar, alla avbrott men inget skydd. För löst och agenten redigerar filer och kör kommandon som du hade velat granska först.

Den lösa inställningen är lättast att försvara i en sandlåda, där följderna av ett dåligt verktygs-anrop begränsas. Utanför en sådan väljer de flesta att godkänna läsningar automatiskt och hålla en människa i loopen för allt som inte går att ångra.

Användning:

”Den pausade för varje grep — det dödade hela AFK-körningen.”

”Lätta på behörighetsläget för skrivskyddade verktyg, men fortsätt fråga vid skrivning och skal. De flesta behörighetsfrågor under en researchsession är brus.”

En förinställning som formar hur agenten arbetar vid körning — den kombinerar ett behörighetsläge med beteendeinstruktioner som läggs in i systemprompten. Exempel: ett standardläge som frågar vid riskabla anrop, ett planeringsläge som blockerar redigeringar och styr agenten mot undersökning, ett godkänn redigeringar-läge som godkänner ändringar automatiskt och ett kringgå behörigheter-läge (i vardagligt tal YOLO-läge) som godkänner allt automatiskt. Läget kan ändras mitt i en session.

Det är kombinationen som skiljer ett läge från en enkel behörighetsinställning. Ett behörighetsläge är bara en grind: det avgör vilka verktygsanrop som släpps igenom. En grind i sig ger en agent som vill redigera men inte får — den föreslår en skrivning, blockeras och försöker på ett annat sätt. De insatta instruktionerna tar bort viljan: planeringsläget blockerar inte bara redigeringar, det säger åt agenten att den befinner sig i en planeringsfas, så den läser, frågar och föreslår i stället för att kämpa mot grinden. Grind och styrning pekar åt samma håll.

I praktiken ändrar du läge när ditt förtroende förändras under arbetets gång. Samma uppgift kan passera genom flera lägen: planeringsläge medan lösningen tar form, standardläget med frågor för de första känsliga redigeringarna, godkänn redigeringar när agenten visat att den förstår ändringen och kringgåelse för en obevakad körning i en sandlåda. Det kostar ingenting att byta läge: samtalet fortsätter precis där det var, men med nya behörigheter och nya instruktioner. Om du märker att du godkänner varje fråga utan att läsa den är läget stramare än ditt faktiska förtroende; om du hela tiden avvisar redigeringar är det lösare.

Leverantörstermer: Claude Code kallar dessa ”behörighetslägen”, Codex kallar dem ”godkännandelägen” — båda termerna fanns innan beteendeinstruktioner paketerades in.

Användning:

”Den fortsätter redigera filer fast jag bara vill ha en plan.”

”Byt till planeringsläge — det blockerar skrivningar och håller sig till undersökning.”

”Och för den obevakade körningen senare?”

”Kringgåelseläge, men bara inne i sandlådan.”

En isolerad miljö som agenten kör i — en container, VM, tillfälligt filsystem eller shell med begränsade behörigheter. Begränsar spridningsområdet för agentens handlingar: även om den kör destruktiva kommandon eller hämtar något skadligt stannar skadan där. Säkerhetsgrunden som gör obevakat arbete praktiskt.

Sandlådan och behörighetsläget löser samma problem från olika håll. Behörigheter frågar innan en åtgärd körs; en sandlåda begränsar vad den kan nå om den väl körs. Behörigheter kräver att du är med i loopen — varje prompt avbryter — och en session som frågar hela tiden är knappt autonom. En sandlåda använder infrastruktur i stället för uppmärksamhet: ju starkare isolering, desto färre frågor behöver ställas.

Isolering finns i olika grader:

Det ingen sandlåda innehåller är handlingar som medvetet lämnar den. En agent med dina git-inloggningsuppgifter kan pusha; en med nätverksåtkomst kan anropa produktions-API:er. Bestäm vad som får passera gränsen innan du bestämmer hur tjock den ska vara.

Användning:

”Jag vill låta den köra bypass-permissions över natten, men är inte redo för det ännu.”

”Sätt den i en sandlåda — ny container, inga monterade inloggningsuppgifter, inget utgående nätverk. I värsta fall raderar den sitt eget filsystem och du kastar containern.”

Överdrivet instämmande modell-svar. Orsakas av träningen: modellen formades för att föredra svar som människor uppskattade, och människor uppskattar ofta medhåll mer än att få höra att de har fel. Modellen lärde sig därför att instämmande belönas — även när medhållandet är felaktigt.

Visar sig som:

• Ger efter vid mothugg — ändrar ett korrekt svar när du säger ”är du säker?”.
• Berömmer dåliga indata — kallar din bristfälliga plan briljant innan den analyserar den.
• Partisk vinkling — granskningen blir positiv när du antyder att du skrev den och negativ när du säger att någon annan gjorde det. Samma artefakt, olika omdöme.
• Härmande — upprepar dina misstag som en bekräftelse.

Diagnostiskt test: skulle modellen ha sagt detta utan din styrning? Om det enda som ändrades var din ton eller inramning handlar det om inställsamhet, inte en verklig förändring i analysen.

Åtgärd: dölj dina preferenser. Formulera frågor neutralt — ”granska den här koden”, inte ”är den här koden bra?”.

Undvik: att använda ”inställsamhet” om varje felaktigt svar som råkar behaga dig. Utan det diagnostiska testet säger termen inte mer än ”fel”.

Användning:

”Den sa att min refaktoriseringsplan såg jättebra ut. Sedan frågade jag ’är du säker?’ och då tog den tillbaka allt.”

”Typisk inställsamhet — den höll med först eftersom du lät säker och gav sedan efter när du lät tveksam. Planens kvalitet ändrades inte, men din ton gjorde det. Rensa och fråga igen utan att signalera åt något håll.”

Självsäkert felaktigt modell-svar. Det finns två varianter med olika orsaker och åtgärder:

Nästa-token-prediktion skapar flytande svar oavsett om den underliggande uppgiften är sann — modellen har ingen intern signal om att den saknar kunskap, så en påhittad metod uttrycks lika säkert som en korrekt. Hallucinerad kod är trovärdig av sin konstruktion: den ser ut som API:t skulle se ut om det fanns, vilket gör att den passerar en ytlig granskning och fallerar först när den körs.

Du behöver veta vilken variant du ser, eftersom åtgärden för den ena förvärrar den andra. Faktatrohet handlar om saknad kunskap: lösningen är att lägga till kontext — dokumentationen, typdefinitionerna, filen. Trohet handlar om att kunskapen finns men förlorar kampen om uppmärksamheten: lösningen är att ta bort kontext. Om du feldiagnostiserar bristande trohet som bristande fakta klistrar du in mer dokumentation, vilket gör kontexten större och avvikelsen värre. När agenten gör fel bör du kontrollera om korrekt information redan fanns i kontexten innan du avgör vilket problem det gäller.

Undvik: ”hallucination” som allmän synonym för ”fel” — utan att ange varianten har termen inget diagnostiskt värde.

Användning:

”Den hallucinerade en `parseAsync`-metod för schemat.”

”Faktatrohet eller trohet?”

”Metoden finns i dokumentationen jag klistrade in — den slutade bara läsa den efter beurt fyrtio.”

”Då handlar det om trohet. Komprimera och läs in på nytt; lägg inte till mer dokumentation.”

Det modellen ”vet” från träningen, lagrat i dess parametrar. Kunskapen fryses vid träningen — modellen kan varken se sina egna parametrar eller uppdatera dem. Detaljer går förlorade i sammanpressningen: miljarder fakta packas in i ett fast antal parametrar och ovanliga fakta blir suddiga. Källa till flytande svar om vanliga ämnen och påhitt om ovanliga. Motsatsen till kontextuell kunskap.

Parametrisk kunskap lagras inte som fakta. Träningen ger aldrig modellen en databas att slå upp saker i; parametrarna justeras tills modellen förutsäger text väl, och en modell som förutsäger text om ett ämne väl beter sig som om den känner till ämnet. Kunskapens tillförlitlighet följer hur ofta något förekom i träningsdatan: ett ämne med miljontals exempel återges korrekt, medan modellen för ett ämne med bara en handfull exempel gissar utifrån hur liknande ämnen ser ut. Att återge och att gissa är samma process för modellen, så den kan inte skilja mellan dem. Ett påhittat svar kommer lika flytande som ett korrekt. Hallucination är när modellen gissar fel.

Parametrisk kunskap åldras också. Parametrarna slutar ändras vid kunskapsgränsen, så ett bibliotek som släppts eller fått nytt namn efter det datumet finns inte i dem, och ett API som ändrats finns kvar i sin gamla form.

För båda luckorna — sådant som är för ovanligt och sådant som är för nytt — är lösningen densamma: kunskapen kan inte läggas till i parametrarna, så den måste tillhandahållas som kontextuell kunskap i stället.

Användning:

”Den skriver felfri React men hittar på metoder i vårt interna SDK.”

”React finns det gott om i den parametriska kunskapen — miljontals träningsexempel. Ditt SDK gör det inte, så modellen fyller i med former som ser rimliga ut. Läs in SDK-dokumentationen i kontexten.”

Datumet efter vilket en modell saknar parametrisk kunskap. Bibliotek, API:er och händelser efter gränsen blir fällor för fabricerade svar om inte dokumentationen lästs in som kontextuell kunskap. Varje modellversion har sin egen gräns.

Gränsen finns på grund av hur modeller skapas: träningen bakar in en ögonblicksbild av text i modellens parametrar, som sedan fryses. Modellen vet inte att dess kunskap har en gräns — om du frågar om något från tiden efter denna gräns vägrar den inte svara, utan extrapolerar från det närmaste den faktiskt känner till. Det är det som gör fällan svår att upptäcka: kod skriven för en gammal biblioteksversion ser rimlig ut, kompilerar ofta och fallerar först på de delar som ändrats.

Lösningen är alltid densamma: för in aktuell information i kontexten. Läs in ändringsloggen, peka på typdefinitionerna för den installerade versionen eller be agenten läsa dokumentationen på webben. Allt i kontexten väger tyngre än det som saknas i parametrarna.

Användning:

”Den skriver hela tiden syntax för SDK v3 — vi använder v5.”

”v5 släpptes efter kunskapsgränsen. Läs in ändringsloggen för v5 som kontextuell kunskap, annars fortsätter den att hitta på utifrån den äldre parametriska versionen.”

Fakta som agenten just nu kan läsa direkt ur kontexten — användarens uppgift, filer som agenten har läst in, verktygsresultat och innehåll från AGENTS.md som laddats in vid sessions-start. Motsatsen till parametrisk kunskap: parametrisk kunskap hämtas ur minnet från parametrarna; kontextuell kunskap läses från fönstret. Hallucinationer är mycket ovanligare när agenten arbetar utifrån kontextuell kunskap — svaret står framför den i stället för att grävas fram ur ett suddigt minne.

Av de två kunskapstyperna är det bara den kontextuella du kan påverka. Parametrarna är frysta, så det enda sättet att ge modellen kunskap den saknar — ett internt SDK, ett bibliotek som släpptes efter kunskapsgränsen, ett beslut som fattades i går — är att lägga in den i kontexten. Mycket praktiskt AI-kodarbete går ut på just detta: att ge modellen rätt fakta när den behöver dem.

När kontextuell och parametrisk kunskap står i konflikt vinner den kontextuella oftast. Klistra in aktuell API-dokumentation så följer modellen den i stället för sitt inaktuella minne av det gamla API:t — även om den gamla versionen fortfarande kan sippra igenom, särskilt långt in i en lång session. Om agenten fortsätter återgå till ett gammalt mönster trots att dokumentationen lästs in läcker parametrisk kunskap förbi den kontextuella; det kan hjälpa att upprepa rättelsen eller flytta den närmare arbetet.

Till skillnad från parametrisk kunskap kostar kontextuell kunskap något att använda. Allt som läses in i fönstret förbrukar token och konkurrerar om modellens uppmärksamhetsbudget, så mer är inte automatiskt bättre — målet är att ha relevanta fakta i fönstret, inte alla fakta.

Använd det här begreppet endast när du jämför med parametrisk kunskap; annars säger du helt enkelt kontext.

Undvik: ”arbetsminne” — kontextuell kunskap är det som finns i fönstret nu; ett minnessystem är det som för över innehåll mellan sessioner. Det handlar om olika skalor; blanda inte ihop dem.

Användning:

”Varför klarar den API:t när jag klistrar in dokumentationen men hittar på saker när jag inte gör det?”

”Med dokumentationen blir det kontextuell kunskap — den läser direkt från sidan. Utan den förlitar den sig på parametrisk kunskap, och de ovanliga slutpunkterna blir suddiga.”

När modellen förutsäger varje token väger den in alla andra token i kontexten — vissa tungt, andra knappt alls. Kopplingen mellan två token är en uppmärksamhetsrelation, och meningsfulla par (”henne” med ”Sarah” eller ett `getUser()`-anrop med definitionen `function getUser`) påverkar varandra mer än orelaterade par. En kontext med N token har i storleksordningen N² relationer.

Det är i parningarna som modellens skenbara förståelse finns. När den löser ett pronomen beror det på att uppmärksamhetsrelationen mellan ”henne” och ”Sarah” är stark. När den anropar en funktion med rätt argument gör relationen mellan anropsstället och definitionen den läste tidigare jobbet. Ingenting slås upp — beräkningen görs på nytt vid varje modell-leverantörsförfrågan, för varje par.

Det är värt att fundera över N²-siffran, eftersom den växer snabbare än intuitionen antyder:

Varje parning beräknas dessutom mer än en gång. Modeller har flera uppmärksamhetshuvuden — exakta antal för de mest avancerade modellerna offentliggörs inte, men femtio till hundra är en rimlig gissning — och varje huvud beräknar sin egen version av varje relation. Därför dupliceras varje parning i tabellen ovan för varje huvud. Det blir många parningar.

Bara ett fåtal av dessa relationer spelar roll för en viss uppgift. Kopplingen mellan din instruktion och koden den styr är en av få som räknas; nästan alla andra par i mängden är brus. Och de växer i olika takt: de viktiga relationerna förblir ungefär konstanta medan den totala mängden växer kvadratiskt med kontextstorleken. Vid 1 000 token är parningen du bryr dig om en på en miljon; vid 100 000 token är den en på tio miljarder. Detta är matematiken bakom uppmärksamhetsbudgeten, och försämrad uppmärksamhet är känslan när de viktiga relationerna får en alltför liten andel.

Användning:

”Den blandar hela tiden ihop de två `user`-symbolerna i diffen — det låter som att vi är i den tröga zonen.”

”Ja, uppmärksamhetsrelationen mellan varje anropsställe och dess deklaration konkurrerar med den andra — samma tokenform, olika bindningar. Byt namn på en så blir parningarna tydligare.”

Varje token har en begränsad mängd påverkan att fördela över resten av kontexten. Stor påverkan på en relation lämnar mindre åt andra. Budgeten gäller per token och växer inte när kontexten gör det, vilket är anledningen till att långa sessioner urvattnas.

Tänk på det som signal och brus. Din instruktion är en signal med fast volym; varje annan token i kontextfönstret är ett konkurrerande ljud. Instruktionen blir aldrig tystare — den finns kvar, tecken för tecken — men när kontexten växer blir rummet bullrigare omkring den och signal-brusförhållandet sjunker. En instruktion som var det starkaste ljudet vid 10k kontexttoken är bakgrundsbrus vid 150k. Detta är mekanismen bakom försämrad uppmärksamhet: modellen glömmer inte; signalen försvinner i bruset.

Symtomet ser ut som olydnad — agenten gick med på en begränsning tidigt men avviker sedan från den, och att klistra in begränsningen på nytt hjälper bara en kort stund. Orsaken är inte instruktionen; det är allt annat i fönstret som konkurrerar med den.

Du kan påverka vad som tas in i kontexten. Innehåll som inte hjälper uppgiften är inte neutralt — det skapar brus ovanpå allt som faktiskt gör det. Håll fönstret litet, rensa när den ackumulerade kontexten inte längre är värd sin kostnad och upprepa de viktiga begränsningarna i stället för att lita på att de nämndes tidigt.

Användning:

”Varför ignorerar den hela tiden schemat jag klistrade in högst upp?”

”Vi är långt inne i den tröga zonen — varje tokens uppmärksamhetsbudget är fast, men kontexten har fortsatt att växa. Signalen om schemat konkurrerar nu med tusentals nyare token.”

När en session växer fördelas varje tokens uppmärksamhetsbudget på fler konkurrenter. Signalen i en meningsfull relation krymper; brus från irrelevant kontext tränger sig på. Samma modell, samma parametrar — bara fler munnar att mätta från samma tallrik. Orsak till smart-/dum-zoneffekten.

Det märks som att modellen blir sämre mitt i sessionen: begränsningar den följde i en timme börjar glida, den frågar igen om saker den fått veta och skriver kod som ignorerar en fil den läste tidigare. Ingenting med modellen ändrades — den enda variabeln är hur mycket kontext den nu uppmärksammar.

Det sker gradvis, vilket gör det svårt att märka inifrån sessionen. Det finns inget felmeddelande och ingen tydlig gräns; varje tur är bara lite sämre än den förra, och när missarna blir uppenbara har du varit i den dumma zonen ett tag.

Du återhämtar dig genom att ta bort kontext, inte lägga till mer. Att klistra in den ignorerade instruktionen igen lägger till ännu en konkurrent i samma överfulla fönster och hjälper bara kortvarigt. Det som fungerar: Rensa och läs bara in det uppgiften behöver, eller komprimera, eller överlämna till en ny session. Se minskad följsamhet mot instruktioner som en signal om kontextens längd, inte om modellen.

Användning:

”Den är djupt inne i den dumma zonen — hittar på generiska typer som inte finns i typfilen.”

”Försämrad uppmärksamhet. Typdefinitionerna finns fortfarande i kontexten, men signalen från dem ligger begravd under allt vi lagt till sedan. Rensa och läs in igen.”

Tidigt i en session befinner sig agenten i en ”skärp zon” — den är skarp och fokuserad och minnet fungerar bra. När sessionen växer glider den in i en ”trög zon”: slarvigare, mer glömsk, fler misstag — och fler trohetsrelaterade hallucinationer. Samma modell, samma agentmiljö — bara mer kontext. Den upplevda effekten av försämrad uppmärksamhet. För de mest avancerade modellerna börjar den tröga zonen ofta vid ungefär 125K–150K token — även om detta diskuteras. Rensa eller komprimera när sessionen sväller; kämpa inte vidare.

Försämringen sker gradvis och är därför lätt att missa. Det kommer inget felmeddelande och ingen synlig gräns; agenten börjar bara prestera lite sämre och sedan märkbart sämre. Vanliga tecken: den glömmer en instruktion från tjugo turer tidigare, upprepar ett misstag den redan rättat eller hävdar självsäkert något som motsägs av kontexten. Eftersom försämringen är jämn är den vanliga reaktionen att kämpa vidare och förklara igen — vilket lägger till mer kontext och förvärrar problemet.

Zonerna följer inte gränsen för kontextfönstret. En session kan vara djupt inne i den tröga zonen trots att större delen av fönstret är ledigt: gränsen anger när agentmiljön vägrar fortsätta, men kvaliteten sjunker långt innan dess. Planera efter den skarpa zonen, inte fönstret — den praktiska budgeten för en uppgift är antalet token agenten arbetar bra med, inte antalet den tekniskt kan hålla.

Den skarpa zonen är en budget, och orelaterat arbete förbrukar den. Varje uppgift i en session använder token, så en andra uppgift i samma session börjar närmare den tröga zonen. Om du gör en uppgift per session får varje uppgift den skarpaste delen av sessionen. När en enda uppgift är större än en skarp zon bör du dela upp den: lämna över eller komprimera vid en naturlig gräns och låt en ny session göra nästa del.

Användning:

”Den klarade de tre första komponenterna och förstörde den fjärde.”

”Du är utanför den skarpa zonen — samma modell, bara långt inne i den tröga zonen nu. Komprimera och läs in planen igen; nästa komponent kommer att fungera.”

Avsluta den aktuella sessionen och starta en ny. Nästa meddelande börjar i en tom session med ett tomt kontextfönster. Vanligtvis på användarens initiativ.

Rensning är botemedlet mot en förorenad kontext. En session samlar på sig allt: misslyckade försök, felaktiga spår, inaktuella verktygsresultat, övergivna planer. Modellen läser om allt detta vid varje tur, och den dåliga historiken tynger nytt arbete. Djupt inne i en lång session blir agenten vagare och mindre följsam — tydliga instruktioner ignoreras, kvaliteten sjunker och det hjälper inte att be den skärpa sig, eftersom bruset den tar sig igenom fortfarande finns i dess kontext. Rensning tar bort bruset.

Rensning raderar inte samtalet. De flesta agentmiljöer sparar sessionshistoriken på datorn, så utskriften går fortfarande att läsa eller återuppta. Det som försvinner är agentens arbetsläge: modellen är tillståndslös, så den nya sessionen vet inget av det den gamla visste. Om sessionen innehåller beslut eller framsteg som nästa session behöver bör du be agenten skriva en överlämningsartefakt först och sedan hänvisa till den när den nya sessionen startar.

Jämför med komprimering, som sammanfattar sessionen till det nya sammanhanget i stället för att börja tomt. Rensning är det grövre verktyget: inget följer med, inklusive skräpet.

Användning:

”Den har fastnat i en loop kring det misslyckade testet.”

”Rensa bara — starta en ny session med plandokumentet och testfilen. Det är ingen idé att kämpa mot den befintliga kontexten.”

Överföra en agents kontext från en session till en annan. Mekanismen varierar — en skriven överlämningsartefakt, en sammanfattning i minnet (komprimering) eller något annat. Skiljer sig från rensning, där inget överförs. Orsakerna varierar: byta roller (planerare → implementerare), starta en AFK-körning, sprida arbete över parallella sessioner eller frigöra utrymme i kontextfönstret.

Den mottagande sessionen börjar utan kontext — modellen är tillståndslös, och inget från den gamla sessionen är synligt för den nya. Allt som nästa session behöver måste överföras uttryckligen; resten är borta. ”Ingen returväg” är begränsningen som formar överföringen: den nya sessionen kan inte fråga den gamla vad den menade, så det som förs över måste kunna stå på egna ben.

Ett misslyckat överlämnande märks som att den nya sessionen tar upp redan avgjorda frågor på nytt, eftersom överföringen noterade vad som beslutats men inte varför. Bedöm överlämningen utifrån vad en session utan någon kontext kan göra med den.

Användning:

”Planeringssessionen börjar bli tung — ska jag bara fortsätta?”

”Gör en överlämning. Skriv besluten i ett dokument, rensa och börja implementeringen i en ny session som läser dokumentet.”

En primärkälla i sin ursprungliga form — koden, samtalstranskriptionen, råloggen, det faktiska API-svaret. Inte en redogörelse för saken, utan saken själv. Motsatsen till sekundärkälla.

Om du vill veta vad kodbasen gör är koden primärkällan. Dokumentationen, arkitekturdiagrammet och README-filen beskriver den — korrekta när de skrevs och därefter uppdaterade enligt sina egna tidsscheman. När en agent självsäkert påstår något felaktigt om projektet är frågan vilken källa den arbetade utifrån: en agent som läste dokumentation ärver dess inaktualitet; en agent som läste koden läser den aktuella sanningen.

Kostnaden är anledningen till att primärkällor inte är standard. Det är dyrt att läsa in en i kontextfönstret — hela filen, hela transkriptionen, varje token faktureras som input och konkurrerar om uppmärksamhetsbudgeten. Vad kostnaden ger dig är fullständighet: ingen har filtrerat bort något utifrån sin egen bedömning av vad som spelade roll. En sammanfattning från förra månaden kan inte innehålla den detalj som visade sig viktig i dag; det kan fortfarande primärkällan.

Vänd dig till primärkällan när precision är viktig — exakt signatur, faktiskt fel, raden som kastar det. Mycket av arbetet med att hantera kontext handlar om att avgöra när det är värt att betala för primärkällan och när en sekundärkälla räcker.

Användning:

”Agenten säger att återförsökslogiken väntar exponentiellt längre, men jag ser den hamra på ändpunkten.”

”Den läste det i designdokumentet. Peka den mot den faktiska återförsöksmodulen — arbeta från primärkällan när beteendet spelar roll.”

En redogörelse för en primärkälla, ett steg bort — dokumentation som beskriver kod, en sammanfattning som beskriver en transkription, en rapport som beskriver sökresultat. Billigare att läsa in i kontextfönstret än källan den beskriver, men förlustbehäftad till sin konstruktion: den som skrev den avgjorde vad som var viktigt, och det som utelämnades är osynligt för en läsare som bara har sammanfattningen.

Mycket av arbetet med att utforma kontext går ut på att skapa sekundärkällor. Komprimering förvandlar sessionens historik till en sammanfattning som startar nästa session. En underagent använder sitt eget kontextfönster på en brusig sökning och returnerar en kort rapport. En överlämningsartefakt kondenserar sessionens beslut till ett dokument nästa session läser. Minnesystem destillerar vad en session lärt sig till anteckningar. Alla gör samma avvägning: trohet mot originalet byts mot utrymme.

Sekundärkällor fallerar på två sätt. De är förlustbehäftade — komprimeringssammanfattningen som tappade beslutet om schemat, rapporten som inte nämnde specialfallet. Och de driver iväg — primärkällan ändras men redogörelsen följer inte med, så dokumentationen beskriver förra kvartalets arkitektur med det här kvartalets självsäkerhet. När en agent agerar utifrån en sekundärkälla som har fallerat på något av sätten arbetar den självsäkert med fel information; lösningen är att skicka tillbaka den till primärkällan.

Inget av felen innebär att sekundärkällor är en dålig idé. Kontextfönstret är begränsat och primärkällor dyra; utan sammanfattningar, rapporter och överlämningsdokument får inget stort plats. Färdigheten är att veta vilka detaljer som tål förlusten — och att verifiera mot primärkällan när de inte gör det. En välgjord sekundärkälla har en kontexthänvisning tillbaka till originalet — sammanfattningen namnger transkriptionen den kommer från, dokumentet namnger filen det beskriver — så när redogörelsen inte räcker kan läsaren följa hänvisningen i stället för att arbeta utifrån det som gått förlorat.

Användning:

”Överlämningsdokumentet säger att autentiseringen är klar, men den nya sessionen hittar fortfarande trasig tokenförnyelse.”

”Dokumentet är en sekundärkälla — förra sessionen skrev vad den trodde, inte vad som är sant. Be den nya sessionen köra autentiseringstesterna och lita på primärkällan.”

Ett dokument som används för att bära information vid en överlämning — skrivs till miljön av en session och läses av en annan. Specifikationer, ärenden och plandokument är alla överlämningsartefakter.

Skälet att skriva ett sådant dokument: Modellen är tillståndslös, så inget i en session överlever när den rensas. Beslut, begränsningar och halvfärdiga planer — allt försvinner tillsammans med kontexten som innehöll dem. Miljön finns kvar. Genom att skriva det viktiga till en fil flyttas det till en plats där nästa session kan läsa det.

Artefakten är en sekundärkälla — en redogörelse för sessionens arbete, inte själva arbetet. Det är vad som gör den liten nog att introducera en ny session med, och även varför den kan vilseleda: den dokumenterar vad den skrivande sessionen trodde, och allt den utelämnade eller missförstod är osynligt för läsaren. När ett påstående är viktigt bör nästa session verifiera det mot primärkällan — koden och testerna — i stället för att ärva det.

En bra artefakt är skriven för en session som inte har någon kontext. Konkreta filsökvägar i stället för ”filen vi diskuterade”. Vad som beslutades och varför, så att nästa session inte tar om diskussionen. Vad som är klart och vad som återstår. Det hjälper att berätta för den skrivande sessionen vart artefakten ska: ”skriv ett överlämningsdokument för en ny session som inte vet någonting om det här arbetet”.

Det alternativa sättet att föra över innehåll är komprimering, som sammanfattar i minnet. Artefakten har två fördelar: den ligger på disk där du kan läsa och rätta den innan något blir beroende av den, och den kan återanvändas — samma specifikation kan introducera fem parallella sessioner.

Användning:

”Hur delar jag det här mellan planerings-agenten och den som implementerar?”

”Be planeraren skriva en överlämningsartefakt — filsökvägar, beslut och begränsningar. Implementeringssessionen börjar med en hänvisning till artefakten och använder den som sin instruktion.”

En överlämningsartefakt som beskriver ett arbete som sträcker sig över flera sessioner — vad som byggs, inte hur varje session bidrar. Den förändras medan arbetet fortskrider. Består av ärenden.

Specifikationen finns eftersom sessioner är tillfälliga, men stora arbeten inte är det. Allt som kräver mer än ett kontextfönster av arbete behöver en plats utanför kontexten — någonstans i agentens miljö som överlever rensa, oavsett om det är en fil i repot, ett GitHub-ärende eller ett ärendehanteringssystem agenten kommer åt. Specifikationen är den platsen: målet, begränsningarna, besluten hittills och listan över ärenden med status. En ny session kan läsa den och förstå var arbetet står utan att ärva bruset från den tidigare sessionen.

Specifikationer har igenkännbara stilar, till stor del ärvda från hur team redan skriver ned saker. Ett produktkravsdokument (PRD) betonar användarens vad och varför — funktioner, beteende och acceptanskriterier. Ett designdokument eller en RFC är mer tekniskt — den valda lösningen, förkastade alternativ och avvägningar. I den enklare änden gör en vanlig `plan.md` med en checklista över ärenden samma jobb för en funktion som sträcker sig över flera sessioner. Stilen är mindre viktig än rollen: för agenten är allt detta samma sak — en beständig avsiktsförklaring som den läser i början av varje session.

Användning:

”Borde allt det här göras i en session?”

”Nej, skriv en specifikation — dela upp den i ärenden och kör varje ärende i en egen session. Om du försöker göra allt i ett enda kontextfönster hamnar du i den dumma zonen innan du kommit halvvägs.”

En överlämningsartefakt som avgränsar en session arbete. Den står för sig själv eller ingår i en specifikation som ett av dess underordnade ärenden. Ärenden kan blockera eller blockeras av syskonärenden, så arbetsordningen följer av beroendegrafen i stället för en linjär plan.

Den avgörande begränsningen är storleken: en session. Ett ärende ska kunna slutföras innan sessionen driver ut ur den smarta zonen — och den begränsningen går att testa. Om sessionerna för dina ärenden regelbundet försämras innan arbetet är klart är ärendena för stora; dela upp dem. Om varje session ägnar större delen av sin kontext åt förberedelser innan fem minuters arbete utförs är de för små; slå ihop dem.

Ett bra ärende skrivs för en läsare utan annan kontext. Målet, acceptanskriterierna och kontexthänvisningar till relevanta filer och beslut — tillräckligt för att sessionen ska kunna börja arbeta utan att behöva återskapa det den förra visste.

Beroendegrafen möjliggör också parallellism. Oberoende ärenden — grafens löv — kan köras i varsin session samtidigt. Det är ett effektivt sätt att köra flera agenter samtidigt. I en programvarufabrik är det i sig signalen att ett ärende markerats som klart som startar dess session.

Användning:

”Var börjar jag med migreringsspecifikationen?”

”Titta på ärendegrafen — schemaändringen blockerar återfyllningen, och återfyllningen blockerar API-bytet. Välj ett löv och kör en session på det.”

En överlämning som görs i minnet: historiken från den föregående sessionen sammanfattas, och sammanfattningen startar en ny session. Den är avsiktligt förlustbehäftad: transkriptionen är en primärkälla, sammanfattningen en sekundärkälla — detaljer byts mot mer utrymme. Startas manuellt av användaren eller automatiskt via autokomprimering.

Mekanismen: Kontextfönstret är begränsat, och en lång session fyller det — varje verktygsresultat, varje läst fil och varje felsteg finns kvar i historiken. När det blir fullt ber agentramverket modellen sammanfatta sessionen, kastar bort den ursprungliga historiken och startar en ny session med sammanfattningen. Det som inte kom med i sammanfattningen är borta från kontexten. Vissa agentramverk mildrar detta genom att behålla den gamla transkriptionen på disk och lägga en kontexthänvisning till den i sammanfattningen — sekundärkällan länkar tillbaka till sin primärkälla, så att en detalj sammanfattningen tappat kan återfås genom att läsa originalet igen.

Sammanfattningen skrivs av modellen och kan därför styras av en prompt. ”Bevara besluten om schemat” gör det genererade artefaktet mer genomtänkt. Tidpunkten spelar också roll — komprimera vid ett fasbyte, när planen är fastställd, inte mitt i en uppgift.

Jämför med rensning, som tar bort allt och börjar från noll: komprimering försöker ta med det väsentliga; rensning förutsätter att det redan finns nedskrivet någon bättre stans.

Användning:

”Kontexten börjar bli tung och jag måste fortfarande få testet att gå igenom.”

”Komprimera innan du börjar — skriv in i sammanfattningsprompten vad som måste bevaras, så behåller den nya sessionen schemabesluten och släpper utforskandet.”

Komprimering som agentmiljön utlöser automatiskt när kontextfönstret nästan är fullt.

Agentmiljön håller koll på hur fullt kontextfönstret är. När det passerar en gräns — ofta omkring 80 % — pausar den, ber modellen sammanfatta sessionen hittills och fyller en ny session med sammanfattningen. Arbetet fortsätter sedan som om inget hade hänt.

Men något hände. Komprimering är förlustbringande, och automatisk komprimering sker vid en tidpunkt du inte valt. Manuell komprimering görs vid en fasgräns, när du kan säga åt modellen vad den ska bevara. Automatisk komprimering utlöses mitt i arbetet så snart gränsen nås — kanske halvvägs genom en refaktorering, medan sammanfattningen själv avgör vilka av dina beslut som var värda att behålla. Det klassiska symtomet: agenten fortsätter självsäkert men har i tysthet glömt en begränsning du slog fast för en timme sedan, och du märker det först när arbetet börjar motsäga den.

Försvaret är att inte låta den utlösas. Håll koll på kontextindikatorn och komprimera manuellt vid en naturlig gräns, eller skriv besluten i ett plandokument eller en överlämningsartefakt på disk, där ingen sammanfattning kan tappa bort dem. De flesta agentmiljöer låter dig också anpassa bufferten — flytta gränsen tidigare eller senare eller stänga av automatisk komprimering helt — så att du kan välja hur mycket marginal du behåller innan den utlöses.

Användning:

”Den verkar inte minnas vad vi bestämde om schemat tidigare.”

”Automatisk komprimering utlöstes mellan turerna — de tidiga besluten sammanfattades och vi måste ha tappat bort något. Läs in plandokumentet igen eller komprimera manuellt nästa gång så att du styr vad som bevaras.”

Ett system som försöker göra en agent tillståndsfull mellan sessioner. Det sparar information i miljön under en session och läser in den i kontextfönstret igen när framtida sessioner börjar, så att agenten behåller kontinuitet även efter att användaren rensat sessionen.

Ett minnessystem har två halvor. Skrivvägen: under en session sparar agenten det den har lärt sig — en preferens du uttryckt, ett faktum om projektet — som filer i miljön. Läs vägen: vid sessionsstart läser agentramverket in dessa filer, eller ett index över dem, i kontextfönstret igen. Många agentramverk levereras med ett eget minnessystem — Claude Codes `/memory` är ett exempel — men du kan också bygga ett själv: en katalog med anteckningar och en instruktion i AGENTS.md att läsa dem.

Samma avvägningar som för allt innehåll som alltid läses in gäller. Minnen samlas på hög, så de flesta system läser in ett index på en rad och lämnar själva innehållet bakom kontexthänvisningar i stället för att bädda in allt. Minnen är också sekundärkällor, och därför blir de inaktuella: ett faktum från mars läses in med samma säkerhet i juni, efter att projektet gått vidare. Ett minnessystem behöver rensas, precis som AGENTS.md.

Användning:

”Jag måste hela tiden berätta att jag använder Postgres, inte MySQL.”

”Koppla in ett minnessystem — skriv det agenten lär sig till filsystemet vid första turen, läs in det igen när sessionen startar. Modellen är i sig tillståndslös; minneslagret låtsas ge den kontinuitet.”

En fil i miljön som agentramverket läser in i kontextfönstret när en session börjar — projektets stående instruktioner till agenten. En konvention som fungerar över agentramverk; vissa har även en egen variant (Claude Codes heter CLAUDE.md).

Eftersom filen läses in automatiskt är den ett sätt att slippa upprepa sig mellan sessioner. Modellen är tillståndslös — en korrigering du ger i en session är borta i nästa, och du får tala om för varje ny session att projektet använder pnpm, att tester körs med en viss flagga och att en katalog är genererad och inte ska röras. När du har korrigerat agenten om samma sak två gånger är korrigeringen en möjlig rad i AGENTS.md.

Lämpligt innehåll är sådant agenten inte kan härleda ur koden: bygg- och testkommandon, konventioner som inte är uppenbara i kodbasen och absoluta begränsningar (”redigera aldrig den genererade klienten”). Kort och deklarativt — det är en instruktion, inte dokumentation.

Avvägningen är att allt i filen alltid läses in. Instruktioner samlas på hög, de flesta irrelevanta för en viss uppgift, och en lång AGENTS.md kostar tokens och urvattnar sig själv — ju fler instruktioner som finns i kontexten, desto mindre tillförlitligt följer modellen någon av dem.

Undvik: att använda AGENTS.md för innehåll som bör visas gradvis — allt i filen kostar en token varje tur, i varje session, oavsett om sessionen behöver det eller inte. En stilguide kan ligga bakom en skill eller kontexthänvisning; reservera AGENTS.md för regler som gäller överallt.

Användning:

”Varför börjar varje session med att 4 000 tokens redan har förbrukats?”

”Kolla AGENTS.md — någon klistrade in hela stilguiden där i stället för att lägga den bakom en skill.”

Läs bara in den kontext en agent behöver just nu och använd kontextpekare till resten. Begreppet är hämtat från gränssnittsdesign, där det betyder att bara visa användarna de kontroller som hör till deras aktuella uppgift och dölja resten bakom ett klick.

Tekniken finns eftersom kontext kostar på två sätt. Varje token som läses in i förväg faktureras som indatatoken vid varje tur, och varje token förbrukar uppmärksamhetsbudget oavsett om agenten behöver den eller inte. En AGENTS.md som fyllts med hela stilguiden, drifthandboken och databasreglerna gör agenten sämre på alla tre områden — instruktionerna som är viktiga för den aktuella uppgiften späds ut av dem som inte är det. Tecknet är en agent som ignorerar regler du vet finns i dess kontext: reglerna finns där, men de är begravda.

Progressiv visning vänder på det. Håll det alltid inlästa lagret litet — en mening per ämne och en pekare till var detaljerna finns. Agenten läser stilguiden när den skriver en komponent, drifthandboken vid driftsättning och ingendera när den rättar ett test. Färdigheter är det mönster som byggts in i agentmiljön: en kort beskrivning läses in varje session, och de fullständiga instruktionerna läses bara in när färdigheten aktiveras.

Användning:

”Ska jag lägga in hela stilguiden i AGENTS.md?”

”Nej — använd progressiv visning. Hänvisa till stilguiden som en färdighet agenten läser in när den faktiskt behöver skriva en komponent. AGENTS.md kostar token vid varje tur.”

En hänvisning i ett dokument till ett annat, så att agenten bara hämtar in det i kontextfönstret när uppgiften kräver det. Grundenheten som gradvis visning byggs av.

Skälet till att använda en hänvisning (i stället för att bädda in innehållet) är kostnaden. En hänvisning är en rad i kontextfönstret. Dokumentet bakom kan innehålla tusentals token, men de kostar ingenting förrän agenten faktiskt följer hänvisningen. Bädda in en driftshandbok på 2 000 token i AGENTS.md, så betalar varje session för den; ersätt den med ”utrullningsprocess: se `internal/deploy.md`”, så laddas den bara in i de sessioner som rullar ut. Agenten följer hänvisningen med ett verktygsanrop när uppgiften passar.

En hänvisning behöver två delar för att fungera: en stabil sökväg och en tillräcklig beskrivning för att agenten ska veta när det är värt att följa den. En naken sökväg ger agenten ingen anledning att följa den; ”se `internal/deploy.md`” utan någon antydan om innehållet hoppas över av en session som hade behövt den. Skriv raden så att den stämmer med hur uppgifter ser ut: ”release, utrullning eller återställning — läs `internal/deploy.md` först”.

Hänvisningar finns överallt när man väl börjar leta: rader i AGENTS.md, beskrivningar av skills (agentramverket läser in beskrivningen; innehållet i skillen väntar bakom den), filnamn i en kataloglista och länkar mellan dokument.

En hänvisning kan också knyta en sekundärkälla tillbaka till den primärkälla den bygger på — komprimeringssammanfattningen som nämner den ursprungliga transkriptionen, dokumentet som nämner källfilen det beskriver. Då kan sekundärkällans förluster återställas: när sammanfattningen inte räcker följer agenten hänvisningen och läser originalet i stället för att arbeta utifrån det sammanfattningen råkade behålla.

Undvik: ”referens” — för torrt; förmedlar inte att det drar in mer kontext att följa den. ”Portal” — för högtravande.

Användning:

”AGENTS.md börjar bli enorm.”

”Det mesta bör vara kontexthänvisningar, inte innehåll. Behåll reglerna som alltid gäller direkt i filen; gör driftshandboken och stilguiden till skills och lämna kvar en kontexthänvisning.”

En inlärningsbar förmåga samlad som en enhet — instruktioner och resurser för att utföra en uppgift väl, förvarade i miljön tills en kontexthänvisning hämtar in dem i kontextfönstret för den aktuella uppgiften. Enheten för gradvis visning i ett agentramverk.

Skills är en öppen standard som definieras på agentskills.io — ursprungligen utvecklad av Anthropic och sedan antagen av de flesta större agentramverk, så en skill som skrivs en gång fungerar i dem alla. Formatet är en mapp som innehåller:

• En `SKILL.md`-fil — metadata (minst ett namn och en beskrivning) samt själva instruktionerna
• Eventuellt skript som agenten kan köra
• Eventuellt mallar och referensmaterial som instruktionerna hänvisar till

Som standard finns bara namn och beskrivning i kontexten. När agentens uppgift passar läser den in resten. Fram till dess tar skillen nästan ingen plats — en mening eller två av token, oavsett hur omfattande hela instruktionen är.

Detta skiljer skills från AGENTS.md, som läses in i varje session oavsett uppgift. En skill läses när en viss typ av arbete blir aktuell — en release, uppstart av en ny tjänst eller skrivandet av en migrering — och ignoreras resten av tiden.

Undvik: ”verktyg” — ett verktyg är något agenten anropar; en skill är instruktioner den läser.

Användning:

”Var ska jag lägga utrullningshandboken?”

”Som en skill — agenten läser in den bara när uppgiften gäller utrullning. I AGENTS.md skulle den kosta tokens vid varje tur för något vi använder varje vecka.”

En agent som startas av en annan agent via ett verktygsanrop. Körs i sin egen session med eget kontextfönster, och skickar tillbaka ett enda verktygsresultat. Skild från en överlämning — den överordnade agenten förväntar sig uttryckligen ett svar; en överlämning har ingen returväg. Kan inte starta fler underagenter — trädet går bara en nivå ned. Underagenter finns till för att isolera kontext, inte för att bygga hierarkier.

Poängen är att hålla störande arbete borta från den överordnade agentens kontext. En bred sökning eller en lång utflykt bland filer producerar sidor med verktygsresultat, varav de flesta bara är relevanta precis så länge det tar att hitta svaret. Körs det i den överordnade agenten stannar allt i dess kontext resten av sessionen. Körs det i en underagent fyller bruset i stället ett tillfälligt fönster — bara slutrapporten hamnar i den överordnades kontext. Rapporten är en sekundärkälla: den överordnade agenten får underagentens redogörelse, inte råresultaten, så allt rapporten utelämnar är osynligt för den.

Underagenter kör också parallellt — en överordnad agent kan starta flera samtidigt för oberoende arbetsdelar.

Användning:

”Grep-resultaten fyller hela min kontext.”

”Starta en underagent för sökningen — den använder sitt eget kontextfönster på bruset och rapporterar de två filsökvägar du faktiskt behöver.”

Ett arbetssätt där en eller flera människor arbetar tillsammans med agenten under en session — granskar, styr om eller samarbetar i realtid. Människan är närvarande och engagerad, inte bara en grindvakt för enskilda åtgärder.

Kontrasten är obevakat arbete, där agenten kör utan tillsyn och du bedömer resultatet efteråt. Människa i loopen innebär att fånga problem medan de fortfarande är billiga: du ser agenten välja fel fil, misstolka kravet eller börja gå åt fel håll, och styr om den med en mening — i stället för att upptäcka tjugo minuters självsäkert arbete byggt på misstaget. Agenter vet inte pålitligt när de är på fel spår; lämnade ensamma fortsätter de hellre framåt än stannar och frågar.

Vilket arbetssätt som passar beror på uppgiften. Väl specificerade uppgifter med låg risk och enkla sätt att verifiera passar obevakat. Uppgifter som är tvetydiga, oåterkalleliga eller svåra att granska i efterhand — en schemamigrering, ett knepigt designbeslut, allt som påverkar produktion — passar bäst när du är med i loopen. Bedömningen handlar i grunden om hur dyrt ett felsteg är och hur sent du skulle upptäcka det.

Vissa arbeten är naturligt sett människa-i-loopen eftersom dina reaktioner är själva inputen. Grillning fungerar bara om du är där och svarar på frågorna; prototypning fungerar bara om du är där och reagerar på artefakten.

Att vara med i loopen kostar uppmärksamhet, den knappa resursen. En del av att bli bättre på att arbeta med agenter är att säkert flytta mer arbete ut ur loopen — med planer, automatiska kontroller och mänsklig granskning i slutet i stället för tillsyn hela tiden. En programvarufabrik tar detta längre genom att starta sessioner från utlösare, så inte ens igångsättningen behöver dig.

Användning:

”Ska jag köra detta obevakat över natten?”

”Nej, schemamigrering — håll det med människa i loopen. Jag vill se varje steg och styra om den väljer fel kolumn att fylla på från.”

”Away from keyboard” — borta från tangentbordet. Ett arbetssätt där användaren startar en session och lämnar agenten att arbeta utan tillsyn. Genomströmningsmultiplikatorn för AI-kodning — många obevakade sessioner kan köras parallellt medan du sover, äter eller arbetar med något annat. Kräver vanligtvis ett tillåtande behörighetsläge och sandlådeisolering för att vara säkert.

När du inte är där hanterar agenten tvetydigheter annorlunda. När du tittar uppstår ett oklart beslut som en fråga och du svarar; när du har gått väljer agenten ett standardalternativ och fortsätter, och alla senare beslut bygger på den gissningen. Det typiska felet är att komma tillbaka till flera timmars färdigt, självsäkert arbete som bygger på ett felaktigt beslut från de första tio minuterna. Arbetet är inte slarvigt — det hänger ihop, men det handlar om fel sak.

Eftersom du inte kan bidra under körningen behöver du bidra före och efter. Före: red ut oklarheten i förväg — en grillnings-session, en skriven specifikation — så agenten får färre luckor att fylla ensam. Under tiden: Automatiska kontroller och automatisk granskning ersätter uppmärksamheten du inte ger och stoppar snabbt sådant som går att fånga mekaniskt. Efteråt: körningen slutar i något granskningsbart — en PR, inte redan sammanslagna ändringar. Obevakad körning tar inte bort mänsklig granskning; den skjuter upp den till slutet, och därför måste det som kommer då vara värt att granska. Därför är också AX viktigast vid obevakade körningar — utan någon som tittar är miljön agentens enda stöd.

Undvik: ”bakgrundsagent” — sätter maskinen (”kör i bakgrunden”) i centrum i stället för det mänskliga arbetssättet (”användaren har gått”). AFK namnger det som spelar roll: användaren tittar inte.

Användning:

”Jag kör detta obevakat — tre agenter i sandlådor på refaktoreringen, och granskar PR:erna i morgon bitti.”

”Kringgå behörigheter?”

”Ja, skrivskyddat filsystem, inget nätverk.”

En deterministisk verifiering som körs i miljön — tester, typkontroller, lintning, bygge och pre-commit-hookar. Godkänt eller underkänt, utan bedömning. Signalen en agent kan självkorrigera utifrån utan att involvera någon annan. Ett fladdrigt test är en trasig kontroll, inte en icke-kontroll; automatiska kontroller är deterministiska med avsikt.

Självkorrigering fungerar som en loop. Agenten gör en ändring, kör kontrollen som ett verktygsanrop, och felutdata hamnar i dess kontextfönster — ett typfel med fil och rad, ett misslyckat påstående med förväntade och faktiska värden. Det räcker för att agenten ska kunna rätta problemet och köra kontrollen igen, om och om igen tills den godkänns, utan att någon människa behöver ingripa. Determinismen är det som gör loopen pålitlig: samma kod ger alltid samma utslag, så ett godkänt resultat betyder något. En fladdrig kontroll förgiftar detta — agenten ”rättar” kod som var korrekt eller försöker sig förbi ett verkligt fel.

Därför är bra kontroller en stor del av en kodbas AX. En agent i ett repo med strikta typer, en snabb testsvit och en linter upptäcker de flesta av sina egna misstag innan du ser dem; en agent i ett repo utan detta levererar vad den än producerar. Skillnaden spelar störst roll vid obevakade körningar, där kontrollerna är den enda verifieringen medan körningen pågår. Men en kontroll fångar bara det den påstår sig kontrollera — gröna kontroller betyder att de egenskaper som påstås gäller, inte att koden är riktig. Luckorna som kräver bedömning är vad automatisk granskning och mänsklig granskning är till för.

Undvik: ”återkopplingsloop” / ”mottryck” — båda blandar ihop kontroller med granskning. Undvik: ”test” — tester är automatiska kontroller, men alla automatiska kontroller är inte tester.

Användning:

”Agenten levererar hela tiden trasig kod i de obevakade körningarna.”

”Vilka automatiska kontroller är kopplade till sandlådan?"

”Bara enhetstesterna.”

”Lägg till typkontroll och lintning — agenten självkorrigerar med dem innan PR:en ens öppnas.”

En agent som granskar en annan agents arbete, ofta med en annan modell eller systemprompt. Icke-deterministisk: den gör en bedömning. Kan köras var som helst — före sammanslagning av en PR, i efterhand på commit-historik eller mitt i en session som en underagent. En LLM som domare i CI är automatisk granskning, inte en automatisk kontroll; det är vad påståendet gör som avgör kategorin, inte var det körs.

Det fungerar eftersom granskaren hålls åtskild från arbetsagenten. Att be agenten som skrev koden granska sitt eget arbete ger väldigt lite — sessionen som skapade buggen innehåller också resonemanget som ledde fram till den, och agenten läser sina egna slutsatser som bekräftelse. En granskare med ett nytt kontextfönster saknar den kopplingen: den ser diffen som en främling skulle göra, vilket granskning bygger på. En annan modell eller en systemprompt särskilt utformad för granskning vässar detta ytterligare — andra blinda fläckar och en systemprompt avgränsad till det du faktiskt bryr dig om (säkerhet, API-kontrakt, prestanda) i stället för ett vagt ”leta efter problem”.

Den passar mellan de andra granskningslagren. Automatiska kontroller är deterministiska och fångar sådant som kan hävdas mekaniskt; mänsklig granskning är dyr och svårast att skala. Automatisk granskning ligger mitt emellan: den fångar problem som kräver bedömning — ett missvisande funktionsnamn, ett missat specialfall — till maskinkostnad. Eftersom den är icke-deterministisk kan den missa saker och flagga sådant som inte är problem; se den som ett filter som höjer lägstanivån innan en människa tittar, inte som en grind som ersätter människan.

Undvik: ”AI-granskning” / ”agentgranskning” — för vagt för att skilja från själva arbetsagenten.

Användning:

”Vi får för många dåliga PR:er från de obevakade körningarna.”

”Lägg till ett steg med automatisk granskning före sammanslagning — annan modell, separat systemprompt, avgränsad till säkerhet och kontraktsändringar.”

Användaren läser koden som agenten har skapat och bildar sig en uppfattning om den. Att läsa diffen eller de ändrade filerna räknas; att läsa agentens beskrivning av vad den gjorde gör det inte — berättelsen är inte artefakten. Beskrivningen är en sekundärkälla, skriven av den som granskas; diffen är primärkällan, och granskning innebär att läsa den.

Agenter ökar mängden producerad kod, så granskningen blir flaskhalsen. En användbar idé är att lägga olika granskningsmetoder i lager. Automatiska kontroller hittar mekaniska fel, automatiserad granskning hittar sådant som går att beskriva, och mänsklig granskning reserveras för det bara du kan bedöma — om ändringen är rätt ändring, om tillvägagångssättet passar kodbasen och om detta över huvud taget bör finnas.

Granskning är också billigare ju tidigare den sker. Att läsa en plan innan arbetet börjar eller en liten diff mitt under arbetet tar minuter; att gräva igenom en färdig gren efter en AFK-körning tar längre tid. Var du placerar granskningskontrollen är ett human-in-the-loop-beslut, inte något man kommer på i efterhand.

Undvik: enbart ”kodgranskning” — det är tvetydigt mellan mänsklig och automatiserad granskning.

Användning:

”Jag granskade AFK-utdata manuellt.”

”Läste du diffen eller bara sammanfattningen?”

”Diffen. Sammanfattningen sa att den tog bort död kod — det visade sig att funktionen anropades från en genererad fil.”

Ett arbetssätt där användaren accepterar agentens kod utan mänsklig granskning. Diffen behandlas som ogenomskinlig — det viktiga är om programmet beter sig rätt, inte vad som finns inuti. Automatisk granskning och automatiska kontroller kan fortfarande köras; vibekodning tar inte ställning till något av dem.

Uttrycket kommer från Andrej Karpathy, som myntade det i början av 2025: man ”ger sig helt hän åt vibbarna” och ”glömmer att koden ens finns” — beskriver vad man vill ha, accepterar resultatet och bedömer det genom att köra det.

Vibekodning byter granskning mot hastighet. Att läsa differ är oftast det långsammaste steget i agentdrivet arbete, så att hoppa över det tar bort den största flaskhalsen. För kod där fel är billiga — prototyper, engångsskript och interna verktyg — är det en rimlig avvägning. Risken ökar med kodens livslängd och betydelse.

Kostnaden kommer senare. Vibekodade ändringar samlas i en kodbas ingen har läst, och beteendet var det enda som kontrollerades — därför levereras allt som beteendet inte avslöjar, som en hemlighet i loggarna, ett missat specialfall eller felaktig datahantering, utan att upptäckas. Första gången någon felsöker systemet är första gången någon läser koden. När mänsklig granskning är borta är den automatiska verifiering som återstår — tester, typer och automatisk granskning — den enda grinden koden passerar. Samma hållning till en hel kodbas, eller en del av den, vars ändringar kommer från en programvarufabrik, kallas en mörk fabrik.

Undvik: ”vibekodning” som synonym för ”AI-kodning av låg kvalitet” — ordet beskriver inställningen till granskning, inte resultatets kvalitet.

Användning:

”Läste du vad den ändrade i autentiseringsflödet?”

”Vibekodade det — inloggningen fungerar fortfarande, det var allt jag kollade.”

”Läs diffen innan du pushar; vibekodning av autentisering är hur hemligheter hamnar i loggarna.”

Den gemensamma förståelsen av vad som byggs, som användaren och agenten delar men som är fristående från alla artefakter. Brooks begrepp (The Design of Design): samtalet, överlämningsartefakterna och koden är alla artefakter som försöker fånga eller nå designkonceptet, men ingen av dem är det. Designkonceptets kvalitet märks på kvaliteten hos samtalet som formade det.

Begreppet sätter namn på glappet bakom en välbekant frustration: agenten skriver exakt det du bad om, men resultatet är ändå fel. Den vanliga orsaken är att du inte själv hade kommit fram till exakt vad du ville ha. Designkonceptet var inte färdigt i ditt eget huvud — prompten fångade det du hade rett ut och var tyst om det du inte hade rett ut. Agenten fyllde tystnaden med egna antaganden eftersom det inte fanns något att stämma av mot. Inget gick sönder. Ni saknade ett gemensamt designkoncept eftersom det ännu inte fanns något helt koncept att dela.

Du märker att ni delar ett designkoncept på samma sätt som med en kollega: den andra parten börjar besvara frågor du ännu inte har ställt på det sätt du själv skulle ha gjort. Fram till dess består arbetet av samtal — utfrågning är den medvetna varianten — och att skriva en specifikation för tidigt bevarar bara missförståndet i en mer beständig artefakt. Designkonceptet förändras också när du lär dig mer; artefakterna släpar efter. Därför kan en specifikation som troget återger förra veckans förståelse ändå vilseleda den här veckans session.

Användning:

”Den skriver exakt det jag bad om, men det är ändå fel.”

”Ni delar ännu inget designkoncept — den fyller luckorna med antaganden. Fortsätt prata tills avbeställning, återbetalning och delleverans stämmer överens mellan er innan du ber den skriva en specifikation.”

En teknik för att utveckla ett designkoncept med en agent: agenten intervjuar användaren sokratiskt, ett beslut i taget, och föreslår ett rekommenderat svar för varje. Den bromsar rusningen mot en färdig plan — inget överlämningsartefakt skrivs förrän konceptet stabiliserats.

Tekniken behövs eftersom agenter tyst fyller i luckor. När agenten ombeds skriva en specifikation utifrån en prompt på två rader stannar den inte vid besluten du ännu inte har fattat — den väljer standardvärden och skriver in dem. Resultatet ser komplett ut, och gissningarna går inte att skilja från valen, så du upptäcker dem sent: vid granskningen eller när den byggda funktionen hanterar ett specialfall på ett sätt du aldrig valt. Grillning vänder på detta — i stället för att gissa måste agenten fråga.

Det är en människa-i-loopen-teknik: dina svar är inputen. När en fråga inte går att besvara i samtal — du skulle behöva se saken — byt till prototypning.

Användning:

”Den gick direkt på att skriva specifikationen och fick avbeställningslogiken fel.”

”Grilla den först — be den fråga om delavbeställningar, återbetalningar och tidpunkter innan den binder fast något i dokumentet. Billigare att reda ut i samtal än i kod.”

Låta agenten bygga en snabb och grov version av något när samtalet inte ger tillräcklig detaljrikedom och du behöver en faktisk artefakt att diskutera.

Utfrågning reder ut designbeslut i ett samtal. Samtal är billiga men detaljfattiga: vissa frågor går inte att besvara med ord — hur en interaktion känns, om formen på ett API är smidig i verklig anropskod eller om en layout fungerar med verkliga datamängder. Intervjun når en fråga och ditt ärliga svar är ”det vet jag inte, jag måste se det”. Efter den punkten går diskussionen i cirklar. Be i stället agenten bygga saken, titta på den och återvänd till samtalet med ett svar.

Agenter sänker byggkostnaden, vilket gör det här praktiskt. En grov version som tidigare tog en dag att skissa fram tar nu minuter, så det lönar sig att göra det regelbundet. Det är en human-in-the-loop-teknik: prototypen finns där för att du ska kunna reagera på den.

Du brukar inte nöja dig med en enda titt. Iterera med prototypen — reagera, be om en ändring, reagera igen — så att varje omgång löser ytterligare ett beslut utifrån den verkliga artefakten, med högre detaljrikedom än samtalet kan ge.

En prototyp måste inte vara slarvig i alla delar. Du kan bygga just de delar du utvärderar med produktionskvalitet, så att komponenten eller API:t du reagerade på kan flyttas in i den riktiga kodbasen när beslutet är fattat. Därför är prototypen viktigt underlag för specifikationen.

Användning:

”Vi har ägnat en halvtimme åt att diskutera om guiden ska vara en sida eller tre steg.”

”Ord avgör det inte — låt agenten prototypa båda. Vi klickar oss igenom dem och vet om fem minuter.”

Utvecklarupplevelse — hur lätt en kodbas och dess verktygskedja gör det för människor att utföra ett bra arbete. Bra DX innebär snabb återkoppling, tydliga felmeddelanden, dokumentation som besvarar den fråga man faktiskt har och en konfiguration som fungerar på första försöket. Begreppet är mycket äldre än AI-kodning; det finns främst här som kontrast till AX.

DX beskriver samspelet mellan människan och kodbasen — inget mer. Den viktigaste skillnaden mellan målgrupperna är att människor är tillståndsbevarande medan agenter är tillståndslösa. En människa lär sig kodbasen en gång och bär med sig kunskapen varje dag därefter, vilket gör dålig DX uthärdlig: hon kringgår långsam CI genom att samla sina pushar, kompenserar för saknad dokumentation genom att fråga i Slack en gång och minns var saker finns trots en förvirrande struktur. Med tiden samlas lösningarna på problemen, och teamet blir produktivt i en kodbas som motarbetar dem.

Agenter möter samma kodbas utan att kunna bygga vidare på sådana erfarenheter. Eftersom de är tillståndslösa mellan sessioner lär de sig kodbasen från början varje gång — de tjänar på snabba tester och tydliga felmeddelanden, men allt de kom fram till i går är borta om det inte skrevs in i omgivningen, som agenten bara uppfattar genom verktygsresultat. Det är denna skillnad AX beskriver: de delar av DX som finns kvar när utvecklaren är en agent, plus sådant människor inte behöver tänka på, som att hålla kontextfönstret fritt.

Överlappningen gör att investeringar i DX ofta förbättrar AX på köpet — strikta typer, snabba tester och förutsägbar struktur hjälper båda. Skillnaderna innebär att det inte alltid gäller: en utmärkt introduktionsguide hjälper en människa i en vecka men inte en agent, såvida den inte går att hitta via AGENTS.md.

Användning:

”Vår DX är bra — nyanställda blir produktiva på en vecka.”

”Produktiva eftersom någon sitter med dem under den veckan. Agenten får inte den veckan; granska AX separat.”

Agentupplevelse — hur väl miljön är ordnad för att en agent ska kunna göra ett bra jobb i en kodbas. Motsvarigheten till DX för agenter. När samma agent fungerar bra i ett repo och dåligt i ett annat — samma modell, samma agentramverk — är skillnaden oftast AX. Första impulsen är att skylla på modellen eller skriva om prompten; lösningen finns oftare i repot.

God AX har tre huvuddimensioner:

AX och DX överlappar — bra kontroller och ren arkitektur hjälper båda målgrupperna — men de skiljer sig också åt. Människor klarar av tyst kunskap, långsam CI och ”fråga Sarah om faktureringsmodulen”; agenter gör det inte. Agenter har ingen nytta av verktygstips i IDE:n eller snygga dashboards; de behöver fel som text i ett verktygsresultat. En kodbas kan ha god DX och dålig AX.

Undvik: att behandla AX som synonym till DX — målgrupperna behöver olika investeringar.

Användning:

”Agenten skriver fantastisk kod i API-repot och skräp i frontend.”

”API-repot har strikta typer och en snabb testsvit; frontend har inget av det och fyrtio alltid inlästa skills. Det är en AX-skillnad, inte ett modellproblem.”

Ett arbetssystem där agent-sessioner startas av utlösare — ett skapat ärende, ett schema, ett CI-fel eller att en annan session avslutas — i stället för av en människa, så att mer arbete körs obevakat och mänsklig uppmärksamhet ägnas åt de människa-i-loopen-beslut som återstår.

Utan en fabrik börjar varje session för att någon startade den. Även helt obevakat arbete väntar på att någon öppnar sessionen, pekar den mot ärendet och sätter igång. Team vill kunna leverera mer än så. En fabrik tar bort människan från starten av sessioner, men inte nödvändigtvis från något annat.

Vanliga utlösare och sessionerna de startar:

En fabrik behöver inte täcka hela programvaruprocessen. Ett cronjobb som kör en sorts session och öppnar en granskningsbar PR är en fabrik. Det är användbart att börja så smått: en smal loop ger små, likartade PR:er, och granskningen visar hur mycket du kan lita på loopen innan den breddas.

Människor kan vara var som helst i en fabrik — skriva och etikettera ärendena som utlöser sessioner, godkänna en plan innan implementeringen börjar och göra mänsklig granskning före sammanslagning. Huvudfrågan i utformningen är vilka beslut som förblir mänskliga. En kodbas, eller en del av den, där ingen människa granskar fabrikens resultat, är en mörk fabrik.

Användning:

”Vem rättade alla överträdelser av `no-floating-promises`?”

”Fabriken. Ett cronjobb väljer en lintregel per natt och öppnar en PR. Jag granskar den bara på morgonen.”

En kodbas, eller en del av en, där en programvarufabrik skriver koden och ingen människa läser den. Det finns ingen mänsklig granskning. Människor kan fortfarande skriva ärendena som startar arbetet, men ingen läser koden som kommer ut. Namnet kommer från fabriker med ”släckta lampor”, där produktionen sker utan människor på golvet.

En mörk fabrik är vibekodning för ett kodområde, inte för en enskild ändring. När du vibekodar väljer du att inte läsa en ändring du själv har bett om. Men du vet att ändringen finns. I en mörk fabrik gör teamet det valet en gång för hela området. Därefter ber ingen om varje ändring eller ser den. Ändringar kommer så fort utlösarna startar nytt arbete.

Problemet märks när något går sönder. Du vet inte vad som ändrades eftersom ingen läste ändringarna. Du måste felsöka kod som ingen i teamet har läst. Orsaken kan finnas i vilken som helst av många ändringar, och alla klarade kontrollerna.

Automatiska kontroller och automatisk granskning är de enda grindarna. Om de inte hittar något problem hamnar problemet i koden.

Undvik: att kalla en kodbas ”mörk” bara för att fabriken kör utan att någon tittar. Om agent-sessioner körs obevakat och en människa granskar PR:erna är det en programvarufabrik. Det är inte en mörk fabrik.

Användning:

”Vem ändrade återförsökslogiken i faktureringstjänsten? Ingen i teamet minns det.”

”Faktureringstjänsten är en mörk fabrik. Agenterna slår ihop alla ändringar som klarar CI. Ingen läste den ändringen.”