Sådan bliver en forretningsbygget AI-prototype til produktionssoftware

Forretningsteams møder i stigende grad op med mere end krav. Efter en workshop bruger de AI-værktøjer til at bygge deres egen prototype, afprøver ideer mellem møderne og kommer tilbage med en version, der udtrykker deres mening langt tydeligere, end en præsentation kunne.

Den gamle reaktion ville være at afvise prototypen som uformel, ufærdig eller teknisk naiv. Det overser, hvad den er. En forretningsbygget prototype er et eksekverbart udtryk for faglig viden: arbejdsgang, sprogbrug, prioritering og brugerforventning i en form, alle kan se på. Spørgsmålet er ikke længere, om prototypen er god nok. Det er, hvad et udviklingsteam skal stille op med den.

Hvad tallene faktisk siger om AI-assisteret udvikling

AI-assisteret udvikling er ikke længere et forsøg. DORA's rapport fra 2025 opgør den daglige brug til omkring 90 % af udviklerne. Udbredelsen har ikke taget tilliden med sig: i Stack Overflows undersøgelse fra 2025 mistroede 46 % af udviklerne præcisionen i AI-værktøjer, mens 33 % stolede på den.

Sikkerheden viser den samme forskel mellem at virke og at være forsvarligt. Veracodes test fra 2026 på over hundrede modeller fandt, at syntaktisk korrekt kode reelt er et løst problem, mens andelen af kode, der bestod sikkerhedstesten, stod stille på 56 %. Kode kan kompilere, køre og demonstrere overbevisende og stadig indeholde en kendt sårbarhedstype.

Gartner har opgjort, at kun 41 % af generative AI-prototyper i gennemsnit når i produktion. Tallet dækker en bredere kategori end vibe-kodede forretningsapplikationer og er derfor ikke et pejlemærke for det enkelte projekt. Men det beskriver den samme organisatoriske udfordring fra den anden ende: det er blevet billigt at lave en prototype, og det er ikke blevet billigere at eje software. Det er samme afstand, vi beskriver i operationel AI over for AI-pilotprojekter.

Vibe-kodet siger noget om oprindelsen, ikke om modenheden

Det meste forvirring i den her diskussion kommer af at bruge "vibe-kodet" som en kvalitetskarakter. Det er en oprindelsesbetegnelse. Modenhed er en anden akse, og det er den, der afgør, hvad der skal ske nu.

Metoden i seks trin

Den produktive tilgang begynder med at lytte til, hvad forretningen har lavet, og hvorfor, og derefter oversætte det til noget, et udviklingsteam kan bygge efter. Hvert trin har et resultat, og det fjerde er der, hvor beslutningen reelt træffes.

1. Indfang hensigten

Find ud af, hvad prototypen forsøger at sige, med dens ophavsmænd til stede. Resultatet er et billede af hensigten, ikke en teknisk vurdering.

• Hvem brugeren er, og hvilken opgave der skal løses
• Det forretningsmæssige resultat, skærmene sigter mod
• Arbejdsgangen i den rækkefølge, arbejdet faktisk sker
• Sprogbrugen, præcis som forretningen bruger den
• Prioriteringen: hvad står på første skærm, og hvad blev udeladt
• De undtagelser, ophavsmændene allerede kender
• De spørgsmål, prototypen ikke svarer på

2. Udled specifikationen

Oversæt skærme og interaktioner til eksplicit adfærd: roller, rettigheder, forretningsregler, tilstandsskift, dataejerskab, validering, kanttilfælde og acceptkriterier. Det er den samme bevægelse, som specifikationsdrevet værktøj som GitHubs Spec Kit sætter i system, og den virker på en prototype, fordi en prototype allerede er en kravspecifikation skrevet i det forkerte sprog.

En knap med teksten "Opret lejemål" er et element på en skærm. Specifikationen skal sige, hvem der må trykke på den, hvilke tilstande en plads må have, hvad der sker med ventelisten, hvordan en nøgle tildeles, og hvad der bliver registreret.

