DOKUMENTATION

SPÅRBAR LEVERANS

Dokumentera beroenden, AI-komponenter och bevis

När AI föreslår ett paket, en modell, ett externt API eller en ny byggkomponent behöver dokumentationen följa den faktiska leveransen — inte bara chattens förslag.

• Uppdatera beroende- och licensinformation samt SBOM för den version som byggs.
• Dokumentera källa, version, konfiguration och kända begränsningar för modell eller AI-tjänst som ingår i systemet.
• Koppla säkerhetskrav och acceptanskriterier till testresultat, analysrapport, simulering eller annan verifiering.
• Spara beslut och avvikelser i ordinarie ADR-, change- eller releaseprocess. En chattlogg är inte ensam ett tekniskt godkännande.

CISA:s uppdaterade miniminivå för SBOM anger att varje version eller uppdatering bör ha en tillhörande komponentförteckning och att även transitiva beroenden ska omfattas.

PRINCIP

Dokumentation är det ingenjörer gör minst gärna — och AI är bra på det

Teknisk dokumentation är kritisk men underprioriterad. Den skrivs för snabbt, underhålls inte, och missar det som faktiskt är viktigt: varför beslut fattades, inte bara vad systemet gör.

AI kan radikalt minska friktionen — inte genom att ta bort behovet av dokumentation, utan genom att göra det snabbt nog att faktiskt bli av med.

GE AI KOD OCH KONTEXT — FÅ DOKUMENTATION TILLBAKA
DU LÄGGER TILL VARFÖR, AI SKRIVER HUR

API-DOKUMENTATION

Dokumentera API:er med AI

Ge AI din kod och be den generera API-dokumentation i det format du behöver: OpenAPI/Swagger, JSDoc, docstrings, Markdown eller annat.

Bra att specificera i prompten:

• Format och standard (OpenAPI 3.0, JSDoc, Google-style docstrings)
• Målgrupp (intern, extern, teknisk, icke-teknisk)
• Vad som ska inkluderas (parametrar, felkoder, exempel, begränsningar)
• Exempeldata du vill att dokumentationen ska använda

Kontrollera alltid att AI:s beskrivningar stämmer med faktiskt beteende — framför allt felkoder, gränsvärden och sidoeffekter.

API-DOCS

SYSTEMDOKUMENTATION

Arkitekturdokument och systemöversikter

Beskrivande systemdokumentation är tidskrävande att skriva men värdefull för introduktion och underhåll. AI kan hjälpa dig strukturera och skriva den — du behöver ge den ett grovt underlag.

Effektiv approach:

1. Skriv en rörig, ofullständig beskrivning av systemet som du själv förstår det. Punktlista, diagram i text, anteckningar — vad som helst.
2. Be AI strukturera detta till ett systemdokument med standardsektioner: syfte, komponenter, integrationer, dataflöde, begränsningar, beslutslogg.
3. Granska och komplettera med det AI inte kan veta: affärskontext, historiska beslut, icke-uppenbara begränsningar.

DU KAN SYSTEMET — AI KAN STRUKTURERA OCH FORMULERA
KOMBINATIONEN GER BRA DOKUMENTATION SNABBT

SYSTEMDOK

BESLUTSLOGG

Dokumentera arkitekturbeslut (ADR)

Architecture Decision Records (ADR) är en av de mest värdefulla formerna av teknisk dokumentation — och en av de mest försummade. Framtida ingenjörer behöver veta varför ett system är byggt som det är, inte bara hur.

AI hjälper dig skriva ADR:er snabbt. Beskriv för AI:

• Vilket problem som behövde lösas
• Vilka alternativ som övervägdes
• Vilket beslut som fattades och varför
• Kända konsekvenser och avvägningar

AI strukturerar detta till ett välformulerat ADR med standardsektioner. Det tar tio minuter istället för en timme — och du får ett dokument som faktiskt hjälper nästa team.

DOKUMENTERA BESLUT NÄR DE FATTAS — INTE EFTERÅT
ADR SPARAR MÅNADER AV FÖRVIRRING I FRAMTIDEN

ADR

SNABB KONTROLL

Innan dokumentation publiceras i repo eller wiki

• Stämmer API-beteende, felkoder och gränsvärden mot faktisk implementation?
• Är beslut, avvägningar och konsekvenser spårbara i ADR eller beslutslogg?
• Har känsliga uppgifter, interna endpoints och tokens rensats från exempel?
• Är format och nivå anpassat för målgruppen som ska använda dokumentationen?