Åbningen 'Dage, ikke måneder' hvad kilderne hævder
Her er påstanden, som sætter scenen: AI Parabellum siger “Use AI to decode inherited code in days, not months.” Snillds manual peger samme vej, men beskriver metoden bag: kombinationen af “kodeindeksering”, “kontekstuelle prompt-skabeloner” og “automatiserede testgeneratorer”. Formålet er tempo og en brugbar mental model af et system, man ikke selv har bygget.
Afgrænsning først. De nævnte tidsgevinster er leverandør- og praktikervurderinger, operationelt underbyggede, ikke akademisk kvantificerede. Det er ambitioner, ikke garantier.
Hvordan en AI-assistent arbejder sig gennem kodebasen
Start med indeks. Kodefiler crawles og parses, og metadata som modulafhængigheder, API-overflader og testsignaturer gemmes i en søgbar struktur. Snilld-manualen beskriver det som forudsætningen for gode spørgsmål. Uden kontekst bruger man tokens på gæt.
Brug faste prompt-skabeloner. Ikke åbne “hvad gør systemet”, men bestemte formater: “Returnér en funktionsoversigt med input, output, sideeffekter og pegefelter til kaldende og kaldte funktioner.” Manualen anbefaler korte, gentagelige skabeloner. Så undgår man fluff.
Lad tests være motoren. Manualen beskriver, at assistenten kan foreslå enhedstests og smoke-tests ud fra signaturer og eksempler i repoet. De er ikke perfekte, men et net. Når de køres, falder noget af dokumentationen ud af assertion-fejlene.
Konkrete outputs der flytter noget
Sigtepunktet er tre artefakter. 1) Moduloversigter: kort ansvar, nøgleafhængigheder, sideeffekter. 2) Funktionskort: tabeller eller JSON-lister over centrale funktioner med parametre, returtyper og kaldetræ. 3) Fejlsøgningsstier: trin-for-trin gennem en brugerrejse eller API-vej.
Valider dem med eksplicitte kriterier. For oversigter: kun moduler med navngivne eksterne afhængigheder og konfigurationsnøgler. For funktionskort: automatisk match mod eksporterede symboler omkring det fulde sæt. For fejlsøgningsstier: afspilning i staging dokumenteret med logs og test-output.
Forvent fejl, især hvor navngivning og arkitektur divergerer, eller hvor refleksion og dynamisk import skjuler forbindelser. Læs ikke kun, kør det.
Governance og sikkerhed de skjulte omkostninger
Snilld-manualen er eksplicit om best practice: governance, sikre dataflows, inkrementel refaktorering og menneskelig verifikation i feedback-loops. Det er forskellen på en nyttig pilot og en demo.
Dataflow først. Afklar hvad må forlade huset, og hvad skal blive internt. Bruger I en offentlig LLM-tjeneste, skal hemmelige nøgler, persondata og forretningskritiske strenge redigeres ud af både prompt og kontekst.
Styr adgangen. Afgræns hvilke repos og branches assistenten kan læse og skrive til. Brug servicekonti og log alt. Behandl assistenten som en developer-bot under change management.
Og gem sporene. Arkivér prompt, kontekstudsnit, modelversion og output for større forslag. Når noget går skævt, skal I kunne genskabe forløbet.
Pilotforslag med faste kanter i 6 til 8 uger
Lav et smalt scope. Vælg 1–2 kritiske moduler, ikke hele monolitten. Gå efter områder hvor testbarhed er mulig, fx prisberegning, fakturering eller en API-gateway. Snilld-manualen anbefaler netop en “pilot på kritiske moduler (inkl. automatisk testdækning og dokumentationsgeneration) før fuld udrulning”.
Sæt milepæle. Uge 1–2: kodeindeksering, datasanitering, prompt-skabeloner. Uge 3–4: første dokumentationsbatch og auto-genererede tests som separate CI-jobs. Uge 5–6: fejlsøgningsstier på konkrete fejl og en runde inkrementel refaktorering af lavrisikofunktioner. Uge 7–8: stabilisering, review, beslutning om skalering.
Mål på få, hårde nøgletal. Tid til første godkendte moduloversigt. Antal fejl tests fanger før staging. Andel forslag der kan merges uden omskrivning. Hold øje med compute- og modelomkostninger, så budgettet ikke vokser lydløst.
Hvor metoden typisk fejler
Kend faldgruberne. 1) Binære artefakter og proprietære formater. Ligger logik i f.eks. hjemmelavede XML-skemaer eller regneark-makroer, knækker assistenten ofte. Her skal der laves bro-kode eller manuelle uddrag. 2) Testhuller. Uden baseline-tests bliver autogenererede tests overfladiske eller misledende. Skriv 5–10 håndlavede tests for de vigtigste flows, før I trykker på knappen. 3) Komplekse runtime-dynamikker. Plugins, refleksion, eval og kø-systemer udfordrer tidsforståelsen. Brug tracing og profiler.
Et kort pseudo-eksempel for at gøre det håndgribeligt: Et modul loader regler fra en XML-fil via dynamiske stinavne. Modellen foreslår pæne tests, men alle passerer, fordi den aldrig rammer de rigtige paths i staging. Løsning: log de faktiske filstier under kørsel, fød dem tilbage i prompten, og kræv kildecitater i svaret. Først derefter giver tre-reglen et solidt grundlag for merge.
Det bringer os til kontrolmekanismerne. Tracing afslører de reelle kald og timingen. Statiske værktøjer og linters giver en baseline uden LLM. Sammen holder de fantasien i kort snor.
Risiko for hallucination og hvordan man holder den i snor
Vær direkte her. Generative modeller vil hellere svare end tie, så hallucination er en strukturel risiko i dokumentation. Risikoen falder, når konteksten begrænses, og svarene kræver citater fra kildekode.
Brug tre-reglen fra manualen: Ingen dokumentation merges uden 1) filstier og linjer, 2) en test der bekræfter påstanden, eller 3) en reviewer der underskriver. Opfyld mindst to af tre. Tempoet falder lidt, tilliden stiger meget.
Supplér med statisk analyse. Det er ikke enten eller.
Parallellen til hardware-standarden MHS
Pointen her er interoperabilitet. MarkTechPost rapporterer, at Anthropic har åbnet en research preview af Model Hardware Standard, så agenter kan opdage og betjene fysiske enheder. Anthropic hævder, at MHS reducerer typisk opsætningstid fra uger eller måneder til timer eller minutter. Det er et leverandøranslag, men illustrerer værdien af fælles formater.
Overført til devtools: Hvis værktøjer til kodeanalyse, testgeneration og dokumentation kunne eksportere og importere simple, åbne formater, blev det lettere at udskifte komponenter undervejs. Lige nu er det fragmenteret, og det koster integrationstid.
Konsekvensen for indkøb er enkel. Vælg værktøjer, der kan udveksle artefakter i åbne formater. Ellers låser I jer inde.
Praktiske råd til implementering
Prioritér rigtigt. Start hvor forretningsrisikoen er høj, og kodestien er testbar. En årgangs-COBOL-kernedel uden CI er sjældent første pilot, uanset fristelsen. Vælg moduler med klar I/O, logning og mulighed for afspilning.
Hold compliance ren. Dokumentér datavejen: Hvilke filer går i modellen, hvilke går ikke, og hvem godkender det. Tag runden med sikkerhed og juridik før første prompt, ikke bagefter.
Lav et simpelt ROI-billede. Sæt ord på tre gevinster I selv kan måle efter piloten: onboardingtid for nye udviklere, fejl fanget før staging, og kortere MTTR via bedre fejlsøgningsstier. Snilld-manualens formuleringer om gevinster er pejlemærker, indtil jeres tal bekræfter dem.
Sådan samler man værktøjsstakken uden støj
Byg småt. Vælg et indeksværktøj med sprogunderstøttelse til jeres top-3 sprog og incremental crawl. Vælg en model-adapter, der kan skifte mellem lokal model og cloud efter datasensitivitet. Vælg en testgenerator, der afleverer i kendte testrammer, ikke et nyt format.
Begræns outputs. Ét repo, én pipeline, to artefakter: dokumentation og tests. Udviklere har ret i at være allergiske over for fem nye dashboards.
Forbered exit. Gem indeks i et åbent format. Læg prompts og skabeloner i repo. Hvis værktøjet forsvinder, skal I ikke starte forfra.
Pilotens håndværk i detaljer
Definér scope på en halv side. Skriv de funktionelle grænser og de datafelter, der er in scope. Nævn eksplicit hvad der er out of scope. Det føles småt, og det er meningen.
Fastlæg tekniske milepæle. 1) Indekset kører nightly og opdaterer på under et kvarter. 2) Første dokumentationsbatch leverer moduloversigter med filstier og kaldetræ som vedhæftet JSON. 3) Auto-tests kører i CI uden at gate hovedpipen i de første to uger. 4) Efter uge fire flyttes de mest stabile tests ind som gate.
Håndter risiko tidligt. Giv assistenten skrivebeskyttet adgang til produktionsnære branches. Brug feature branches med PR-skabeloner, der kræver kildehenvisning. Kør staging med syntetiske data, mens saniteringen modnes.
Hvad der stadig mangler belyst
Vær åben om hullerne. Der mangler uafhængige kvantitative studier. Påstande om “dage, ikke måneder” og MHS’ “timer eller minutter” kommer fra AI Parabellum og Anthropic. Interessant, men kræver verifikation i andre miljøer.
Fejlklasser er underdokumenterede. Hvilke legacy-misligheder driller mest, ud over de åbenlyse som binære blobs og selvopfundne formater. Branchen har brug for flere åbne post mortems.
Skalerings- og omkostningsprofiler er uklare. Hvad koster det at holde meget store kodebaser indekseret og tilgængelige for en assistent over tid. Værktøjsleverandører bør være mere transparente her.
Hurtigt overblik
Hvis I skal i gang nu: 1) Afklar governance og dataflow før første prompt. 2) Kør en smal 6–8 ugers pilot på 1–2 kritiske moduler med dokumentation og tests i fokus. 3) Mål på få, hårde nøgletal og brug menneskelig verifikation. AI kan ofte skære onboarding fra måneder til dage ifølge praktikere, men gevinsten bliver først reel, når den kan måles i jeres miljø.
