Claude Opus 5 potrafi samodzielnie pisać kod przez wiele godzin. Które elementy POS wciąż wymagają czegoś więcej niż kod?

Elementy systemu POS, które nadal wymagają czegoś więcej niż kod, to te, które dotykają pieniędzy i świata fizycznego: umowy o przetwarzanie płatności, zgodność z PCI (zasady bezpieczeństwa branży kart płatniczych dotyczące przetwarzania danych kart), certyfikowane terminale do płatności fizycznych oraz prowadzenie dokumentacji, która musi być bezbłędna za każdym razem. Claude Opus 5, wydany 24 lipca 2026 r., może prowadzić sesje kodowania przez wiele godzin przy minimalnym nadzorze¹. Żadna z tych godzin nie utworzy jednak konta kupieckiego (merchant account).

Wersje modeli i daty w tym wpisie są dokładne na dzień publikacji; podane szczegóły należy traktować jako stan na dany moment.

Co tak naprawdę zmienił Claude Opus 5?

Firma Anthropic opisuje model stworzony z myślą o długo działających agentach: planuje w sposób przemyślany, weryfikuje własną pracę oraz działa dłużej i bardziej autonomicznie niż poprzednie modele Opus². W najtrudniejszym teście inżynierii oprogramowania firmy Anthropic uzyskał ponad dwukrotnie wyższy wynik niż jego poprzednik¹. Pierwsi testerzy zgłaszają, że powierzają mu zadania, które wcześniej trzeba było dzielić na wiele małych etapów, i otrzymują kompletne rezultaty.

To prawdziwa zmiana, która umacnia trend omówiony przez nas przy okazji premiery GPT-5.6: co kilka miesięcy ilość działającego oprogramowania uzyskiwana z jednego promptu rośnie. Interfejs kasy, którego tworzenie za pomocą promptów zajmowało w zeszłym roku tydzień, teraz zajmuje jedno popołudnie, a w przypadku Opus 5 model pracuje dalej nawet wtedy, gdy odejdziesz od komputera.

Dlaczego dłuższy czas kodowania nie kończy zadania?

Ponieważ najtrudniejsze elementy punktu sprzedaży nie są problemami w postaci kodu. Autonomiczny model generuje więcej kodu i lepiej go weryfikuje. Nie potrafi jednak wydać decyzji o ocenie ryzyka (underwritingu), uzyskać certyfikacji sprzętowej ani przeprowadzić audytu bezpieczeństwa, niezależnie od tego, jak długo pracuje. Te rzeczy pochodzą od instytucji, a nie z kompilatorów.

Istnieje drugie, subtelniejsze ograniczenie. Główną umiejętnością Opus 5 jest weryfikacja własnej pracy, a weryfikacja wymaga punktu odniesienia do rzeczywistości (ground truth). Model może sprawdzić, czy obliczenia przy kasie się zgadzają. Nie może jednak przeprowadzić testu z rzeczywistą siecią kart płatniczych, realnym harmonogramem rozliczeń (gdy środki z kart faktycznie trafiają do Twojego banku) ani z organem podatkowym, ponieważ żaden z nich nie istnieje wewnątrz piaskownicy programistycznej. Kod może być idealnie spójny wewnętrznie, a i tak zderzy się z rzeczywistością po raz pierwszy dopiero przy Twojej ladzie.

Które elementy POS wciąż wymagają czegoś więcej niż kod?

Głównie cztery.

• Przepływ pieniędzy. Obciążenie karty wymaga relacji z operatorem płatności (firmą, która rozlicza środki z kart na Twoim koncie bankowym): oceny ryzyka, harmonogramów wypłat, monitorowania oszustw i obsługi sporów. Żadna sesja kodowania nie wygeneruje zatwierdzonego konta kupieckiego.

• Bezpieczeństwo danych kart. Zgodność z PCI dotyczy każdego systemu przetwarzającego numery kart. Wygenerowany kod kasy przetwarzający dane kart przerzuca ten ciężar audytowy na Ciebie; certyfikowana infrastruktura płatnicza istnieje właśnie po to, by wyłączyć sprzedawców z tego zakresu.

• Sprzęt do płatności fizycznych kartą. Płatności zbliżeniowe i chipowe działają na certyfikowanych terminalach z bezpiecznym oprogramowaniem układowym (firmware), którego nikt nie pisze ad hoc. To ta sama ściana, o którą rozbijają się aplikacje płatnicze tworzone przez vibe coding odrzucane z App Store: przeszkodami są uprawnienia i certyfikaty, a nie jakość kodu.

• Bezblędna dokumentacja za każdym razem. Stany magazynowe przetrzymujące dwie jednoczesne transakcje sprzedaży oraz raporty, które się zgadzają (odpowiadają pieniądzom, które faktycznie wpłynęły), to technicznie kod, ale kod, który musi być bezbłędny zawsze. Opisaliśmy tę barierę w artykule Vibe Coding w systemach POS. Opus 5 pisze tego typu kod lepiej niż jakikolwiek model przed nim, ale nadal nie chcesz, aby jego pierwszy test produkcyjny odbył się podczas sobotniego szczytu w Twoim sklepie.

Co zatem warto pozwolić zbudować Claude Opus 5?

Wszystko powyżej tej linii: ekrany, przepływ, logikę oraz specyficzne dla branży zachowania, które sprawiają, że POS pasuje do Twojej firmy, a nie jest gotowym szablonem. Ta warstwa to kod, a Opus 5 jest obecnie bez wątpienia najpotężniejszym dostępnym do tego narzędziem.

Praktyczną drogą jest MCP (Model Context Protocol, otwarty standard pozwalający narzędziom AI łączyć się z innym oprogramowaniem). Zamiast prosić model o odbudowywanie płatności od zera, łączysz go z platformą, na której przepływ pieniędzy, certyfikacja sprzętu i zgodność z przepisami już istnieją, i pozwalasz mu zbudować kasę na tej bazie. Pisaliśmy już wcześniej o różnicy między platformami, którymi AI może sterować, a platformami, na których AI może budować; autonomiczne modele sprawiają, że ta druga kategoria zyskuje znacznie na znaczeniu, ponieważ model może teraz samodzielnie poprowadzić proces tworzenia bez Twojego udziału.

Generator Build w Final działa właśnie w ten sposób: narzędzie opiera się na promptach, opisujesz żądany przepływ lub podłączasz własne AI przez MCP, a przepływ jest wdrażany na infrastrukturze, gdzie Final Pay, certyfikowane terminale i podległa dokumentacja są już obsłużone. Artykuł Jak użyć Claude Fable 5 do zbudowania działającego POS-a pokazuje, jak to wygląda w praktyce z większym bratem modelu Opus 5.

Które więc elementy POS wciąż wymagają czegoś więcej niż kod?

Te, które kończą się umową, certyfikatem lub wypłatą środków: przetwarzanie płatności, zgodność z PCI i sprzęt do płatności fizycznych, a także dokumentacja, która musi być bezbłędna za każdym razem. Claude Opus 5 zmienił to, jak dużą część POS-a można uzyskać z sesji kodowania. Nie zmienił jednak tego, co sesja kodowania może wytworzyć. Przydatna zasada: jeśli zadanie kończy się kodem, przekaż je modelowi; jeśli kończy się umową, certyfikatem lub przepływem pieniędzy, przekaż je infrastrukturze.

Jeśli chcesz zobaczyć, gdzie w praktyce przebiega ta granica, podłącz własne AI do Build przez MCP i pozwól modelowi wykonać część, w której jest obecnie świetny.