Vibe-koding av ein POS: Kor langt kan du eigentleg kome?
Vibe-koding gir deg ein overtydande POS-demo på ein ettermiddag. Det gir deg ikkje ein lagerstyring som overlever to samtidige sal, rapportar som stemmer, eller kortbetalingar. Her er kvar veggen faktisk står.
Overraskande langt, og så rett i veggen. Vibe-koding av ein POS gir deg ein overtydande betalingsskjerm, ein produktkatalog og fungerande korglogikk på ein ettermiddag, heilt utan krav til kodekunnskap. Det du ikkje får, er ein POS du kan køyra ei bedrift på. Avstanden mellom desse to tinga er temaet for dette innlegget, fordi demoen gjer at gapet ser mykje mindre ut enn det faktisk er.
Eitt atterhald før detaljane: AI-verktøy endrar seg månadleg, så sjå på detaljane her som eit augeblikksbilete, nøyaktig på publiseringstidspunktet.
Kva kan du faktisk byggje med vibe-koding?
Meir enn skeptikarane påstår. Gi eit verktøy som Lovable, Replit eller v0 instruksjonen «bygg ein POS for kaffibaren min», og du får tilbake eit ekte grensesnitt: menyoppsett, tilval, ei handlekorg, ein totalsum, kanskje til og med eit fiktivt betalingssteg. Det ser rett ut, det reagerer rett når du klikkar, og du kan vise det fram til folk same dag.
Dette er ikkje eit triks. For det synlege laget av ein POS er AI-generering genuint bra, og det blir stadig betre. Dersom det du treng er ein prototype, ein presentasjonsdemo eller ein måte å tenkje gjennom din eigen betalingsflyt på, leverer vibe-koding.
Kvar fell ein vibe-koda POS saman?
På dei delane som må vere rette kvar einaste gong, utan at nokon passar på.
Lagerstyring under samtidig belastning (to sal som skjer i akkurat same sekund): AI-generert lagerlogikk leser vanlegvis av eit tal, trekkjer frå éin, og skriv det tilbake. To samtidige sal av den siste eininga vil begge gå gjennom, og du har selt ei vare du ikkje har på lager.
Rapportar som stemmer (totalsummar som samsvarar med pengane som faktisk vart flytta): ein demorapport summerer berre ein tabell. Ein reell rapport overlever refusjonar, annulleringar, delbetalingar og prisendringar midt på dagen utan å avvike frå tala til betalingsformidlaren din.
Skatt: satsar etter region, reglar etter produktkategori, avrunding på linjenivå versus totalsum. Feil svar her er ikkje berre programvarefeil, det er eit juridisk ansvar.
Sikkerheit: I Veracode si undersøking frå 2025 av over 100 AI-modellar, feila 45 % av dei genererte kodeslane på sikkerheitstestar mot OWASP Top 10, og feilraten vart ikkje betre med nyare eller større modellar¹.
Ingen av desse feila viser seg i ein demo. Alle saman dukkar opp i månad to av å køyra ein butikk.
Kva med å ta imot reelle betalingar?
Her er det stopp. Digitale kortbetalingar krev PCI-samsvar (sikkerheitsreglar for kortdata), og fysiske betalingar krev i tillegg sertifisert terminalmaskinvare kopla saman med ein betalingsformidlar. Det finst ingen instruksjon som kan spytte ut ein maskinvaresertifisering.
Apple og Google handhevar dette strengt: vi har dekt kvifor vibe-koda betalingsappar blir avviste i App Store, og den korte versjonen er at vurderingsteama sjekkar kven som formidlar betalingane lenge før dei sjekkar kor fint grensesnittet ditt er.
Kan du sjå om AI-en tok feil?
Dette spørsmålet avgjer om vibe-koding er trygt for ein gitt del av POS-en din. Du kan vurdere ein betalingsskjerm berre ved å sjå på han. Du kan ikkje vurdere koden for lagerlåsing eller avstemming berre ved å sjå på han, og dei fleste butikkeigarar ville ikkje eingong vite kva dei skulle sjå etter.
Den vanlege innvendinga er «få ein utviklar til å gå gjennom koden frå AI-en». Jau då, men då betalar du for utvikling uansett, og å setje seg inn i og vurdere andre sin ukjente kode, enten han er skriven av eit menneske eller ein AI, tek ofte lengre tid enn å skrive han på nytt frå botnen av. Økonomien som gjorde vibe-koding attraktivt, fell bort.
Så, kor langt kan du eigentleg kome?
Helt fram til ein overtydande demo, og nesten ingen veg på dei delane som gjer ein POS til eit reelt forretningssystem. Det synlege laget er eit løyst problem for AI; pengelaget er det ikkje, og det sviktar i det stille. Den praktiske tommelfingerregelen: før du lèt AI-en byggje noko, spør deg sjølv om du ville oppdaga det dersom han tok feil. Dersom svaret er ja, er det berre å koda i veg. Dersom svaret er nei, høyrer den delen heime på testa infrastruktur.
Dette skiljet er akkurat slik AI-POS-byggjarar som Final sine er oppbygde: AI-en utformar betalingsflytane dine, medan lager, rapportering og betalingar køyrer på førehandsbygde skjener han ikkje kan ødelegge. Dersom du vil sjå korleis dette fungerer i praksis, kan du byrje med å byggje din første flyt eller lese gjennomgangen vår av å bruke ChatGPT til å byggje ein tilpassa POS.
Ofte stilte spørsmål
Kva er vibe-coding?
Vibe-coding betyr å beskrive programvara du vil ha i vanleg språk og la ein AI skrive koden, der du i stor grad godtek resultatet i tillit. Omgrepet skaut fart i 2025 og dekkjer no verktøy som Lovable, Replit og v0, i tillegg til koding direkte med ein chat-robot.
Kan AI byggje eit komplett POS-system frå ein prompt?
Det kan byggje det synlege laget: betalingsskjermen, produktkatalogen og handlekorglogikken. Delane ei bedrift er avhengig av, som nøyaktig lagerhald under belastning, rapportar som stemmer overeens, og regelverksetterlevande kortbetalingar, krev testa handelsinfrastruktur under AI-en.
Er vibe-koda programvare trygg for å ta imot kortbetalingar?
Ikkje i seg sjølv. Kortbetalingar krev PCI-etterleving (tryggleiksreglar for kortdata), og fysiske kortbetalingar krev sertifisert terminalmaskinvare. Ingen av delane kan genererast av ein prompt, og det er grunnen til at vibe-koda betalingsappar rutinemessig blir avviste frå appbutikkar.
Kva er forskjellen på eit demo-POS og eit produksjons-POS?
Ein demo treng berre å fungere éin gong, medan du ser på. Eit produksjons-POS må vere korrekt kvar einaste gong utan at nokon følgjer med: to samtidige sal må ikkje føre til oversal av varer, og kvar rapport må stemme med pengane som faktisk blei flytta.