Skip to main content
POS17 lipca 2026· Mathias Nielsen

ChatGPT-5.6 od OpenAI potrafi stworzyć aplikację internetową w kilka godzin — czy potrafi zbudować działający POS?

GPT-5.6 bez problemu tworzy gry żeglarskie za pierwszym podejściem i bije wszelkie rekordy w testach kodowania. Jednak działający punkt sprzedaży to zupełnie inny problem — a powód tego mówi wiele o tym, co sztuczna inteligencja potrafi, a czego nie potrafi wygenerować.

Holograficzny schemat AI ekranu kasowego unoszący się nad niepodłączonym fizycznym sprzętem POS — terminalem płatniczym, drukarką pokwitowań i szufladą kasową

Firma OpenAI wydała GPT-5.6 9 lipca — trzy nowe modele, rekordy w niemal każdym benchmarku kodowania i fala imponujących wersji demonstracyjnych w ciągu zaledwie kilku godzin. Zatem pytanie w tytule zasługuje na prostą odpowiedź: nie, GPT-5.6 nie potrafi samodzielnie zbudować działającego POS. Każdy, kto próbuje zbudować działający POS za pomocą AI, trafia na tę samą ścianę i nie ma to nic wspólnego z inteligencją. Elementy, które sprawiają, że punkt sprzedaży jest „działający” — rozliczone płatności kartą, stan magazynowy, który pozostaje prawidłowy pod obciążeniem, certyfikowany sprzęt czytnika — nie mogą zostać wygenerowane jako kod, bez względu na to, jak dobry stanie się model piszący ten kod.

Twierdzenie to wymaga poparcia faktami, ponieważ ten model jest naprawdę niezwykły.

Co ludzie do tej pory zbudowali za pomocą GPT-5.6?

Całkiem sporo i to szybko. Sol, flagowy model z nowej rodziny (obok tańszych Terra i Luna), to najlepszy jak dotąd model kodujący od OpenAI. Zdobywa 80 punktów w indeksie Artificial Analysis Coding Agent Index — co stanowi nowy rekord — zużywając przy tym mniej niż połowę tokenów wyjściowych swojego najbliższego rywala. Strona startowa OpenAI pokazuje przeglądarkową grę żeglarską, zegarową wioskę i pełną stronę internetową muzeum, z których każda powstała na podstawie krótkiego promptu, przy czym model sam sprawdzał wygenerowane przez siebie efekty wizualne i naprawiał błędy przed przekazaniem pracy.

Wczesne testy ujawniły jeszcze ciekawsze fakty w ciągu zaledwie jednego dnia:

  • Sol stał się pierwszym modelem, który wygrał publiczną grę ARC-AGI-3, uzyskując wynik 87% w środowisku łamigłówek zaprojektowanym do testowania płynnej inteligencji.

  • Jeden z menedżerów produktu przekazał mu dokumentację PRD i za pierwszym podejściem otrzymał w pełni zgrywalizowaną aplikację do śledzenia zadań domowych — z punktami XP, awatarami towarzyszy do odblokowania i panelem dla rodziców do edycji nagród.

  • Nowe ustawienie ultra koordynuje pracę czterech agentów równolegle, dzieląc wymagające zadania na jednoczesne strumienie pracy.

  • Lovable donosi, że GPT-5.6 kończy budowanie aplikacji użytkowników przy użyciu o około 25% mniejszej liczby kroków i do 48% mniejszej liczby wywołań narzędzi niż poprzedni model.

Zatem założenie z nagłówka jest prawdziwe. Kompetentna, dopracowana aplikacja internetowa stworzona w jedno popołudnie to obecnie standard, a nie wybitne osiągnięcie.

Dlaczego GPT-5.6 nie potrafi zbudować działającego POS?

Ponieważ POS to nie aplikacja internetowa z przyciskiem „Zapłać”. Kod aplikacji — ekrany, przyciski, logika koszyka — to widoczne 20%. Pozostałe 80% to infrastruktura handlowa, a infrastruktury nie da się wygenerować jako tekstu.

Płatności to pierwsza ściana. Przyjmowanie kart osobiście wymaga konta handlowego (merchant account), zgodności z PCI oraz terminali płatniczych, które przeszły certyfikację sprzętową. Każda z tych rzeczy to umowa, audyt lub fizyczne urządzenie. GPT-5.6 potrafi napisać bezbłędny ekran kasy w dziewięćdziesiąt sekund; nie potrafi jednak sprawić, by na jego końcu można było przyjąć kartę Visa. Na to nie ma promptu.

Co przestaje działać po płatnościach?

