Dług technologiczny na sterydach: co AI robi z kodem, którego nie sprawdzasz

Musimy sobie wprost powiedzieć, że AI jest troszeczkę jak Uran. W sensie on jest bardzo fajnym materiałem, ale on promieniuje i on ma bardzo duże zdolności do tego, żeby się rozlewać i musimy też go pilnować, bo potrafi też nam lintery powyłączać. Testy przechodzą, wszystko jest elegancko, no ale w kodzie widzimy, że te testy są po prostu powyłączane. Drodzy widzowie, witamy Was w kolejnym odcinku podcastu serii Data Driven. Tematem tego odcinka będzie dług technologiczny na sterydach, czyli czy AI pisze nowy lepszy kod, czy generuje dług technologiczny, czy wytwarza sytuację, której jeszcze się nie spotkaliśmy wcześniej i nas w sumie trochę nie obchodzi co jest w środku.

Co do tej definicji, to ja mam takie zdanie, znaczy nie chcę tu podważać autorytetów, broń Boże. Definicja jest według mnie okej, natomiast z tym świadomym zaciąganiem długu, to nie jestem przekonany, czy to do końca zawsze tak jest, że go zaciągamy świadomie. Zakładając, że nad projektem pracował doświadczony zespół, I podejmował świadome decyzje, to okej, ale często jest tak, że brak jakichś kompetencji ludzkich, zakładając jeszcze, że mówimy o świecie bez AI, ten dług też jakby to wyklucza się trochę z tej definicji, bo wtedy zaciągamy go nieświadomie. Chodzi mi o to, że według mnie efekt jest podobny.

Czyli biznes nie do końca wie, jak wyglądają jego procesy. Proces ewoluuje w czasie. My staramy się dowieść to jak najszybciej, sprostowując oczekiwania. Mi po drodze gdzieś dochodzi kwestia pójścia na skróty. I w momencie, w którym my sami nie piszemy tego kodu, no nie możemy powiedzieć o samoświadomości. Nie możemy powiedzieć o tym, że robimy coś OK, ja sam wytworzyłem ten kod, ja sam podjąłem tę decyzję. Jedyne, co możemy dopuścić tutaj pod rozważaniem, Takie wprost. To wybór narzędzia, że okej, poszliśmy tutaj na skróty, dopuściliśmy ryzyko, którym jest AI, dopuściliśmy skrzynkę i wiemy, w których momentach została ona dopuszczona.

I dalej moim zdaniem ta definicja pozostaje, natomiast sposób rozumienia jej po prostu zostaje troszeczkę zmieniony. Ja się tak chciałem trochę doczerpić do tej definicji oryginalnej, ale to w sumie może nie ma co nad tym spędzać za dużo czasu. Czy bałagan, czy dług techniczny zaciągnięty świadomie, ale nawet jeżeli byśmy przyjęli tą kategorię, że dzisiaj już przechodząc do tematów może bardziej związanych z wytwarzaniem kodu w erze AI, to czy na pewno ten kod wytwarzany przez AI to jest nieświadomo... Możemy to podciągnąć pod tą kategorię, że to jest nieświadome. Bo jednak wybieramy te narzędzia świadomie i wiemy jakie są skutki.

I jeżeli oddajemy im zbyt duże pole manewru, to według mnie to jest nasz błąd. W sensie wciąż tu powinna być jakaś kontrola, żeby można było powiedzieć, że świadomie korzystamy z tych narzędzi. Bo według mnie powiedzenie, Możemy tutaj powiedzieć o tym bałaganie, że AI wprowadza bałagan, wprowadza skróty tylko dlatego, że używamy AI. To jest takie trochę przerzucenie odpowiedzialności z człowieka na AI. A wydaje mi się, że nie możemy tego zrobić. Tym bardziej, że koniec końców to programista się podpisuje pod tym, Co wypuścił, nie? To nie jest tak, że AI startuje taska, wydaje mi się, że jeszcze nie, choć nie wykluczam, że za 2-3 lata to tak może wyglądać, że AI wystartuje taska i da go na done i się pod tym podpisze, bo klient później w razie problemów nie będzie miał jakby fontów, że tak powiem, do sztucznej inteligencji, tylko do człowieka, który ją nadzorował, powiedzmy, nie?

