Produkter bygget med AI
En stifter kan i dag få en fungerende app på skærmen på få dage ved at beskrive den for et AI-værktøj, og et udviklingsteam skriver kode anderledes end for få år siden. Begge dele er nyttige. Spørgsmålet, der følger efter, er det samme i begge tilfælde: hvem står for arkitekturen, sikkerheden og driften, når koden er skrevet af en maskine, og betalende kunder lægger deres data i produktet? Siden her samler artiklerne til stifteren med en AI-bygget app og til ledelsen af et team, der bruger AI i hverdagen.
Det, der går igen
Det første spørgsmål er, om I stadig afprøver en idé, eller om rigtige brugere og rigtige data er på vej ind. Så længe det er en afprøvning, må det gerne gå hurtigt. Når kunder logger ind, skal nogen kunne svare på, om den ene kunde kan se den andens data, hvor nøgler til betalinger og tjenester ligger, og om der findes en backup, der kan bruges. Det næste spørgsmål er ejerskab: kan produktet flyttes væk fra værktøjet, det er født i? Det tredje handler om grundlaget. Grundlaget skal holde, uanset hvem der skrev den første kode, og derfor gælder det samme for de arkitekturbeslutninger, der er dyre at ændre.
Stifteren, der vil bygge selv
- Vibe coding: hvad er det, og hvor langt kan det bære et produkt? Begrebet forklaret for en stifter, med det, metoden egner sig til, og det, der kræver mere, når rigtige kunder kommer ind.
- Kan vi selv bygge det med AI? Grænsen for, hvad en stifter kan klare selv, og hvad der følger med, når nogen betaler for produktet.
- Lovable, Bolt, Cursor eller Claude Code: hvad passer til hvad? En uvildig gennemgang af app-byggere og kodeværktøjer, og af den kontrol og det ansvar, der følger med hver type.
Fra prototype til noget, kunder kan stole på
- Fra AI-bygget prototype til produkt, kunderne kan stole på Rækkefølgen, når appen virker på skærmen, og hvornår prototypen hellere skal bruges som specifikation.
- Eftersyn af AI-genereret kode før lancering De kendte svagheder set fra stifteren, og hvad en menneskelig gennemgang skal kunne svare på.
- Kan I tage koden med ud af AI-værktøjet? Kode, database, login og domæne, når produktet er født på en platform.
Teamet, der bruger AI til koden
- AI-kodeassistenter i udviklingsteamet: regler for brug Rammer for kvalitet, fortrolighed og gennemgang, også i gammel kode, og hvorfor retsstillingen for AI-genereret kode endnu er uafklaret.
Når prøven er ved at blive et produkt
Mange stiftere kommer hertil med den samme oplevelse. Produktet virker, de første kunder er interesserede, og ingen ved helt, hvad der ligger under overfladen. Det er et godt sted at standse og tage stilling, før nye funktioner lægges ovenpå. Hører I til dem, der ikke selv koder, er den næste læsning Startup uden teknisk medstifter. Handler det om AI som en funktion i det produkt, kunden køber, ligger stoffet under AI i produktet. Forarbejdet til en test af sikkerheden er beskrevet under sikkerhed i produktet.
Ophavsret til kode, som AI har skrevet, er et spørgsmål til advokat. Retsstillingen er ikke afklaret af nogen dansk myndighed, vi kender til.
Det skal I lade være med
- At tage en demo for et færdigt produkt · skærmen viser det, brugeren ser, og siger intet om adgangskontrol og data.
- At lægge nøgler og hemmeligheder ind i selve appen · det, der ligger i browseren, kan læses af den, der leder.
- At bygge videre uden at vide, hvor koden kan flyttes hen · spørgsmålet er lettere at stille tidligt.
- At sætte AI-værktøjet til at vurdere sig selv · en anden kritisk læser skal se resultatet.
Det skal I kræve af den eksterne
- ☐ Egen brugserfaring med værktøjerne og et klart svar på, hvad de ikke kan.
- ☐ En prioriteret liste over det, der skal på plads, før kunder får adgang.
- ☐ Et overblik over, hvor kode, database, login og domæne ligger, og hvem der ejer dem.
- ☐ Rammer for AI i teamet, som udviklerne selv kan se fornuften i.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Artikler om CTO as a Service · Arkitektur og teknologivalg
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
Mangler I en CTO?
Fortæl kort, hvad der fylder: produktet, teamet, leverandøren eller en kunde, der stiller krav. Rådgivningen er uvildig og uden bindinger til leverandører, så svaret tager udgangspunkt i jeres situation.
Seneste artikler
De tekniske nøgletal, bestyrelsen i et SaaS‑hus skal se
5. november 2026
Hvad er en MVP? Den første version forklaret
5. november 2026
NIS2 og CRA: hvilke regler rammer softwarehuset?
5. november 2026