Fra prompt til kasse: Beskrive et POS på helt vanlig norsk

Å beskrive et POS på helt vanlig norsk fungerer, men bare hvis du beskriver bedriften din i stedet for programvaren. De beste beskrivelsene lyder som om du lærer opp en nyansatt på deres første skift: dette er hva vi selger, dette er hvordan folk betaler, dette er hva det må stå på kvitteringen. En prompt-basert bygger kan gjøre en slik beskrivelse om til en kasse du faktisk kan gjennomføre et ekte salg på. Om du ender opp med et fungerende kasseapparat eller en pen demo koker ned til fem detaljer, og ingen av dem er tekniske.

Hvordan høres en POS-beskrivelse på vanlig norsk ut?

Det høres ut som deg, en tirsdag formiddag, som viser noen disken:

«Jeg driver et bakeri med én kasse. Vi selger brød, bakverk og traktekaffe. Bakverk selges enkeltvis eller som halvsnese. Kaffe leveres i to størrelser med valgfri melk. Nesten alle taster eller tapper kort, men vi tar også kontanter. Hele brød er fritatt for MVA her; alt annet har merverdiavgift. Kundene vil som regel ha kvitteringen på e-post.»

Ingen funksjonsnavn, ingen skjermbeskrivelser. Sju setninger som bærer hele betalingspunktet i butikken: katalogen, valgene, betalingsmetodene, skattereglene og kvitteringen. En bygger kan jobbe med det. Det den derimot ikke kan jobbe med, er «lag et moderne POS for et bakeri», som beskriver en stemning, ikke en bedrift.

Hvilke fem detaljer avgjør om kassen fungerer?

De en nyansatt ville spurt om før lunsj. Dekk hver enkelt med dine egne ord:

• Hva du selger og hvordan det er gruppert. Ikke hver enkelt vare, bare struktureringen av katalogen: kategoriene dine, og om varene har valg som størrelse eller tillegg. Et POS kaller disse valgene modifikatorer, og å utelate dem er den vanligste årsaken til at det første utkastet føles feil i kassen.

• Hvordan folk betaler. Kort, kontanter eller begge deler, og om tips er en del av hverdagen bak disken.

• Skattereglene dine slik du faktisk bruker dem. Ikke lovteksten, men butikkens virkelighet: hva det skal beregnes MVA på, hva som er fritatt, og om avgifter er inkludert i hylleprisen eller legges til i kassen.

• Hva kvitteringen må inneholde. E-post, utskrift eller begge deler, pluss alt som må være med, som organisasjonsnummer eller returpolicy.

• Unntakene. Pant, varer som veies, ansattrabatter, stammisen som betaler i slutten av måneden. Én setning på hver er nok. En kasse som håndterer et vanlig salg, men ikke de spesielle tilfellene dine, blir forkastet innen en uke. Det gjør unntakene til de mest verdifulle setningene i hele beskrivelsen.

Hva kan ikke vanlig norsk gjøre?

En beskrivelse bestemmer virkemåten; den kan ikke sørge for at maskineriet under er korrekt. Lagerbeholdning som holder seg nøyaktig når to salg treffer samme vare samtidig, dagsrapporter som stemmer overens (samsvarer med pengene som faktisk ble flyttet), MVA lagt til på samme måte ved det tusende salget som ved det første, og kortbetalinger som oppfyller PCI-reglene (sikkerhetsstandarden i kortbransjen) er ikke ting en setning kan gi deg. Plattformen beskrivelsen din havner på, tilbyr enten dette, eller så gjør den det ikke.

Det er her «gjør-det-selv»-forsøk stopper opp. En KI-kodegenerator vil lage overbevisende kasseskjermer fra de samme sju setningene, og resultatet ser riktig ut helt til ekte penger og ekte varer treffer systemet. Vi har kartlagt hvor den veggen treffes i vibe-koding av et POS og i hvorfor en ledende kodemodell fortsatt ikke kan levere et fungerende POS på egen hånd. Vanlig norsk er en komplett spesifikasjon for de delene av et POS du kan se. Noen må fortsatt ha bygget delene du ikke ser.

Hvordan forbedrer du det første utkastet?

På samme måte som du ville korrigert den nyansatte: spesifikt og én ting om gangen. Gjennomfør et testsalg så snart du har en forhåndsvisning, først den vanligste bestillingen din, og deretter den merkeligste. Når noe er feil, retter du det opp med en enkel setning («halvsnese bør spørre om hvilke seks bakverk») i stedet for å beskrive hele butikken på nytt. Hvis det er selve skjermen som må bearbeides, kan du bruke prompteksempler som gir gode POS-layouter; å beskrive transaksjonen i stedet for skjermen gjør mesteparten av jobben.

Hos Final er denne prosessen en chat: beskriv, forhåndsvis, korriger, publiser – der hver endring lagres som et gjenopprettingspunkt du kan rulle tilbake til. Steg-for-steg-veiledningen finner du i slik bygger du din første flyt, og hvis du heller vil bli i et KI-verktøy du allerede bruker, kan du koble til din egen KI over MCP (en standardmåte å koble KI-verktøy til annen programvare på) og bygge mot den samme live-forhåndsvisningen. Det finnes en lengre artikkel om hvorfor prompting erstattet visuelle byggere hvis du er nysgjerrig på hvordan vi havnet her.

Så, kan vanlig norsk virkelig ta deg fra prompt til kasse?

Ja. En beskrivelse som dekker katalogen, betalingsmetodene, skattereglene, kvitteringen og unntakene, er en komplett spesifikasjon for salgspunktet i butikken, og en prompt-basert bygger kan gjøre den om til en fungerende kasse samme dag. Det ingen beskrivelse kan levere, er handelsinfrastrukturen under panseret, så rett setningene dine mot en plattform der den delen allerede eksisterer. Tommelfingerregelen: beskriv disken din slik du ville lært opp en nyansatt, og la plattformen ta seg av alt en nyansatt aldri ser.

Hvis du vil se en beskrivelse bli til et fungerende kasseapparat, er Slik kommer du i gang med Build femminuttersversjonen.