W sensie jak na przykład nas później Klaudiusz się zapyta, czy ma to zrobić tak, tak czy tak i często gęsto nawet ci potrafi doradzić, że to jest droga na skróty, ta zajmie dłużej, ta jest bardziej skomplikowana itd. Czy to nie jest to miejsce, gdzie jakby Dalej, ta stara definicja działa dobrze, tylko się ona, że tak powiem, znalazła nowe miejsce życia, nie? Bo zakładam, że summa summarum i tak nikt nie będzie tworzył dużych projektów z zero-shotami, nie? W sensie, że siądzie, odpali clouda i zacznie coś tam szukać. Ej, zaimplementuj mi to i to i to, dzięki, a ja idę na kawę, nie? No sądzę, że to jednak tak nie działa, nie? No dokładnie, tutaj się zgadzam. Kwestia podejścia tak naprawdę i na dzień dzisiejszy wydaje mi się, że to co powiedział Spektr Driven Development to jest to jak się powinno podchodzić do współpracy z AI i tworzenia oprogramowania przy użyciu AI.

To nie jest one shot, robimy to wciąż iteracyjnie, nie? Przygotowujemy tą dokumentację, staramy się nawet wspomagając się AI, przygotowujemy tą dokumentację, on nam pomaga w analizie, ale wciąż my jesteśmy tą osobą, która powiedzmy prowadzi tą konwersację, jest w ciągu tej konwersacji i widzi output tej konwersacji, nie? I my ją musimy ocenić. Jeżeli nie jesteśmy zadowoleni z rezultatów, musimy sobie odpowiedzieć na pytanie, czy jak ja bym to robił, Powiedzmy może dłużej, może dwa tygodnie zamiast jeden dzień. Czy ja bym się spodziewał takiego samego efektu, czy nie? Jeżeli jestem niezadowolony z tego efektu, to znaczy, że coś poszło nie tak. Prompt nie był wystarczająco obszerny. Kontekst dostarczony sztucznej inteligencji nie był wystarczający. I tutaj iterujemy, aż dojdziemy do tego, co byśmy chcieli uzyskać.

No i biorąc pod uwagę tą dokumentację, od tego jak ona jest dobra od samego początku, zakładając, że mówimy o jakimś projekcie typu Greenfield, gdzie faktycznie mamy możliwość zaprojektowania, pogadania z klientem i ustalenia tych wymagań. No to wtedy mamy dobry punkt bazowy, żeby z tym kontynuować i tak samo przy już implementacji konkretnych tasków, no to to wygląda podobnie. Opieramy się na tej dokumentacji, to jest dobry kontekst dla sztucznej inteligencji. Ale wciąż my jesteśmy w środku. To nie jest tak, że mamy black boxa, odpalamy AI na tydzień i po tygodniu sprawdzamy, jak wygląda nasz system. I tutaj też bym rozróżnił jeszcze poziom skomplikowania, bo takie podejście według mnie na dzień dzisiejszy jest możliwe

Z tego co wiem, no jest to praktykowane, rynek jest zalany w tym momencie AI slope'ami, nie? I to nie tylko jeśli chodzi o kod, ale też o grafiki, muzykę i tak dalej. Wydaje mi się, że już jest moment, że wszyscy są tym trochę zmęczeni i przebodźcowani. No ale jeśli chodzi o aplikacje takie proste typu, nie wiem, lista zakupów albo ktoś chce sobie zrobić jakiegoś one pagera, To jak najbardziej. Tutaj nawet jeżeli coś poszłoby nie tak, to koszt nie jest duży przepisania tego od nowa, ale jeżeli mówimy o jakichś systemach albo legacy, które przejmujemy, albo takie, które budujemy od podstaw, ale są to systemy duże, gdzie w grę wchodzą pieniądze, ludzkie życie albo coś takiego, to nie jest jeszcze ten moment, żebyśmy oddali autonomię sztucznej inteligencji w pełni.

