Claude Opus 5 kan kode i timer på egen hånd. Hvilke deler av et POS krever fortsatt mer enn kode?

Delene av et POS som fortsatt krever mer enn kode er de som berører penger og den fysiske verdenen: avtaler om betalingsbehandling, PCI-samsvar (kortbransjens sikkerhetsregler for håndtering av kortdata), sertifiserte terminaler for fysiske kort og registreringer som må være nøyaktige hver eneste gang. Claude Opus 5, lansert 24. juli 2026, kan kjøre kodesesjoner i timevis med minimalt tilsyn¹. Ingen av disse timene oppretter en brukerstedsavtale.

Modellversjoner og datoer i dette innlegget er nøyaktige ved publisering; ta enkelthetene som et øyeblikksbilde.

Hva endret egentlig Claude Opus 5?

Anthropic beskriver en modell bygd for agenter som kjører over lang tid: Den planlegger grundig, verifiserer sitt eget arbeid og kjører lenger og mer autonomt enn tidligere Opus-modeller². På Anthropics tøffeste ytelsestest for programvareutvikling mer enn doblet den poengsummen til forgjengeren¹. Tidlige testere rapporterer at de gir den oppgaver som tidligere måtte deles opp i mange små biter, og får komplette resultater tilbake.

Dette er et reelt skifte, og det forsterker et mønster vi dekket da GPT-5.6 ble lansert: Hver par måneder øker mengden fungerende programvare du får fra én enkelt prompt. Et kassegrensesnitt som tok en uke med prompting i fjor, tar en ettermiddag nå, og med Opus 5 fortsetter modellen å jobbe etter at du har gått fra den.

Hvorfor fullfører ikke mer kodetid jobben?

Fordi de vanskeligste delene av et kassesystem ikke er kodeformede problemer. En autonom modell produserer mer kode, og bedre kontrollert kode. Den kan ikke produsere en godkjenningsbeslutning fra en innløser, en maskinvaresertifisering eller en sikkerhetsrevisjon, uansett hvor lenge den kjører. De kommer fra institusjoner, ikke fra kompilatorer.

Det finnes en annen og mer subtil grense. Opus 5s viktigste ferdighet er å verifisere sitt eget arbeid, og verifisering krever en fasit fra den virkelige verden. En modell kan teste at matematikken i kassen stemmer. Den kan ikke teste mot et reelt kortnettverk, en reell oppgjørsplan (når kortmidlene faktisk når banken din) eller en reell skattemyndighet, for ingenting av dette finnes i et sandkasse miljø for koding. Kode kan være perfekt konsistent i seg selv, og likevel møte virkeligheten for første gang på disken din.

Hvilke deler av et POS krever fortsatt mer enn kode?

Hovedsakelig fire.

• Å flytte penger. Å belaste et kort krever et forhold til en betalingsbehandler (selskapet som gjør opp kortmidler til banken din): risikovurdering, utbetalingsplaner, overvåking av svindel, håndtering av tvister. Ingen kodesesjon leverer en godkjent brukerstedsavtale.

• Sikkerhet for kortdata. PCI-samsvar gjelder for alle systemer som berører kortnumre. Generert kassekode som håndterer kortdata legger denne revisjonsbyrden på deg; sertifisert betalingsinfrastruktur finnes nettopp for at selgere skal slippe dette ansvaret.

• Utstyr for fysisk kortbetaling. Tæpping og chip-betalinger kjører på sertifiserte terminaler med sikker fastvare som ingen får skrive ad hoc. Det er den samme veggen som gjør at vibe-kodede betalingsapper blir avvist fra App Store: Hinderne er rettigheter og sertifiseringer, ikke kadekvalitet.

• Registreringer som må stemme hver gang. Lagerbeholdning som tåler to samtidige salg, og rapporter som stemmer overens (matcher pengene som faktisk kom inn), er teknisk sett kode, men kode som må være riktig for alltid. Vi kartla den veggen i Vibe Coding a Point of Sale. Opus 5 skriver denne typen kode bedre enn noen modell før den; du vil likevel ikke at den første testen i produksjon skal være under lørdagsrushet.

Så hva bør du la Claude Opus 5 bygge?

Alt over den linjen: visningene, flyten, logikken, den bransjespesifikke oppførselen som gjør at et POS passer til virksomheten din i stedet for en mal. Det laget er kode, og Opus 5 er nå uten tvil det sterkeste verktøyet som er tilgjengelig for det.

Den praktiske veien er MCP (Model Context Protocol, den åpne standarden som lar AI-verktøy koble seg til annen programvare). I stedet for å be modellen om å bygge opp betalinger fra bunnen av, kobler du den til en plattform der pengeflyt, maskinvaresertifisering og regelverkssamsvar allerede finnes, og lar den bygge kassen oppå det. Vi har tidligere skrevet om forskjellen mellom plattformer en AI kan betjene, og plattformer en AI kan bygge på; autonome modeller gjør den andre kategorien langt viktigere, fordi modellen nå kan drive en bygging langt uten deg.

Finals Build fungerer på denne måten: Byggeren er prompt-basert, du beskriver flyten du ønsker eller kobler til din egen AI over MCP, og flyten rulles ut på infrastruktur der Final Pay, sertifiserte terminaler og den underliggende registreringen allerede er håndtert. Hvordan du bruker Claude Fable 5 til å bygge et fungerende POS gjennomgår hvordan det ser ut med Opus 5s større søsken.

Så, hvilke deler av et POS krever fortsatt mer enn kode?

De som ender i en avtale, en sertifisering eller en utbetaling: betalingsbehandling, PCI-samsvar og utstyr for fysisk kortbetaling, pluss registreringer som må være riktige hver gang. Claude Opus 5 endret hvor mye POS du kan få ut av en kodesesjon. Den endret ikke hva en kodesesjon kan levere. En nyttig tommelfingerregel: Hvis oppgaven slutter med kode, gi den til modellen; hvis den slutter med en avtale, en sertifisering eller flytting av penger, gi den til infrastrukturen.

Hvis du vil se hvor grensen går i praksis, kan du koble din egen AI til Build over MCP og la modellen gjøre den delen den nå er veldig god på.