Dokumentation som kod. AI-dokumentation med markdownfiler

Dokumentation som kod: Så får du effekt av AI i din kunskapsbas

Word- och PowerPoint-filer fungerar bra för människor, men sämre för AI. Genom att tänka på dokumentation som kod, i rena textfiler med Markdown, kan du skapa en kunskapsbas som AI både kan förstå, söka i och arbeta direkt i. Resultatet blir snabbare arbetsflöden, bättre samarbete och helt nya möjligheter att använda AI i praktiken.

I arbetet skapar vi ofta dokumentation av olika slag. Det kan vara planer, krav, rapporter, instruktioner, regler, metoder, beslut och så vidare.

Det är vanligt att dokumentationen görs i till exempel Word eller PowerPoint, eller kanske Confluence eller Notion.

Filerna kräver leverantörens programvara för att läsas och redigeras. Exempelvis kräver docx att mottagaren använder Word eller annat kompatibelt program; Confluence-sidor måste öppnas i Confluence.

För att bearbeta filerna med AI är du i händerna på leverantörernas eventuellt bristfälliga AI-lösningar (t.ex. Copilot). Det kommer att hindra dig från att nå den riktiga potentialen med AI.

Programmerare däremot har i alla tider skrivit kod i ren text. All information i kodbasen finns där, rakt upp och ner läsbar, rad för rad. Koden (textfilerna) lagras lokalt på datorn och en AI kan utan problem läsa, förstå och göra ändringar i dessa.

För att få ut den riktiga potentialen av AI måste du även börja se dokumentation som kod. Och du måste börja använda ditt AI-verktyg (t.ex. ChatGPT eller Claude) på din dator med tillgång till ditt filsystem.

Filformat-domumentation.jpgMed dokumentation som kod menas inte att du måste lära dig något programmeringsspråk - vi använder oss av rena textfiler. Det enda vi använder i filerna utöver själva texten är ett simpelt syntax som kallas Markdown. Det gör vi för att ge dokumenten lite mer struktur genom att till exempel kunna sätta rubriker och göra punktlistor. Markdown kan både människor och maskiner lätt förstå. Mer om det snart!

Vad är det vi vill uppnå?

Målet är att bli mer produktiva och få utökade förmågor med hjälp av AI. Att bli "AI-first". För att det ska vara möjligt måste du sätta upp en miljö där en AI-agent effektivt kan ta del av din och ditt företags nedskrivna kunskap, samt att den kan agera på den och skapa och ändra innehållet.

Varje nuvarande arbetsuppgift du har (förutsatt att du inte jobbar med att flytta atomer i verkliga världen) bör göras med AI inblandat. Ännu behövs oftast ett samarbete mellan människan och AI i dessa uppgifter, men behovet av det försvinner gradvis.

Därför är det viktigt att sätta dig i förarsätet i denna transformation. Både för att skörda produktivitetsvinsterna och för att själv ha chansen att vara med och forma framtidens arbetsuppgifter.

Varför AI har svårt att arbeta med Word och PowerPoint-filer

Först måste vi förstå hur filerna egentligen är uppbyggda.

Något som överraskar många: både .docx och .pptx är i grunden vanliga ZIP-arkiv. Byter man filändelsen till .zip och packar upp dem hittar man en mappstruktur med en mängd XML-filer. Ett Word-dokument ser ut ungefär så här inuti:

mydocument.docx/ ├── [Content_Types].xml ├── _rels/ │ └── .rels ├── word/ │ ├── document.xml ← själva innehållet │ ├── styles.xml ← alla stilar och formatering │ ├── settings.xml ← dokumentinställningar │ ├── fontTable.xml ← teckensnittsreferenser │ ├── theme/ │ │ └── theme1.xml │ ├── _rels/ │ │ └── document.xml.rels │ └── media/ ← inbäddade bilder └── docProps/ ├── app.xml └── core.xml ← metadata: författare, datum

En PowerPoint är strukturerad på liknande sätt, men med en egen XML-fil per bild under ppt/slides/ - vilket snabbt blir många filer i en längre presentation.