Dobrze, a Patryku pozwól, że Ciebie spytam, czy uważasz, że jakby ten spec-driven development, niezależnie od frameworka, którego wybierzemy, bo tych frameworków jest już w chwili obecnej też mnóstwo, czy on rzeczywiście nas w jakiś sposób może zabezpiecza? Nie tyle przed długiem technologicznym, ale przed tym bałaganem właśnie, że minimalizuje tą przypadkowość i brak determinizmu decyzji, przynajmniej na poziomie architektonicznym. Dalej to wszystko jak wszystko zależy. To znaczy, tak, jest już to jakiś framework, który potencjalnie daje nam pole manewru, usprawniające sposób działania AI na pewno w ramach kontekstu.

Natomiast cały problem polega na tym, że cała ta specyfikacja, którą piszemy, często zmienia się o tyle szybko, Dług technologiczny na sterydach – co AI robi z kodem, którego nie sprawdzasz. AI, bo musimy sobie wprost powiedzieć, że AI jest troszeczkę jak Uran. W sensie on jest bardzo fajnym materiałem, ale on promieniuje i on ma bardzo duże zdolności do tego, żeby się rozlewać w miejsce, w które nawet nie chcemy, żeby on się rozlewał. I o ile jest to potężne narzędzie, ono potrafi nam zaoszczędzić kupę czasu. O tyle ono rzuca się we wszystkie strony teoretycznie randomowo i output tego nie jest po prostu deterministyczny.

Rzucamy AI i leć sobie sam. Na tym utnę może w ten sposób, bo troszeczkę wychodzę poza zakres moich kompetencji, żeby dorzucać trochę więcej cegieł. A ja jeszcze się tak trochę dalej pociągnę jednak ten temat. Ja mogę wam przytoczyć taką opowieść u siebie, że kiedyś miałem takie repo, gdzie bardzo zależało mi na tym, żeby wyłączyć Cloudowi dostęp do interfejsu z Githuba. W sensie ja je chcę tam komituje gitem, ale żeby żadnych tam PR-ów, komentarzy, niczego nie wrzucał, więc ja zablokowałem mu w settings.json dostęp do GH.

No to on sobie znalazł restowe API i tak zrobił to, co chciał za stosowne i było na razie. Właśnie, no i to jest kolejny argument za tym, że my dostrzegamy na co dzień w swojej pracy, że zbyt często zdarzają się takie rzeczy, że coś jest poza naszą kontrolą. Mnie na przykład osobiście, to też chyba jedna z najbardziej drastycznych rzeczy, które mi się zdarzyły, to że gdzieś tam przez moją nieuwagę pozwoliłem na to, że agent coś zakomitował za szybko powiedzmy. Ja musiałem później te zmiany wycofywać. No ale to mi dało jakby takie poczucie, że skoro tutaj, z uwagi pewnie na moje przeoczenie, no bo czemu jest winny AI, ono chce dla nas jak najlepiej, przynajmniej póki co, no ale mógłby pójść dalej.

Założyłby sobie, że np. drop na bazie to jest dobry pomysł, bo dalej nam przeszkadzają i testy nie przechodzą np. Czemu tak miałoby się nie wydarzyć? Ale mamy w teorii narzędzia, tak jak powiedziałeś, którymi możemy ten zakres ograniczać. No tylko jak widać, nie zawsze to działa, więc nie jest to do końca deterministyczne. I tak samo, jeszcze rozmawiając przed naszym podcastem, chwilę poruszyłem temat O stabilności narzędzi. Używamy różnych CLI do gadania z AI. Ja osobiście doświadczyłem w ostatnim czasie problemów, nie będę mówił z którym, ale to jest jeszcze warstwa pośrednia pomiędzy nami a sztuczną inteligencją. Jakieś update'y.

Dalej jest to moim zdaniem taka cecha po prostu AI w dzisiejszych czasach jako młodej technologii. To musi w pewnym momencie wyewoluować w coś bardziej stabilniejszego, ale na chwilę obecną rynek jest tak zachłyśnięty, tak bardzo potrzebuje narzędzi na teraz, że na polerkę przyjdzie czas za moment. Po prostu rynek to musi zweryfikować. A czy też uważacie, że jakby, jeszcze pozwolę sobie wrócić na chwilę do oryginalnej definicji długu, bo tam zakładaliśmy, że on będzie gdzieś świadomie zapisany, nie? Teraz jakby, Większość tych frameworków spec-driven development zapisuje rezultat i uzasadnienie decyzji, a niekoniecznie zapisuje cały proces dojścia do decyzji.

