Modellen har inget minne mellan sessioner, och ditt eget är sämre än du tror. En beslutslogg är en kort fil där varje rad säger vad ni bestämde, varför, vad som ligger utanför och hur det verifierades. Den tar minuter att underhålla och gör att nya sessioner startar från redan fattade beslut i stället för att öppna dem igen.
Slingan: samma diskussion varje session
Det här är inte att modellen är opålitlig. Den är konsekvent på ett sätt som är lätt att missförstå: den ger det bästa svaret den kan utifrån det den ser. Ser den inte att frågan redan är avgjord, behandlar den den som öppen.
Följden blir en form av drift som är svår att upptäcka i stunden. En dag föreslås DTO-mappningen i routelagret. Nästa dag, med något annorlunda kontext i prompten, föreslås samma logik i tjänstelagret. Båda förslagen är rimliga i sig. Bara det ena stämmer med vad ni faktiskt bestämt.
Kostnaden är inte främst tiden det tar att diskutera om. Det är att kodbasen sakta blir inkonsekvent, eftersom olika delar byggdes under olika sessioner med olika svar på samma fråga. Ett halvår senare är det ingen som kan säga vilket mönster som är det rätta, för det finns tre.
Vad en beslutslogg är — och vad kontextfilen gör i stället
Det finns redan en fil som de flesta AI-verktyg läser automatiskt, och som verktygsguiden rekommenderar att du skriver. Den är inte samma sak, och det är värt att hålla isär dem.
Skillnaden märks tydligast när något ska ändras. Kontextfilen säger att ni använder ett visst köbibliotek. Beslutsloggen säger att ni valde det framför alternativet därför att ni behövde fördröjda meddelanden, och att det var det enda kravet som avgjorde. Med den informationen kan både du och modellen bedöma om beslutet fortfarande håller — utan den blir varje omprövning en gissning.
Det är frestande att lägga besluten i kontextfilen och slippa en fil till. Problemet är att kontextfilen ska vara kort nog att skickas med i varje prompt. Läggs historiken där växer den tills den tränger ut det som faktiskt behövs varje gång, och då börjar folk stryka i den. Håll dem åtskilda och skicka med beslutsloggen bara när ämnet berörs.
Fyra fält per post
Det här är inte arkitekturdokumentation. Det är en arbetsanteckning som ska gå att skriva på två minuter medan beslutet fortfarande är färskt.
Vad varje post innehåller
- Beslutet. Vad som gäller, i en mening, i presens. "Validering sker i tjänstelagret, inte i kontrollern."
- Skälet. Varför, med det avgörande argumentet först. Inte alla argument — det som fällde avgörandet.
- Avgränsningen. Vad beslutet inte gäller. Det här fältet hoppas oftast över och är det som sparar mest tid senare.
- Verifieringen. Hur ni vet att det fungerar. Ett test, en mätning, en körning — eller ärligt "inte verifierat, antagande".
En färdig post kan se ut så här, och behöver inte se snyggare ut än så:
Beslut: All indatavalidering sker i tjänstelagret. Kontrollern gör bara typkonvertering.
Skäl: Samma anrop görs från både HTTP-API och bakgrundsjobb. Validering i kontrollern hade missat jobben helt.
Avgränsning: Gäller inte formatvalidering i klienten, som finns kvar för användarvänlighetens skull.
Verifierat: Test som kör samma ogiltiga indata via båda ingångarna och förväntar samma fel.
Fyra rader. Nästa gång någon — människa eller modell — föreslår att validering flyttas till kontrollern finns svaret redan, och det tar tio sekunder att läsa i stället för tjugo minuter att återuppfinna.
När en post ska skrivas — och när den inte ska det
En logg som innehåller allt läses inte. Tröskeln är enkel: skriv en post när beslutet är sådant att någon rimligen kunde ha valt annorlunda, och när det skulle kosta att ändra det senare.
En rimlig takt för ett aktivt projekt är några poster i månaden. Blir det fler har tröskeln satts för lågt; blir det noll under ett kvartal där mycket hänt är den satt för högt.
Att använda loggen i en prompt
Loggen gör ingen nytta liggande i repot. Poängen är att den klistras in när ämnet berörs — och bara då, eftersom hela loggen i varje prompt är precis det brus som promptguiden varnar för.
Formuleringen som fungerar är kort och stänger dörren:
Följande beslut är redan fattade och ska inte omprövas i den här uppgiften:
[klistra in relevanta poster]
Om du anser att något av dem är fel — säg det separat och fortsätt ändå enligt beslutet.
Den sista meningen är värd att ha med. Den gör att du får höra invändningen om det faktiskt finns en, utan att modellen börjar bygga om på eget bevåg. Ibland är invändningen befogad, och då har du underlag för att ta upp beslutet igen — medvetet, i stället för av misstag.
Att hålla den levande
En logg som beskriver hur ni tänkte för ett år sedan, utan att säga att det ändrats, är sämre än ingen logg alls. Både du och modellen följer den utan att invända.
Lösningen är att aldrig radera. När ett beslut ändras stryks det gamla över och den nya posten hänvisar bakåt:
Beslut: Ersätter beslutet från 2026-02-03. Bakgrundsjobb körs nu i samma process som API:t.
Skäl: Den separata arbetarprocessen infördes för belastning som aldrig uppstod. Två processer att driftsätta kostade mer än de gav.
Avgränsning: Gäller tills kötiden regelbundet överstiger en minut. Då tas frågan upp igen.
Verifierat: Lasttest på tre gånger nuvarande trafik utan köuppbyggnad.
Historiken är inte skräp — den är det som gör att nästa person förstår varför lösningen ser ut som den gör, och slipper göra om resan. Det är samma princip som en versionshistorik: värdet ligger i att den visar rörelsen, inte bara nuläget.
Att börja i dag
Skapa en fil. Skriv ned det beslut du senast fick förklara för någon — det är per definition ett beslut som inte var självklart. Fyra rader räcker.
Loggen hör till samma familj av arbetsvanor som att hålla ändringarna små: båda handlar om att göra arbetet möjligt att följa i efterhand, av dig själv och av andra.