Om Developer Experience, AI Harness och varför vi optimerade fel sak i tjugo år.
Det tog ungefär tjugo år att bygga upp Developer Experience som disciplin. Bättre IDE:er, CI/CD, DevOps, linting, formatering, testautomatisering, och otaliga sprint-retrospektiv om varför testautomatiseringen fortfarande inte fungerar som den ska. Och nu sitter du och promptar. Inte för att verktygen var dåliga — utan för att paradigmet har skiftat under fötterna på oss, tyst och utan att boka in ett möte först.
Jag har följt det här området tillräckligt länge för att ha sett flera “detta förändrar allt”-moment. De flesta var överdrivna. Det här är inte ett av dem. ALMBoK.com startade jag som en öppen kunskapsbas om Application Lifecycle Management — med hundratals artiklar om DevOps, arkitektur och Developer Experience — och jag har dokumenterat den här resan medan den pågick, inklusive Vibe Coding och AI Augmented Development. Det ger mig åtminstone rätten att säga det utan att låta som någon som just läst sin första AI-artikel: det här skiftet är på riktigt, och det är större än de flesta inser.
Fel metafor har styrt branschen i två decennier
Developer Experience (DX) har alltid haft en tyst, oformulerad grundförutsättning: det vi ska bli bättre på är att skriva kod. Men koden var aldrig målet. Den var ett fordon. Vi förväxlade bilen med resan och ägnade sedan tjugo år åt att polera lacken.
Nu sitter konkurrenten bredvid dig och promptar fram ett fungerande system på en eftermiddag — utan en enda rad kod i traditionell mening. Du har en perfekt konfigurerad linter. Det är inte ditt fel. Det är ett paradigmskifte som inte skickar en kalenderinbjudan i förväg.
Från kod till beteende — och vad vi kanske borde kalla det
Traditionell DX ställer frågor som: Hur snabbt deployas det? Hur ren är koden? Hur kort är feedbackloopen? Alla rimliga frågor — i ett deterministiskt universum. Men vi designar nu sannolikheter. Du vet inte exakt vad som händer, du designar vad som sannolikt händer, och det kräver ett fundamentalt annat tankesätt.
Den nya frågan är inte hur snabbt du skriver kod. Det är: hur snabbt kan du skapa rätt beteende hos ett system?
Det är en subtil förändring i frågeställningen, men konsekvenserna är stora. Och om Developer Experience handlar om att göra det lättare att skriva kod — vad kallar vi då det här? Några börjar prata om Intelligence Experience (IX). Jag vet inte om begreppet fastnar, men något nytt behövs. DX räcker inte längre som beskrivning av vad vi faktiskt håller på med. Och för att förstå vart vi är på väg är det värt att först ta reda på var vi faktiskt befinner oss.
Var på resan är du egentligen?
Dan Shapiro beskriver resan från spicy autocomplete till dark factory — från AI som glorifierad tab-completion till helt automatiserade utvecklingskedjor. Det är en användbar karta. En liknande modell finns beskriven på aiwiki.se under AI-mognadsmodeller — men kortversionen för mjukvaruutveckling ser ut så här:
| Nivå | Namn | Kort beskrivning | Människans roll |
|---|---|---|---|
| 0 | Manuell kodning | AI används nästan inte alls | Skriver och designar all kod själv |
| 1 | AI-intern | AI används för mindre deluppgifter | Delegerar smått, granskar resultatet |
| 2 | Parprogrammering | AI genererar större kodblock | Designar systemet, samarbetar med AI |
| 3 | Kodchef | AI producerar majoriteten av koden | Granskar, testar och kvalitetssäkrar |
| 4 | AI-teamledare | Människan definierar krav och mål | Formulerar specifikationer, övervakar |
| 5 | Mörk fabrik | Hela kedjan automatiseras | Sätter strategiska mål och ramar |
De flesta som läser det här befinner sig på nivå 1–2 och tror att de är på 2–3. Det är ingen kritik — det är ett mönster. Det intressanta är vad som krävs för att faktiskt ta nästa steg, och det handlar sällan om verktyg. Det handlar om hur du tänker på din egen roll.
Vill du utforska verktygen konkret har jag skrivit två öppna kurser på svenska som ligger på aiwiki.se — min öppna kunskapsplattform för generativ AI, byggd för alla som vill förstå och använda AI utan att behöva navigera engelska dokumentation på tre ställen samtidigt. OpenCode kursen handlar om att bygga smartare kodflöden med agenter och open source-modeller, och OpenClaw kursen tar dig från noll till en fungerande AI-agent på ett handfast sätt — helt gratis, helt på svenska.
Vibe Coding — det flummiga begreppet som beskriver något verkligt
Vibe Coding låter som något en UX-konsult myntade efter ett retreatkurs i mindfulness. Men det beskriver faktiskt något konkret — det är när du slutar specificera exakt vad som ska hända och istället guidar modellen mot ett resultat. Du arbetar med intention istället för instruktion, riktning snarare än detaljer, feedback istället för fullständig kontroll.
De flesta tekniker reagerar på det med mild panik, och det är förståeligt. Vi är tränade i exakthet. Vi vill veta vad systemet gör. Men i AI-världen är exaktheten på radnivå ofta irrelevant — det är träffsäkerheten i helheten som räknas. Du behöver förstå hur systemet beter sig, inte vad det gör på rad 147. Det är inte mindre engineering. Det är engineering som kräver att du slutar vara rädd för att inte ha fullständig kontroll. Om du vill testa det i praktiken är OpenClaw — en av kurserna på aiwiki.se — ett bra sätt att komma igång. Den är byggd för att ta dig från noll till agent utan att behöva förstå allt på en gång.
Men vibe coding utan struktur är bara vibb. För att det ska fungera i ett riktigt system behöver du något mer stabilt under huven — och det börjar med kontext.
Kontext är den nya koden
Om det finns en enda mening som sammanfattar förändringen är det den här: kontext är den nya koden. Tidigare levde logiken i funktioner och klasser. Nu lever den i prompts, instruktioner, dokument, exempel och externa källor som hämtas in vid rätt tillfälle. Kontext avgör hur modellen tolkar en fråga, vilka svar den genererar och hur konsekvent den är över tid. Dålig kontext ger ett system som imponerar i demo och sviker i produktion — och det är ett mönster som upprepas förvånansvärt ofta.
Det kräver en ny disciplin. Inte dramatiskt annorlunda från systemarkitektur, men applicerad på intelligens istället för infrastruktur. Vad du stoppar in, när du stoppar in det och i vilken form det är strukturerat — det är det som avgör om systemet faktiskt fungerar när ingen tittar. På aiwiki.se/kontext har jag samlat ett växande bibliotek av återanvändbara kontextblock — allt från domänkontext och arkitekturprinciper till stilguide och rollspecifik kontext. Varje block är designat för att fungera både för en människa som vill förstå och för en AI-modell som ska använda texten som arbetsmaterial — ett paketerat kontextlager där du pekar på rätt block istället för att skriva om samma bakgrund varje gång.
Det är precis det tankesättet som leder oss till nästa byggblock.
SKILL.md — mikroarkitektur för förmågor
En SKILL.md-fil är ett textdokument som beskriver hur en AI ska lösa en specifik uppgift — med regler, standarder och förväntade resultat inbyggda. Inte kod. Inte dokumentation. Exekverbar kunskap. Tänk på det som ett kontextblock med ett specifikt syfte: att paketera ett beteende snarare än bara en bakgrund.
En SKILL.md för kravanalys. En för riskbedömning. En för kodgranskning. En för att rita systemdiagram konsekvent varje gång, oavsett vem i teamet som sitter vid tangentbordet. Det ser ut som en fil. Det är en kompetenskomponent — och det liknar mikrotjänster mer än det liknar ett Word-dokument, fast istället för API:er handlar det om förmågor.
Den intressanta frågan din organisation förmodligen inte har ställt sig än: vem äger de förmågor du bygger upp? Om de lever i din prompthistorik och ditt huvud är de inte en organisationstillgång — de försvinner med dig ut genom dörren. Versionerade, delade och underhållna är de strukturkapital. Det är en väsentlig skillnad. För att hantera just det har jag byggt Skill Manager — ett enkelt verktyg för att skapa, redigera och organisera dina SKILL.md-filer. Inte för att det är tekniskt komplicerat att skriva en textfil, utan för att strukturen och disciplinen är det svåra. Källkoden finns öppen på GitHub — fri för alla att använda, forka och bygga vidare på.
Men när du väl har ett dussin SKILL.md-filer och ett team på femton personer uppstår nästa problem: var bor de, vem hämtar dem, och hur vet modellen vilken kontext som är relevant just nu? Det är där MCP kommer in.
MCP — när kontext blir en tjänst
Model Context Protocol (MCP) löser ett konkret problem: du kan inte trycka in all kontext i en prompt manuellt varje gång, och du vill inte kopiera samma SKILL.md till varje verktyg varje gång någon uppdaterar den. MCP är ett sätt att exponera kontext som en tjänst — ungefär som API:er exponerar funktioner och databaser lagrar data, exponerar MCP kunskap. Du kopplar modellen till en extern källa och den hämtar rätt kontext vid rätt tillfälle, automatiskt, från en enda sanningskälla.
Det innebär att din SKILL.md för kodgranskning inte behöver kopieras till tio olika verktyg. Den versioneras på ett ställe, och MCP-lagret serverar den till alla modeller som behöver den. Samma princip gäller kontextblocken på aiwiki.se/kontext — varje block har en mcp_key som gör det möjligt för en MCP-server att hämta och leverera exakt rätt block som kontext till en modell, utan manuellt klipp och klistra. Det är en evolution av RAG, men mer strukturerat och mer arkitektoniskt. Och det passar direkt in i länk-lagret i MOLD — vilket leder oss till helheten.
AI Harness — formen som håller ihop alltsammans
Kontext. SKILL.md. MCP. Var för sig är de värdefulla. Tillsammans bildar de delar av något större — men bara om du har en struktur som håller ihop dem. Det är problemet de flesta missar. Många börjar sin AI-resa med en prompt, och det är helt rätt. Men det är också där de fastnar. Ett demo är inte ett system — det är en välgjord lögn som fungerar när du väljer inputen själv.
Det vi egentligen behöver är en AI Harness — ett sele, en form, en struktur som håller ihop delarna. Precis som en gjutform inte är produkten men avgör vad produkten blir, är AI Harness inte intelligensen i sig utan det som formar hur intelligensen används. Vilka modeller, vilken kontext, vilka flöden, vilka gränser. Utan den strukturen får du ett system som beter sig utmärkt i fyra minuter och sedan gör något oförutsägbart vid exakt fel tillfälle.
För att ge det en konkret form använder jag MOLD — vilket inte råkar vara engelska för gjutform av en slump:
| Modell | Vilken modell används, varför just den, och vilka begränsningar finns inbyggda? |
| Omfattning | Vad får systemet göra — och lika viktigt, vad får det inte göra? |
| Länkar | Vilka externa kontexter kopplas in, via MCP, API:er eller dokument? |
| Data | Hur ser input och output ut, och vilken struktur gäller? |
Länk-lagret är till exempel där dina SKILL.md-filer och kontextblock kopplas in via MCP — den direkta bryggan mellan allt vi pratat om tidigare och det system som faktiskt kör. Poängen är inte att MOLD är komplex — poängen är att den är enkel nog att faktiskt använda. En AI Harness utan den strukturen är som en gjutform av gelé. Tekniskt sett en form. Men den håller ingenting.
Från lacken till resan
Vi brukade prata om clean code, design patterns och best practices. Nu pratar vi om clean context, återanvändbara förmågor och behavioral design. Det låter som en liten förskjutning. Det är det inte.
Det handlar i grunden om vad vi värderar som kompetens. Att följa processer, implementera kända mönster och leverera i förutsägbar ordning — det är färdigheter som AI behärskar bättre än de flesta människor, och den kurvan pekar bara åt ett håll. Det som däremot blir mer värdefullt är förmågan att förstå ett problem på riktigt, att designa strukturen som andra jobbar i, att orkestrera intelligens mot ett mål som ingen ännu har formulerat exakt. Det har alltid varit kärnan i riktigt bra ingenjörsarbete. AI gör det bara omöjligt att låtsas som att det inte spelar roll.
Kanske är det här vad Intelligence Experience faktiskt innebär — inte ett nytt buzzword, utan en ny uppsättning frågor. Hur designar du kontext? Hur paketerar du förmågor? Hur bygger du en harness som formar intelligensen mot rätt beteende, konsekvent, över tid, av hela teamet? Det är frågorna som har tagit över efter “hur konfigurerar jag min linter” — och de kräver ett fundamentalt annat slags tänkande. Mer arkitektur. Mer omdöme. Mindre syntaxkoll.
Tjugo år av Developer Experience lärde oss att bygga bättre verktyg för att skriva kod. Det var inte bortkastad tid — det var nödvändigt, och det formade branschen. Men nästa tjugo år handlar om något annat: att bygga strukturer för intelligens, att paketera förmågor som kan delas och återanvändas, och att förstå att det vi skapar nu inte längre bara är mjukvara — det är beteenden vi designar, sannolikheter vi formar, och system som agerar även när vi inte tittar.
Din linter är perfekt. Frågan är vad du bygger härnäst.
Vad bor din kompetens i — ditt huvud, eller en fil som teamet kan använda på måndag?