Vibe-koding av en POS: Hvor langt kan du egentlig komme?
Vibe-koding gir deg en overbevisende POS-demo på en ettermiddag. Det gir deg ikke en lagerbeholdning som overlever to samtidige salg, rapporter som stemmer, eller kortbetalinger. Her møter du veggen.
Overraskende langt, og så rett i veggen. Vibe-koding av en POS gir deg en overbevisende betalingsskjerm, en produktkatalog og fungerende handlekurvlogikk på en ettermiddag, helt uten krav til kodekunnskap. Det du ikke får, er en POS du faktisk kan drive en virksomhet med. Avstanden mellom disse to tingene er temaet for dette innlegget, fordi demoen får gapet til å se mye mindre ut enn det faktisk er.
Én forutsetning før vi går inn på detaljene: AI-verktøy endrer seg månedlig, så se på detaljene her som et øyeblikksbilde, nøyaktig på publiseringstidspunktet.
Hva kan du faktisk bygge med vibe-koding?
Mer enn skeptikerne hevder. Gi et verktøy som Lovable, Replit eller v0 prompten "bygg en POS for kaffebaren min", og du får tilbake et ekte grensesnitt: meny-rutenett, varianter, en handlekurv, en totalsum, kanskje til og med et simulert betalingstrinn. Det ser riktig ut, det fungerer når du klikker, og du kan vise det frem til folk samme dag.
Dette er ikke et triks. Når det gjelder det synlige laget av en POS, er AI-generering genuint bra, og det blir stadig bedre. Hvis det du trenger er en prototype, en pitch-demo eller en måte å tenke ut din egen betalingsflyt på, leverer vibe-koding varene.
Hvor faller en vibe-kodet POS sammen?
På de delene som må være korrekte hver eneste gang, uten at noen overvåker dem.
Lagerbeholdning under samtidig belastning (to salg som skjer i nøyaktig samme sekund): AI-generert lagerlogikk leser vanligvis et antall, trekker fra én, og skriver det tilbake. To samtidige salg av den siste enheten vil begge lykkes, og du har solgt varer du ikke har på lager.
Rapporter som stemmer (totalsummer som samsvarer med pengene som faktisk ble flyttet): en demorapport summerer bare en tabell. En reell rapport overlever refusjoner, annulleringer, delbetalinger og prisendringer midt på dagen uten å avvike fra tallene til betalingsformidleren din.
Skatt: satser etter region, regler etter produktkategori, avrunding på varelinjenivå versus totalsummen. Feil svar her er ikke bare programvarefeil, de er juridiske ansvar.
Sikkerhet: I Veracodes 2025-studie av over 100 AI-modeller feilet 45 % av de genererte kodesurene på sikkerhetstester mot OWASP Top 10, og feilraten ble ikke bedre med nyere eller større modeller¹.
Ingen av disse feilene dukker opp i en demo. Alle sammen dukker opp i måned to av å drive en butikk.
Hva med å ta imot ekte betalinger?
Her er det full stopp. Kortbetalinger på nett krever PCI-samsvar (sikkerhetsregler for kortdata), og fysiske betalinger krever i tillegg sertifisert terminalmaskinvare koblet til en betalingsformidler. Det finnes ingen prompt som kan spytte ut en maskinvaresertifisering.
Apple og Google håndhever dette strengt: vi har dekket hvorfor vibe-kodede betalingsapper blir avvist i App Store, og den korte versjonen er at vurderingsteamene sjekker hvem som ruter betalingene lenge før de sjekker hvor pent grensesnittet ditt er.
Kan du se om AI-en tok feil?
Dette spørsmålet avgjør om vibe-koding er trygt for en gitt del av din POS. Du kan vurdere en betalingsskjerm bare ved å se på den. Du kan ikke vurdere kode for lagerlåsing eller avstemming bare ved å se på den, og de færreste forhandlere ville vite hva de skulle se etter.
Den vanlige innvendingen er "få en utvikler til å gå gjennom AI-ens kode". Joda, men da betaler du for utvikling uansett, og å gå gjennom andres ukjente kode, enten den er skrevet av et menneske eller en AI, tar ofte lengre tid enn å skrive den fra bunnen av. Økonomien som gjorde vibe-koding attraktivt, faller bort.
Så, hvor langt kan du egentlig komme?
Helt frem til en overbevisende demo, men nesten ingen vei på de delene som gjør en POS til et forretningssystem. Det synlige laget er et løst problem for AI; pengelaget er det ikke, og det feiler i det stille. Den praktiske tommelfingerregelen: før du lar AI bygge noe, spør om du ville oppdaget det om det ble feil. Hvis ja, prompte i vei. Hvis nei, hører den delen hjemme på testet infrastruktur.
Dette skillet er nøyaktig slik AI-POS-byggere som Finals er strukturert: AI-en designer betalingsflyten din, mens lagerbeholdning, rapportering og betalinger kjører på ferdigbygde skinner som den ikke kan ødelegge. Hvis du vil se hvordan det ser ut i praksis, kan du starte med å bygge din første flyt eller lese gjennomgangen vår av å bruke ChatGPT til å bygge en tilpasset POS.
Ofte stilte spørsmål
Hva er vibe-koding?
Vibe-koding betyr å beskrive programvaren du ønsker i vanlig tekst og la en AI skrive koden, der du i stor grad godtar resultatet i god tro. Begrepet skjøt fart i 2025 og dekker nå verktøy som Lovable, Replit og v0, i tillegg til koding direkte med en chatbot.
Kan AI bygge et komplett POS-system fra en prompt?
Den kan bygge det synlige laget: betalingsskjermen, produktkatalogen og handlekurvlogikken. Delene en bedrift er avhengig av, som nøyaktig lagerbeholdning under belastning, rapporter som lar seg avstemme, og kortbetalinger som oppfyller gjeldende regler, krever testet handelsinfrastruktur under AI-en.
Er vibe-kodet programvare trygg for å ta imot kortbetalinger?
Ikke i seg selv. Kortbetalinger krever PCI-etterlevelse (sikkerhetsregler for kortdata), og fysiske kortbetalinger krever sertifisert terminalmaskinvare. Ingen av delene kan genereres av en prompt, og det er derfor vibe-kodede betalingsapper rutinemessig blir avvist fra appbutikker.
Hva er forskjellen på et demo-POS og et produksjons-POS?
En demo trenger bare å fungere én gang, mens du ser på. Et produksjons-POS må være nøyaktig hver eneste gang uten at noen følger med: to samtidige salg må ikke føre til oversalg av varer, og hver rapport må stemme overens med pengene som faktisk ble flyttet.