Jasne, tutaj jest kwestia tego, że jeżeli bierzemy kredyt na 10 złotych, wątpię, żeby którykolwiek z nas potrzebował takiego kredytu, No to, no ryzyko jest żadne. W sensie takim, że no okej, przepchniemy to, nieważne co tam jest napisane, no chyba, że będą straszne kauzule. No natomiast jak kupujemy dom, no to już wszystko raczej czytamy i no jesteśmy samoświadomi jako dorosła osoba, że no coś może pójść nie tak. I podobnie jest z AI-em, no jeżeli nam nikt nie wytłumaczy, nikt nie pokazuje nam tego drobnego kruczku, w jaki sposób był przebierany ten modus operandi tego języka, W jaki sposób wyplułem te dane? Jesteśmy w stanie dalej próbować to pushować, ale robimy to trochę po ciemku. Palimy tokeny, palimy czas, palimy tak naprawdę próby, gdzie możliwe, że trzeba będzie zmienić po prostu parading map, więc realnie kosztowne.

Mateuszu, a powiedz mi, AI co do zasady, Ten kod, który generuję, on go generuje tak dość ładny, nie? W sensie... Może nie zawsze to jest najlepiej zaprojektowany kod, no ale przynajmniej, że tak powiem, mid developer by się go nie powstydził. Jakby jest w miarę składny, ładnie sformatowany, często obkomentowany już od razu na wejściu. Nazwy zmiennych też są zazwyczaj jakieś sensowne. Wygląda tak co najmniej na 7, 8, na 10 jakby przyzwoicie. I teraz pytanie jest czy Jakby, że tak powiem, po zapachu, po wyglądzie, jesteśmy w stanie w ogóle zidentyfikować, że z tym kodem może być cokolwiek nie tak?

Natomiast wydaje mi się, że nie powinno nas to zwalniać z odpowiedzialności, żeby ten kod jednak przeglądać. Nie sądzę, by ocenianie kodu po samych komentarzach i o tym, że one są przeważnie przekonywujące. Tutaj to była taka intencja, dlatego tak to zostało zrobione. Ja osobiście mam z tym problem, że często AI mi wrzuca za dużo komentarzy. Ja nie lubię kodu, w którym jest zbyt dużo komentarzy, no bo funkcje powinny opisywać same siebie i jeżeli kod jest dobrze zaprojektowany, zgodnie z jakimiś dobrymi praktykami, to się go po prostu łatwo czyta. W miarę, wiadomo. Chyba, że przesadzimy z jakimiś wzorcami architektonicznymi na siłę, bo to też nie ma co odbijać w drugą stronę. Natomiast tak, zmierzając do sedna, wydaje mi się, że jesteśmy w stanie i powinniśmy to robić, oceniać ten kod, który jest wypluwany przez AI.

Tutaj jakby nie ma wymówek. AI ma tendencję do duplikowania kodu i pozornie może to się wydawać niegroźne, ponieważ możemy sobie równie dobrze, równie łatwo wygenerować kolejne funkcje, które robią praktycznie to samo. I nie przejmować się tym, żeby gdzieś tam podziedziczyć po jakiejś klasie i tak dalej, żeby ten kod był poprawny z takiego inżynierskiego punktu widzenia. Także jest to pokusą, ale wydaje mi się, że powinniśmy tutaj stać na straży i taka jest nasza rola jako doświadczonych inżynierów, żeby tego pilnować, żeby nie pozwolić, żeby świat programowania poszedł w tą stronę.

Obecnie możemy tam władować dużą ilość informacji i po prostu traktujemy albo pamięć dyskową, tak samo traktujemy to jako coś po prostu zbędnego, ładujemy tam Zdjęcia małych kotków. Tak w przyszłości prawdopodobnie będzie tak samo z kontekstem, gdy moc obliczeniowa, ewentualnie algorytmy będą skonstruowane pod specjalnie kontekst. No i też tutaj przytoczę sobie troszeczkę z Bitcoina. Kiedyś było tak, że bloki były liczone bezpośrednio na komputerach fizycznych. Później powstały specjalizowane maszyny. Jeżeli cały świat obecnie jest zapatrzony na AI, prawdopodobnie powstaną maszyny specjalnie dedykowane pod AI.

