Kontext slår prompter. Policy slår hype.

Varje team landar i samma frågor

Jag har kört över tio workshops med utvecklarteam, säljorganisationer och blandade grupper det senaste året. Varje gång samma sak: när ett team sätter sig med riktiga problem från sin egen backlog och faktiskt använder verktygen, så dyker policyfrågor upp. Inte för att någon planerat det. För att praktiken tvingar fram beslut.

Inte identiska frågor. Men samma beslutsområden. Varje gång.

En grupp bygger en modul direkt i produktionskod. Fem dollar i modellkostnad. Ingen dokumentation. Ingen change request. Vem äger den koden nu?

En annan grupp får inte igång det externa verktyget. Laddar ner en lokal språkmodell på en bärbar dator och bygger naturligt språk-sökning i sin reseplaneringsprodunkt. Ingen extern API. Ingen hjälp. Levererar. Men vilken data gick igenom modellen?

En tredje grupp planerar och genomför 60% av vad utvecklingschefen kallar "minst två veckors arbete" på en dag. Senior utvecklare förutspådde edge cases som modellen oberoende identifierade i nästa fråga. Samma prompt som alla andra använde. Skillnaden? Kontexten i fönstret. Inte prompten.

Elva policyfrågor uppstod under en enda dag. Ingen av dem planerad.

Det här är inte unikt för det teamet. Det är ett mönster.

Elva frågor som varje team behöver besvara

Efter tio workshops har jag sett samma beslutsdomäner dyka upp oavsett bransch, teamstorlek eller teknisk mognad. Jag kallar dem "elva frågor" - inte för att det alltid är exakt elva, utan för att dessa kategorier täcker det som behöver beslutas.

1. Ägandskap av AI-genererad kod

Vem äger output? Den som skrev prompten? Den som checkade in koden? Organisationen?

Svaret är enkelt: den som checkar in koden är personligt ansvarig. Oavsett om den är AI-genererad eller handskriven. Det här konsensus finns redan i de flesta team. Men det saknas ofta en formell policy att luta sig mot.

2. Commit-disciplin

Ska commit-meddelanden skrivas manuellt eller genereras automatiskt?

AI-genererade commit-meddelanden är ofta bättre formulerade. Men de tar bort en tankemässig kontrollpunkt. Att skriva commit-texten för hand tvingar utvecklaren att formulera vad som gjordes och varför. Det kräver förståelse. Det är inte overhead. Det är jobbet.

3. Changelog som tänkverktyg

Manuell uppdatering eller automatisk generering?

När ett fel rapporteras månader senare är en strukturerad changelog med versionsnummer ovärderlig. Språkmodellen har inte hela git-historiken i sitt kontextfönster. Men den har din changelog. Gör den till en kontrollpunkt, inte en eftertanke.

4. Inspelning och transkribering

När och hur får samtal spelas in?

Svensk lag tillåter inspelning om en part är medveten. Men kundrelationen kan skadas om det upplevs som hemligt. Teams har inbyggd inspelning med synlig ikon. Extern telefon är krångligare. Enas om en approach. Policy minskar individuell osäkerhet.

5. Data till externa modeller

Vad får skickas? Personnummer - aldrig. Kunddata - bedömning per fall. Intern kod - oftast tillåtet. Ekonomi och avtal - gråzonen.

Den verkliga risken är inte att någon medvetet bryter mot reglerna. Det är att någon skickar information till en gratisversion utan att tänka på datalagring. Utan policy bestämmer varje individ själv. Det är inte en strategi.

6. Verktygsstyrning

Vilka verktyg får användas för arbete? Ska gratisversioner av ChatGPT vara tillåtna? Vad är skillnaden i säkerhetsnivå mellan en Enterprise-prenumeration och ett gratisspår?

Frågan dyker alltid upp när teamet inser att hälften av kollegorna redan använder gratisversioner för arbete. Det är inte ett val längre. Det är en verklighet som behöver hanteras.

7. Kostnadsmedvetenhet

Synlighet, inte restriktion. Visa förbrukning per utvecklare. Regelbunden avstämning. Men inte strypt.

En utvecklare gick från 50 dollar per månad till 300 dollar genom att byta till en dyrare modell för ett komplext problem. Pedagogisk fråga, inte missbruk. Dyra modeller för planering, billiga för implementation. Loggfiler äter tokens lika mycket som kodfiler. Kostnad utan värdeskapande.

8. Kunskapsdelning

Hur delar teamet AI-erfarenheter internt?

Utan ett system försvinner insikterna med individen. En intern kanal där alla delar en grej i veckan. Inte en presentation. Inte en rapport. Bara: "jag testade X, det fungerade/fungerade inte." Rådata som grund för en veckosummering.

En CTO satte upp dedikerade forskningstillfällen. Första veckan deltog en person. Presentationen var så bra att det utlöste spontant deltagande. Kultur först, struktur sen.

9. Terminologifil

Interna förkortningar och begrepp som språkmodellen inte förstår.

Varje organisation har internt språk. Produktnamn, processteg, kundkategorier. När språkmodellen bearbetar intern data utan denna kontext tolkar den fel. En fil med definitioner, lagd i repots rot eller kontextfönstret, tar en halvdag att skapa och sparar oändligt med felaktig output.

