Rapid PoC w kilka godzin. Co właściwie zbudowaliśmy i co dalej?

Wzięliśmy arkusz z wymaganiami aplikacji biznesowej średniej złożoności i przekazaliśmy go trzem narzędziom: Claude, OpenAI Codex oraz Cursorowi używanemu z Grokiem. Chcieliśmy sprawdzić, jak daleko można dojść, zaczynając od tego samego opisu procesu.

Punktem odniesienia był system, którego pierwotne wytworzenie wymagało około 1000–1500 roboczogodzin. Pierwsza działająca wersja przygotowana z użyciem Claude powstała w około cztery godziny.

Ta różnica przyciąga uwagę. Nie jest jednak najważniejszym wynikiem eksperymentu.

Cztery godziny nie zastąpiły pełnego projektu obejmującego analizę, testy, integracje, bezpieczeństwo, wdrożenie i późniejsze utrzymanie. Wystarczyły za to, aby zamienić opis wymagań w działający Rapid PoC: aplikację, którą można uruchomić, obejrzeć i skonfrontować z rzeczywistym procesem.

To zmienia sposób rozpoczynania projektu. Jednocześnie stawia nowe pytanie: skoro pierwsza wersja może powstać w kilka godzin, to co właściwie zostało zbudowane i czego nadal nie wiemy?

Ten sam arkusz nie oznacza tego samego rezultatu

Każde z narzędzi otrzymało wymagania dotyczące tej samej aplikacji. Wyniki różniły się jednak nie tylko jakością wykonania, lecz także tym, na czym narzędzia skupiły się w pierwszej kolejności.

Claude najlepiej odwzorował proces

W naszym sprawdzeniu Claude najpełniej uwzględnił reguły biznesowe opisane w materiale wejściowym. Pierwsza wersja wymagała dopracowania wyglądu, ale dobrze reagowała na kolejne instrukcje i zachowała istotne elementy procesu.

To właśnie w tym podejściu pierwsza działająca wersja powstała w około cztery godziny.

OpenAI Codex zrobił najlepsze pierwsze wrażenie

Codex przygotował najbardziej przekonujący wizualnie interfejs. Sprawnie radził sobie także z kolejnymi poprawkami UI.

Głębsze sprawdzanie ujawniło jednak pominięcia i uproszczenia w logice aplikacji. Na ekranie rezultat wyglądał dojrzalej, niż wynikało to z kompletności zaimplementowanego procesu.

Cursor z Grokiem najszybciej zgubił część wymagań

Cursor używany z Grokiem również szybko wygenerował pierwszą wersję, ale pominął istotną część wymagań. W tej próbie uzyskaliśmy najsłabsze odwzorowanie procesu.

Nie sprawdziliśmy, jak zmieniłby się rezultat po rozbiciu pracy na znacznie mniejsze zadania i przeprowadzeniu większej liczby iteracji. Nie byłoby więc uzasadnione wyciąganie na tej podstawie ogólnego wniosku o możliwościach modelu lub narzędzia.

To nie jest ranking modeli

Porównywaliśmy całe środowiska pracy, a nie same modele w kontrolowanym laboratorium. Na wynik wpływały interfejs, dostępny kontekst, sposób prowadzenia kolejnych iteracji, narzędzia wykonawcze i limity poszczególnych rozwiązań.

Nie przeprowadziliśmy identycznego scenariusza kolejnych poleceń ani pełnego zestawu wspólnych testów akceptacyjnych. Był to praktyczny eksperyment, nie benchmark.

Możemy natomiast wyciągnąć z niego wniosek ważniejszy niż wskazanie zwycięzcy: jeden rezultat nie opisuje jakości aplikacji.

Warto osobno oceniać:

• kompletność odwzorowania wymagań;
• poprawność reguł biznesowych;
• jakość i ergonomię interfejsu;
• tempo wprowadzania kolejnych zmian;
• architekturę oraz możliwość dalszego rozwoju;
• zakres testów potrzebnych przed wdrożeniem;
• bezpieczeństwo, integracje i wymagania operacyjne.

Narzędzie, które wygrywa w jednym z tych wymiarów, nie musi być najlepsze w pozostałych.