Det mesta av innehållet i dessa filer är inte text. Det är formatering, layoutinstruktioner och metadata. En enkel mening som "Hej världen" ser ut så här i document.xml:

<w:p> <w:pPr> <w:pStyle w:val="Normal"/> </w:pPr> <w:r> <w:rPr/> <w:t>Hej världen</w:t> </w:r> </w:p>

I Markdown är samma mening bokstavligen bara: "Hej världen"

Ett vanligt femsidigt Word-dokument innehåller typiskt 2 000–5 000 rader XML enbart i document.xml. Motsvarande innehåll i Markdown är ungefär 100–200 rader. Det faktiska meningsbärande innehållet utgör kanske 10–15 % av Word-filens totala datamängd, resten är struktur och formatering. Det är alltså väldigt mycket brus och tidskrävande konverteringar som AI:n måste tas sig igenom för att jobba med docx-filer. 

Kod som textfiler.jpg

PowerPoint är ett ännu svårare fall

Word har åtminstone ett linjärt textflöde - ett stycke följer på ett annat. PowerPoint fungerar fundamentalt annorlunda. Varje element på en slide (textrutor, former, diagram, bilder) är positionerat med absoluta X/Y-koordinater. Det finns ingen inbyggd läsordning. Det som ser ut som en rubrik och ett brödtextstycke är i praktiken två flytande objekt på en koordinatyta.

Det innebär att när en AI läser en PowerPoint-presentation försvinner inte bara formatering och figurer, även den rumsliga kontexten försvinner, som ofta bär en stor del av meningen i presentationer.

Sökbarhet

Vi har redan diskuterat svårigheten för AI att läsa och skriva docx eller pptx.

En annan avgörande förmåga AI:n behöver är att kunna söka i innehållet i filerna, och den måste klara av det på en mycket stor mängd information - till exempel alla dina egna dokument du skapat sen du började jobba, eller hela ditt företags gemensamma dokumentation.

Sökningen måste ske blixt snabbt eftersom den kan vara en del i ett långt agentiskt flöde som förväntas ta några få minuter.

Copilot gör viss magi i SharePoint som delvis hanterar sök i docx och pptx. Microsoft bygger automatiskt ett separat sökindex i bakgrunden. Filernas textinnehåll extraheras, delas upp i bitar och omvandlas till vektorer som representerar betydelsen av innehållet. Men detta är en svart låda där information förloras (Microsoft kan inte heller tolka den visuella logiken i dina PowerPoint-slides), indexeringen tar tid, och du kommer sen inte mycket längre än just bara till att ha en ganska imponerande sökmotor.

I Markdown-världen behövs inga indexeringstjänster eller vektorberäkningar. Texten är sökbar direkt i terminalen. Med kommandot `grep` kan du på ett ögonblick söka igenom tusentals markdown-filer efter ett ord eller en fras.

Och nu till det fantastiska: AI:n kan använda terminalen

Det är här det börjar hända något. En AI med tillgång till ditt filsystem kan köra exakt samma kommandon som du kan i terminalen. Den kan läsa filerna den hittar, redigera dem direkt, flytta och organisera dem:

grep -r "produktlansering" ~/dokument/ # hitta relevant innehåll cat strategi/q3-plan.md # läs en fil mv utkast/idé.md strategi/idé.md # flytta rm utkast/gammal-version.md # radera

När den ska göra ändringar i filerna: lägga till ett stycke, skriva om en mening, uppdatera ett beslut, så gör AI-agenten det direkt i filen, utan att behöva öppna ett program eller använda konverterings-script. Den kan utan problem gå igenom 100 filer i ett svep och göra alla de ändringar den behöver för att slutföra uppgiften. Och inte bara triviala ändringar: AI-agenten har sin fulla kompetens som du är van vid från att ha chattat med ChatGPT eller Claude på webben.

Dokumentation-bläckfisk.jpg

Sista pusselbiten: Git

Git är vad utvecklare sedan länge använt för att versionshantera och kunna samarbeta med kod inom ett företag. Vi använder det för våra markdown-filer men principen är densamma: ändringarna som görs kan delas med dina kollegor som får samma uppdateringar i era gemensamma filer. Och varenda ändring som görs blir spårbar och kan backas vid behov.

