Twoje demo AI działa. Co dalej? Od Rapid PoC do produkcji

AI przyspiesza tworzenie oprogramowania. Interfejsy, integracje i kompletne działające procesy, które kiedyś wymagały tygodni pracy, coraz częściej można zbudować w kilka dni przy wsparciu agentów programistycznych AI. To więcej niż wzrost produktywności. Zmienia się sposób, w jaki powinniśmy odkrywać, wyceniać i budować dedykowane oprogramowanie.

W Inero uważamy, że tradycyjny model tworzenia custom software traci pozycję domyślnego sposobu rozpoczynania projektu. Długa sekwencja zbierania wymagań, tworzenia specyfikacji, projektowania i przekazywania pracy między zespołami — zanim ktokolwiek może skorzystać z rozwiązania — miała sens, gdy implementacja była najdroższym etapem zdobywania wiedzy. W świecie developmentu wspieranego przez AI ten sam proces może utrwalić założenia, zanim zespół wykorzysta najszybszy dostępny sposób ich sprawdzenia.

Nie oznacza to, że analiza i specyfikacja stają się zbędne. Zmienia się moment, w którym mają największą wartość. Gdy kształt produktu pozostaje niejasny, działający demonstrator może dostarczyć wiedzy szybciej niż kolejna runda abstrakcyjnych dyskusji. Kiedy workflow, ograniczenia i ryzyka są już lepiej rozumiane, dokumentacja i wycena mogą opierać się na dowodach.

Im szybciej powstaje kod, tym większego znaczenia nabiera wiedza domenowa. Najtrudniejsza część pracy coraz częściej polega na zrozumieniu biznesu, właściwym zdefiniowaniu problemu, rozpoznaniu wyjątków, wyborze tego, co warto automatyzować, oraz określeniu, jakich dowodów potrzebujemy, aby zaufać systemowi. Kod jest konieczny, ale sam kod nie jest produktem.

Zmienia się również sposób współpracy klienta z zespołem technicznym. Klient nie może już po prostu przekazać specyfikacji i czekać na rezultat. Jego eksperci domenowi powinni pozostać częścią pętli uczenia się. Inżynierowie wykorzystują AI, aby szybko zamieniać założenia w działające oprogramowanie; klient konfrontuje je z rzeczywistością operacyjną; obie strony aktualizują swoje rozumienie problemu.

Klient przychodzi do nas z pomysłem. On rozumie swój biznes. My rozumiemy oprogramowanie i AI. Ale żadna ze stron nie rozumie jeszcze w pełni produktu. I właśnie w tym momencie od firmy programistycznej tradycyjnie oczekuje się precyzyjnej wyceny jego budowy.

Możemy spędzić tygodnie, próbując usunąć niepewność wyłącznie za pomocą dokumentów. Możemy też wspólnie zbudować coś na tyle szybko, aby obie strony mogły odnieść się do działającego rozwiązania, a nie do abstrakcyjnego opisu.

W Inero Rapid PoC trwa zazwyczaj 2–3 dni robocze, a w przypadku większych lub bardziej złożonych projektów może potrwać do 5 dni roboczych. Jego głównym celem nie jest stworzenie taniej wersji finalnego produktu. Chodzi o zbudowanie wspólnego, zweryfikowanego zrozumienia między klientem a zespołem inżynierskim.

Przed PoC obie strony znają tylko część obrazu

Klient zna proces, odbiorców, ograniczenia i powody, dla których problem jest ważny. Może jednak nie wiedzieć, co współczesne AI i technologie programistyczne są w stanie realnie zapewnić, gdzie pozostają zawodne ani która z pozoru prosta funkcja okazuje się trudnym problemem technicznym.

My znamy technologię. Na początku nie znamy jednak jeszcze całej terminologii klienta, nieformalnych sposobów radzenia sobie z problemami, wyjątków, zależności i reguł biznesowych.