10. Parallella kontextfönster

Får man köra flera AI-trådar parallellt på samma kodbas?

En uppdatering i en tråd reflekteras inte i den andra. Filer som ändras i tråd A är inte uppdaterade i tråd B. Konflikter uppstår. Rekommendation: en tråd per produktionsuppgift. Parallella trådar för separata, oberoende uppgifter.

11. Extern datakoppling

Vad får kopplas ihop med AI-verktyg? CRM-data? Mejl? Kundsystem?

MCP-servrar och liknande protokoll gör det möjligt att hämta data från externa system direkt in i kontextfönstret. Frågor: policyn för att läsa CRM-data via AI, policyn för att läsa mejl via AI, GDPR-aspekter på EU-server kontra amerikanska.

Tre ansvarsnivåer - ett tänkverktyg

Inte alla policyfrågor behöver besvaras på samma sätt. Tänk i tre nivåer:

Solo - enskild medarbetare som experimenterar. Riktlinjer att luta sig mot, inte detaljstyrning. Här testar man, gör fel, lär sig. Reglerna är minimala men medvetna.

Uppdrag - leverans till kund eller projekt. Varje rad måste förstås av den som levererar. Dokumentation är inte valfritt. Den som levererar måste kunna förklara varför.

Bolagsleverans - kod och processer som representerar organisationen. Namngivet commit-ägarskap, gemensam policy, dokumenterade riktlinjer. Här är disciplinen som högst för att konsekvenserna är störst.

De elva frågorna bör besvaras med dessa nivåer i åtanke. Kodansvar gäller på alla nivåer. Parallella trådar är mest relevant på bolagsnivå. Kunskapsdelning är viktigast på uppdragsnivå. Matrisen är inte statisk. Den är ett sätt att kalibrera medvetet istället för att hamna i default.

Från beslut till vardag

Tack till Dan Rosenthal (workflows.io) för konceptet "Company OS" som strukturerar hur ett team kan bygga sin organisationslogik i ett gemensamt repo. Vi tog det konceptet och anpassade det baserat på vad vi ser i workshops.

En policy som lever i ett dokument är inte en policy. Den måste leva där arbetet sker.

Alt A: Repo-nativt

För team som använder Claude Code, Kilo Code eller liknande.

Policybeslut hamnar i en CLAUDE.md eller CONVENTIONS.md i repots rot. Varje session börjar med att verktyget läser era riktlinjer. Policyn är inte något man behöver komma ihåg. Den är i kontextfönstret från start.

En terminologifil med interna begrepp. En kontextfil med produktbeskrivningar. Arbetsloopen kopplar policyn till varje steg:

• Läs projektet - policyfilen finns där
• Skriv en change request - dokumentationskravet gäller
• Välj modell - styrningen gäller här
• Granska varje rad - ägandskapet gäller här
• Committa - commit-text-policyn gäller här

Alt B: Repo-angränsande

För team med gemensam kodbas men utan AI-kodningsverktyg som läser repot.

En docs/-mapp med policyfiler, länkade från README. Inte lika integrerat som Alt A, men bättre än ingenting. Nackdel: policyn måste aktivt uppsökas istället för att vara inläst.

Alt C: Verktygsbaserat

För blandade team eller organisationer utan gemensamt kodrepo.

Confluence, Notion, Teams-wiki. Minst effektivt. Policyn lever långt från där arbetet faktiskt sker. Men realistiskt för team där hälften av medarbetarna aldrig öppnar ett repo.

Feedbackloopen

Utan den dör policyn. Regler ackumuleras men problem rapporteras inte. Ingen vet om riktlinjerna faktiskt följs eller om de är föråldrade.

En CTO lade ut riktlinjer för två månader sedan. Inget klagomål. Inget godkännande. Tystnad. Det är inte konsensus. Det är frånvaro av feedback. Bygg in en loop: en kanal där teamet rapporterar vad som funkar och vad som inte funkar. Utan den är policyn dekorativ.

Senioritet är multiplikatorn

Det här är vad jag ser i varje workshop: senioritet är multiplikatorn. Inte promptteknik.

Utvecklaren med 15 års erfarenhet av sitt system slår den som kan skriva "bättre" prompter men inte förstår domänen. Varje gång. Klyftan ökar.

Prompten är den minst intressanta variabeln i ekvationen. Det som avgör output är vad verktyget redan vet när du frågar. Kontextfönstret. Det som är inläst innan du skriver en enda rad. Det är hela grejen.

Policy förstärker detta. Den skyddar organisationen från att självsäkra men felaktiga svar skeppas till produktion. Den ser till att erfarenhet trumfar hastighet. Att den som vet mest också har störst utväxling.

Slutsats

Branschen lägger oproportionerligt mycket energi på prompter. Det säljer kurser. Det säljer nyhetsbrev. Men det bygger ingenting.

Det som bygger något: riktiga problem, riktiga verktyg, riktiga beslut. Policy som växer ur praktik. Inte ur ett inspirationsföredrag.

Varje team jag har jobbat med har landat i samma insikt: det handlar inte om att formulera bättre frågor. Det handlar om att ladda rätt kontext och ta ansvar för resultatet.

Kontext slår prompter. Varje gång.