Claude Opus 5 Can Code for Hours on Its Own. Which Parts of a POS Still Need More Than Code?

The parts of a POS that still need more than code are the ones that touch money and the physical world: payment processing agreements, PCI compliance (the card industry's security rules for handling card data), certified card-present terminals, and record-keeping that has to be right every single time. Claude Opus 5, released July 24, 2026, can run coding sessions for hours with minimal oversight¹. None of those hours produce a merchant account.

Model versions and dates in this post are accurate as of publication; treat the specifics as a snapshot.

What did Claude Opus 5 actually change?

Anthropic describes a model built for long-running agents: it plans deliberately, verifies its own work, and runs longer and more autonomously than previous Opus models². On Anthropic's hardest software engineering benchmark it more than doubled its predecessor's score¹. Early testers report handing it work that used to be broken into many small pieces and getting complete results back.

That is a real shift, and it compounds a pattern we covered when GPT-5.6 shipped: every few months, the amount of working software you get from one prompt grows. A checkout interface that took a week of prompting last year takes an afternoon now, and with Opus 5, the model keeps going after you walk away.

Why doesn't more coding time finish the job?

Because the hardest parts of a point of sale are not code-shaped problems. An autonomous model produces more code, and better-checked code. It cannot produce an underwriting decision, a hardware certification, or a security audit, no matter how long it runs. Those come from institutions, not from compilers.

There is a second, subtler limit. Opus 5's headline skill is verifying its own work, and verification needs ground truth. A model can test that its checkout math adds up. It cannot test against a real card network, a real settlement schedule (when card funds actually reach your bank), or a real tax authority, because none of those exist inside a coding sandbox. Code can be perfectly self-consistent and still meet reality for the first time on your counter.

Which parts of a POS still need more than code?

Four, mainly.

• Moving money. Charging a card requires a relationship with a payment processor (the company that settles card funds to your bank): underwriting, payout schedules, fraud monitoring, dispute handling. No coding session outputs an approved merchant account.

• Card-data security. PCI compliance applies to any system that touches card numbers. Generated checkout code that handles card data puts that audit burden on you; certified payment infrastructure exists precisely to keep merchants out of scope.

• Card-present hardware. Tap and chip payments run on certified terminals with secure firmware nobody gets to write ad hoc. It is the same wall that gets vibe-coded payment apps rejected from the App Store: the blockers are entitlements and certifications, not code quality.

• Correct-every-time records. Inventory that survives two simultaneous sales and reports that reconcile (match the money that actually arrived) are technically code, but code that has to be right forever. We mapped that wall in Vibe Coding a Point of Sale. Opus 5 writes this kind of code better than any model before it; you still do not want its first production test to be your Saturday rush.

So what should you let Claude Opus 5 build?

Everything above that line: the screens, the flow, the logic, the industry-specific behavior that makes a POS fit your business instead of a template. That layer is code, and Opus 5 is now arguably the strongest tool available for it.

The practical route is MCP (Model Context Protocol, the open standard that lets AI tools plug into other software). Instead of asking the model to rebuild payments from scratch, you connect it to a platform where money movement, hardware certification, and compliance already exist, and let it build the checkout on top. We have written before about the difference between platforms an AI can operate and platforms an AI can build on; autonomous models make the second category matter far more, because the model can now carry a build a long way without you.

Final's Build works this way: the builder is prompt-based, you describe the flow you want or connect your own AI over MCP, and the flow deploys onto infrastructure where Final Pay, certified terminals, and the record-keeping underneath are already handled. How to use Claude Fable 5 to build a working POS walks through what that looks like with Opus 5's bigger sibling.

So, which parts of a POS still need more than code?

The ones that end in an agreement, a certification, or a payout: payment processing, PCI compliance, and card-present hardware, plus records that must be correct every time. Claude Opus 5 changed how much POS you can get from a coding session. It did not change what a coding session can produce. A useful rule of thumb: if the task ends with code, hand it to the model; if it ends with an agreement, a certification, or money moving, hand it to infrastructure.

If you want to see where the line sits in practice, connect your own AI to Build over MCP and let the model do the part it is now very good at.