Prawidłowość działania pod rzeczywistym obciążeniem. Kilka przykładów, które rozpozna każdy sprzedawca:

  • Równoległy stan magazynowy. Dwie kasy sprzedają ostatniego rogalika w tym samym momencie. Kod aplikacji internetowej, który „zazwyczaj działa”, dopuści do nadsprzedaży; POS musi za każdym razem poprawnie rozwiązać ten konflikt wyścigu (race condition).

  • Uzgodnienie. Sumy na koniec dnia muszą zgadzać się co do grosza z rozliczeniem procesora płatności — uwzględniając sprzedaż, zwroty, zwroty częściowe, napiwki i dopłaty. Wynik „bliski” ideałowi to incydent księgowy.

  • Podatki. Stawki, grupy, zwolnienia i reguły zaokrąglania różnią się w zależności od jurysdykcji i zmieniają się bez uprzedzenia.

  • Tryb offline. Gdy w godzinach szczytu padnie internet, kasa musi dalej sprzedawać, a potem bezproblemowo zsynchronizować dane.

  • Sprzęt. Drukarki pokwitowań, szuflady kasowe i skanery kodów kreskowych komunikują się za pomocą własnych protokołów i ulegają awariom na własne, specyficzne sposoby.

Zwróć uwagę na asymetrię: wygenerowane demo, które działa w 95% przypadków, to sukces. Kasa, która myli się w 0,5% przypadków, przynosi codzienne straty finansowe i zostaje usunięta w ciągu miesiąca. Testy porównawcze nagradzają ten pierwszy standard; sprzedawcy żyją według tego drugiego.

Czy w takim razie AI ma w ogóle rację bytu przy kasie?

Tak — i to ogromną. Błędnym wnioskiem byłoby „trzymanie AI z dala od POS”. Właściwy wniosek jest taki, że model powinien projektować rozwiązania w oparciu o istniejącą infrastrukturę handlową, a nie generować dla niej zamiennik. Niech model robi to, co teraz robi zdumiewająco dobrze — układ, logikę przepływu, iterację z prędkością rozmowy — podczas gdy płatności, stany magazynowe, podatki i sprzęt działają na systemach zbudowanych i certyfikowanych do tego zadania.

Ten podział pracy jest dokładnie tym, co umożliwia MCP (Model Context Protocol, otwarty standard łączenia narzędzi AI z systemami zewnętrznymi) i dlatego zbudowaliśmy wokół niego narzędzie Build od Final. Wpisz prompt, wybierz „Połącz własne AI (MCP)” i wklej wygenerowany blok do ChatGPT, Claude Code, Cursor lub Codex — Twoje własne narzędzie AI zbuduje proces kasy z podglądem na żywo, a następnie wdroży go na infrastrukturze, gdzie Final Pay obsłuży płatności, certyfikowane terminale przyjmą karty, a stany magazynowe pozostaną prawidłowe na każdym stanowisku. GPT-5.6 naprawdę może zbudować Twój punkt sprzedaży w kilka godzin — pod warunkiem, że nikt nie będzie od niego wymagał zbudowania również tych części, których stworzenie zajęło lata. Pełny przewodnik krok po kroku znajdziesz w artykule jak użyć ChatGPT-5.6 do zbudowania niestandardowego punktu sprzedaży.

Najczęściej zadawane pytania

Co to jest GPT-5.6?

GPT-5.6 to rodzina modeli OpenAI wydana 9 lipca 2026 roku w trzech wersjach: Sol (flagowej), Terra i Luna. Sol to jak dotąd najpotężniejszy model programistyczny OpenAI, zajmujący pierwsze miejsce w rankingu Artificial Analysis Coding Agent Index z wynikiem 80.

Czy ChatGPT może przyjmować płatności kartą?

Nie. Akceptowanie płatności kartą wymaga konta sprzedawcy (merchant account), zgodności z PCI oraz certyfikowanych terminali płatniczych do transakcji osobistych. Model językowy może napisać kod kasy, ale nie potrafi rozliczać środków ani certyfikować sprzętu.

Czy w ogóle można użyć ChatGPT-5.6 do zbudowania POS?

Tak — łącząc go przez MCP z platformą, która obsługuje już infrastrukturę handlową. Model projektuje proces kasy, natomiast platforma zajmuje się płatnościami, stanami magazynowymi, podatkami i sprzętem.

Co jest najtrudniejsze do zbudowania od zera w systemie POS?

Płatności oraz stany magazynowe odporne na błędy jednoczesności. Akceptowanie kart wiąże się z umowami, audytami i certyfikowanymi urządzeniami, a stany magazynowe muszą za każdym razem prawidłowo rozliczać jednoczesną sprzedaż — żadnej z tych rzeczy nie da się po prostu wygenerować jako kod.

Co to jest MCP?

Model Context Protocol (MCP) to otwarty standard łączenia narzędzi AI, takich jak ChatGPT, Claude Code i Cursor, z zewnętrznymi systemami, dzięki czemu model może działać na rzeczywistej infrastrukturze, a nie tylko generować tekst.

Czy ChatGPT-5.6 może zbudować działający POS? Nie sam — dlaczego | Final POS