Rapid PoC łączy te dwie niepełne perspektywy. Pętla uczenia się jest prosta:

problem biznesowy → implementacja → informacja zwrotna klienta → korekta → nowe zrozumienie → implementacja

Kiedy rozwiązanie zaczyna działać na ekranie, informacje zwrotne stają się bardziej konkretne. Klient może powiedzieć:

• „W praktyce nasi pracownicy robią to inaczej”.
• „Ten przypadek ma inną ścieżkę akceptacji”.
• „Zapomnieliśmy o tym wyjątku”.
• „Czy system może również korzystać z tych danych?”.
• „Nie wiedzieliśmy, że AI może to zrobić”.
• „Taki wynik nigdy nie może zostać wygenerowany automatycznie”.

W tym samym czasie nasi inżynierowie poznają rzeczywisty workflow, ukryte zależności, wymagania integracyjne i obszary ryzyka. Demonstrator staje się narzędziem komunikacji i odkrywania problemu.

Dlatego PoC ma wartość nawet wtedy, gdy żadna linia jego kodu ostatecznie nie trafi na produkcję. W prostym projekcie może stać się podstawą implementacji produkcyjnej. W innym zdobyta wiedza może uzasadnić zmianę architektury lub istotne przeprojektowanie rozwiązania. Nie powinniśmy z góry zakładać żadnego z tych scenariuszy, zanim nie zbierzemy dowodów.

AI zmienia ekonomię uczenia się

W przeszłości nawet prototyp mógł wymagać oddzielnych etapów zbierania wymagań, projektowania interfejsu, tworzenia backendu i frontendu, integracji, wdrożenia oraz kolejnych rund informacji zwrotnej. Doświadczony lider techniczny korzystający z agentów programistycznych AI może dziś skompresować istotną część tej pracy do kilku dni.

Ta przewaga nie wynika z samego pisania promptów. Powstaje przez połączenie analizy biznesowej, oceny technicznej oraz umiejętności kierowania pracą generowaną przez AI i jej weryfikowania.

Osoba prowadząca Rapid PoC nadal musi:

• przełożyć język biznesowy na precyzyjny problem techniczny;
• rozumieć, co obecne modele i narzędzia potrafią, a czego nie;
• wybrać część workflow, której prototypowanie dostarczy najwięcej wiedzy;
• kierować agentami programistycznymi i sprawdzać wyniki ich pracy;
• rozpoznawać skróty architektoniczne i ukryte luki produkcyjne;
• wyjaśniać ograniczenia na tyle jasno, aby klient mógł podjąć świadomą decyzję.

Inero wykorzystuje agentów programistycznych AI do przyspieszania prototypowania, ale to inżynierowie odpowiadają za architekturę, decyzje techniczne i walidację. AI pozwala szybciej testować pomysły. Nie usuwa potrzeby inżynierskiej oceny.

A potem demo zaczyna działać

Agent odpowiada poprawnie. Workflow dochodzi do końca. Wywołanie API się udaje. W systemie pojawia się rezerwacja. Dokument zostaje przeanalizowany. Wszyscy wreszcie widzą, że pomysł jest wykonalny.

To ważny kamień milowy. Jest to również niebezpieczny moment, ponieważ łatwo wtedy przyjąć kuszące założenie:

Działa. Jesteśmy prawie gotowi.

Udane demo AI potwierdza wykonalność. Samo w sobie nie potwierdza niezawodności produkcyjnej.

Dopracowany prototyp może poprawnie obsłużyć pięć starannie wybranych przykładów i poważnie zawieść przy szóstym, którego nikt nie przewidział. Przejście od prototypu AI do produkcji nie polega więc głównie na dokończeniu pozostałych ekranów. To praca nad odkrywaniem, definiowaniem, testowaniem i stopniowym kontrolowaniem możliwych trybów awarii.

