Claude Opus 5 може кодувати годинами самостійно. Які частини POS все ще потребують більше ніж просто код?

Частини POS, яким усе ще потрібно більше, ніж просто код, — це ті, що пов'язані з грошима та фізичним світом: угоди про обробку платежів, відповідність вимогам PCI (правила безпеки платіжної індустрії щодо обробки даних карток), сертифіковані термінали для фізичних карток і ведення обліку, який має бути точним кожного разу. Claude Opus 5, випущений 24 липня 2026 року, може виконувати сесії кодування годинами з мінімальним контролем¹. Але жодна з цих годин не створить для вас торговий акаунт.

Версії моделей і дати у цій статті є точними на момент публікації; сприймайте специфіку як зріз інформації на поточний момент.

Що насправді змінив Claude Opus 5?

Anthropic описує модель, створену для довготривалих агентів: вона ретельно планує, перевіряє власну роботу та працює довше й автономніше, ніж попередні моделі Opus². На найскладнішому бенчмарку Anthropic із програмної інженерії вона понад удвічі перевищила результат попередника¹. Перші тестувальники повідомляють, що передають моделі завдання, які раніше доводилося розбивати на багато дрібних частин, і отримують готові результати.

Це справжній зсув, який підсилює тенденцію, про яку ми писали під час виходу GPT-5.6: кожні кілька місяців обсяг працюючого програмного забезпечення, отриманого з одного промпту, зростає. Інтерфейс каси, створення якого минулого року вимагало тижня складання підказок, тепер займає один день, а з Opus 5 модель продовжує працювати навіть після того, як ви відійшли від комп'ютера.

Чому збільшення часу кодування не завершує роботу?

Тому що найскладніші частини POS-системи не є задачами у формі коду. Автономна модель створює більше коду й краще перевіреного коду. Проте вона не може видати рішення про андерайтинг, сертифікацію обладнання чи безпековий аудит, незалежно від того, скільки часу вона працює. Ці речі надходять від інституцій, а не від компіляторів.

Є й друге, менш очевидне обмеження. Головна перевага Opus 5 — це перевірка власної роботи, а перевірка потребує наявності еталону. Модель може перевірити, чи сходиться математика замовлення. Проте вона не може виконати перевірку на реальній картковій мережі, у реальному графіку розрахунків (коли кошти за карткою фактично надходять до вашого банку) або в реальному податковому органі, оскільки нічого з цього не існує всередині пісочниці для коду. Код може бути ідеально узгодженим із самим собою, але при цьому вперше зіткнутися з реальністю вже на вашому прилавку.

Які частини POS все ще потребують більше ніж код?

Здебільшого чотири.

• Переказ грошей. Для прийому картки потрібні відносини з платіжним провайдером (компанією, яка зараховує кошти з карток на ваш банківський рахунок): андерайтинг, графіки виплат, моніторинг шахрайства, розгляд спорів. Жодна сесія кодування не видасть схвалений торговий акаунт.

• Безпека даних карток. Відповідність PCI застосовується до будь-якої системи, яка торкається номерів карток. Згенерований код каси, який обробляє дані карток, перекладає цей тягар аудиту на вас; сертифікована платіжна інфраструктура існує саме для того, щоб вивести торговців із цієї зони ризику.

• Обладнання для фізичних карток. Оплати дотиком і чипом працюють на сертифікованих терміналах із захищеною прошивкою, яку нікому не дозволено писати довільно. Це той самий бар'єр, через який платіжні застосунки, створені «на вайбі», відхиляють у App Store: перешкодою є права доступу та сертифікації, а не якість коду.

• Записи, які мають бути точними завжди. Інвентар, який залишається коректним при двох одночасних продажах, і звіти, що зводяться (відповідають реально отриманим грошам), технічно є кодом, але кодом, який має бути правильним завжди. Ми описали цю межу в статті Vibe-кодування POS-системи. Opus 5 пише такий код краще за будь-яку модель до нього; але ви все одно не захочете, щоб його першим робочим тестом стала суботня година пік.

Тож що варто дозволити будувати Claude Opus 5?

Усе, що знаходиться вище цієї межі: екрани, процес, логіку, специфічну для вашої галузі поведінку, яка робить POS придатною саме для вашого бізнесу, а не просто шаблоном. Цей шар є кодом, і Opus 5 наразі є, мабуть, найсильнішим інструментом для нього.

Практичний шлях — це MCP (Model Context Protocol, відкритий стандарт, що дозволяє інструментам ШІ підключатися до іншого програмного забезпечення). Замість того, щоб просити модель переписати платежі з нуля, ви підключаєте її до платформи, де переказ грошей, сертифікація обладнання та відповідність вимогам уже реалізовані, і дозволяєте їй побудувати процес розрахунку зверху. Ми вже писали про різницю між платформами, якими ШІ може керувати, і платформами, на яких ШІ може будувати; автономні моделі роблять другу категорію набагато важливішою, оскільки модель тепер може вести розробку тривалий час без вашої участі.

Build у Final працює саме так: конструктор працює на основі підказок (промптів), ви описуєте бажаний процес або підключаєте власний ШІ через MCP, а процес розгортається на інфраструктурі, де Final Pay, сертифіковані термінали та облік коштів під ними вже налаштовані. У статті Як використовувати Claude Fable 5 для створення працюючої POS детально описано, як це виглядає на практиці.

Отже, які частини POS все ще потребують більше ніж код?

Ті, що завершуються угодою, сертифікацією або виплатою коштів: обробка платежів, відповідність PCI та обладнання для карток, плюс облік, який має бути точним кожного разу. Claude Opus 5 змінив обсяг POS, який ви можете отримати за один сеанс кодування. Проте він не змінив того, що саме може створити сесія кодування. Корисне правило: якщо завдання закінчується кодом, передайте його моделі; якщо воно закінчується угодою, сертифікацією або рухом грошей, передайте його інфраструктурі.

Якщо ви хочете побачити, де проходить ця межа на практиці, підключіть власний ШІ до Build через MCP і дозвольте моделі зробити ту частину, у якій вона тепер дуже хороша.