Ryzyka związane z programowaniem czarnej skrzynki przy użyciu AI

W obszarze QA i testowania powszechnie mówi się o testach czarnej skrzynki (black-box) lub testach białej skrzynki (white-box). Testy czarnej skrzynki są przeprowadzane, gdy nie zna się wewnętrznego działania systemu i sprawdza się wyłącznie jego funkcjonalność. Testy białej skrzynki wykonuje się wtedy, gdy zna się wewnętrzną strukturę lub działanie systemu, a scenariusze testowe konfiguruje się tak, aby sprawdzić różne możliwe przypadki przewidziane w kodzie.

Wraz z narzędziami sztucznej inteligencji pojawia się zjawisko, które moglibyśmy nazwać programowaniem czarnej skrzynki. Użytkownik określa dla AI to, czego oczekuje pod kątem funkcjonalnym od aplikacji, a AI to generuje.
Użytkownik nie wie, jak jego aplikacja działa od wewnątrz, nie interesuje go to lub nie jest w stanie zrozumieć konsekwencji sposobu wdrożenia danego rozwiązania.
Byłby to typowy przypadek użycia narzędzi takich jak Lovable oraz kilku innych, które zaczynają się pojawiać, ale akceptowanie kodu wygenerowanego przez AI bez weryfikacji i zrozumienia również można uznać za programowanie czarnej skrzynki.

W przeciwieństwie do programowania czarnej skrzynki istnieje również programowanie białej skrzynki przy użyciu AI. W tym przypadku występuje osoba odpowiedzialna technicznie, która decyduje o architekturze, sposobie wdrożenia rozwiązania i wspiera się AI, aby zaimplementować je szybciej. W zależności od kontekstu i zdolności pojmowania, fragmenty delegowane do AI są większe lub mniejsze.
Rola twórcy produktu zmienia się: zamiast pisać linie kodu, projektuje/kieruje, aranżuje i weryfikuje, będąc całkowicie odpowiedzialnym za to, „jak” to działa. Z tego powodu zalecam, aby fragmenty zamawiane u AI były na tyle małe i zwięzłe, by można było je przejrzeć, zrozumieć i przejąć ich późniejsze utrzymanie (moja rekomendacja: nic większego niż pull request, który jesteśmy w stanie samodzielnie zweryfikować i zrozumieć). Choć pełna wiedza jest nieogarniona i istnieje wiele odcieni bieli, programowanie białej skrzynki polega na zrozumieniu rozwiązania tak głęboko, jak to możliwe; nie chodzi o dzielenie dużej czarnej skrzynki na mnóstwo mniejszych czarnych skrzynek.

Choć oczywiście mam swoje preferencje, żadna z tych form nie jest z natury dobra ani zła, po prostu trzeba je zrozumieć, dostrzec ich plusy i minusy, a przede wszystkim pojąć ryzyka z nimi związane.

W przypadku programowania czarnej skrzynki ryzyka, które moim zdaniem należałoby ocenić, to:

Ryzyko 1: Brak odpowiedzialności. Jak już wspominałem w poprzednim artykule, AI nie może prowadzić do rozmycia odpowiedzialności. Jeśli wygenerowane oprogramowanie nie działa prawidłowo, wykazuje problemy z wydajnością, bezpieczeństwem, stabilnością lub nieprzewidzianymi skutkami ubocznymi, osoba odpowiedzialna musi być jasno określona. Brak zrozumienia „jak” i „dlaczego” te problemy występują, komplikuje przyjęcie odpowiedzialności.
Ryzyko 2: Brak kontroli nad jakością. Brak wiedzy o tym, jak oprogramowanie zostało wygenerowane, sprawia, że nie wiemy, czy powstał produkt wysokiej jakości, czy też nie. To nie jest nowe zjawisko; większość interesariuszy chce po prostu, aby oprogramowanie działało, bez względu na to, czy zostało stworzone dbając o jakość. Jednak ci, którzy pracują z architekturą oprogramowania i ją znają, wiedzą, że brak jakości i dług techniczny ostatecznie dają o sobie znać: trudności w utrzymaniu, błędy, powolne działanie, skomplikowanie struktury, a w ostateczności konieczność napisania całego kodu od nowa.
Ryzyko 3: Nieznajomość architektury oprogramowania: Brak znajomości architektury oprogramowania oznacza nieznajomość jego mocnych i słabych stron, niewiedzę, którą część trzeba będzie wzmocnić lub nawet w jakim kierunku aplikacja może lub powinna ewoluować. To także brak wiedzy o jej zależnościach i potencjalnych podatnościach.
Ryzyko 4: Wydajność: Wydajność aplikacji jest ściśle powiązana z jej architekturą. Możemy mówić o problemach ze skalowalnością lub „po prostu” o nieefektywnym wykorzystaniu zasobów, ale bez zrozumienia, jak aplikacja jest zbudowana, niemożliwe jest nie tylko samodzielne działanie, ale nawet zaproponowanie jakichkolwiek optymalizacji.
Ryzyko 5: Wiedza ukryta (implicite): Kiedy definiujemy i wdrażamy projekt, istnieje kontekst i wiedza ukryta każdego z uczestników procesu, która wnosi wartość. Na przykład architekt oprogramowania lub deweloper wniesie wiedzę na temat architektury, wzorców projektowych, bezpieczeństwa danych, a także kwestii funkcjonalnych opartych na wcześniejszych doświadczeniach i wdrożeniach. Ponieważ jest to wiedza ukryta, duża jej część nie jest przekazywana do AI ani nie wymaga się jej zastosowania, przez co otrzymujemy rozwiązanie o niższej jakości, niż gdyby w jego tworzeniu brało udział wielu ludzi z różnorodną wiedzą.
Ryzyko 6: Ewolucja kontra rewolucja (refaktoryzacja kontra przepisanie - refactor vs replatform): Musimy pamiętać, że tworzenie oprogramowania to proces iteracyjny. Nie robi się aplikacji raz na zawsze. Trzeba ją rozwijać, naprawiać, ulepszać itd. Nie znając sposobu, w jaki została stworzona, nie można precyzyjnie określić ewolucji określonych aspektów, lecz dodaje się nowe specyfikacje wysokiego poziomu. Istnieje wtedy bardzo duże ryzyko, że AI przepisze istniejący kod, aby spełnić nowe wymagania, przestając spełniać poprzednie, ponownie popełniając błędy i ogólnie wywołując wszystkie problemy, które pojawiają się przy ponownym pisaniu oprogramowania zamiast jego refaktoryzacji.
Ryzyko 7: Utrata szans z powodu braku wiedzy: Istnieją przypadki, w których wiedza o tym, jak coś jest zrobione oraz znajomość możliwości technologicznych generują okazje biznesowe, nowe opcje funkcjonalne itp. Jest to tak zwany rozwój produktu „od dołu do góry” (down to top). Pomijając tę wiedzę i tych uczestników, którzy wiedzą, jak system jest zbudowany, tracimy tę zdolność kreatywną.

Znając te ryzyka, należy zachować ostrożność w obliczu konsekwencji programowania czarnej skrzynki. Niemniej jednak, jak wspomnieliśmy wcześniej, nie jest to z natury zła metoda; istnieją przypadki, w których ten rodzaj programowania może być interesujący, ponieważ wiąże się z mniejszym zużyciem zasobów ludzkich (w kwestię zużycia tokenów tutaj nie wchodzę).

Na przykład przy projektach typu Proof of Concept, pilotach czy prototypach może to być ciekawe rozwiązanie, ponieważ są to przypadki, w których wydajność i stabilność produkcyjna nie są tak niezbędne jak szybkość i możliwość przetestowania samych założeń, a ponadto nie ma intencji tworzenia oprogramowania, które ma pozostać na stałe, poprawiać się i ewoluować.

Podsumowując, kiedy programujemy z AI, podobnie jak w przypadku zlecania oprogramowania firmie doradczej, musimy zadać sobie pytanie o konsekwencje nieznajomości tego kodu, ryzyka z tym związane oraz o to, jak zamierzamy go utrzymywać. Musimy zastanowić się, czy zlecamy stworzenie oprogramowania jako rozwiązanie problemu, czy też chcemy je sami zaimplementować.