Pytanie zmienia się z „Czy potrafimy sprawić, żeby to zadziałało?” na „Jakich dowodów potrzebujemy, aby móc zaufać temu rozwiązaniu w rzeczywistych warunkach?”

Przypadek brzegowy, którego nikt nie zaprojektował

Wyraźnie zobaczyliśmy tę różnicę podczas testowania głosowego systemu AI. Oczekiwane scenariusze rozmowy działały dobrze. Potem jeden z użytkowników poprowadził rozmowę w nietypowym kierunku.

Problem nie musiał być halucynacją AI. Był bardziej podstawowy: nikt nie zaprojektował tej ścieżki, ponieważ nikt wcześniej o niej nie pomyślał. Ani my, ani klient.

Wiele awarii produkcyjnych nie wynika z niepoprawnej implementacji znanych wymagań. Ujawniają wymagania, o których istnieniu nikt wcześniej nie wiedział.

Ten sam mechanizm pojawia się w projektach cyberbezpieczeństwa, często na bardziej technicznym poziomie. Nietypowy stan systemu, kombinacja zależności lub ścieżka ataku może stać się widoczna dopiero wtedy, gdy inżynierowie szczegółowo przeanalizują działający system.

PoC nie odkryje każdego przypadku brzegowego. Daje nam jednak znacznie lepszy sposób, aby zacząć je odkrywać.

Niezawodność zaczyna się od zdefiniowania, co znaczy „poprawnie”

Zanim zaczniemy ewaluować system AI, biznes musi określić, czym jest sukces. Brzmi to oczywiście, ale często okazuje się najtrudniejszą częścią pracy.

Warto zacząć od rzeczywistych przypadków. W zależności od systemu może to oznaczać zebranie dziesiątek reprezentatywnych przykładów zamiast polegania wyłącznie na syntetycznych, idealnych scenariuszach. Oczekiwane zachowanie powinien ocenić ktoś, kto zna daną dziedzinę: specjalista operacyjny, ekspert ds. rozliczeń, lider obsługi klienta, specjalista ds. bezpieczeństwa, likwidacji szkód lub inny odpowiedzialny ekspert domenowy.

Jeśli eksperci domenowi nie zgadzają się co do poprawnego wyniku, zespół odkrył przede wszystkim problem z regułą biznesową, a nie z AI. Tę niejednoznaczność trzeba rozwiązać, zanim zaczniemy optymalizować agenta względem odpowiedzi, której nikt nie potrafi uzasadnić.

Poprawne zachowanie obejmuje także sytuacje, w których system nie powinien wykonywać zadania. Może być konieczne, aby:

• poprosił o brakujące informacje;
• odmówił wykonania operacji bez wymaganych uprawnień;
• oznaczył sprzeczne rekordy;
• przekazał sprawę człowiekowi;
• zatrzymał się z powodu niewystarczającej pewności.

Agent, który zawsze udziela odpowiedzi, może być mniej niezawodny niż taki, który wie, kiedy tego nie robić. Dla agenta głosowego może to oznaczać eskalację rozmowy, która wyszła poza obsługiwany proces. Dla agenta wykonującego operacje — odmowę wywołania narzędzia, dopóki nie zostaną spełnione wymagane warunki.

Sprawdzaj rzeczywistość, nie tylko opinię innego modelu

Ewaluacje AI powinny korzystać z najlepszego dostępnego źródła prawdy. Jeżeli wynik można sprawdzić deterministycznie, taka kontrola jest silniejsza niż pytanie innego modelu językowego, czy rezultat wygląda wiarygodnie.

• Wynik obliczenia sprawdź za pomocą deterministycznego kodu.
• Odpowiedź dotyczącą danych zweryfikuj przy użyciu zapytania do bazy.
• Rezerwację porównaj z rzeczywistym rekordem w systemie.
• Wymagane pola sprawdź za pomocą walidacji schematu.
• Deklarowane działanie potwierdź, analizując rzeczywistą zmianę stanu systemu.

