Tworzenie oprogramowania z wykorzystaniem AI: od prototypu do produkcji

Sztuczna inteligencja zmienia sposób tworzenia oprogramowania szybciej, niż większość zespołów zdążyła zaktualizować swoje prezentacje sprzedażowe. W ciągu kilku minut można dziś wygenerować fragment aplikacji, przygotować zapytanie do bazy danych, napisać test albo stworzyć pierwszą wersję integracji.

To duża zmiana. Nie oznacza jednak, że od teraz wystarczy wpisać kilka zdań do narzędzia AI, nacisnąć „Generate” i wrócić po południu po gotowy produkt. Gdyby tworzenie systemów produkcyjnych było aż tak proste, każdy projekt kończyłby się sukcesem, a działy IT nie znałyby pojęcia „pilna poprawka”.

AI może znacząco przyspieszyć tworzenie oprogramowania. Największą wartość daje jednak dopiero wtedy, gdy jest używana w dobrze zaprojektowanym procesie i połączona z doświadczeniem inżynierskim.

AI przyspiesza pracę, ale nie rozumie całego produktu

Narzędzia AI dobrze radzą sobie z zadaniami, które są powtarzalne, jasno opisane i mają przewidywalny rezultat. Mogą pomóc w przygotowaniu pierwszej wersji kodu, testów jednostkowych, dokumentacji, migracji danych czy prostych integracji.

W praktyce oznacza to mniej czasu poświęconego na mechaniczne czynności. Inżynier może szybciej przejść od pomysłu do działającego przykładu, przetestować kilka podejść i wcześniej zobaczyć, gdzie znajdują się problemy.

To ważne, szczególnie na początku projektu. Zamiast przez kilka dni przygotowywać podstawowy szkielet rozwiązania, można szybciej dojść do momentu, w którym pojawiają się prawdziwe pytania:

czy ten proces rzeczywiście rozwiązuje problem użytkownika,
czy model danych jest właściwy,
czy integracja wytrzyma większą liczbę użytkowników,
co stanie się, gdy dane będą niepełne,
kto powinien mieć dostęp do konkretnej funkcji,
jak system zachowa się w przypadku błędu.

AI pomaga szybciej dotrzeć do tych pytań. Nie odpowiada jednak automatycznie na wszystkie z nich.

Model może wygenerować kod, który wygląda bardzo rozsądnie. Może mieć właściwe nazwy funkcji, eleganckie komentarze i nawet testy. Problem pojawia się wtedy, gdy nie zna całego kontekstu systemu: decyzji podjętych wcześniej, ograniczeń infrastruktury, wymagań bezpieczeństwa czy planu rozwoju produktu.

Kod może być poprawny sam w sobie, a jednocześnie nie pasować do reszty aplikacji. To trochę jak kupienie bardzo dobrych drzwi bez sprawdzenia, czy ktoś wcześniej wymierzył futrynę.

Model nie „wie” — przewiduje kolejne tokeny

Warto odczarować sposób działania współczesnych generatywnych modeli językowych. Model oparty na architekturze Transformer nie przechowuje odpowiedzi w formie klasycznej bazy wiedzy i nie rozumuje dokładnie tak jak człowiek. Analizuje kontekst, a następnie przewiduje, jaki token powinien pojawić się jako następny.

Token może być całym słowem, jego fragmentem albo znakiem. Model oblicza prawdopodobieństwo różnych możliwości i wybiera jedną z nich. Potem wykonuje ten sam proces ponownie: bierze dotychczasowy tekst, przewiduje następny token i dokłada go do odpowiedzi.

Z zewnątrz wygląda to jak rozmowa, analiza albo tworzenie kodu. W środku działa jednak mechanizm probabilistyczny. Model nie sprawdza automatycznie, czy jego odpowiedź jest prawdziwa, aktualna albo zgodna z rzeczywistością. Tworzy najbardziej prawdopodobną kontynuację na podstawie wzorców poznanych podczas treningu i kontekstu dostarczonego w danym momencie.

To właśnie dlatego model potrafi napisać bardzo przekonujące zdanie, które jest jednocześnie nieprawdziwe. Brzmi dobrze, ponieważ jest językowo prawdopodobne. Nie oznacza to jeszcze, że opisuje fakty.

Można porównać to do bardzo doświadczonego autora, który potrafi płynnie dokończyć niemal każde zdanie, ale nie zawsze ma możliwość sprawdzenia, czy zawarte w nim informacje są poprawne. Jeśli poprosimy go o odpowiedź bez dostępu do właściwych źródeł, może napisać coś brzmiącego wiarygodnie tylko dlatego, że pasuje do kontekstu.