Git möjliggör ett professionellt samarbete kring den gemensamma kunskapsbasen i markdown och ger dessutom sidoeffekten att lätt kunna visa hur dokumentationen har förändrats över tiden.

Med vår dokumentation i markdown kan vi börja jobba!

Vi låtsas att vi driver en floristbutik. Vi ska ta in sommarjobbare och vill att de ska komma igång snabbt med jobbet. Deras uppgift är att komponera buketter baserat på kundens behov och skapa ett kort som kan följa med buketten.

Butiken har ett antal olika sorters blommor i lager. Varje blomma är en markdown-fil som beskriver dess egenskaper. Vi har också en prislista som markdown.

Blomfilerna i markdown är väl strukturerade. En `#` betyder huvudrubrik, två `##` är en rubriknivå lägre. Listor inleder varje rad med `-` . Fet text görs med dubbla stjärnor runt texten `**` . Enkla tabeller kan byggas upp med pipes `| hej |`.

Mycket svårare än så är inte markdown. Dessutom kan vi använda en text-editor om vi vill för att slippa se eller lära oss den här syntaxen. Här är Obsidian ett bra och gratis alternativ.

screenshot - markdown.png

Dags att starta igång Claude

För att börja jobba med AI på våra lokala filer behöver vi även starta vår AI lokalt på datorn.

Observera: detta är inte att förväxla med var själva språkmodellen körs. Det sker fortfarande på leverantörens servrar, troligtvis i USA, vilket är viktigt att tänka på om du har dokumentation som inte får korsa Atlanten.

I exemplet här används Claude Code. OpenAI Codex är ett annat starkt alternativ.

Claude kan installeras som en app med ett grafisk gränssnitt, men renaste upplevelsen får man genom att installera Claude Code som CLI (command-line interface) och köra det i terminalen.

Vi startar Claude i vår mapp som håller dokumentationen i vår floristbutik.

Nu kan vi chatta med Claude och all dokumentation som finns i mappen är tillgänglig för den vid behov, både för att läsa och skriva i.

screenshot-claude.pngAgent-skills

För våra vanligt återkommande uppgifter så har vi skapat "skills". Just nu har vi bara en skill: "skapa-bukett" för att komponera buketter baserat på kundens önskemål.

En skill är bara en markdown-fil: en instruktion till AI:n hur den ska lösa en viss uppgift på sättet som vi vill, skriven som en helt vanlig text med steg-för-steg instruktioner och saker den ska tänka på.

En skill är som en lång och väl genomtänkt prompt som är lätt att återanvända och lätt att dela med sina kollegor. I exemplet ovan skriver vi bara vilka önskemål och budget som kunden har på blombuketten, och AI:n gör jobbet.

Sub-agenter.jpg

Sub-agenter

I det här fallet har vi också skapat en "sub-agent" som ansvarar för skapandet av själva kortet. Det gör vi för att kunna låta den agenten jobba samtidigt som huvud-agenten som komponerar buketten och håller ihop helheten. Det finns ett par anledningar att använda bakgrunds-agenter:

  • Det kan spara tid om flera agenter kan jobba parallellt

  • Varje agent kan ha sitt eget fokus, sina egna unika instruktioner. Det möjliggör att ta sig an problem från olika synvinklar

  • Sub-agenterna har sitt eget närminne (kontext), vilket är bra om stora mängder text behöver ladas in för att lösa uppgiften. Kontext-fönstret är nämligen begränsat och agenten börjar få problem om det närmar sig fullt.

Sub-agenter.jpg

Resultatet

AI:n följer instruktionerna precis som vi bett om. Baserat på en situation, lite fakta om mottagaren och en budget plockar den ihop lämpliga blommor baserat på sin ofantliga LLM-kunskap, samt styrning från skapa-bukett-skillen. En beskrivning av en bukett har generats som en ny markdown-fil, samt ett kort i det AI-vänliga formatet HTML.

screenshot-resultat-kollage.png

Vad skulle kunna vara nästa steg?

Förutom blom-filerna och prislistan skulle man kunna utveckla mappen med:

strategi-och-roadmap.md styleguide.md tonalitet.md om-företaget.md