3. Udfordr prototypen

En synlig prototype fastlåser alle, der ser den, også udviklerne. Skærme bliver bevaret, fordi de findes, og et pænt lykkeligt forløb bliver forvekslet med en færdig driftsmodel.

• Hvilke antagelser er aldrig blevet prøvet af på en rigtig sag?
• Hvilke brugere eller roller mangler helt?
• Hvad sker der, når en handling fejler halvvejs?
• Hvad får prototypen til at se enklere ud, end det er?
• Er deltagerne enige i arbejdsgangen, eller reagerer de på fremvisningen?

4. Klassificér hver væsentlig del

Det er en beslutning pr. del, ikke en dom over prototypen som helhed. Hver væsentlig del får ét af tre udfald.

• Bevar som hensigt: forretningsreglen eller arbejdsgangen er det værdifulde, uanset hvordan koden omkring den ser ud
• Genbrug efter verifikation: implementeringen består gennemgang, test og sikkerhedsscanning og går videre
• Byg om: genvejen strider mod målarkitekturen, sikkerhedsmodellen eller driftskravene

Begrundelsen betyder lige så meget som beslutningen. Det er den, der gør det muligt et halvt år senere at svare på, hvorfor en skærm, forretningen selv byggede, ikke længere ser sådan ud.

5. Byg fundamentet til drift

Derefter afklares det, en prototype strukturelt ikke kan tage stilling til. Det meste er systemarkitektur, og det er ikke noget, der falder ud som biprodukt af en prompt.

• Arkitektur og snitflader mellem tjenester
• En holdbar datamodel og migreringer
• Identitet, rettigheder og adskillelse mellem kunder
• Integrationer til de systemer, arbejdet reelt løber igennem
• Tilgængelighed
• Sikkerhed og styring af afhængigheder
• Overvågning og logning
• Udrulning, tilbagerulning, backup og genetablering
• En navngiven driftsansvarlig

6. Dokumentér driftsparatheden

Driftsparathed er dokumentation, ikke en fornemmelse. Listen er kort, og hvert punkt efterlader noget, man kan se på: accepttest af de kritiske arbejdsgange, sikkerheds- og afhængighedsscanning, kontrol af tilgængelighed, belastningstest hvor mængderne er reelle, en genetablering der faktisk er gennemført fra en backup, overvågning og alarmer der når frem til et menneske, en afprøvet tilbagerulning, en navngiven driftsansvarlig, og en gennemgang med dem, der byggede prototypen.

Hvad en prototype rummer, og hvad den forbigår

At læse en prototype ordentligt kræver, at man ved, hvilke dele af den der bærer information. En forretningsbygget prototype er tæt på de områder, dens ophavsmænd arbejder i hver dag, og næsten tavs om de områder, de aldrig ser.

• Som regel pålidelig: navngivning, rækkefølge, og hvilke felter der hører sammen på den skærm, hvor en beslutning træffes
• Kan ikke udtrykkes i en prototype: adfærd ved samtidig brug, ved reelle datamængder, eller når en kilde er utilgængelig
• Stiltiende antaget: én rolle med fuld adgang, fordi den, der byggede den, ikke havde nogen grund til at modellere andres rettigheder
• Tilfældigt: strukturer, der afspejler, hvad værktøjet gjorde nemt, frem for hvad fagområdet kræver

Den sidste kategori er den, der giver problemer, for en prototype kan ikke selv fortælle, hvilke af dens valg der var bevidste. Det kan kun dens ophavsmænd, og deres erindring om, hvorfor et felt ligger, hvor det gør, falmer hurtigt. Gennemgangen hører derfor tidligt i forløbet, med de mennesker til stede, og hvert væsentligt valg bør markeres som fagligt krav, bekvemmelighed eller åbent spørgsmål.

Skemaet over driftsparathed

Garage admin: hvad prototypen faktisk fortalte