Raz, że będą większe możliwości. Pod tym kątem, a dwa, że ten tooling będzie się poprawiał i dobre praktyki pracy z AI, które też są wciąż wypracowywane. Różne są podejścia. Spec-driven development, o którym tu mówiliśmy, na razie do mnie najbardziej przemawia. I wydaje mi się, że jeżeli będziemy pamiętać tego, żeby w projekcie były te ADR-y, zanim przystąpimy do implementacji jakiegoś większego feature'a, To też tymi plikami później możemy się posługiwać, żeby implementować konkretne taski, zmniejszając przy tym kontekst. No dobra, bo tutaj np. użyłaś takiego słowowego klucza, które cieszę się, że padło, np. garbage collector. Czasy, kiedy sami sobie malokowaliśmy pamięć i zarządzaliśmy wskaźnikami już chyba dawno minęły.

Jakieś segmentation faulty też już raczej coraz rzadziej oglądamy. Tak, a do dziś pamiętam laborki na polibudzie, kiedy oblałem właśnie zadanie przez wycieki pamięci. Wszystko działało idealnie, ale pamięć nie była zwalniana. No właśnie, i teraz jakby trochę przyjęliśmy, że ten garbage collector po prostu działa, jakby tam nikt się nie za bardzo wczytuje w środek, dlaczego to działa, po prostu działa. I czy nie dojdziemy do takiego samego etapu z AI, kiedy naprawdę go przyjmiemy za taką czarną skrzynkę, że już tak będzie wytestowana przez szeroko community na świecie, że po prostu działa, bo inaczej przecież ktoś by to Zgłosił, tak? To trochę tak jak, nie wiem, konektor do Postgresa, no jakby nikt nie sprawdza, czy konektor do Postgresa działa albo ile ma testów jednostkowych w sobie.

No i tak jest do dzisiaj. Natomiast wydaje mi się, że jeśli chodzi o garbage collector i o to jak, nie wiem, kod jest kompilowany Z tego powiedzmy kodu C-Sharpowego do kodu maszynowego, to jest jednak bardziej deterministyczne niż to co nam wypluwa AI. Na wejściu mamy jakąś tam ograniczoną liczbę parametrów i są jakieś reguły, które tym zarządzają i one się nie zmieniają chyba tak często, to już jest powiedzmy stabilne wszystko. Jeśli chodzi o AI, ten input mamy dużo większy i zmieniają się wersje modeli, zmieniają się wersje tooli, za pomocą których gadamy z tymi modelami, więc wydaje mi się, że teraz to jest zbyt dynamiczne, żeby można stwierdzić jednoznacznie.

Chyba, że to też by było jak w jakiś sposób ustandaryzowane, że te prompty byłyby budowane za pomocą jakiegoś wizarda, nie? I ten input byłby zawsze taki sam dla konkretnego typu zadania, I wiedzielibyśmy, że output, który dostaniemy, będzie dokładnie taki, jaki byśmy chcieli. Tylko wydaje mi się, że to jest zbyt złożone, że ten input jednak jest... tam jest zbyt dużo parametrów. Jakby ten prompt, który przekazujemy do AI rozłożyć na jakieś parametry konkretne, no to tam jest mnóstwo tego, bo to jednak jest... Słowo. To jest myśl w rozumieniu ludzkim i ona jest przekładana na tokeny. I te tokeny są tymi, powiedzmy, parametrami, ale tym inputem do procesowania tego dalej.

I czy nie będzie tak, że mała zmiana w prompcie zmieni całkowicie wynik? No to jest dobre pytanie, bo to też tak naprawdę może zależy od tego, jaki duży wpływ to ma na tokenizację, bo czasami jedna mała drobna zmiana potrafi znacząco zmienić tokenizację i potrafi w tym momencie to polecieć w zupełnie inną ścieżkę. Jeszcze jedna rzecz, język w jakim piszemy. Dzisiaj nie ma problemu, czy piszesz w języku angielskim czy w języku polskim, pracuje się mniej więcej tak samo z AI, o ile go pilnujesz, jesteś w stanie uzyskać podobny efekt. Także sam język nie jest problemem, ale pewnie wpływa jakoś na wynik. Mając ten sam prompt napisany po angielsku i po polsku, No to już tutaj wprowadzasz ten szum w postaci translacji po swojej stronie.