LLM judge nadal może być przydatny do oceny kryteriów jakościowych, na przykład tego, czy wyjaśnienie jest adekwatne, zrozumiałe lub zgodne z polityką. Taki sędzia jest jednak kolejnym systemem AI, więc również jego decyzje wymagają walidacji. Porównujemy próbkę jego ocen z ocenami ekspertów domenowych i badamy systematyczne rozbieżności, zamiast bezkrytycznie ufać wygodnemu wskaźnikowi.

W systemach agentowych końcowa odpowiedź jest tylko częścią dowodu. Jeśli agent mówi: „Twoja wizyta została zarezerwowana”, ewaluacja powinna również sprawdzić, jakie narzędzia wywołał, jakie parametry przekazał, z których rekordów skorzystał, czy wybrał właściwe konto lub osobę i czy rezerwacja rzeczywiście istnieje. Wiarygodnie brzmiące zdanie może ukrywać niepoprawną ścieżkę wykonania.

Tracing i obserwowalność są więc częścią kontroli jakości, a nie wyłącznie diagnostyki produkcyjnej.

Jedno udane uruchomienie nie oznacza powtarzalności

Systemy AI są niedeterministyczne. Przypadek, który zadziałał raz, może zawieść przy kolejnym uruchomieniu. Dla ważnych workflow ten sam przypadek należy uruchamiać wielokrotnie.

Przydatne miary obejmują odsetek sukcesów, niezawodność przy pierwszej próbie, powtarzające się wzorce błędów oraz ocenę, czy ponowienie jest akceptowalne w danym procesie. Nagranie idealnego demo dowodzi, że jedno wykonanie się udało. Niewiele mówi o powtarzalności.

Ta sama dyscyplina obowiązuje po każdej zmianie. Nowy prompt, model, narzędzie, źródło kontekstu, strategia wyszukiwania lub reguła biznesowa może naprawić jeden przypadek i zepsuć inny. Ewaluacje regresyjne porównują nową wersję z poprzednią i odpowiadają na pytania:

• Co się poprawiło?
• Co działa gorzej?
• Które przypadki zmieniły zachowanie?
• Czy zmiana była zamierzona?

Część przypadków powinna pozostać poza zbiorem używanym podczas dostrajania systemu. W przeciwnym razie zespół może nadmiernie dopasować agenta do znanego zbioru ewaluacyjnego i pomylić zapamiętane zachowanie testowe z szerszą niezawodnością.

Nie naprawiaj tylko promptu. Zamień błąd w test.

Początkowe przypadki testowe reprezentują wiedzę zespołu sprzed uruchomienia systemu. Produkcja ujawnia to, czego nikt wcześniej nie wiedział. Dlatego zbiór ewaluacyjny powinien rozwijać się razem z produktem.

Kiedy na produkcji pojawia się istotny błąd, stosujemy praktyczny, sześcioetapowy proces:

1. Zapisz przypadek. Zachowaj wystarczająco dużo informacji, aby odtworzyć zachowanie, z poszanowaniem wymagań prywatności i bezpieczeństwa.
2. Zdefiniuj oczekiwane zachowanie. Osoba odpowiedzialna lub ekspert domenowy określa, co powinno się wydarzyć.
3. Dodaj przypadek do zbioru ewaluacyjnego i regresyjnego. Incydent staje się wiedzą inżynierską, którą można ponownie wykorzystać.
4. Napraw system. Zmiana może dotyczyć promptu, kontekstu, kodu, narzędzi, workflow lub logiki walidacji.
5. Uruchom pełny zestaw testów regresyjnych. Sprawdź przypadek, który zawiódł, oraz potwierdź, że poprawka nie uszkodziła wcześniej działających zachowań.
6. Wdróż po odpowiedniej ewaluacji. Wymagany poziom dowodów zależy od ryzyka systemu i wykonywanego działania.

