Claude Opus 5 kan koda i timmar på egen hand. Vilka delar av ett POS kräver fortfarande mer än kod?

De delar av ett POS som fortfarande kräver mer än kod är de som berör pengar och den fysiska världen: inlösenavtal för betalningar, PCI-efterlevnad (kortbranschens säkerhetsregler för hantering av kortdata), certifierade terminaler för fysiska kortbetalningar samt bokföring som måste vara rätt varje enskild gång. Claude Opus 5, som släpptes den 24 juli 2026, kan köra kodningssessioner i timmar med minimal tillsyn¹. Ingen av dessa timmar skapar ett inlösensavtal.

Modellversioner och datum i det här inlägget är korrekta vid publiceringen; se specifikationerna som en ögonblicksbild.

Vad förändrade egentligen Claude Opus 5?

Anthropic beskriver en modell byggd för agenter med långa körningstider: den planerar medvetet, verifierar sitt eget arbete och körs längre och mer autonomt än tidigare Opus-modeller². På Anthropic svåraste riktmärke för mjukvaruteknik mer än fördubblade den föregångarens resultat¹. Tidiga testare rapporterar att de ger den arbete som tidigare var tvunget att delas upp i många små delar och får tillbaka färdiga resultat.

Det är ett reellt skifte, och det bygger vidare på ett mönster vi tog upp när GPT-5.6 lanserades: med några månaders mellanrum växer mängden fungerande mjukvara du får från en enda prompt. Ett kassagränssnitt som tog en vecka av promptande förra året tar en eftermiddag nu, och med Opus 5 fortsätter modellen att arbeta efter att du gått därifrån.

Varför gör mer kodningstid inte färdigt jobbet?

Eftersom de svåraste delarna av en kassalösning inte är kodformade problem. En autonom modell skapar mer kod, och bättre kontrollerad kod. Den kan inte skapa ett riskbedömningsbeslut, en maskinvarucertifiering eller en säkerhetsrevision, oavsett hur länge den körs. De kommer från institutioner, inte från kompilatorer.

Det finns en andra, mer subtil begränsning. Opus 5:s främsta färdighet är att verifiera sitt eget arbete, och verifiering kräver en verklig referenspunkt. En modell kan testa att dess beräkningar i kassan stämmer. Den kan inte testa mot ett riktigt kortnätverk, en riktig utbetalningsplan (när kortmedel faktiskt når din bank) eller en riktig skattemyndighet, eftersom inget av det finns i en sandlåda för kodning. Kod kan vara helt koherent i sig själv och ändå möta verkligheten för första gången på din disk.

Vilka delar av ett POS kräver fortfarande mer än kod?

Huvudsakligen fyra.

• Flytta pengar. Att ta emot en kortbetalning kräver en relation med en betalleverantör (företaget som för över kortmedel till din bank): riskbedömning, utbetalningsplaner, bedrägeribevakning, testhantering av tvister. Ingen kodningssession skapar ett godkänt inlösensavtal.

• Säkerhet för kortdata. PCI-efterlevnad gäller för alla system som hanterar kortnummer. Genererad kassakod som hanterar kortdata lägger hela granskningsbördan på dig; certifierad betalningsinfrastruktur finns just för att ta handlarna ur den kravramen.

• Maskinvara för fysiska kort. Blipp- och chipbetalningar körs på certifierade terminaler med säker mjukvara som ingen får skriva ad hoc. Det är samma vägg som gör att vibe-kodade betalningsappar blir avvisade från App Store: hindren är tillstånd och certifieringar, inte kodkvalitet.

• Dokumentation som alltid stämmer. Ett lagerutbud som klarar två samtidiga köp och rapporter som stämmer överens (matchar pengarna som faktiskt kom in) är tekniskt sett kod, men kod som måste stämma för alltid. Vi kartlade den väggen i Vibe Coding a Point of Sale. Opus 5 skriver den typen av kod bättre än någon modell före den; du vill ändå inte att dess första skarpa test ska vara under din lördagsrusning.

Så vad ska du låta Claude Opus 5 bygga?

Allt ovanför den gränsen: skärmarna, flödet, logiken, det branschspecifika beteendet som gör att ett POS passar din verksamhet istället för en mall. Det lagret är kod, och Opus 5 är nu förmodligen det starkaste verktyget som finns för det.

Den praktiska vägen är MCP (Model Context Protocol, den öppna standarden som låter AI-verktyg anslutas till annan mjukvara). Istället för att be modellen bygga om betalningar från grunden ansluter du den till en plattform där penningförflyttningar, maskinvarucertifiering och efterlevnad redan finns, och låter den bygga kassan ovanpå det. Vi har tidigare skrivit om skillnaden mellan plattformar som en AI kan driva och plattformar som en AI kan bygga på; autonoma modeller gör att den andra kategorin spelar betydligt större roll, eftersom modellen nu kan driva ett bygge väldigt långt utan dig.

Finals Build fungerar på det sättet: byggaren är promptbaserad, du beskriver flödet du vill ha eller ansluter din egen AI via MCP, och flödet distribueras till en infrastruktur där Final Pay, certifierade terminaler och den underliggande dokumentationen redan hanteras. Hur du använder Claude Fable 5 för att bygga ett fungerande POS går igenom hur det ser ut med Opus 5:s större syskon.

Så, vilka delar av ett POS kräver fortfarande mer än kod?

De som slutar med ett avtal, en certifiering eller en utbetalning: betalningshantering, PCI-efterlevnad och maskinvara för fysiska kort, samt dokumentation som måste vara korrekt varje gång. Claude Opus 5 förändrade hur mycket POS du kan få ut av en kodningssession. Det förändrade inte vad en kodningssession kan skapa. En användbar tumregel: om uppgiften slutar med kod, lämna över den till modellen; om den slutar med ett avtal, en certifiering eller penningförflyttning, lämna över den till infrastrukturen.

Om du vill se var gränsen går i praktiken kan du ansluta din egen AI till Build via MCP och låta modellen göra den del den nu är väldigt bra på.