Nie każdy system AI działa w ten sposób. Klasyfikatory, systemy Computer Vision czy rozwiązania oparte na klasycznym machine learningu mogą mieć inną architekturę. Ten mechanizm dotyczy przede wszystkim współczesnych generatywnych modeli językowych, z którymi użytkownicy najczęściej stykają się w narzędziach do rozmowy, analizy i generowania treści.

Prawdopodobieństwo nie jest pewnością

W systemach produkcyjnych różnica pomiędzy prawdopodobną odpowiedzią a potwierdzoną informacją ma duże znaczenie. Model może wygenerować poprawną odpowiedź, ale sam fakt, że odpowiedź jest płynna i konkretna, nie stanowi dowodu jej jakości.

Dlatego rozwiązania AI często potrzebują dodatkowych mechanizmów:

dostępu do sprawdzonych danych,
wyszukiwania w dokumentach,
ograniczenia zakresu odpowiedzi,
walidacji wyniku,
reguł biznesowych,
wskazywania źródeł,
ręcznej akceptacji,
monitoringu błędów.

W przypadku systemu analizującego dokumenty nie wystarczy, że odpowiedź „wygląda sensownie”. Trzeba jeszcze wiedzieć, z którego fragmentu dokumentu pochodzi, czy spełnia wymagany format i co system powinien zrobić, jeśli dane są niejednoznaczne.

Podobnie w generowaniu kodu: model może zaproponować rozwiązanie, które jest prawdopodobne w kontekście wielu przykładów treningowych, ale nie pasuje do konkretnej architektury, wersji biblioteki albo zasad bezpieczeństwa projektu.

AI nie jest więc wyrocznią. Jest bardzo zaawansowanym narzędziem przewidywania i generowania. Wartość pojawia się wtedy, gdy zostanie osadzone w odpowiednim kontekście i poddane kontroli.

Prototyp to początek, nie gotowy system

AI jest szczególnie przydatna podczas prototypowania. Pozwala szybko sprawdzić, czy dany pomysł jest możliwy do zrealizowania, jak może wyglądać podstawowy przepływ użytkownika albo czy określony model potrafi pracować z konkretnym rodzajem danych.

Na tym etapie nie trzeba jeszcze rozwiązywać wszystkich problemów. Celem prototypu jest odpowiedź na najważniejsze pytania:

czy rozwiązanie jest technicznie wykonalne,
czy użytkownik rozumie sposób działania,
czy dane są wystarczającej jakości,
czy potencjalna korzyść uzasadnia dalszą pracę,
czy wybrana technologia pasuje do problemu.

Prototyp powinien być szybki, ale nie powinien udawać systemu produkcyjnego. To narzędzie do nauki, a nie obietnica, że wszystko jest już gotowe do wdrożenia.

Przejście z prototypu do produkcji wymaga dodatkowych decyzji. Trzeba ustalić, jak przechowywane są dane, kto ma dostęp do funkcji AI, jak obsługiwane są błędne odpowiedzi i co dzieje się wtedy, gdy model nie potrafi udzielić odpowiedzi.

Należy również uwzględnić:

autoryzację i role użytkowników,
ochronę danych,
limity i koszty wywołań modeli,
monitoring jakości odpowiedzi,
logowanie błędów,
wersjonowanie promptów i modeli,
obsługę sytuacji wyjątkowych,
integrację z istniejącym backendem,
możliwość ręcznej korekty wyniku.

W prezentacji prototyp może wyglądać świetnie po podaniu jednego idealnego przykładu. Produkcja ma zwykle inne poczucie humoru. Użytkownicy przesyłają niepełne dane, zmieniają zdanie, klikają przyciski w nieoczekiwanej kolejności, a system zewnętrzny potrafi przestać odpowiadać dokładnie wtedy, gdy ktoś najpilniej go potrzebuje.

Dlatego prototyp pokazuje kierunek. Produkcja wymaga architektury.

Człowiek nadal odpowiada za decyzje

AI może zaproponować rozwiązanie, ale odpowiedzialność za jego zastosowanie nadal ponosi zespół.

Dotyczy to szczególnie decyzji związanych z:

architekturą systemu,
bezpieczeństwem,
prywatnością danych,
wyborem modelu,
jakością odpowiedzi,
kosztami działania,
utrzymaniem i dalszym rozwojem.

Doświadczony inżynier potrafi ocenić nie tylko to, czy kod działa, ale również czy będzie możliwy do utrzymania za sześć miesięcy. Potrafi zauważyć, że szybka integracja tworzy zbyt silne uzależnienie od jednego dostawcy albo że pozornie proste rozwiązanie nie będzie działać przy większej skali.

W praktyce dobry proces pracy z AI obejmuje:

wygenerowanie propozycji,
analizę rozwiązania,
dopasowanie go do architektury,
code review,
testy automatyczne,
testy z rzeczywistymi danymi,
monitoring po wdrożeniu.

AI może przygotować pierwszą wersję. Nie powinna być ostatnią instancją.