Działająca aplikacja może wyglądać na bardziej kompletną, niż jest

Rapid PoC ma pokazać, czy pomysł można uruchomić i jak może wyglądać kluczowy proces. Nie dowodzi jeszcze, że wszystkie reguły zostały poprawnie zrozumiane.

Łatwo zauważyć brakujący przycisk. Trudniej dostrzec, że system nie zachowuje historii zmian, inaczej interpretuje wyjątek w procesie albo przyjmuje założenie, które będzie niebezpieczne przy rzeczywistych danych. Jeszcze mniej widoczne są wymagania niefunkcjonalne: kontrola dostępu, odporność na błędy, wydajność, audytowalność, kopie zapasowe czy sposób aktualizacji systemu.

Im bardziej dopracowany jest interfejs, tym łatwiej uznać, że pod nim znajduje się równie kompletna logika. Nasz eksperyment pokazał, że te dwie cechy nie muszą iść w parze.

Dlatego działającego PoC nie należy oceniać wyłącznie pytaniem: „Czy można przejść przez główny ekran?”. Lepsze pytania brzmią:

• Które wymagania zostały rzeczywiście zaimplementowane?
• Jak system zachowa się w przypadkach brzegowych?
• Jakie założenia przyjął agent bez potwierdzenia?
• Co zostało uproszczone, aby szybko pokazać główny proces?
• Jakich dowodów potrzebujemy, aby zaufać rozwiązaniu na produkcji?

Agent znał rozwiązanie, ale nie wskazał problemu

Najbardziej interesujący moment pojawił się podczas rozmowy o architekturze.

W wygenerowanym rozwiązaniu istniał problem, który miał znaczenie dla dalszego rozwoju aplikacji. Kiedy człowiek zwrócił na niego uwagę, agent potrafił go poprawnie wyjaśnić i zaproponować właściwe podejście. Nie uwzględnił go jednak wcześniej z własnej inicjatywy.

To ważne rozróżnienie. Model może posiadać wiedzę potrzebną do rozwiązania problemu, a jednocześnie nie rozpoznać, że właśnie ten problem występuje w danym projekcie.

Podobnie jest z wymaganiami biznesowymi. Agent może wiedzieć, jak modelować historyczność danych, uprawnienia lub wieloetapową akceptację. Jeśli materiał wejściowy nie opisuje ich wystarczająco precyzyjnie, system może przygotować wiarygodnie wyglądającą wersję bez zadania pytania, które zadałby doświadczony analityk albo architekt.

Właśnie dlatego szybsze generowanie kodu nie zmniejsza znaczenia wiedzy specjalistycznej. Przesuwa ją w inne miejsce. Coraz większą wartość ma umiejętność:

• wybrania właściwej części procesu do prototypowania;
• zadania pytań ujawniających ukryte reguły i wyjątki;
• rozpoznania skrótów architektonicznych;
• sprawdzenia rezultatu na reprezentatywnych scenariuszach;
• oddzielenia efektownego demo od podstawy systemu produkcyjnego.

Rapid PoC zmienia rozmowę o wymaganiach

Tradycyjnie duża część początkowej pracy nad dedykowaną aplikacją odbywa się w dokumentach, diagramach i rozmowach. Zespół próbuje opisać przyszły system na tyle precyzyjnie, aby można go było oszacować i zbudować.

Jeżeli działający prototyp można przygotować w kilka dni, a czasem nawet w kilka godzin, pojawia się dodatkowe narzędzie discovery. Zamiast dyskutować wyłącznie o opisie przyszłego rozwiązania, klient i zespół techniczny mogą odnieść się do czegoś, co już działa.

Wtedy informacja zwrotna staje się konkretniejsza:

• „Ten etap w praktyce przebiega inaczej”.
• „Tutaj potrzebujemy dodatkowej akceptacji”.
• „Ta informacja musi pozostać dostępna po zmianie danych”.
• „Ten użytkownik nie powinien widzieć całego rekordu”.
• „To wygląda dobrze, ale brakuje najważniejszego wyjątku”.

Rapid PoC nie usuwa analizy. Pozwala przeprowadzić jej część na działającym rozwiązaniu, dzięki czemu szybciej ujawniają się różnice między opisem procesu a jego rzeczywistym przebiegiem.

