Kva AI gjer feil når han designar ei utsjekking (og korleis du fiksar det)

AI gjer éin føreseieleg feil når han designar ei utsjekking: han designar for demoen, ikkje for den ti-tusenande transaksjonen. Spør ein AI-appbyggjar om ei utsjekking, og du får noko overtydande på få minutt. Rein handlekorg, ryddige knappar, ein sjølvsikker betalingsskjerm. Feila ligg i alt ein skjermdump ikkje kan vise: korleis flyten handterer ein refusjon, ei delt betaling, ein skatteregel eller ein kø av kundar klokka tolv på ein laurdag.

Løysinga er ikkje betre prompting. Det handlar om å avgjere kva delar av utsjekkinga AI-en skal eige, og kva delar han aldri skal få lov til å improvisere. Her er der AI-genererte utsjekkingar faktisk sviktar, og kva du skal gjere med kvar av dei.

Kvifor ser ei AI-designa utsjekking rett ut, men sviktar i bruk?

To grunnar. For det første lærer AI utsjekkingsdesign frå eksisterande utsjekkingar, og eksisterande utsjekkingar er middelmåtige. Baymard Institute reknar ut at den gjennomsnittlege dokumenterte avbrotsprosenten for handlekorger på nett er 70,22 %¹, og finn at ei gjennomsnittleg amerikansk utsjekking viser 23,48 skjemaelement der ein ideell flyt treng 12 til 14¹. Ein modell som er trena på gjennomsnittet, reproduserer gjennomsnittet, inkludert feila.

For det andre: solskinsscenario-bias (happy-path bias). Generert programvare blir vurdert på same måte som ein demo: fungerer normalsituasjonen? Ei utsjekking blir vurdert på same måte som eit kassaapparat: fungerer alle tilfelle, kvar gong, medan ein kunde ser på? Dette er heilt ulike krav, og gapet mellom dei er usynleg fram til ekte pengar strøymer gjennom systemet.

Kva gjer AI eigentleg feil i ei utsjekking?

Fem feil viser seg om og om igjen. (For det djupare infrastrukturgapet bak dei, sjå Kan du byggje ein POS med Lovable eller Replit? Denne lista handlar om sjølve utsjekkinga.)

• Pengematematikk. Generert kode gjer rutinemessig valutarekning med flyttal (desimalmatematikk som rundar av uføreseieleg), slik at øre byrjar å sprike over rabattar, skattar og delte betalingar. Symptomet viser seg ved dagsavslutning: totalsummar som ikkje lèt seg avstemme (stemmer på øret) mot dagsrapporten din.

• Skattar og avgifter. AI hardkodar éin sats. Reell meirverdiavgift avheng av jurisdiksjon, varetype, fritak og datoar, og ho endrar seg utan å gje beskjed til koden din. Ei utsjekking som gjettar på moms, er ikkje ei utsjekking; det er ein risiko med eit fint grensesnitt.

• Dei vanskelege tilfella (unhappy paths). Refusjonar, annulleringar, delbetalingar, prisoverstyringar, eit brot i sambandet midt under ei belastning. Demoar testar aldri dette; butikkdiskar møter det dagleg. Dei fleste AI-genererte utsjekkingar manglar dette heilt.

• Kassahastigheit. AI kopierer e-handelsmønster som er bygde for ein kunde som sjekkar ut éin gong. Ein kassamedarbeidar køyrer den same flyten hundrevis av gonger i løpet av ei vakt, så kvart ekstra trykk samlar seg opp til køtid. Sjølv små val endrar dynamikken ved disken; kor tipsvarslinga ligg er ei heil avgjerd i seg sjølv.

• Betalingar. Ein betalingsknapp er ikkje ei betaling. Å ta imot kort fysisk krev ein betalingsformidlar, PCI-samsvar (sikkerheitsreglane til kortbransjen) og sertifisert kortlesarmaskinvare. Ingenting av dette kan genererast frå ein tekstinstruksjon; det må vere på plass. Kva betalingsinfrastruktur faktisk omfattar er meir omfattande enn dei fleste forventar.

Korleis fiksar du ei AI-designa utsjekking?

Del jobben i to. AI er genuint god på designdelen: oppsett, rekkjefølgje i flyten, ordlyd og å forme skjermen rundt korleis butikken din faktisk sel. Lat han eige det. Pengedelen (rekning, skattar, betalingsbehandling, transaksjonslogg) bør kome frå ein handelsinfrastruktur som er deterministisk (han gjev det same, korrekte svaret kvar gong), ikkje frå kode som blir funnen på per tekstinstruksjon.

«Berre instruer han til å handtere moms korrekt» løyser ikkje dette, fordi du ikkje kan sjå om det fungerte berre ved å kike på det. Ei utsjekking kan rekne feil med nokre få øre per transaksjon i månader før nokon merkar det. Så løysinga er strukturell:

• Set grenser i staden for å bruke prompting. Bruk ei plattform der totalsummar, moms og betalingsmidlar er innebygde, og AI-en berre kan plassere dei, ikkje finne dei opp på nytt.

• Test dei vanskelege tilfella før lansering. Køyr ein refusjon, ei annullering, ei delt betaling og eit avbrot midt i ei belastning. Dersom noko av dette manglar, har du ein demo, mot ein kasse.

• Avstem på dag éin. Samanlikna totalsummane frå utsjekkinga di med rapportane frå betalingsformidlaren etter den første reelle salsdagen. Øreavvik viser seg med ein gong eller ikkje i det heile.

• Hald auge med omvegar. Dersom dei tilsette finn opp eigne snarvegar utanom flyten i veke éin, har designet svikta. Fiks det før omvegane blir sjølve systemet.

Så, kva gjer AI feil når han designar ei utsjekking?

Han får biletet rett, men røyropplegget feil: solskinsscenario-flytar, improvisert pengematematikk, gjetta moms og inga løysing for refusjonar, delte betalingar eller fysiske kortbetalingar. Ingenting av dette blir løyst av ein betre tekstinstruksjon; det blir løyst ved å leggje AI-en på toppen av ein infrastruktur som allereie handterer pengane. Tommelfingerregelen: lat AI designe flyten, aldri lat han improvisere med pengane.

Dette skillet er ideen bak tekstbaserte byggjarar som Final sitt Build, der du beskriv utsjekkinga du vil ha, og totalsummane, momsen og Final Pay-transaksjonane under kjem frå eit system som alltid reknar rett. For å sjå det i praksis, bygg din første flyt på rundt ti minutt, eller zoom ut med AI for bedrifter: Kva det kan (og ikkje kan) gjere.