To szczególnie ważne w systemach, które podejmują decyzje, przetwarzają dokumenty, analizują obraz albo pracują na danych klientów. W takich przypadkach „model był pewny siebie” nie jest wystarczającym kryterium jakości.

AI jako część większego systemu

Dedykowane oprogramowanie AI rzadko jest wyłącznie modelem. Najczęściej stanowi jedną z warstw większego produktu.

Poza samym modelem potrzebne mogą być:

interfejs użytkownika,
backend,
baza danych,
system autoryzacji,
kolejki zadań,
integracje z innymi aplikacjami,
przechowywanie dokumentów,
monitoring,
system powiadomień,
obsługa wyjątków,
panel administracyjny,
narzędzia do ręcznej weryfikacji.

Przykładowo, system analizujący dokumenty nie kończy się na odczytaniu tekstu z pliku. Musi jeszcze rozpoznać rodzaj dokumentu, wyciągnąć istotne dane, wskazać poziom pewności, obsłużyć brakujące informacje i przekazać wynik do systemu księgowego, CRM albo wewnętrznego procesu.

Podobnie aplikacja wykorzystująca Computer Vision potrzebuje nie tylko modelu rozpoznającego obiekty. Potrzebuje kamer, odpowiedniego środowiska uruchomieniowego, sposobu przesyłania danych, logiki obsługi błędów oraz interfejsu, który pokaże wynik osobie podejmującej decyzję.

Wartość nie powstaje więc w pojedynczym wywołaniu modelu. Powstaje w całym przepływie, który łączy dane, oprogramowanie i użytkowników.

Zacznij od problemu, nie od modelu

Jednym z częstszych błędów jest rozpoczęcie projektu od technologii. Firma wybiera konkretny model, bibliotekę albo modne rozwiązanie, a dopiero później próbuje znaleźć dla niego zastosowanie.

Lepsza kolejność wygląda inaczej:

określ problem biznesowy,
opisz obecny proces,
sprawdź, gdzie występuje największe tarcie,
zidentyfikuj dane potrzebne do rozwiązania,
określ, jaka część procesu może zostać zautomatyzowana,
wybierz odpowiednią technologię,
przygotuj prototyp,
zaplanuj przejście do produkcji.

Nie każdy problem wymaga generatywnej AI. Czasem wystarczy dobrze zaprojektowany workflow, wyszukiwarka, klasyfikator, reguły biznesowe albo klasyczna integracja.

Technologia powinna wynikać z problemu. Inaczej łatwo zbudować bardzo nowoczesne rozwiązanie, które skutecznie rozwiązuje problem, którego nikt w firmie nie miał.

AI nie usuwa potrzeby dobrego engineeringu

Wykorzystanie AI nie zwalnia zespołu z pracy nad fundamentami. Wręcz przeciwnie — im szybciej można tworzyć kod, tym większe znaczenie mają architektura, testy, dokumentacja i kontrola jakości.

Jeżeli zespół generuje kod szybciej, ale nie ma czasu na jego zrozumienie, system może rosnąć w złym kierunku. Dług technologiczny również może być tworzony z pomocą AI. Narzędzie nie odróżnia automatycznie rozwiązania trwałego od rozwiązania, które tylko dobrze wygląda podczas demonstracji.

Dlatego w projektach AI ważne są:

jasne granice odpowiedzialności,
czytelny model danych,
przewidywalne API,
testowalność,
kontrola dostępu,
monitoring,
dokumentacja decyzji,
możliwość wymiany modelu lub dostawcy,
plan obsługi awarii.

To nie są najbardziej efektowne elementy prezentacji. Są za to bardzo przydatne, gdy system działa już na produkcji i ktoś musi go rozbudować bez przerywania pracy użytkowników.

Od szybszego prototypu do lepszego produktu

AI może znacząco skrócić drogę od pomysłu do pierwszego działającego prototypu. Może ułatwić eksperymentowanie, przyspieszyć tworzenie kodu i pomóc zespołowi szybciej zweryfikować założenia.

Nie zastępuje jednak rozumienia problemu, decyzji architektonicznych ani odpowiedzialności za końcowy rezultat.

Najlepsze efekty pojawiają się wtedy, gdy AI jest używana jako narzędzie wspierające pracę doświadczonego zespołu. Taki zespół potrafi wykorzystać szybkość modeli, a jednocześnie wie, kiedy zatrzymać się, sprawdzić założenia i powiedzieć: „To działa w przykładzie, ale zanim wdrożymy to na produkcję, musimy jeszcze porozmawiać o danych, błędach i uprawnieniach”.

To właśnie połączenie AI i klasycznego software engineeringu pozwala budować produkty, które nie tylko dobrze wyglądają w prototypie, ale również mają szansę dobrze działać po wdrożeniu.