Och vipps har vi också en bra grund för att t.ex. vibe-koda en hemsida åt floristbutiken, eller få agenten att skriva svar på sociala medier, eller planera inköpsresor, och mycket mycket mer!

Om ditt företag redan sådan information i något annat format (pdf, docx eller liknande) så går det bra att låta din AI konvertera filerna till markdown först. Men det kan ta lite tid och det kan kräva en del handpåläggning i efterhand för det ska bli bra.

6.jpgSammanfattning

Valet av filformat är inte en teknisk detalj. Det är ett strategiskt beslut som avgör hur mycket du faktiskt kan göra med AI. Word och PowerPoint är designade för att se bra ut på skärm och i utskrift, inte för att bearbetas av maskiner. Markdown är designat för att vara läsbart av båda.

De viktigaste insikterna att ta med sig:

  • Format avgör förmåga. En AI som läser ren text kan söka, förstå och redigera med full precision. En AI som försöker tolka XML-paket med formatering och koordinater tappar stor del av meningen, oavsett hur smart den är.

  • Sökbarhet är grundbulten. Utan att AI:n snabbt och tillförlitligt kan hitta rätt information i din kunskapsbas kan den inte agera på den. Markdown löser det utan indexeringstjänster och svarta lådor.

  • Skills och sub-agenter är multiplikatorer. En välskriven skill-fil förvandlar ett manuellt arbetsflöde till något AI:n kan utföra konsekvent och upprepat. Sub-agenter låter dig dela upp komplexa uppgifter och köra dem parallellt, precis som ett riktigt team.

  • Git möjliggör professionellt samarbete. Git är inte bara för kod. Det är det som gör att du kan samarbeta om en gemensam kunskapsbas utan att tappa spåret av vad som ändrats, av vem och varför.

Floristexemplet i den här artikeln är litet och pedagogiskt, men logiken skalas. Samma principer fungerar för en juristfirmas avtalsdatabas, ett produktteams kravdokumentation eller ett företags metodbibliotek.

Det krävs inte att du bygger om allt på en gång. Ta ett dokument i taget, en skill i taget. Men varje steg du tar mot en AI-läsbar kunskapsbas är ett steg mot att faktiskt kunna nyttja AI på allvar. Inte bara som en avancerad sökmotor, utan som en kollega som förstår ditt sammanhang och kan agera i det.

Vill du veta hur detta ser ut i praktiken för din organisation? Vi på XLENT hjälper er att hitta rätt startpunkt!

Bilaga 1: Skillen "skapa-bukett" i sin helhet

--- name: skapa-bukett description: Denna skill ska användas när användaren ber om att "skapa bukett", "komponera bukett", "beställa blommor", "välj blommor", eller diskuterar att skapa en bukett för ett tillfälle som födelsedag, bröllop, begravning eller annan blomsterarrangemang. --- # Skapa Bukett Du är en expertflorist. Skapa skräddarsydda buketter baserat på kundens önskemål med blommor från `Blommor/` och priser från `prislista.md`. ## Steg ### 1. Förstå kundens behov Om tillfälle, färgpalett/stil eller budget saknas — ställ alla frågor i ett enda meddelande innan du går vidare. ### 2. Skapa bukettkort När du har all information — starta OMEDELBART bakgrundsagenten `bukettkort` för att skapa ett fint kort parallellt med bukettkomponering. Agenten behöver följande information: - Tillfälle - Stil/önskemål - Datum: VIKTIGT: Fortsätt sedan direkt med Steg 3 utan att vänta på bakgrundsagenten. ### 3. Hitta lämpliga blommor - Använd Grep för att söka på `occasions`, `colors` och `role` i `Blommor/` för att snabbt identifiera kandidater - Läs `prislista.md` för priser - Läs INTE blomfilerna i detta steg — frontmattern räcker för urvalet - Kontrollera INTE lagerstatus ### 4. Komponera buketten och beräkna pris - Välj 3–7 sorter som passar tillfället, färgpaletten och budgeten - Basera valet på symbolik, färgharmoni och kombinationer som fungerar bra tillsammans - Bestäm antal per sort för balans mellan huvud- och fyllnadsblommor - Använd ENDAST blommor som finns i `Blommor/` - Räkna ut totalpriset internt (antal × pris/styck per sort) — visa bara slutresultatet, inte mellansteg eller omräkningar ### 5. Presentera buketten - Läs blomfilerna för de valda sorterna för att hämta skötselråd och beskrivningar - Beskriv buketten poetiskt och professionellt - Lista varje blomma med: antal, pris, och en kort motivering (t.ex. symbolik, färgroll, komplementär funktion i buketten) - Förklara hur blommorna kompletterar varandra - Ge skötselråd baserat på blommornas egenskaper ### 6. Spara buketten Skapa OMEDELBART en fil i `Buketter/` — fråga INTE om bekräftelse. **Format:** `Buketter/bukett_YYYY-MM-DD_tillfalle.md` **Exempel:** `Buketter/bukett_2026-02-17_fodelsedag.md` Filen ska innehålla: tillfälle, blomkomposition med antal, priskalkyl per blomma, totalpris, skötselråd. Nämn också att ett HTML-kort skapas (eller är klart) i `Kort/kort_{YYYY-MM-DD}_{tillfalle}.html`.

