Vibe coding af et point of sale: Hvor langt kan du egentlig nå?
Vibe coding giver dig en overbevisende POS-demo på en eftermiddag. Det giver dig ikke en lagerstyring, der overlever to samtidige salg, rapporter, der stemmer, eller kortbetalinger. Her er, hvor muren reelt rammes.

Overraskende langt, og derefter direkte ind i en mur. Vibe coding af et point of sale giver dig en overbevisende betalingsskærm, et produktkatalog og en fungerende kurve-logik på en eftermiddag, helt uden krav om kodekendskab. Hvad det ikke giver dig, er et POS, du kan drive en forretning på. Afstanden mellem de to ting er emnet for dette indlæg, fordi demoen får gabet til at se meget mindre ud, end det er.
Et enkelt forbehold før detaljerne: AI-værktøjer ændrer sig månedligt, så betragt detaljerne her som et øjebliksbillede, der er nøjagtigt på udgivelsestidspunktet.

Hvad kan du egentlig bygge med vibe coding?
Mere end skeptikerne påstår. Giv et værktøj som Lovable, Replit eller v0 prompten "byg et POS til min kaffebar", og du får en rigtig grænseflade tilbage: Menukort, tilvalg, en kurv, en total og måske et fiktivt betalingstrin. Det ser rigtigt ud, det reagerer rigtigt, og du kan præsentere det for folk samme dag.
Det er ikke et trick. Til det synlige lag af et POS er AI-generering legitimt god, og den bliver hele tiden bedre. Hvis det, du har brug for, er en prototype, en pitch-demo eller en måde at gennemtænke dit eget betalingsflow på, vibe coding leverer varen.
Hvor falder et vibe-coded POS fra hinanden?
Ved de dele, der skal være korrekte hver eneste gang, uden at nogen overvåger det.
Lagerstyring under samtidighed (concurrency) (to salg, der sker i samme øjeblik): AI-genereret lagerlogik læser typisk en mængde, trækker én fra og skriver det tilbage. To samtidige salg af den sidste enhed lykles begge, og du har solgt en vare, du ikke har på lager.
Rapporter, der stemmer (totaler, der matcher de penge, der faktisk blev flyttet): En demorapport lægger blot tallene i en tabel sammen. En rigtig rapport håndterer refusioner, annulleringer, delvise betalinger og prisændringer i løbet af dagen uden at afvige fra din betalingsformidlers tal.
Skat og moms: Satser efter region, regler efter produktkategori, afrunding på linjeniveau versus totalen. Forkerte svar her er ikke bare fejl, de er et juridisk og økonomisk ansvar.
Sikkerhed: I Veracodes 2025-undersøgelse af over 100 AI-modeller fejlede 45 % af de genererede kodesamples sikkerhedstests mod OWASP Top 10, og fejlraten blev ikke forbedret med nyere eller større modeller¹.
Ingen af disse fejl viser sig i en demo. De dukker alle op i måned to af butikkens drift.

Hvad med at tage imod rigtige betalinger?
Dette er den sværeste hindring. Online kortbetalinger kræver PCI-overholdelse (sikkerhedsregler for kortdata), og fysiske kortbetalinger kræver desuden certificeret terminalhardware parret med en betalingsformidler. Der findes ingen prompt, der kan spytte en hardwarecertificering ud.
Apple og Google håndhæver dette ved indgangen: Vi har dækket, hvorfor vibe-coded betalingsapps bliver afvist i App Store, og den korte version er, at godkendelsesteams tjekker, hvem der formidler betalingerne, længe før de tjekker, hvor flot din grænseflade er.

Kan du se, om AI'en tog fejl?
Dette spørgsmål afgør, om vibe coding er sikkert for en given del af dit POS. Du kan vurdere en betalingsskærm ved at kigge på den. Du kan ikke vurdere lagerlåsning eller afstemningskode ved at kigge på den, og de færreste forhandlere ville vide, hvad de skulle kigge efter.
Den gængse indvending er "få en udvikler til at gennemgå AI'ens output". Fair nok, men så betaler du alligevel for udvikling, og at gennemgå en andens ukendte kode – uanset om den er skrevet af et menneske eller en AI – er ofte langsommere end at skrive den forfra. Den økonomiske fordel, der gjorde vibe coding attraktiv, forsvinder.
Så hvor langt kan du egentlig nå?
Hele vejen til en overbevisende demo, men stort set ingen vegne med de dele, der gør et POS til et forretningssystem. Det synlige lag er et løst problem for AI; pengelaget er ikke, og det fejler i det stille. Den praktiske tommelfingerregel: Før du lader AI bygge noget, skal du spørge dig selv, om du ville kunne se, hvis det var forkert. Hvis ja, så prompt løs. Hvis nej, hører den del hjemme på testet infrastruktur.
Den opdeling er præcis, hvordan AI POS-byggere som Finals er struktureret: AI'en designer dine betalingsflows, mens lager, rapportering og betalinger kører på forudbyggede skinner, som den ikke kan ødelægge. Hvis du vil se, hvordan det ser ud i praksis, kan du starte med at bygge dit første flow eller vores gennemgang af at bruge ChatGPT til at bygge et specialtilpasset POS.
Ofte stillede spørgsmål
Hvad er vibe coding?
Vibe coding betyder, at man beskriver den software, man ønsker, i almindeligt sprog og lader en AI skrive koden, hvor man i høj grad accepterer resultatet i god tro. Begrebet tog fart i 2025 og dækker nu over værktøjer som Lovable, Replit og v0 samt det at kode direkte med en chatbot.
Kan AI bygge et komplet POS-system ud fra et prompt?
Den kan bygge det synlige lag: betalingsskærmen, produktkataloget og kurv-logikken. De dele, som en virksomhed afhænger af – såsom præcis lagerbeholdning under belastning, rapporter, der stemmer, og regelkonforme kortbetalinger – kræver en testet handelsinfrastruktur under AI'en.
Er vibe-kodet software sikkert til at tage imod kortbetalinger?
Ikke i sig selv. Kortbetalinger kræver PCI-overholdelse (sikkerhedsregler for kortdata), og fysiske kortbetalinger kræver certificeret terminalhardware. Ingen af delene kan genereres af et prompt, hvilket er grunden til, at vibe-kodede betalingsapps rutinemæssigt afvises i app stores.
Hvad er forskellen på et demo-POS og et produktions-POS?
En demo skal kun fungere én gang, mens du kigger på. Et produktions-POS skal være fejlfrit hver gang, uden at nogen holder øje: To samtidige salg må ikke overskride lagerbeholdningen, og hver eneste rapport skal stemme overens med de penge, der rent faktisk blev flyttet.