Awaria produkcyjna powinna sprawić, że system będzie trudniej zepsuć drugi raz w ten sam sposób.

Z czasem zbiór ewaluacyjny łączy początkowe przypadki biznesowe, przypadki brzegowe odkryte podczas rozwoju, potwierdzone błędy produkcyjne oraz nowe wymagania biznesowe. Staje się pamięcią inżynierską opisującą, jak system powinien się zachowywać i dlaczego określone zachowania mają znaczenie.

Ewaluacja nie kończy się po wdrożeniu

Monitoring produkcyjny nie jest wartościowy dlatego, że tworzy kolejny dashboard. Ma wartość wtedy, gdy zamyka pętlę informacji zwrotnej:

produkcja → obserwacja → walidacja człowieka → przypadek regresyjny → ulepszenie → ewaluacja → produkcja

W zależności od systemu i wymagań prywatności monitoring może obejmować nieudane workflow, eskalacje, nietypowe rozmowy, wyniki o niskiej pewności, awarie narzędzi, poprawki użytkowników i interwencje operatorów. Celem jest rozpoznawanie nowych kategorii błędów i przekazywanie potwierdzonej wiedzy z powrotem do procesu inżynierskiego.

Zakres tych działań zależy od konsekwencji błędu. Wewnętrzny asystent podsumowujący dokumenty niskiego ryzyka może tolerować sporadyczne pomyłki. Agent, który przesuwa pieniądze, zmienia uprawnienia dostępu, modyfikuje ważne rekordy, komunikuje się z pacjentami, podejmuje decyzje związane z bezpieczeństwem lub wykonuje nieodwracalne działania, wymaga znacznie silniejszych mechanizmów kontroli.

Właściwe pytanie nie brzmi, czy „AI” jest abstrakcyjnie gotowe do pracy na produkcji. Powinniśmy zapytać:

Czy dowody niezawodności są odpowiednie do tego, co system może robić?

Wyceń system, który teraz lepiej rozumiesz

Przed Rapid PoC obie strony wyceniają pomysł. Po jego zbudowaniu wiedzą znacznie więcej o workflow, integracjach, danych, regułach biznesowych, przypadkach brzegowych, ryzyku, potrzebach walidacji i pozostałych lukach produkcyjnych.

Ta wiedza sprawia, że kolejna wycena ma więcej sensu.

Jeżeli nadal istnieje istotna niepewność, projekt może być kontynuowany w modelu iteracyjnym: budujemy, uczymy się, ustalamy priorytety i stopniowo rozwijamy rozwiązanie do poziomu produkcyjnego. Jeśli oczekiwany rezultat, założenia i kryteria odbioru można określić z wystarczającą pewnością, odpowiedni może być projekt o zdefiniowanym zakresie i stałej cenie.

Te dwa sposoby rozpoczynania projektu opisujemy szerzej na stronie Od pomysłu do produkcji.

Kolejność ma znaczenie:

problem biznesowy + doświadczenie techniczne + agenci programistyczni AI → Rapid PoC → wspólne zrozumienie → luki produkcyjne → rzeczywiste przypadki i ewaluacje → produkcja → błędy w rzeczywistym środowisku → testy regresyjne → ulepszenie

Rapid PoC nie jest miniaturowym systemem produkcyjnym. To szybki sposób na zastąpienie założeń rozwiązaniem, które obie strony mogą zobaczyć i ocenić. Gdy pomysł zaczyna działać, rozpoczyna się inżynieria produkcyjna: definiowanie poprawnego zachowania, sprawdzanie rzeczywistości, śledzenie działań, mierzenie powtarzalności i zamienianie błędów w trwałe testy.

To rozróżnienie pozwala nam intensywnie korzystać z AI tam, gdzie daje realną przewagę, bez mylenia szybkiego generowania z tworzeniem niezawodnego oprogramowania.