Tę rolę PoC opisujemy szerzej w artykule Twoje demo AI działa. Co dalej? Od Rapid PoC do produkcji.

Co powstaje w kilka godzin?

W kilka godzin może powstać wersja wystarczająca, aby:

• pokazać główny przebieg procesu;
• zweryfikować, czy wymagania zostały podobnie zrozumiane przez obie strony;
• porównać warianty interfejsu i sposobu działania;
• sprawdzić wykonalność kluczowej funkcji;
• odkryć brakujące reguły oraz pytania;
• podjąć lepszą decyzję o dalszej inwestycji.

Nie oznacza to automatycznie gotowości do obsługi rzeczywistych użytkowników i danych. Droga do produkcji może nadal obejmować przebudowę modelu danych, integracje, kontrolę dostępu, testy regresyjne, obsługę błędów, monitoring, dokumentację i przygotowanie sposobu utrzymania.

Kod z PoC może stać się podstawą dalszego rozwiązania. Może też zostać częściowo lub całkowicie zastąpiony. Wartością Rapid PoC nie jest obietnica, że każda wygenerowana linia trafi na produkcję. Jest nią wiedza zdobyta wcześniej i taniej niż w tradycyjnym, długim cyklu realizacji.

Co zmienia się dla klienta

Szybsze prototypowanie pozwala wcześniej sprawdzić pomysł i ograniczyć ryzyko inwestowania w źle zrozumiane rozwiązanie. Jednocześnie czas powstania pierwszej wersji staje się coraz słabszym miernikiem jakości oferty.

Przy ocenie partnera technologicznego warto więc pytać nie tylko o to, jak szybko pokaże aplikację, ale również:

• w jaki sposób sprawdzi kompletność procesu;
• kto odpowiada za decyzje architektoniczne;
• jak zostaną zdefiniowane kryteria akceptacji;
• które elementy prototypu wymagają przebudowy przed produkcją;
• jak zostaną rozwiązane kwestie bezpieczeństwa i integracji;
• kto będzie utrzymywał system po uruchomieniu.

Pierwsza wersja może być tania i szybka. Koszt niezauważonego błędu w procesie biznesowym nadal może być wysoki.

Od szybkiej wersji do odpowiedzialnego systemu

W Inero traktujemy Rapid PoC jako początek uporządkowanej drogi, a nie skrót omijający inżynierię.

Najpierw wybieramy problem, dane i fragment procesu, których sprawdzenie dostarczy najwięcej wiedzy. Następnie budujemy działającą wersję, zbieramy informację zwrotną i identyfikujemy luki. Dopiero na tej podstawie określamy zakres pracy potrzebnej do produkcji: architekturę, integracje, bezpieczeństwo, testy i sposób późniejszego utrzymania.

Takie podejście rozdziela trzy rodzaje pracy:

1. Rapid PoC i discovery — weryfikacja pomysłu, procesu oraz kluczowych założeń.
2. Doprowadzenie do produkcji — architektura, integracje, kryteria akceptacji, bezpieczeństwo i testy.
3. Utrzymanie i rozwój — monitoring, aktualizacje, obsługa błędów oraz kolejne zmiany.

AI może zdecydowanie przyspieszyć każdy z tych etapów. Nie sprawia jednak, że wszystkie stają się tym samym zadaniem.

Kod powstaje szybciej. Odpowiedzialność nie znika

Nasz eksperyment nie odpowiedział ostatecznie na pytanie, które narzędzie jest najlepsze. Pokazał coś bardziej użytecznego: różne narzędzia potrafią bardzo szybko wygenerować przekonujące, ale odmienne interpretacje tych samych wymagań.

Dlatego przewaga nie polega wyłącznie na wyborze modelu. Powstaje z połączenia wiedzy domenowej, doświadczenia technicznego, właściwego prowadzenia agentów i systematycznej weryfikacji rezultatu.

Coraz szybciej możemy zobaczyć pierwszą działającą wersję. Coraz ważniejsze staje się to, kto potrafi ocenić, czego w niej brakuje, doprowadzić ją do produkcji i wziąć odpowiedzialność za jej dalsze działanie.