O Claude Opus 5 consegue programar por horas sozinho. Quais partes de um POS ainda precisam de mais do que código?

As partes de um POS que ainda exigem mais do que código são aquelas que envolvem dinheiro e o mundo físico: contratos de processamento de pagamento, conformidade PCI (as regras de segurança do setor de cartões para lidar com dados de cartão), terminais presenciais certificados e registros que precisam estar corretos todas as vezes. O Claude Opus 5, lançado em 24 de julho de 2026, pode executar sessões de programação por horas com o mínimo de supervisão¹. Nenhuma dessas horas gera uma conta de comerciante.

As versões dos modelos e datas neste artigo são precisas até o momento da publicação; trate as especificidades como um panorama da época.

O que o Claude Opus 5 realmente mudou?

A Anthropic descreve um modelo desenvolvido para agentes de longa duração: ele planeja de forma deliberada, verifica o próprio trabalho e executa tarefas por mais tempo e de forma mais autônoma do que os modelos Opus anteriores². No teste de referência de engenharia de software mais difícil da Anthropic, ele mais que dobrou a pontuação do seu antecessor¹. Os primeiros testadores relatam ter entregado a ele tarefas que antes eram divididas em vários pequenos trechos e recebido resultados completos de volta.

Essa é uma mudança real e reforça o padrão que abordamos quando o GPT-5.6 foi lançado: a cada poucos meses, a quantidade de software funcional obtido com um único prompt aumenta. Uma interface de checkout que levava uma semana de comandos no ano passado agora leva uma tarde, e com o Opus 5, o modelo continua trabalhando mesmo depois de você se afastar.

Por que mais tempo de programação não conclui o trabalho?

Porque as partes mais difíceis de um ponto de venda não são problemas em forma de código. Um modelo autônomo produz mais código e um código mais verificado. No entanto, ele não pode gerar uma decisão de subscrição, uma certificação de hardware ou uma auditoria de segurança, não importa quanto tempo seja executado. Essas coisas vêm de instituições, não de compiladores.

Existe um segundo limite, mais sutil. O principal destaque do Opus 5 é verificar o próprio trabalho, e a verificação exige dados do mundo real. O modelo pode testar se a matemática do checkout está certa. Ele não pode testar contra uma rede de cartões real, um cronograma de liquidação real (quando os fundos do cartão chegam de fato ao seu banco) ou uma autoridade fiscal real, porque nada disso existe dentro de um ambiente isolado de código (sandbox). O código pode ser perfeitamente coerente consigo mesmo e, ainda assim, encarar a realidade pela primeira vez apenas no seu balcão.

Quais partes de um POS ainda precisam de mais do que código?

Quatro, principalmente.

• Mover dinheiro. Cobrar um cartão exige um relacionamento com um processador de pagamento (a empresa que liquida os fundos do cartão no seu banco): subscrição, prazos de repasse, monitoramento de fraudes, gestão de disputas. Nenhuma sessão de programação gera uma conta de comerciante aprovada.

• Segurança de dados do cartão. A conformidade PCI se aplica a qualquer sistema que manuseie números de cartão. O código de checkout gerado que lida com dados de cartão transfere essa carga de auditoria para você; a infraestrutura de pagamento certificada existe justamente para manter os comerciantes fora desse escopo.

• Hardware para pagamento presencial. Pagamentos por aproximação e chip rodam em terminais certificados com firmware seguro que ninguém pode escrever de forma improvisada. É o mesmo obstáculo que faz com que aplicativos de pagamento criados por vibe coding sejam rejeitados na App Store: os impedimentos são autorizações e certificações, não a qualidade do código.

• Registros que precisam estar corretos todas as vezes. O estoque que resiste a duas vendas simultâneas e relatórios que batem (correspondem ao dinheiro que realmente entrou) são tecnicamente código, mas um código que precisa estar certo para sempre. Mapeamos esse limite em Vibe Coding em um Ponto de Venda. O Opus 5 escreve esse tipo de código melhor do que qualquer modelo anterior; ainda assim, você não vai querer que o primeiro teste em produção dele seja no seu pico de movimento de sábado.

Então o que você deve deixar o Claude Opus 5 construir?

Tudo acima dessa linha: as telas, o fluxo, a lógica, o comportamento específico do setor que faz o POS se adequar ao seu negócio em vez de ser um modelo genérico. Essa camada é código, e o Opus 5 é hoje, sem dúvida, a ferramenta mais forte disponível para isso.

O caminho prático é o MCP (Model Context Protocol, o padrão aberto que permite que ferramentas de IA se conectem a outros softwares). Em vez de pedir ao modelo para reconstruir os pagamentos do zero, você o conecta a uma plataforma onde a movimentação de dinheiro, a certificação de hardware e a conformidade já existem, e o deixa construir o checkout por cima disso. Já escrevemos antes sobre a diferença entre plataformas que uma IA pode operar e plataformas sobre as quais uma IA pode construir; modelos autônomos tornam essa segunda categoria muito mais relevante, porque o modelo agora consegue levar a construção muito adiante sem a sua intervenção.

O Build do Final funciona assim: o construtor é baseado em prompts, você descreve o fluxo desejado ou conecta sua própria IA via MCP, e o fluxo é implantado em uma infraestrutura na qual o Final Pay, as maquininhas certificadas e o controle de registros na camada inferior já estão resolvidos. O artigo Como usar o Claude Fable 5 para construir um POS funcional explica detalhadamente como é esse processo com o irmão maior do Opus 5.

Afinal, quais partes de um POS ainda precisam de mais do que código?

Aquelas que terminam em um contrato, em uma certificação ou em um repasse financeiro: processamento de pagamentos, conformidade PCI e hardware para pagamento presencial, além dos registros que devem estar corretos todas as vezes. O Claude Opus 5 mudou a quantidade de POS que você pode obter a partir de uma sessão de código. Ele não mudou o tipo de coisa que uma sessão de código é capaz de produzir. Uma boa regra de ouro: se a tarefa termina em código, entregue-a ao modelo; se termina em um contrato, uma certificação ou movimentação de dinheiro, entregue-a à infraestrutura.

Se quiser ver na prática onde fica esse limite, conecte sua própria IA ao Build via MCP e deixe o modelo fazer a parte em que se tornou muito bom.