Bilaga 2:  Sub-agenten "bukettkort" i sin helhet

--- name: bukettkort description: Skapar ett fyndigt bukettkort i HTML-format med en dikt anpassad till tillfälle och stil. Används som bakgrundsagent från skapa-bukett-skillen. --- # Bukettkort-agent Du skapar ett kort till en bukett som en HTML-fil, avsedd för utskrift. ## Verktyg Du har tillgång till **Write**. Det är det enda verktyget du behöver. - Använd Write för att skriva HTML-filen direkt till utdatasökvägen - Write skapar saknade mappar automatiskt — du behöver INTE skapa dem separat - Använd INTE Bash, kör INTE mkdir, installera INTE paket ## Instruktioner Du får följande information i prompten: - **Tillfälle** — t.ex. födelsedag, bröllop, kondoleans - **Stil/önskemål** — kundens beskrivning av buketten, ton och känsla - **Datum** — i formatet YYYY-MM-DD Spara filen till `Kort/kort_{YYYY-MM-DD}_{tillfalle}.html` i projektets rotkatalog (din nuvarande arbetskatalog), där `{tillfalle}` är tillfället i gemener utan svenska specialtecken (å→a, ä→a, ö→o). ## Steg ### 1. Skriv dikten Skriv en fyndig, varm dikt på svenska (4–8 rader) anpassad till tillfälle och stil. **VIKTIGT:** Använd alltid korrekta svenska tecken — å, ä, ö — i dikten och i all text i HTML-filen. Ersätt dem aldrig med a eller o. - Födelsedag: lekfull och glad - Bröllop: romantisk och högtidlig - Kondoleans: stillsam och tröstande - Allmänt: varm och personlig ### 2. Skapa HTML-filen med Write Anropa Write med `file_path` = utdatasökvägen du konstruerade ovan, och `content` = en komplett HTML-fil. **Krav på HTML:** - Avsedd för utskrift — inga animationer, inga rörliga element - `@media print` i CSS: ta bort marginaler, sätt bakgrundsfärger med `-webkit-print-color-adjust: exact` - Fast storlek: A5 liggande (148mm × 210mm), centrerad på sidan - Ingen JavaScript **Färgschema och typografi ska passa tillfället:** - Födelsedag: varma, glada färger (gul, orange, cerise) - Bröllop: vitt/guld/creme, elegant serif-typsnitt - Kondoleans: dämpad, ljus palett (grå, ljusblå, creme) - Allmänt: diskret och elegant **Layout:** - Titel/rubrik centrerad överst (stort, fetstil) - Underrubrik eller mottagarens namn (mellanstor) - Dikt centrerad i mitten, kursiv, luftigt radavstånd - Dekorativa element (t.ex. symboler, streck) i överkant och underkant — inga bilder eller externa resurser - All CSS inline i `<style>`-taggen, inga externa stylesheets eller fonter ### 3. Verifiera Bekräfta för användaren att filen är skapad och var den finns.

Kontakt

Olle Westerlund