Prototypen til garageadministrationen var værdifuld, fordi den blotlagde en driftsmodel, ikke fordi den producerede brugbar kode. Den viste, at en lokation rummer forskellige typer pladser; at en kunde kan bevæge sig fra kontakt til emne og derfra enten på venteliste eller direkte ind i et lejemål; at en nøgle har brug for sin egen tilstand frem for at være et felt på en kundepost; og at opgaver og observationer hører til undtagelseshåndteringen frem for til en generisk huskeliste sat på udenpå.

Det var faglige valg, der var værd at bevare. At gøre dem til produktionssoftware betød at omsætte dem til eksplicitte entiteter, rettigheder, tilstandsskift, valideringsregler og historik. Otte fagbegreber, tre roller (administrator, leder og sagsbehandler) og fem pladstilstande kom ud af gennemgangen som noget, forretningen allerede havde besluttet og kunne begrunde.

En prototype kan farve en plads som optaget. Produktionssoftware skal definere, hvilke handlinger der skaber den tilstand, om to lejemål må overlappe på samme plads, hvem der kan tilsidesætte den, hvad der sker med pladsen, når et lejemål ophører, hvordan ændringen revisionsspores, og hvad systemet gør, når to sagsbehandlere rører den i samme sekund.

Når en forretningsbygget prototype gør leveringen langsommere

Tilgangen er ikke gratis, og den betaler sig ikke altid. En prototype skader mere, end den gavner, når bare ét af følgende er tilfældet.

• Beslutningstagerne har låst sig fast på en tidlig brugerflade og forsvarer den nu som et krav
• Pæne skærme dækker over en forretningsproces, ingen har tænkt færdig
• Den genererede kode bærer arkitektur eller afhængigheder, der ikke kan komme i nærheden af målplatformen
• Der er ingen ansvarlig produktejer, så klassificeringen har ingen til at træffe den
• Følsomme data er allerede havnet i et ukontrolleret værktøj, og første opgave er at begrænse skaden
• Det koster mere at redde koden, end det ville koste at bygge den sammenhængende op igen
• Brugerne bekræfter, at de kan genkende skærmen, ikke at de kan løse opgaven

To fejltyper står for det meste af det. Den første er for høj færdiggrad. En prototype, der ser færdig ud, inviterer til, at man arver dens datamodel sammen med dens indsigt, og en struktur, man har overtaget uden at tage stilling, er dyr at ændre, når resten af systemet hviler på den. Skærmbilleder kan tegnes om sent i forløbet. Datamodellen kan ikke.

Den anden er at lægge prototypen væk i stilhed. Hvis det leverede system ikke har synlig sammenhæng med det, deltagerne afleverede, og ingen har gjort rede for, hvad der blev bevaret og hvorfor, konkluderer de, at øvelsen var pynt, og næste runde giver mindre. Dér hvor et fagligt valg blev tilsidesat, holder det kanalen åben at sige det.

At respektere prototypen er ikke det samme som at acceptere dens valg. Bevar den faglige indsigt, udfordr antagelserne, og læg implementeringen fra jer, når det koster mere at forstå og reparere den end at bygge den sammenhængende op igen.

En bedre rolle til prototypeværktøjerne

AI-værktøjer til prototyping skaber reel værdi, når de hjælper ikke-udviklere med at udtrykke deres hensigt præcist. De forkorter afstanden fra første tanke til produktionsretning, og de rykker ikke ved implementeringsdisciplinen. Det er også den ærlige udlægning at give forretningen: deres prototype er det input, specifikationen skrives ud fra, og det er specifikationen, der bliver bygget. Den samme arbejdsdeling gælder inde i udviklingsteamet, hvor frontier-modeller ændrer, hvordan implementeringen udføres, uden at ændre, hvem der står på mål for resultatet.

Håndteret sådan betaler øvelsen sig for alle: forretningen ser sin tænkning ført videre, udviklerne får et langt rigere udgangspunkt end et kravdokument, og organisationen ender med software, den rent faktisk kan drifte.

