Dokumentation & Technical Writing

Dokumentation og technical writing dækker det skrivearbejde, hvor kilden er teknisk: kode, API-definitioner, konfigurationsfiler, datamodeller og arkitekturbeslutninger. Sprogmodellen bruges til at producere udkast til referencedokumentation, README-filer, brugervejledninger og specifikationer ud fra materiale, der allerede findes i repoet.

Grænsen mod kodegenerering går ved retningen. Her er koden input, og teksten er resultatet. Grænsen mod almindelig indholdsproduktion går ved kravet om verificerbarhed. En marketingtekst kan være upræcis uden at gå i stykker, mens et forkert parameternavn i API-dokumentationen koster læseren en fejlsøgningssession.

En tredje nabo er RAG over eksisterende dokumentation. Der er dokumentationen input til modellen og bruges til at besvare spørgsmål. I denne use-case er dokumentationen selve outputtet, og kvalitetskravene er derfor knyttet til kilden frem for til samtalen.

Et brugbart setup starter med at afgøre, hvad modellen får at se. Struktureret kilde slår rå kode: en OpenAPI-specifikation, et JSON Schema, typedefinitioner eller docstrings giver langt mere stabile resultater end en mappe med filer uden kontekst. Testfiler er ofte den bedste kilde til realistiske eksempler, fordi de viser faktiske kald med faktiske værdier.

Derefter kommer skabelonen. Du beskriver sektionsrækkefølge, overskriftsniveauer, terminologi og formatering i prompten eller i en style guide, som følger med hver kørsel. Uden den skabelon vælger modellen sin egen struktur, og den varierer mellem kørsler, hvilket ødelægger konsistensen på tværs af sider.

Selve genereringen kan deles op efter opgavetype. GPT-5.6 Sol og Claude Sonnet 5 klarer længere sammenhængende tekster som guides og specifikationer, hvor der skal holdes styr på mange filer på én gang. GPT-5 nano er relevant til mekaniske opgaver i stor mængde, for eksempel en docstring per funktion, hvor hvert kald har et lille og velafgrænset input.

Kvaliteten afgøres i praksis af tre ting: hvor præcist konteksten er skåret, hvor detaljeret skabelonen er, og om der findes et eksempel på det ønskede output at pege på.

Den hyppigste fejl er ikke en åbenlys hallucination, men en plausibel en. Modellen skriver et kodeeksempel med et parameternavn, der lyder rigtigt og passer til konventionerne i resten af projektet, men som ikke findes. Fejlen overlever review, fordi den ser ud som alt det andet. Modgiften er at eksekvere eksemplerne som en del af byggeprocessen frem for at læse dem igennem.

Den anden fejl er dokumentation, der genfortæller koden. Modellen kan se, at funktionen tager tre argumenter og returnerer et objekt, så det skriver den. Den kan ikke se, hvorfor grænsen er sat til 100, eller hvilken hændelse der gjorde retry-logikken nødvendig. Resultatet er sider, der teknisk er korrekte og alligevel ikke besvarer det spørgsmål, læseren kom med.

Den tredje fejl opstår over tid. Hvis dokumentationen regenereres ved hver ændring, fyldes dine pull requests med omformuleringer, der ikke betyder noget. Reviewers vænner sig til at godkende uden at læse, og så forsvinder det menneskelige tjek, hele opsætningen hvilede på. Genererer du kun ved reelle signaturændringer, holder støjniveauet sig nede.

Endelig sætter store kodebaser en hård grænse. Modellen ser den fil, du giver den, ikke hvordan funktionen faktisk kaldes fem lag oppe. Den slags sammenhæng skal du selv beskrive i prompten.

En brugbar arbejdsdeling er at lade modellen tage referencelaget og mennesket tage det konceptuelle. Referencelaget er endpoints, parametre, fejlkoder og returværdier, altså information der findes i koden og kan udledes mekanisk.

Det konceptuelle lag er begrundelser, kompatibilitetsløfter, kendte begrænsninger og de fælder, supportsager har afsløret over år. Den viden står ingen steder i repoet, og en model kan ikke gætte sig til den. Forsøger den, får du velformulerede påstande uden dækning.