At klassificere en prototypes dele som bevar, genbrug efter verifikation eller byg om er en arkitekturbeslutning, der træffes under tidspres, og det er nemt at blive for gavmild med den midterste kategori. Den klassifikation er den første arbejdssession i enhver opgave om systemarkitektur, vi kører mod en forretningsbygget prototype, og den er værd at lave sammen med nogen, der ikke var i rummet, da prototypen blev bygget.

Kan en vibe-kodet prototype bruges i produktion?

Ikke som den står, og det handler ikke om, hvordan den er skrevet. En prototype har ikke svaret på det, produktion spørger om: adgangsstyring, adskillelse mellem kunder, dataintegritet, adfærd ved fejl, overvågning, genetablering og ejerskab. Enkelte dele af den kan sagtens komme i produktion, når de er gennemgået, testet og sikkerhedsscannet som al anden kode.

Skal AI-genereret prototypekode skrives om?

Beslut det pr. del, ikke pr. prototype. Bevar forretningsreglerne og arbejdsgangen som hensigt. Genbrug implementeringen, hvor den består gennemgang, test og sikkerhedsscanning. Byg om, hvor genvejen strider mod målarkitekturen eller sikkerhedsmodellen. Veracodes test fra 2026 fandt AI-genereret kode sikker i omkring 56 % af tilfældene uden sikkerhedsrettede prompts, og det er grunden til, at gennemgangen er en port og ikke en formalitet.

Hvilke dele af en forretningsprototype bør udviklerne bevare?

De dele, kun forretningen kunne have lavet: sprogbrugen, den rækkefølge arbejdet faktisk sker i, hvilke felter der hører sammen dér, hvor en beslutning træffes, de undtagelser de allerede kender, og hvad de valgte ikke at have med på første skærm. Det er faglige valg. Layout, datastrukturer og biblioteksvalg er som regel spor efter værktøjet.

Hvad er forskellen på en prototype og en MVP?

En prototype viser, at en idé kan gøres synlig og afprøves. En MVP viser, at den mindste brugbare version kan betjene rigtige brugere og give læring, og derfor skal den kunne driftes, supporteres og være forsvarlig for de brugere. En prototype har ingen af de forpligtelser, og det er præcis det, der gør den hurtig.

Hvad indeholder en gennemgang af driftsparathed?

Dokumentation frem for holdninger: accepttest af de kritiske arbejdsgange, sikkerheds- og afhængighedsscanning, kontrol af tilgængelighed, belastningstest hvor mængderne er reelle, en genetablering gennemført fra en backup, overvågning og alarmer der når frem til et menneske, en afprøvet tilbagerulning, en navngiven driftsansvarlig, og en gennemgang op mod den hensigt, prototypen udtrykte.

Hvem ejer software, som forretningen selv har lavet til at begynde med?

Ejerskabet skal flyttes eksplicit i det øjeblik, det bliver et produktionssystem. En navngiven driftsansvarlig står på mål for det, et udviklingsteam kan læse, gennemgå og ændre det, og de oprindelige ophavsmænd forbliver involveret som fagligt ansvarlige. At lade ejerskabet blive hos den, der kan prompte værktøjet, er måden en prototype bliver til en usupporteret afhængighed på.

Hvordan undgår man, at forretningsbyggede prototyper bliver til skygge-it?

Giv prototyping en godkendt vej frem for et forbud: godkendte værktøjer, klare regler for hvilke data der må lægges i dem, og en fast indgang til den metode, der er beskrevet her. Risikoen er ikke, at forretningen bygger noget. Den er, at ingen opdager det, før det bærer noget.

Kilder

1. State of AI-assisted Software Development 2025 — DORA, Google Cloud
2. 2025 Developer Survey: AI — Stack Overflow
3. 2026 GenAI Code Security Report — Veracode
4. AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production — Gartner
5. Spec Kit: spec-driven development — GitHub