Krzysztof:
To jest 323 odcinek Porozmawiajmy IT. Dziś rozmawiamy o tym,

Krzysztof:
jak kod generowany przez AI wpływa na jakość i dług techniczny. Notatkę, linki i transkrypcję znajdziesz na porozmawiajmyoit.pl łamane na 323. A jeśli myślisz o zmianie pracy, albo po prostu masz dość klikania dalej na ogłoszeniach bez widełek, to zajrzyj na Solid Jobs. Tam wszystko jest na tacy. Wynagrodzenie, technologie, projekty. Bez zgadywania. Nazywam się Krzysztof Kempiński. Tworzę ten podcast, napisałem też książkę Marka Osobista w branży IT. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej albo zostaw ocenę w swojej apce. To jest dla mnie nieoceniona pomoc. A teraz odpalamy! Cześć, moim gościem jest inżynier oprogramowania i przedsiębiorca z 20-letnim doświadczeniem w budowaniu zespołów inżynierskich i doradzaniu firmom technologicznym w Europie i Stanach Zjednoczonych. CEO i współzałożyciel firmy doradczo-programistycznej LLInformatics. Moim waszym gościem jest Łukasz Łażewski. Cześć Łukaszu i ponownie witam cię bardzo serdecznie w podcaście.

Łukasz:
Cześć Krzysztof, cała przyjemność po mojej stronie i również witam słuchaczy.

Krzysztof:
Mieliśmy okazję rozmawiać, tak jak sobie zerknąłem 4 lata temu, strasznie ten czas leci i w kontekście tej naszej rozmowy to mam wrażenie, że wręcz epoka wiele się pozmieniało i nie ukrywamy przed słuchaczami, że się troszkę czasu już znamy, nad niejednym projektem pracowaliśmy. Ja zawsze bez żadnej koketerii z mojej strony uważałem, że pomimo tego, że różne były technologie tych projektów, że różne mody i fale związane z technologiami się zmieniały, to zawsze miałem wrażenie, że skupiałeś się i mocno zwracałeś uwagę na takie podstawy, które później przekładają się na to, że produkujemy dobry software na koniec i jeszcze dodatkowo dobrze i miło nam się nad tym softwarem pracuje. I jestem bardzo ciekaw, czy w kontekście naszej rozmowy, bo chcemy poruszyć temat generowania kodu przez AI i wpływu właśnie tego generowania na jakość, na dług techniczny, który jakoś przy tym powstaje. Czy również wyjdzie ten wątek właśnie skupienia się na podstawach, które leżą właśnie gdzieś u fundamentów tej naszej branży? Myślę, że to pewnie w trakcie tej naszej rozmowy wyjdzie, ale zanim do tego przejdziemy, to chciałbym Cię zapytać o Twoje rekomendacje podcastowe. Czy coś się może właśnie na twojej liście podcastów zmieniło, czy coś ciekawego możesz zaproponować słuchaczom?

Łukasz:
Jasne, od tego zacznijmy. Wiesz co, pewnie ze względu na wieki, zmianę sytuacji życiowej, rodzina przez te cztery ostatnie lata skupiłem się bardziej na longevity, więc poszedłem w takie tematy właśnie zdrowotne, zdrowej diety, pewnych mikroćwiczeń, bo na pełną siłownię po prostu nie ma czasu. I bardzo sobie cenię Mateusza Sobieraja i jego podcast na ten temat jest jakby totalnie w temacie, ma fantastycznych gości zarówno z Polski, jak i z zagranicy, gdzie omawia te wszystkie techniki, gdzie omawia jakie badania wykonać, jakim chorobom przeciwdziałać, także świetny podcast, jak ktoś ma bardzo mało czasu, tak jak ja, a interesuje się longevity, to wydaje mi się to jest go to person w tej chwili w naszym kraju.

Krzysztof:
Świetnie, osobiście nie znam, ale z chęcią sobie zerknę, bo też jestem dużym fanem właśnie takiego, można powiedzieć, mikro-learningu w tym przypadku małych dawek, które sobie gdzieś tam aplikujemy, kiedy jest na to czas z chęcią zerknę i dzięki za to.

Krzysztof:
Rekomendacje. Okej, a wiesz, tak jak tutaj sobie właśnie przed nagrywaniem jeszcze mówiliśmy, nie do końca się utarł, nie do końca się wypracowały różne standardy związane z tą rewolucją AI-ową i generowaniem kodu. Wiele osób gdzieś z tym eksperymentuje. Pomimo tego, co często możemy gdzieś tam widzieć na LinkedInie, no to oczywiście ta adopcja nie jest jeszcze tak daleko posunięta, jak z tego obrazu mogłoby wynikać. Wszyscy gdzieś tam trochę tego tematu dotykają, próbują, podpatrują, no po prostu ten temat się dopiero, mam wrażenie, wykluwa. Ale niezależnie od tego, jak bardzo dana firma, dany programista, w danym projekcie jest zaangażowany w wykorzystywanie narzędzi AI, no to pewnie można tam zauważyć, że tego kodu powstaje więcej niż miało to miejsce, kiedy robiliśmy to ręcznie. I to oczywiście nie likwiduje wszystkich problemów, nie znosi wszystkich bolączek, mam wrażenie, że po prostu uwypukla nieco inne miejsca, czy też obszary, fazy powstawania właśnie software’u

Krzysztof:
I taki problem swego rodzaju, który się pojawia, to jest to, że Łatwo nam ten kod przychodzi do generowania, ale nie zdajemy sobie

Krzysztof:
Sprawy przy tym generowaniu, że dodajemy coś do tego codebase’u, rozszerzamy codebase, w związku z tym będziemy musieli go utrzymywać. No i oczywiście to nie jest problem w przypadku jakichś tam podsłów, w przypadku jakichś jednorazowych projektów towarzyszących jakimś kampaniom marketingowym, bo to wszystko gdzieś tam później pójdzie do kosza, no ale wiele projektów żyje latami i kod raz wygenerowany trzeba będzie utrzymywać, ktoś to będzie musiał robić. Więc chciałbym Cię zapytać, co z jakością, co z takim wpływem na, można powiedzieć, no właśnie quality tego naszego całego projektu, produktu, kiedy kodu przybywa, a tak naprawdę to nie my jako programiści go piszemy, tylko generujemy. Nie zawsze jest wystarczająco czasu na code review, nie zawsze jest wystarczająco czasu na jego pełni takie zrozumienie.

Łukasz:
Tak, obserwuję to w różnym stopniu, również dlatego, że rynki europejski i amerykański bardzo się różnią pod tym względem od siebie. Wiesz, AI Act w Europie trochę blokuje pewne działania i ogranicza spółką tutaj na naszym nazwijmy to europejskim rynku, nawet w Polsce czy poza Polską.

Łukasz:
Natomiast zanim odpowiem o twoje pytanie, o tą jakość, to mam dwie obserwacje, które są potencjalnie do zaparkowania i omówienia też. Pierwsza jest taka, że cały ten proces, również związany z jakością, rozbija się o odpowiedzialność, o to finalne accountability, do kogo się zwracamy, jak coś się wysypie. To jest w ogóle bardzo ciekawe i na poziomie pojedynczego programisty, który teraz steruje tymi modelami, i na poziomie całego biznesu.

Łukasz:
I co przez to rozumiem? Jak w latach 90., gdy zaczynaliśmy, kończyliśmy studia, zależy kto kiedy, to pod koniec lat 90. Wyszedł ten Linux, to wszyscy obserwatorzy rynku IT mówili, kurczę koniec Microsoftu, bo masz darmowy system operacyjny, potem fundacja GNU wypuściła darmowe narzędzia, zarówno koderskie jak i takie nazwijmy do szeroko pojętej pracy biurowej, powstał Open Office, to już trochę później, ale powstał Open Office i na koniec dnia wszyscy byli przekonani, że Microsoft jest skończony, prawda? Powód, dlaczego to się nie działo w retrospekcji według mnie i według kilku osób, z którymi dzielę to zdanie, jest taki, że na koniec dnia, jak masz tego Linuxa z darmowym pakietem Office i on działa, to jest super, ale jak coś się wykrzaczy, tracisz dane, tracisz dokumenty, to nie bardzo masz się do kogo zwrócić o pomoc. Oczywiście powstają firmy third party, które to obsługują, ale nie bardzo masz na przykład możliwość postawienia SLA. Tak? I znowu da się to zrobić, ale to tu się pojawia problem business flow.

Łukasz:
I teraz przenosząc to na dzisiejszą rzeczywistość z AI, mi się wydaje, że jest bardzo podobnie. To znaczy, kiedy ja widzę taki zahajpowany artykuł z lutego tego roku, że dwóch panów z nie pamiętam jakiej gazety, czy redakcji telewizyjnej w ciągu dwóch godzin skopiowało firmę Monday.com przy pomocy vibe kodu, no to już abstrahując od tego, że mam szereg pytań, czy naprawdę to działa i w jaki sposób działa i czy rozumieją oni takie aspekty, jak to, że to jest narzędzie do pracy zespołowej, więc fakt, że działa z laptopa tego gościa niekoniecznie świadczy o tym, że ktoś zewnętrzny może, uczestniczyć teraz w tym projekcie i dokonywać zmian w tych tiketach, to abstrahując od tego, ja zawsze zadaję to pytanie, czy porównujemy jabłka do jabłek. I to jest jeden pattern, który obserwuję. Bo teraz ci panowie, oni to sobie wygenerowali, ale czy wyobrażamy sobie, że w ich redakcji oni są teraz odpowiedzialni za utrzymanie tego, za dalszy rozwój? A co jak oprogramowanie, czy to, na czym to działa, bo na koniec dnia nadal są to jakieś serwery aplikacji na jakichś serwerach fizycznych gdzieś lub w jakiejś murze gdzieś. A co jak to się zaczyna przedawniać, jak się starzeje ta infrastruktura i ten kod? Kto za to odpowiada? Co jak ten pan dostaje awans albo jest przechwycony i idzie do pracy dla innej redakcji? Więc znowu jest to ten problem accountability. I tu dochodzimy moim zdaniem do sedna sprawy i jak ja w ogóle uważam, że tego typu wygenerowany kod będzie stosowany, to oczywiście są.

Łukasz:
Rozwiązania peryferyjne, czyli ktoś dla siebie to rozwiązał pewien problem versus dedykowana firma budująca produkt lub dedykowana firma usługowa, która na co dzień zajmuje się programowaniem. Co nie zmienia faktu, że podobne pytanie musimy sobie postawić nawet w tej sytuacji, o to accountability, i o w wielu wypadkach również traceability, czyli udowodnienie jak coś zostało

Łukasz:
wygenerowane lub stworzone. I tu schodzimy do twojego pytania o tą jakość.

Łukasz:
Obserwuję wolę taką, jeszcze jedna dygresja, przepraszam, żeby to skontekstualizować. Obserwuję, że to ludzie, którzy kodują, mają dość duży opór przed wdrażaniem tego AI. Jednym z argumentów jest argument jakości. I wiele osób, zwłaszcza w biznesie, myśli, że jest to opór, strach przed zastąpieniem. Także, że jasne, mamy 100 osób dzisiaj w zespole koderskim, jak prowadzimy AI, a wzrośnie wytajność o 20%, no to prezes podpisze wypowiedzenia dla 20 z tych 100 osób, no bo będziemy mieli ten sam rezultat, more or less.

Łukasz:
Ale ja nie zgadzam się z tą tezą. Ja uważam, że tu zachodzi takie zjawisko, jak pewnie pamiętamy wspólnie, prawda, z naszych prac, że biznes w pewnym momencie decyduje, kurczę, ten tam, nie wiem, Kowalski to świetnie koduje, jest genialny, ma autorytet w zespole, zróbmy z niego menadżera. Największy grzech biznesu i krzywdę, jaką można zrobić bez oczywiście zakładając, że to zostało jakoś przegadane z tą osobą, że to nie jest tylko decyzja, podparta pieniędzmi, tylko ta osoba na przykład po prostu chce się rozwijać w tym biznesie, to oczywiście wtedy to jest właściwa decyzja, ale z mojego doświadczenia wiem, że 90% takich decyzji jest nietrafione, bo incentive takiego człowieka to jest, no ok, jestem super seniorem, team leadem, zostanę kimś tam wyżej, VP of engineering i to jest już teraz bardziej, meetingosa niż kodowanie. I co tu się dzieje? Ten człowiek jest taki programista, który nie ma preferencji czy predyspozycji, żeby zostać menadżerem, jest przede wszystkim twórcą kreatywnym w moim przekonaniu. I zarządzanie wieloma modelami AI, agentami, tworzenie loopów, czy tych wszystkich architektur, które teraz powstają, fantastyczne skądinąd, jest procesem zarządzania, a nie procesem kreatywnego tworzenia coraz bardziej.

Łukasz:
I to jest dla mnie jedno z sedno problemu dotyczącego jakości, bo tak samo traktujemy wszystkich programistów, oczekując, że oni wszyscy będą teraz zarządzali tymi agentami, czyli wszyscy stają się menadżerami, abstrahując od problemu, zwolnień masowych i całej reszty, co biznes o tym potem myśli i jak bardzo to też jest nietrafione, co już pokazują obecne odwrócenia trendu i z powrotem zatrudnianie przez duże spółki masowe ilości programistów.

Łukasz:
I wydaje mi się, że tu jest pies pogrzebany, bo jeśli ktoś jest osobą kreatywną, z pewną wizją nawet na frontend, czyli na przykład nie ja, nie backendowiec, to może odnaleźć się w takiej roli w inny sposób niż ja bym się odnalazł. Ja już w tej chwili nie koduję, tak, full disclosure od kilku lat i to jest ciekawy moment dla mnie, bo już czuję, że nie mógłbym do tego wrócić właśnie z tego powodu, którym teraz się dzielę, bo ktoś z pewną wyobraźnią, nazwijmy to wizualną, której ja nie mam, generuje produkty, nie mówię o pocach, ale nawet całych feature’ach, w sposób dużo bardziej doskonały w finalnym efekcie niż ja bym to zrobił kiedykolwiek. Chodzi mi o to, że zamiast samej wiedzy koderskiej bardziej doceniamy teraz generyczne umiejętności zarządzania projektem, zarządzania produktem i oczekiwaniami klienta po drugiej stronie, nawet wewnętrznego, prawda? Na to, jak ten feature ma działać i wyglądać. A to, czy to jest zakodowane w Java, w JavaScriptzie, w dotnecie, czy czymkolwiek innym i to, jakie funkcje są pod spodem, jest drugorzędne. To wiem, że mówimy potem, trochę wspomniałeś o tym wcześniej, o tych spekach i całej reszcie. To jakby kod staje się w ogóle drugorzędnym tematem. On teraz naprawdę będzie commodity.

Łukasz:
I tu, wracając do twojego pytania o jakość, tu jest pies pogrzebany, czym jest ta jakość? Bo ona staje się mniej relewantna momencie, kiedy masz wszystko przygotowane i człowieka, który to ogarnia i masz procesy u podstaw, również te biznesowe, przede wszystkim te biznesowe, bo na koniec dnia technologia ma służyć biznesowi, które mogą być wielokrotnie reinterpretowane przy pomocy kolejnych i kontekstualizowane dla kolejnych agentów, żeby odbudowywać lub przebudowywać ten kod. Wręcz nawet od nowa, tak długo jak oczywiście zostawimy wsteczną kompatybilność dla danych, które są w bazie danych i tak dalej. Więc moim zdaniem ta jakość nie ma takiego znaczenia, oczywiście znów wszystkie testy AI lub otherwise, jakiś człowiek musi to przeklikiwać, to musi działać. Ja zakładam po prostu to absolutne minimum. Ale wiesz, takie rzeczy jak wyznaczenie sobie trendów kodowania, czy stylu kodowania, Dla mnie się to staje drugorzędne. Już pomijam, że możesz to raz spisać i każdy model używa tego samego i reviewowanie pod tym kątem ludziom przestaje być potrzebne, tak?

Krzysztof:
Tak, absolutnie, absolutnie. Zgodzę się z Tobą, że to jest problem złożony z wielu warstw, bo oczywiście możemy dany kod, dany feature, dany fragment przegenerowywać nawet w innych technologach, w innych językach, w innych frameworkach. Oczywiście można powiedzieć, że wchodzi tutaj koszt tokenów. No, możemy oczywiście o tym temacie dyskutować, ale zgodzę się absolutnie, że definicja jakości się tutaj zmienia. Zmienia się też podejście do review, na inne rzeczy, znacznie wyższego poziomu, znacznie wyższej abstrakcji. Powinniśmy wówczas zwracać uwagę, a nie na właśnie jakiś tam guideline naszy związany z tym, że zmianę nazywamy tak, a funkcje tak i tak dalej, i tak dalej.

Krzysztof:
Wspomniałeś tutaj o traceability i myślę, że to jest też taki istotny temat, ponieważ miałem jakiś czas temu rozmowę z kimś, kto jest dużym fanem właśnie takiego podejścia na zasadzie, może z pominięciem zrozumienia tego, co zostało wygenerowane. W sensie, jeśli działa, jeśli spełnia jakieś tam założenia funkcjonalne, to jest okej, to jest po prostu tylko jakaś forma połączenia pod spodem jakiegoś pipeliningu, który nie jest istotny z naszego biznesowego punktu widzenia. Jeśli to działa według założeń, to po prostu wrzucamy na produkcję. I ta osoba pytana o to, no dobrze, ale co w przypadku, kiedy o trzeciej w nocy nagle coś się wysypie i ty nie rozumiesz właściwie, jak to pod spodem jest złożone. No ta osoba próbowała to zbijać argumentem, że po to ma narzędzia AI, żeby ewentualnie ten problem albo szybko zrozumieć, wyciągnąć jakąś tam szybką analizę, bo wręcz naprawić, więc jakby jedno możemy leczyć drugim.

Krzysztof:
I ten problem traceability, o którym wspomniałem, myślę sobie, że

Krzysztof:
W pewnych obszarach, w pewnych branżach może mieć znaczenie większe, a w niektórych tam jest pomijalne, tak jak na przykład wspomniałeś i nie musimy się nad nim mocno skupiać. Ale wiem, że też jako firma robicie wiele projektów na przykład związanych z healthcare, czy z finansami itd. To są takie branże, gdzie zgodnie z przepisami, zgodnie z wytycznymi my musimy dość deterministycznie wskazać, dlaczego coś zadziałało w ten sposób, dlaczego wyciągnęliśmy taką decyzję, no bo tutaj jak gdyby finanse i zdrowie człowieka są najważniejsze. Czy myślisz, że tutaj niejako wprowadzenie takiego generowania kodu przez AI degraduje nam nieco albo zmniejsza właśnie ten poziom przewidywalności tego kodu, czy my być może musimy inaczej nieco podejść do tworzenia tego software’u, nieco bardziej rozumieć to, co akceptujemy, poruszając się w projektach właśnie związanych z tymi branżami?

Łukasz:
To jest doskonałe pytanie. Pozór, że odniosę się najpierw do tej konwersacji z tą osobą, bo ona jest kontekstowa. To znaczy, ja bierzę trochę w to, co Jeff Bezos powiedział jakiś czas temu, że są dwa rodzaje decyzji biznesowych. Takie drzwi, które przechodzisz i możesz zawsze przez nie wrócić i takie drzwi, które się za tobą zamykają. Innymi słowy, jeśli mam system, który jest produkcyjny i są na nim żywi klienci, którzy tam operują, którzy mają SLA-ie, którzy mają pewne oczekiwania związane z utrzymaniem i działaniem tego systemu, to dokonywanie zmian na tym systemie może być niemożliwe z punktu widzenia rozwiązania AI-em czy ludźmi w, nazwijmy to, dopuszczalnym czasie biznesowo.

Łukasz:
Jeżeli podejmiemy złe decyzje na początku dotyczące struktury bazy danych, to nie tylko musimy zaproponować nową strukturę bazy danych on the fly, ale również proces migracji i przeniesienia tych danych, który wiąże się z ryzykami, więc warto puścić pewne testy i dokonać tych rzeczy już w semi-automatyczny sposób. I AI nie myśli za nas w każdym casie, ale przede wszystkim programistycznym. Więc kiedy obserwuję ludzi, którzy mówią do prompta make me great, make me rich, to oni troszkę nie rozumieją, że trzeba go nakarmić pewną ścieżką rozumowania. Szybki przykład. Budowałem jakąś tam aplikację w cloud dla siebie samego, nazwijmy to z pewnymi prywatnymi rzeczami, których nie chciałem korzystać z zewnętrznych narzędzi i potrzebowałem tego mieć, to po prostu mieć na laptopie, ewentualnie podzielić się z małżonką. I gdy opisałem tego prompta dość szczegółowo, to ten cloud powiedział super, wybieram dla ciebie node’a, zrobimy to tak, zrobimy to tak.

Łukasz:
Jako, że mam doświadczenie to koderskie i nie koduję już w tej chwili, ale właśnie się bawiłem w ten sposób, to powiedziałem mu, a co cię powstrzymuje przed zbudowaniem tego natywnie na macOS-ie w Swifcie? I on mi mówi, świetna decyzja, masz rację, zróbmy to w Swifcie.

Łukasz:
Mój punkt jest taki, że gdybym tego nie wiedział, albo gdybym jakoś mnie dopytał i tej wiedzy nie uzyskał, to on mnie prowadzi pewną probabilistyczną ścieżką wyborów, które mogą być niesłuszne i nienajlepsze dla mnie lub dla mojego biznesu.

Łukasz:
I to jest to, gdzie pewna wiedza kontekstowa, w przypadku healthcare na przykład, lekarska lub prawnicza niestety, bo to jest bardzo duży compliance, wycieku danych, danych pacjentów i tak dalej, pewnej anonimizacji, jest krytyczna. I ja tego nie przeskoczę na przykład jako programista. Więc odpowiadając na twoje pytanie, my inwidualizujemy te case’y, czyli dla healthcare jest drugoznaczne, jak kod został wygenerowany, czy go napisał człowiek, czy maszyna. Dla healthcare jest ważniejsze gdzie, kiedy i jak i kto ma dostęp do danych. Czyli tu się pojawia problem, ok, wygenerowaliśmy najlepszy na świecie kod i on śmiga, od razu, ale musimy się upewnić, że tam nie ma otwartych luk w API, którymi ktoś z internetu może sobie zastać całą bazę pacjentów, bo to jest bardzo poważne naruszenie HIP-y i GDPR-a. I właściwie kładzie firmy, takie coś. W związku z czym te problemy są na innym poziomie, czyli trzeba mieć świadomość security, safety, testów penetracyjnych. Nie trzeba tego umieć, ale trzeba mieć tą świadomość, że to warto wykonać i trzeba mieć świadomość, że warto takie rzeczy odseparować biznesowo, czyli nie robić tego wewnętrznie innym AI-em, tylko wziąć partnera, również ze względu na accountability, odpowiedzialność i certyfikację tego partnera, której my teraz nie uzyskamy, bo to nie jest nasza specjalizacja. Także.

Łukasz:
Trochę próbuję powiedzieć, że ludzie myślą, że teraz AI-em każda firma zrobi sobie sama wszystko. I teoretycznie jest to możliwe w nieskończonym czasie, przy nieskończonych resursach i nawet tym, jak ten AI się rozwija. Ja też jestem tutaj optymistą, że to będzie coraz lepsze. Ale są konstrainy rzeczywistości obecnej i samoświadomości tych użytkowników, czy tych osób, które te polecenia wydają, czy nawet tych pętli, które już puścimy i się potem same udoskonalają tych różnych agentów. Które nie przeskoczą z rzeczywistości obiektywnej, która jest za oknem. I to jest dla mnie najbardziej krytyczne, czyli wiedza i świadomość ludzi. Zauważę.

Łukasz:
Że startupy często są budowane na ura, bo ktoś ma ideę i nie rozumie pewnej konsekwencji. Dochodzi do pewnego momentu, robi financing, dostaje tą kasę i dopiero są implementowane komplianse, bezpieczeństwo, cała reszta. W tym też to finansowe, księgowe, prawne, podatkowe itd. i tak dalej. To jest bardzo częsta lekcja młodych przedsiębiorców, nomen, nomen, że pewne rzeczy, które zakładali, że robimy tak, no bo winny i coś tam, i przelewam pieniądze, a potem się okazuje, no wiesz, ale Urząd Skarbowy chce o tym wiedzieć. I ja nie zakładam, że każdy młody przedsiębiorca jest nagle ekspertem sprawa podatkowego, ale zakładam, że ma dość samoświadomości, żeby spytać i zatrudnić third party do tego. Nawet jeśli w tym third party, nomen, nomen, w przyszłości będą modele czy agenty czy AI, akurat w tym wypadku, bo to jest bardzo prosty temat z punktu widzenia AI-a. Także tu jest moja granica i ona jest bardzo subtelna i czasem ciężko ją złapać, tak? Czyli tak jak powiedziałeś z tą osobą, z tym kolegą, koleżanką, z którym wcześniej rozmawiałeś, ja się zgadzam, występuje błąd, możesz go przeanalizować AI-em, tylko AI ci może powiedzieć, wiesz co, musimy to zaorać i zrobić od nowa, a to nie jest opcja na stole, tak? Bo na podstawie tej lekcji, którą teraz wyciągnęliśmy, że to się przestało skalować, i nie możemy tego w nieskończowość wertykalnie skalować, a nie przewidzieliśmy wcześniej, bo nie pomyślałem o tym, ja jako EJA, a ty jako użytkownik, że mam dołożyć system kolejkowy od początku, to mamy problem.

Krzysztof:
Zgadza się. Zgadza się absolutnie. Myślę, że takie dwa główne wątki, które wyciągam z tego, co do tej pory powiedziałeś, to jest odpowiedzialność i to jest też nieco zmieniająca się definicja pracy programisty. Spróbujmy może te dwa elementy połączyć. No właśnie, kto według ciebie albo na jakim etapie bierze odpowiedzialność za kod, który generuje i jak zmienia się rola seniora w projekcie. Jeśli to nie jest już osoba, która tylko zajmuje się generowaniem kodu, a w dużej mierze przynajmniej z mojej obserwacji z projektów, które widzę, to jest osoba, która bardzo często jest takim gatekeeperem swego rodzaju, która gdzieś tam pilnuje różnych standardów, która reviewuje ten kod, która stara się gdzieś tam może edukować i tak dalej, i tak dalej. Czy ta rola też się zmienia teraz? Ciężar pewnych obowiązków się nieco przesuwa na inne obszary? Jak ty widzisz, jakie masz tutaj też obserwacje w tym temacie?

Łukasz:
Tak, ja, świetnie, że podjąłeś ten wątek dalej, bo ja tutaj dopowiem, jakby wyklaryfikuję ten element wcześniejszych wypowiedzi. Kiedy mówimy o tych strukturach i zmianie tej pozycji programisty, to wyobrażam to sobie tak. Kiedy mamy dzisiaj, przepraszam, w świecie sprzed AI mamy zespół, który składa się z jakiegoś seniora dwóch, trzech regularów i nie wiem, pięciu juniorów, hipotetycznie, to element kontroli tych juniorów jest pracą, jest ciężką pracą, jest bardzo odpowiedzialną pracą, ale nie jest kodowaniem samym sobie. Prawda? I ja teraz traktuję te modele i tych agentów jako takich mid-tier do low-tier, junior do mid-a programistów. A to oznacza, to nie jest kwestia słuchaj, popraw ten bug, to oznacza, że trzeba jako ten senior rekontekstualizować konwersację z tym modelem, tak jak uczysz juniora.

Łukasz:
Słuchaj, drogi czacie GPT, który injektujesz te śmieszne, długie, nie minusy, tylko myślniki brytyjskie do każdej wypowiedzi z defaultu. W naszej kulturze się ich nie używa, więc proszę cię, nigdy więcej, w żadnej odpowiedzi do mnie ich nie stosuj. I on wtedy buduje wewnętrzną bazę wiedzy tego, o co go prosiłem w każdej kolejnej konwersacji, nowej lub tej samej, bo to już jest wiedza ogólna, już nigdy nie zastosuje tego myślnika. Na przykład.

Łukasz:
Są elementy custom, które ktoś ma w swoim theme mailowym, tak sprowadzając to poza temat samego kodu, ale w kodzie jest to samo. Możesz poprosić o rozpoczynanie maila mniej lub bardziej oficjalnie. Możesz podpisywać się jedną z wielu dostępnych stopek w zależności od tego, do kogo piszesz. I to wszystko jest pewna baza wiedzy, która częściowo uczy się ten model, a częściowo możesz ją zamrażać w jakimś markdownie, którym go karmi się i rekontekstualizujesz za każdym razem. I tak samo jest przy kodowaniu. To jest pierwszy element, albo nawet bym powiedział drugi, bo poprzedzającym elementem, który obserwuję wracając już do świata koderskiego i seniorów, jest reinterpretacja zadania do zrobienia.

Łukasz:
Czyli zanim jeszcze zaczniemy pracować z kodem, a w takim najbardziej wypasionym flow, jaki widziałem do tej pory u naszych klientów teraz takich legal techowych w Stanach, to to jest tak, że model AI-owy analizuje Jira, widzi co jest do mnie asigniente dzisiaj. Na podstawie tego ja mogę go dopytać i nie poświęca mi czasu product manager czy product owner, tylko ten AI mi to tłumaczy. Bo wszystkie rozmowy i konwersacje projektowe z punktu widzenia produktu i biznesu są nagrywane, transkrybowane, uzupełniane o zdjęcia i rysunki, które powstawały odręcznie na tych warsztatach projektowych tego produktu. Potem jest to porównywane, jak to się wpasowuje w tikety, które ten produkt, napisał i jeśli programista czegoś nie rozumie lub zanim nawet zapyta pytanie i poświęci czas na zrozumienie, AI mu natychmiast robi TLDR, tak, too long to read, ale też, podsumowania i wskazówki, że słuchaj, To jest opisane w ten sposób, ale na spotkaniu były jeszcze te dwie alternatywy. Czy chcesz, żebyśmy postawili trzy branche zamiast jednego i te alternatywy też poprowadzili?

Łukasz:
I tu jest maksymalna zmiana, bo jednym z największych w top, ja uważam, że 75% problemów na projektach to nie są tematy koderskie czy programistyczne, tylko na łączeniu, wymagań i przekazywania wymagań od osób produktowych, projektowych czy klientów końcowych do zespołu programistycznego. I to jest po obu stronach oczywiście, bo programista też ma odpowiedzialność, żeby to odpowiednio zinterpretować i dopytać. Ale AI totalnie eliminuje ten problem. Łącznie z tym, że kiedy jest ten intake produktowy, to AI w drugą stronę też mówi, słuchaj Łukasz, ale mówisz tu jakimś logo, ale nie załączyłeś mi pliku. Czy ten programista ma to sam placeholder wstawić, czy ma sobie coś, nie wiem, z internetu ściągnąć, czy pójść do Ani, która jest w zespole designerskim i ona mu wygeneruje to logo. I ten produkt owner też ma takie, no tak, faktycznie, mam dependencję na UX-owcu, UI-owcu na przykład.

Łukasz:
Cały ten proces jest enhancenięty przez AI, wreszcie ląduje to na ekranie tego programisty, dostaje on teoretycznie do tego, feature’a, czy bug fixa, czy epica i przygotowywany jest mu plan pracy. I w ostatecznym momencie nawet, tylko w tej jednej filmie to widziałem, generowane są PR-y z rozwiązaniem i ten senior naparza, słuchaj, 20 do 30 feature’ów dziennie, ponieważ tylko siedzi i reviewuje, o, ten mi się podoba, ten mi się podoba, ten mi się nie podoba, tutaj jeszcze feedback, tu reiteruję, tu rekontekstuję, a tu dopytuję product tonera i to jest jedna wielka konwersacja, z różnymi agentami w różnych formach. To jest to, co miałem na myśli, kiedy powiedziałem wcześniej, że teraz jesteś tym gościem, który zarządza tymi juniorami, lub który stał się tą osobą nie tylko koderską, ponieważ musisz mieć tą wiedzę, żeby zrozumieć, że tutaj on idzie w złym kierunku, bo są takie i takie ryzyka, bo wiesz to z przeszłości.

Łukasz:
Ale też tą produktową i też tą potencjalnie wizualną, bo rozumiesz, jaki jest efekt końcowy. Nagle zatarła się w ogóle, obserwuję to, zatarła się bardzo mocna różnica między frontendowcem a backendowcem. Po prostu wszyscy są full stackami, tak? I w razie wątpliwości, co ja sam robię, bo jestem totalnym bezstalenciem wizualnym, mówię mu widzisz dropbox.com, widzisz tamtą stronę? Ja chcę tak samo. I on po prostu buduje mi, wiesz sam jak to działa. Więc w tym wypadku wiele stoperów, które do tej pory były na projekcie. Oczekiwanie między backendem a frontendem. Oczekiwanie na integrację między API a konsumerem tego API. Oczekiwanie, że Product Owner Mi coś wyjaśni. Te wszystkie elementy zostały, wyeliminowane albo sprowadzone do absolutnego minimum tych wyjątkowych case’ów, gdzie ten model sobie nie radzi albo pytanie jest tak specyficzne, że trzeba to poprawić, ale to zawsze jest iterowalne, bo to jest loop. I najmocniejsze loopy, najmocniejsze pętle są z ludźmi, nie na samej jajach. Tak, bo Product Owner potem się uczy i jego kontekst, jego modeli, które są facing do niego mówią mu, słuchaj, to ja tutaj dodaję do tej checklisty, którą robimy po każdym spotkaniu, gdy spisujemy etikety, ten element, żeby zawsze sprawdzić, czy nie masz dependencji na przykład na designerce, designerze, UI, UX-owcu.

Krzysztof:
W takim flow, w takim modelu naprawdę to może dobrze działać, ale myślę sobie, że jeszcze jesteśmy chyba na takim etapie, gdzie wielu z nas niejako zachwyciło się możliwością szybkiego wygenerowania czegoś, jakiejś namiastki produktu, projektu, co tutaj też na swoim przykładzie opisałeś. Ja to trochę odnoszę do tego, pamiętasz, jak pojawiło się Ruby on Race, w którym mieliśmy troszkę różnych przygód, tam też ta możliwość szybkiego wygenerowania jakiegoś scaffoldingu i tak dalej, pokazania była idealna do takiego proof of concept, bardzo szybko dało się coś wręcz na spotkaniu wygenerować, nie oczywiście za pomocą modelu, ale za pomocą różnych poleceń gdzieś tam w szelu. Natomiast zupełnie inny poziom, czy zupełnie inny nakład pracy był potrzebny, żeby później z tego Proof of Concept stworzyć jakiś faktycznie działający produkt na czterech nogach. I tutaj myślę sobie, że z tym AI trochę możemy być też w podobnej sytuacji, gdzie ta łatwość, jaką przychodzi nam postawienie całego

Krzysztof:
Projektu, tak jak powiedziałeś, nawet bez znajomości danych technologii, bo nie musimy faktycznie być programistą Swift, żeby sobie te komplikacje na Maca gdzieś wygenerować pod warunkiem, że mamy jakieś ogólne pojęcie o wytwarzaniu software’u, natomiast później przychodzi jeszcze ten często długi, mozolny etap rozwijania produktu, oczywiście zderzanie z jakimś rynkiem, szukanie tego market fitu itd.

Krzysztof:
I tutaj chyba potrzebne też są trochę inne skile, albo zupełnie inne podejście do tego wytwarzania oprogramowania, niż to ma miejsce w przypadku budowania tego Proof of Concept. Więc jestem też ciekawy twoich doświadczeń właśnie z takimi projektami typu POC. Dlaczego… Bardzo często one nie docierają na produkcję. Dlaczego rozbijają się już po tym pierwszym etapie?

Łukasz:
Tak, to znaczy wszystko, co powiedziałeś, mogę się oboma rynkoma pod tym podpisać. Ja to nazywam różnym stopniem dojrzałości kodu lub równym stopniem dojrzałości produktowej, to znaczy naszego pełnego pojmowania na poziomie biznesowym i produktowym, na ile to jest gotowe. I tutaj jest taka myśl, pamiętasz takie narzędzie balsamik, już praktycznie wymarłe dzisiaj?

Krzysztof:
Do skaczowania szybkiego, tak?

Łukasz:
Do szybkiego skaczowania i w swojej prostocie i podstawowym zamiarze było potwornie prymitywne wizualnie. Wyglądało, jakbyś rysował dla słuchaczy ołówkiem na kartce papieru. I kiedy zobaczyłem wywiad z tym twórcą tego narzędzia, to się za głowę złapałem, jakie to jest genialne, bo on dokonał takiego odkrycia, że jak pokażesz ludziom w Photoshopie, kilka stron, które są po prostu jpgiem, umówmy się, w eksportu, do JPEG-a, to ludzie myślą, że mają do czynienia z prawdziwą aplikacją. I ta nadinterpretacja prowadzi do błędów poznawczych i decyzji biznesowych, które są niesłuszne, bo są dużo daleko wychodzące w horyzont czasowy.

Łukasz:
Balsami, który związywał, bo zarządzał percepcją. Dla mnie jest kluczowe, więc to jest pewien pierwszy argument, który warto zważyć w głowie, a dla mnie jest kluczowe, żeby wykorzystać POC jako primarily throw away, totalnie do wyrzucenia, po to, żeby zebrać reakcję użytkownika końcowego, klienta końcowego. Bo on sobie może poklikać tą aplikację i albo nam napisać tikety, albo my możemy mieć nawet prostą implementację jakiegoś analityxa i zobaczyć, gdzie on utkwił w tym flowu. I kiedy ktoś, usłyszałem taką alegorię jakiś czas temu, ktoś po prostu to mnie też wgniotło w ziemię, jak to trafnie ocenia sytuację. Kiedy programiści rozmawiają z biznesem lub z osobami produktowymi, to tak jakby biznes im opowiadał film, pokazując im zdjęcia.

Łukasz:
A kiedy masz POC klikowalne, to oglądamy razem ten sam film i on jeszcze może być nie do końca, wiesz, sharp, ten obraz może być rozmyty, ale jednocześnie jesteśmy w tym samym filmie, w tej samej klatce i wszyscy rozumiemy, co się dzieje, jak żeśmy do tej klatki doszli, co ten bohater zrobił w sekundę wcześniej i dokąd zmierza. A to oznacza, że alignment zespołu, zrozumienie zespołu, jak ten flow ma wyglądać, teraz możemy usuwać, dodawać klatki, możemy je przestawiać miejscami, wszystko możemy zrobić, ale mamy pełen obraz sytuacji. I to jest mistrzostwo świata, że teraz takiego poca możesz mieć w kilka godzin. Absolutnie on się może nie nadawać. Wiesz, to może być zmokowane, to może być sam frontend. Wszystkie dane są po prostu twardo osadzonym tekstem w tym HTML-u czy czymkolwiek to jest.

Łukasz:
Przypomnę, że jeszcze niecałe dwa, trzy lata temu Figma robiła to świetnie. Dzisiaj ich biznes po prostu wyparował ta część biznesu i nie musisz mieć nagle, nie wiadomo jakich skilli, żeby to robić, a dokładnie o to samo chodziło wtedy z tymi UX, UAI-owcami, którzy byli w stanie przy pomocy prostych narzędzi jak Figma coś takiego poskładać do kupy. I wydaje mi się, że To jest level POCA, którego nigdy nie zakładałbym, że on ma skończyć na produkcji. Bo to, czym to ten AI wygenerował, jest drugorzędne do tego, że zebraliśmy pewną wiedzę z rynku, na przykład product market fit, sprawdziliśmy sobie, czy jest w ogóle sens to budować, versus co teraz budujemy z architektem, z biznesem, który mówi nam, słuchajcie, my mamy bazę danych i 50 tysięcy klientów od pierwszego dnia dołączy na tą platformę i ta informacja zmienia decyzję, w czym to kodujemy i w jaki sposób. Jak nastawiamy się na skalowalność na przykład jako priorytet w dewelopowaniu tej aplikacji. Coś, co bez tej informacji przy jakimś tam standardowym wzroście i tak dalej mogłoby być problemem. Jest wiele szczegółów oczywiście, które pomijam, no bo co znaczy 50 tysięcy klientów, ale przyjmijmy, że miliony operacji i transakcji będą się odbywały na tej platformie natychmiast i sprawny architekt, który już oczywiście ma te lata doświadczeń, powie, dobrze, to, może pewne rozwiązania znowu oparte o kolejki lub języki funkcyjne, które sobie radzą z takim flow informacji i liczbą transakcji jest bardziej preferowane niż nomen nomen rubion res chociażby tak, które jest.

Łukasz:
Jednowątkowe i to są.

Łukasz:
I to są tematy, które wyróżniają firmy teraz, genialne od takich, które pociągną tego poca, nawet może go wdrożą na produkcję w tym błędnym przekonaniu, że to, co im ktoś narysował ołówkiem na kartce papieru jest końcowym produktem i rynek zweryfikuje całą resztę. Bo mam też kontrargument paradoksalnie przeciwko tej całej tezie, którą teraz postawiłem.

Łukasz:
I brzmi on tak. Co by było abstrahując od elementu biznesowego, Jeśli popatrzysz na Worda lub Excela, nie mam tych danych za pewnik, ale strzelam z dobrym betem, założeniem, że to jest prawda, żeby ustawić pewien kontekst. 90% ludzi, którzy korzystają z Excela na świecie, nie ma pojęcia, czym jest pivot table.

Krzysztof:
100%.

Łukasz:
No nie? W związku z czym ludzie budują sobie tabelę, może budżet domowy i są szczęśliwi, a mają narzędzie, które jest kombajnem. Więc są sytuacje odwrotne do tej, którą przed chwilą opisałem. Są sytuacje, w których ktoś mi tu będzie mówił jakieś wielkie aplikacje, wiesz, w dewelopmencie na lata bez AI-a, nie? W dewelopmencie na lata i tak dalej, i tak dalej. A ja potrzebuję aplikacji do zarządzania domowym budżetem, która da mi jednego spreadsheet’a, która zliczy mi kolumny w poziomie i w pionie i która mi zrobi forecast na następny rok przy takiej czy takiej inflacji. Kropka. I ja uważam, że AI, takie pocowe, produkcyjne do takich rzeczy jest mistrzostwem świata. Jest mistrzostwem świata.

Krzysztof:
Tak, bo wiesz, mam wrażenie, że to był zawsze problem w percepcji ze strony biznesu, że pokazanie takiego poca było trochę jednoznacznie utożsamiane z tym, że my już mamy jakąś pierwszą wersję czegoś, co możemy na następny dzień wdrożyć, a tymczasem, tak jak tutaj słusznie zauważyłeś, to co leży u podstaw poca to jest to, że on za chwilę idzie do kosza, bo mamy jakąś tam tezę do zweryfikowania za jego pomocą, a nie chcemy dokładać ten kod do naszego podstawowego codebase’u.

Krzysztof:
Wiesz, chciałbym Cię zapytać, albo poruszyć taki temat swego rodzaju zagrożenia, które widzę, ale może się okazać, że to wcale nie jest zagrożenie, tylko przechodzimy obecnie przez pewną transformację. Mianowicie z moich obserwacji wynika, że jako programiści coraz bardziej pracujemy indywidualnie nad jakimś featurem, bo mamy wielu agentów, którzy nam w tym pomagają, bo możemy być nagle full stackami i tych interakcji z innymi specjalizacjami jest już mam wrażenie coraz mniej. Zastanawiam się, jak w ten temat wpasowuje się takie zagadnienie wiedzy plemiennej, która zawsze była, pewnych ustaleń, pewnych uzgodnień, które mieliśmy, które nie były nigdzie spisane, udokumentowane, ale tak się robiło, wiedzieliśmy, albo bardzo często jakaś jedna osoba w zespole wiedziała dokładnie, jak to funkcjonuje i na tym opieraliśmy działanie naszego dewelopmentu. Jak w tej erze, kiedy działamy bardziej indywidualnie, kiedy mamy dużo więcej sformalizowanej dokumentacji tworzonej przez albo do agentów jako input. Jak właśnie ten temat wiedzy plemiennej według ciebie może funkcjonować? Czy w ogóle ten temat nadal istnieje, skoro mamy dużą łatwość w tym, żeby pewne rzeczy dokumentować i ustalać?

Łukasz:
Moje doświadczenia ze Slackiem w różnych podgrupach czy konwersacjach mniej lub bardziej profesjonalnych pokazują, że te same pytania wracają. Nadal istnieją fora internetowe, bo ludzie nadal szukają odpowiedzi na te pytania, które stawia kolejne pokolenie programistów czy w jakiejkolwiek dziedzinie. Więc dla mnie to jest kwestia tego, wcześniej z tą wiedzą plemienną było tak… Że dokumentacja szeroko pojęta była zawsze dodatkowym efortem i bardzo szybko się przedawniała. I to jest odwieczna dyskusja i debata i nie ma jasnych zwycięzców i przegranych dokumentować, nie dokumentować sam kod, czy opisywać featurey, co z tym dalej robić. Dzisiaj ma się to niejako za darmo, bo odpowiednie skontekstualizowanie do modelu, które mi powie, słuchaj, fajnie, że mi napisałeś ten kod, a teraz nie tylko możesz mi go wytłumaczyć, albo dlaczego takie decyzje potem przy review podjął Łukasz, żeby tego nie zrobić. Czy to jest uzasadnione, czy to było zrekontekstualizowane do ciebie, co tam masz pamięci, niejako zachowuje tą wiedzę poza ludźmi.

Łukasz:
I to może oznaczać wiele rzeczy, że zrzucasz to co jakiś czas do PDF-ów, że wrzucasz to co jakiś czas z tego AI-a, z tego modelu, do markdownów, które uploadujesz. Nawet w githubie trzymamy często taką wiedzę kontekstową, czy właśnie plemienną, czy learningi dla tych modeli. Nawet jakby ten model stracił całą wiedzę, to możemy ją odzyskać, aplaudując mu te konteksty, czy czasami nazywamy je też konstytucjami, bo są to ramy, z których mu nie wolno wyjść, na przykład w kwestii tego, jakiego używa języka, czy na frontendzie, ze względu na sensitivity i sytuacji. Taki projekt związany z kobietami w ciąży i obsługą jakby porodową. I to jest bardzo krytyczny temat, jakim językiem się tam wyrażać. Zwłaszcza, że te osoby są bardzo wrażliwe i też w takim wrażliwym momencie życia.

Łukasz:
I te elementy są doprecyzowywane i definiowane teraz wspólnie. Czyli o ile wcześniej to była decyzja programisty i on sobie to dokumentował lub nie, dzielił się z kolegami zwykle w jakiejś postaci meetingów, stand-upów czy inny dedykowany case and space, w których mogli to robić, o tyle teraz po każdym sprincie możesz mu powiedzieć, czego się nauczyłeś, co się zmieniło w kontekstualizacji. Przepraszam, wypluj mi tego PDF-a, wypluj mi tego markdowna albo napisz to w tym naszym wiki i mamy to. I wiki ludzie też już nie czytają, nie zrozumie źle. Dzisiaj, jak ktoś dostaje 20-stronicowego PDF-a, wrzuca go do, czata czy innego narzędzia i też odbywa tą konwersancję z punktu widzenia, słuchaj, to jest kontrakt, powiedz mi, jakie są największe ryzyka, powiedz mi, co byś zmienił, co renegocjować, jakie są standardy rynkowe, etc., etc. I to uczy ludzi na wszystkich szczeblach i we wszystkich typach kariery, wydaje mi się, tak mi się wydaje oczywiście, jestem w swojej bańce.

Łukasz:
Pewnej generycznej wiedzy takiej życiowej o pewnych elementach i otwiera nas, i to jest największy w ogóle mój zachwyt nad AI-em, na dostęp do wiedzy, którą inaczej byś nawet nie wiedział, że ona jest. Nie wiem, czy kojarzycie słuchacze, czy ty grzywu taki koncept jak Johari Window, czterech kwadrantów i tam jest pierwszy kwadrant to jest co wiesz o sobie i wiesz, że ludzie wiedzą co oni o tobie wiedzą, czego ty nie wiesz i tam co ty wiesz, czego oni nie wiedzą i wreszcie jest unknown, unknown, to jest największy kwadrant i jeśli nie wiesz, że możesz zrobić setup ze spółką z o.o. W dany sposób bo ci nikt nie powiedział, to nie wiesz nawet jak o to spytać i zdefiniować swój problem który nie wiesz, że masz rozumiesz? Teraz akurat to taki może nie najszczęśliwszy czy przypadek, nie wiem, finansowo-podatkowo-księgowy, ale nawet jeśli chodzi o leczenie. Nie jestem fanem tego, żeby się leczyć przez czar GPT, ale jestem fanem tego, żeby weryfikować to, co słyszysz i skoro dostałem taką diagnozę i takie leki, czy są alternatywy? Bo akurat w aptece nie była, a pani miniu miała powiedzieć. Tak skontekstualizowane rzeczy pokazują mi, że można je wykorzystać w taki sposób, bardzo przemyślany, bardzo ostrożny, nie łykać wszystkiego, co nam powie, żeby łykać, ale naprowadzający nas na terytoria, które nie wiedzieliśmy, że istnieją.

Krzysztof:
No tak, to jest duża na pewno pomoc na różnych fazach rozwoju software’u,

Krzysztof:
właśnie od produktu aż gdzieś tam po testowanie. I właśnie o to testowanie chciałbym Cię teraz zapytać, no bo mówimy tutaj o quality, mówimy o wpływie kodu generowanego przez AI na jakość software’u. No i zawsze takimi strażnikami tej jakości byli właśnie QA-inginerowie, którzy bądź to robili testy manualne, bądź to automatyczne, bo przeplatali te dwa podejścia, dbali o jakość wynikową tego, co gdzieś tam powstaje. Teraz mam wrażenie, że ta rola nieco jest przedefiniowywana, nieco inaczej do niej już podchodzimy. W kilku projektach, które mam okazję gdzieś tam obserwować, widzę, że następuje swego rodzaju taki shift left i zwłaszcza w tych projektach, gdzie wykorzystuje się Specific Development, gdzie tworzy się na początku ten input do AI, skupia się na tym etapie, to wkład takiego inżyniera QA właśnie ma duże znaczenie i często tutaj przykłada się właśnie jego wpływ na projekt, a gdzieś tam ogranicza się testowanie manualne. To są moje obserwacje, ale jestem też ciekawy, jak ty widzisz właśnie tą redefinicję wręcz roli QA w tym obecnym świecie.

Łukasz:
Tak, to jest jedna z tych ról, która uważam w najłatwiejszy sposób w umysłach decydentów jest eliminowana przez automatykę, niestety. I uważam, że nie do końca słusznie. Jeszcze rozumiem ograniczenie tego zespołu, czy zmniejszenie go, ale ograniczenie, eliminacja do zera jest, uważam, błędem. Rozdzielę to pytanie, czy moja odpowiedź na dwie części. Pierwszą jest QA po staremu. AI po prostu powoduje, że nie ma już wymówek na to, żeby test coverage był poniżej 100% na każdą funkcję. Żeby przynajmniej tak zwany happy path nie był przetestowany. I też trzeba robić to z głową, bo jak napiszesz napisz mi testy, to on je napisze, ale w każdym będzie assert true is true i z głowy.

Łukasz:
Więc chociażby do tego nadal QA są potrzebni. Czyli czuwanie nad samym kontekstualizowaniem jakości, oraz tego, jak tiketujemy, i tu wchodzą bardziej w te buty product tunera, oraz tego, jak wyglądają na przykład elementy. Ja w takich wypadkach jestem nawet fanem tego, żeby QA przy pomocy prompta próbował zepsuć dany interfejs, nawet poza same testy integracyjne, wizualne, klikawalne, jakiś playwright, czy jednostkowe na poziomie tego backendy, frontendu oddzielnie. Jestem fanem tego, żeby przegadał z nim, słuchaj, a jak ja bym miał złe intencje i chciał to zepsuć, to co teraz? Bo my normalnie pracując z naszymi happy puffami nadal nie myślimy o tym i nie kontekstualizujemy, nie uczymy AI-a, że słuchaj, bądź odporny na to, że ktoś jednak w to imię wpisze szereg cyfr.

Łukasz:
I walidatory mogą być lub mogą nie być, ale nigdy nie wiemy, czy wygenerowany kod, nawet jakiś SQL injection, czy coś innego, dalej już idąc w to bezpieczeństwo. Więc dla mnie ta rola bardzo mocno wyewoluowała i nie jest jednoznacznie związana z jakością kodu, czy testów, samych testów, ale pilnowania tego, żebyśmy się trzymali pewnych narratyw i ulepszanie tych narratyw związanych z jakością. Dla mnie ta spójność jest kluczowa, bo jeśli każdy programista będzie robił to oddzielnie i te konteksty nie są gdzieś przez kogoś w jakiś sposób zarządzane i utrzymywane, nawet ta wiedza w tych markdownach potem, to to też oznacza, że mamy wiele światów, w związku z tym, na jakim branczu pracujesz i który programista to kontekstualizował, to masz różny rezultat. Tu też jest wartość.

Krzysztof:
Absolutnie, absolutnie. Tak jak obserwowałem i obserwuję tą swego rodzaju rewolucję, nie wiem czy to aż można nazwać rewolucją na pewno istotną zmianę, szybką zmianę relatywnie dla naszej branży, no to widziałem, że pojawienie się, wejście na salony vibe codingu było czymś takim, co bardzo mocno gdzieś tam trafiało do świadomości, tak, że sobie generowaliśmy wręcz nie zastanawiając właściwie co chcemy osiągnąć, za pomocą jakich tutaj ograniczeń chcemy to generowanie ukierunkować i zamknąć. Oczywiście różnego typu wpadki, różnego typu problemy, które z tego wynikały bardzo szybko pokazały, że być może nie tędy droga, trzeba do tego jednak podejść z głową i swego rodzaju następnym podejściem, następną taką iteracją jest właśnie Spec-Driven Development, kiedy przygotowujemy dość obszerny wkład do AI, aby zdefiniować te wszystkie constraints, aby zdefiniować to, co chcemy osiągnąć, jakieś wymagania funkcjonalne, niefunkcjonalne itd. Czy według ciebie to jest, chodzi mi oczywiście o ten aspect driven development, to jest coś, co jest swego rodzaju panaceum na takie generowanie kodu typu YOLO, czy to jest podejście, które według ciebie, które może zostać z nami na dłużej, a może w ten sposób?

Łukasz:
Wydaje mi się, że to kontekstualizowanie Spectrum Development to jest bardzo blisko, tylko dzisiaj te speki też nie są jednoznacznie w rękach programistów, to znaczy oczywiście on opisuje, że słuchaj, no używamy JavaScripta w tej wersji, tak.

Łukasz:
Chcę, żebyś stosował takie, a nie takie funkcje, czy takie, czy nie takie pętle, bo z tego nadal wynikają pewne ryzyka, chcę, żebyś taką i taką kompatybilność wsteczną, Ale to się robi raz, a nie per jakieś konkretne feature’y. Te feature’y, czyli speki, które wynikają z feature’ów, moim zdaniem są jeszcze bardziej w rękach produkt-ownerów. Jeszcze bardziej. I ten element, który wcześniej opowiadałem, opisywałem, gdzie deweloper przygotowywując sobie środowisko, czy też AI mu to robi nomen-nomen, komendami w szelu lokalnie, gdzie zasysa te tikety z Jiry, wybierają wspólnie, dziś najpierw zarobimy tego. Tu są moje trzy rekomendacje, jak do tego podejdziemy. Te rekomendacje, ta konwersacja, one są opisane w speku i to jest flow deweloperski tej organizacji. Czyli to jest trochę wyżej w strukturze, a przekłada się na każdą interakcję. To tutaj też bym wpinał te QAs, te wcześniejsze odpowiedzi, żeby oni się upewniali, że ten flow i że te konteksty markdownu, gdzie są poopisywane, słuchaj, zwróć uwagę, że piszemy tak, tak i tak, a nie tak i tak, bo dlatego, są na przykład elementem repozytorium GitHuba, Tam zachodzi ta kontrola jakości, a to jest propagowane do tych wszystkich modeli i każdej oddzielnej interakcji, którą ma na przykład, nie wiem, 100 programistów w ramach równoległych prac nad kolejnymi feature’ami, czy różnymi aplikacjami w ramach tej samej organizacji.

Łukasz:
Ja myślę, że dzisiaj jest coraz większa świadomość, że YOLO wygenerowany kod to trochę jak z tym Monday’em z lutego. Czyli pokazujesz ludziom Monday’a i mówisz, zobaczcie, możemy sprzedać udziały w spółce Monday, nomen omen polecieli na giełdzie 70% w ciągu jednego tygodnia, w tym lutym, a na koniec się okazało, że to, co widzisz na ekranie, oczywiście wygląda jeden, z dokładnością do piksela, jak to, co jest online na monday.com, z tą subtelnością, że monday.com ma szereg features, których to nie robiło, a najważniejszą z nich jest element współpracy zdalnej z ludźmi i kolaboracji na tych zadaniach.

Łukasz:
Tu największym ograniczeniem będzie, tak jak teraz ze spekami, w sensie tak jak teraz, tak jak przed AI, spek musi pisać ktoś, kto ma pewną świadomość tego, co pisze. Tak jak blueprint do budynku musi napisać dobry architekt, a nie randomowa osoba z ulicy, bo jeśli, rozrobi to randomowa osoba z ulicy, to oczywiście uzyska piękny design, czy piękny zaplanowany budynek, ale na przykład konstrukcyjnie niespójny, albo niezgodny, z obowiązującymi przepisami prawa budowlanego. I to jest ten element może nie wiedzy plemiennej, ale wyspecjalizowanej wiedzy programistów, QAE, Product Ownerów, która nadal istnieje, ale teraz oni razem współtworzą ten spec. Moim zdaniem to już nie jest tak, że programista opisuje spec czy testami, czy w inny sposób dokumentuje kod. To się może dziać, ale to już może robić za mnie agent. Tak długo jak ja mu wyprecyzowałem na początku, jaka jest kultura pracy w tej konstytucji .md w ramach naszego zespołu koderskiego czy kodersko-produktowego. Ja na to patrzę z tej perspektywy. Dla mnie te granice się rozmyły.

Krzysztof:
Jasne, jasne. Myślę sobie, że wykorzystujemy do generowania tego kodu LLM-y, które mają jakieś tam odcięcie w pewnym momencie. Zostały nakarmione wiedzą sprzed iluś tam miesięcy najczęściej. W związku z tym zastanawiam się, czy to też nie powoduje efektu w postaci generowania jednak pewnego długu technicznego. W sensie, czy to nie jest takie trochę narzędzie, taki miecz obosieczny, który może być wykorzystywany, aby szybko robić jakieś refactoringi, rzeczy, które zawsze były gdzieś tam spychane na koniec backlogu z wykorzystaniem AI, możemy sobie w miarę szybko z tym poradzić, czy tam podbić jakieś biblioteki i tak dalej, i tak dalej. A z drugiej strony generując kod, który często jest dziwny, a może tak bym to nazwał, jakkolwiek by tą dziwność nie zdefiniować, czy nie wprowadzamy dodatkowego długu technicznego. No i jeszcze zamknę to pytaniem, czy to w ogóle jest problem, że taki dług techniczny możemy sobie autogenerować.

Łukasz:
To znaczy tu w ogóle dotknąłeś bardzo ciekawego tematu tym pytaniem. Jeśli się nie mylę, OpenAI szkolił swój model do tematów koderskich ze Stack Overflow z Microsoftem. Jak otworzymy Stack Overflow albo jego kopię sprzed kilku lat, to tam były takie strony, które pokazywały ile pytań jest w jakim kontekście języka programowania. Innymi słowy, jeśli się nie mylę, tam PHP i JavaScript były zawsze na pierwszych dwóch miejscach i konkurowały o to pierwsze miejsce. Innymi słowy, dostęp do wiedzy i ewentualnie ilość dokumentów do nauki modelu, do treningu modelu w tych dwóch konkretnych językach jest po prostu dominująca. I oczywiście jest tam gdzieś to Ruby, który jest tam, nie wiem, chyba na 20 pozycji, jeśli dobrze pamiętam, i wszystko pomiędzy, Java, dotnety, wszystko. Ale są takie rzeczy jak Fortran, mamy przyjemność teraz mieć taki projekt z firmą ubezpieczeniową z UK, gdzie te modele sobie już tak nie radzą, ponieważ dostęp do wiedzy szkoleniowej był potwornie ograniczony, bo samym stack overflow było tylko kilka pytań, bo podejrzewam, że tych Fortranistów na świecie zostało kilkuset maksymalnie. I tu się robi bardzo ciekawie i wieje mrozem, bo nawet jako nie Fortranowiec widzimy, że model wypluwa głupoty. Głupoty, w których miesza mu się ten Fortran z innym językiem z tamtego okresu, teraz nie pamiętam co to było.

Łukasz:
Wypluwa głupoty, które de facto wywalają ten system więc dzięki Bogu, że mamy go tam na jakiejś wirtualce i testujemy na tej wirtualce i go wskrzeszamy za każdym razem na tej wirtualce i to jest, ciekawy przypadek, gdzie ta probabilistyczna natura tych modeli, czyli czym więcej masz danych, tym bardziej ci rośnie dokładność, uderza w twórcę I to jest ta odpowiedź też na tą część twojego pytania, gdzie pytasz o dług techniczny. No bo zakładam, że jego probability jest dużo mniejszy na językach, w których ten AI po prostu przejrzał tonę rzeczy, na tym został wytrenowany, i prawdopodobieństwo nam rośnie, versus na czymś mniej popularnym i prawdopodobieństwo nam spada tego, że będzie to zrobione super świetnie bez długu technicznego. Jednocześnie uważam, że sam dług stał się mniejszym problemem, to znaczy.

Łukasz:
Znowu wracam do tego twojego znajomego wcześniej. Ja się zgadzam tą tezą, że gdy pojawia się ten problem długu, może być w ogóle zapuszczony z automatu loop, który leci i agenty, raz, dwa razy w tygodniu, miesiącu przeglądają cały codebase i mówią, tu są ryzyka, tu są takie rzeczy, tworzą tikety z automatu i, jakby planning odbywa się w ten sposób, że dyskutujemy jak to rozwiązać i albo zostawiamy to, w backlogu, albo to rozwiązujemy. I tak naprawdę jedynym czynnikiem, bo kiedyś to był zawsze problem czasu, przede wszystkim, prawda, bo feature’y wygrywały zawsze ze wszystkim innym, bo trzeba sprzedawać, trzeba rozhulać i rozbudować dalej ten biznes. W każdym case’ie wszędzie to widziałem, zawsze był priorytet i olbrzymia przepaść, żeby zająć się czymś innym, często nawet na backfixing nie było czasu, w zależności od organizacji i jej kultury. A co dopiero jakiś dług, którego biznes w ogóle nie może głową pojąć, że to sobie radźcie z długiem, ale proszę mi tu budować dalej biznes. Więc ja to rozumiem i szanuję tą decyzję i ona jest pełni uzasadniona, bo biznes pociąga za sznurki, ale na koniec dnia był to element czasu. Dzisiaj powiedzenie AI-owi, słuchaj, jakie są impakty na tym, żebyśmy przepisali tą funkcję, żeby wzrosła jej wydajność albo żeby poprawić coś tam w inny sposób modelowo, jest tylko i wyłącznie elementem uwzględnienia tego, jakie są impakty biznesowe na obecnie działającą bazę produkcyjną.

Łukasz:
Czy funkcjonalność dla obecnych użytkowników, żeby tego nie zepsuć. Ale poza tym masz to niemalże za darmo, ponieważ jest to kwestia tego, że zamiast kodować coś przez tydzień, dzień czy dwa, jeden dzień w roku ktoś siada i wszystkie te etikety z długu, zakładając ich niski impact na, faktyczną biznes continuity, robi jednym PR-em albo kilkoma PR-ami, do których AI wygenerował mu rezultaty i AI mu stworzył te PR-y. Więc to jest spadek z rzędu tygodni, dni do minut, na rozwiązanie problemu długu więc to przy nawet meetingach planningowych w tym tempie, kiedy omawiane są te problemy widziałem, że ludzie już mieli PR-y gotowe mieliśmy takie sytuacje, omawiamy problem słuchajcie tutaj, zwłaszcza w transformacji kiedy organizacja nie stosuje AI na szeroką skalę tylko na przykład modele frontlinowe do kodowania tylko po stronie programisty i nagle to rozszerza i wchodzą te, konteksty, te markdowny i szeroko pojęta nazwijmy to nadzór również jakiegoś agenta nad całym procesem produktowo-koderskim i nagle się okazuje, że my tu prowadzimy konwersację, ten model co notuje, już to wysłał modelowi, który to analizuje, a ten co analizuje już założył trzy tikety a ja, który pick upuje tiket jest triggerowany tym, że się stworzył tiket powiedział, słuchaj, to jest zero punktów, ja to mogę zrobić tą jedną zmianą, my tu debatujemy i tak dalej, a tu wpada notyfikacja, że pur request został otwarty To jest niesamowite czasy.

Krzysztof:
Tak, tak, w pełni się zgodzę, mam podobne obserwacje. Mam wrażenie, że tylko jeden warunek, żeby to właśnie nie wysypało nam tej produkcyjnej bazy w cudzysłowie, czyli właśnie odpowiednia ilość testów, odpowiednie wytyczne, żebyśmy nie próbowali tutaj wylać dziecka z kąpielą i naprawiając jedno nie

Krzysztof:
zepsuli jakiejś części biznesu, która jednak przynosi pieniądze.

Łukasz:
Dla mnie, jeśli mogę dodać, to jest przede wszystkim challenge zespołów infrastrukturalnych i DevOpsowych, bo teraz bottleneckiem staje się wirtualizacja, jak szybko spin-offujesz te środowiska, z którą wersją kodu, bo tak szybko je produkujesz, żeby potencjalnie to przetestować, w jakiejś formie stagingu, testing environment, czy nawet tak zwanej równoległej produkcji na AB testing, że ten sam klient może wylądować tu i tu i jak jest error, w sensie mierzymy to logami, no to mu wracamy z automatu do poprzedniej wersji, a klienta przepraszamy, ale to było na wybranej grupie, na przykład beta testerów, na tej zasadzie. I stawianie i spin-offowanie tych wirtualek do takich testów jest w tej chwili tym, co widzę najwięcej inwestycji i pola do poprawy. Jest to bardzo blisko, oczywiście Amazon czy Microsoft rozwiązują to na własną rękę, bo to też są dla nich pieniądze, bo w tym momencie po prostu użycie ich infrastruktury. Skoro jest multiplikacja na programistach, to będzie multiplikacja na infrastrukturze, jej kosztach i jej wzroście. Także to jest też ciekawy problem z tej perspektywy.

Krzysztof:
Myślę sobie, że tutaj, co prawda, nie postawiliśmy sobie takiego punktu tutaj w naszej rozmowie, ale pewnie warto zauważyć, że to wcale nie znaczy, że ilość pracy spada dla programisty, bo to, że szybciej może wykonywać pracę wcale nie znaczy, że zapotrzebowanie featurey spada.

Łukasz:
Absolutnie. Ja mam też taką obserwację, że w bardzo dobrych spółkach, i to przede wszystkim Amerykanie świetnie rozumią, w sensie Amerykanie mam na myśli po stronie biznesu, to biznesmeni amerykańscy. Usłyszałem takie zdanie, if you automate yourself out of the job, you will get promoted or you will get a bonus, you won’t get fired. I to jest jakby core biznesu i myślenia Amerykanów, bo oni mówią tak, zawsze jest więcej pracy. Najwyżej ta konkretna dziedzina się skończy, ale będziesz robił coś innego, w innym kierunku, inny projekt, inny produkt, ale jeżeli tak to rozwiązać nam ten problem, to nikt cię nie wypuści z tej firmy. Więc to jest trochę paradoks na odwrót, bo ludzie mówią, kurczę, jak zaczniemy używać AI, to zostanę zwolniony. Większość firm, i to są spółki giełdowe, które WISA robi w sposób, w który ja powiedziałem, usuwani są ludzie, którzy mają opór przed używaniem

Łukasz:
AI, którzy nie chcą tego przyspieszenia. To taka dygresja na koniec.

Krzysztof:
Nie, nie, absolutnie, absolutnie trafna. Łukasz, to już tak powoli tutaj zamykając tam naszą rozmowę, chciałbym jeszcze z tobą spojrzeć w przyszłość. Oczywiście to jest bardzo trudne, trudno pewnie dłużej niż na kilka miesięcy do przodu wysuwać jakieś prognozy, ale jak myślisz, w którym kierunku albo jakie zmiany jeszcze w tym naszym ogólnie rozumianym procesie wytwarzania, oprogramowania zajdą na skutek pewnie coraz większego, coraz szerszego upowszechniania się tych narzędzi AI-owych.

Łukasz:
Ja myślę, że docieramy do pewnej ściany z tym AI-em, dlatego że w tej chwili, i to w wielu źródłach można poczytać, koszty tokenów są sponsorowane, są subsydiowane przez dostarczycieli tych rozwiązań. Jak popatrzysz na dane, raporty finansowe czy giełdowe spółek, które weszły na giełdy i które się stają pewnym otwartym i przejrzystym, bytem, który można sobie spojrzeć, to wychodzi z tego jasno, że te firmy są mocno niedochodowe i to na poziomie 9 do 1 wydatków i tego, co im wpada 10 do 1, czyli porażająca różnica i to może być nie do przeskoczenia. Jeszcze tego dzisiaj nikt nie wie, ale na pewno bardzo mnie ciekawi zastanawia ta idea, że mogą być rozwiązania oparte o hardware i modele deployowane lokalnie. Tak naprawdę już to mamy, bo na dowolnym smartfonie masz modele, które analizują zdjęcia i wyłapują zwierzaka, rower i całą resztę, ale ja mam na myśli wyspecjalizowane modele, kontekstualizowane.

Łukasz:
Trenowane pod konkretne zadania dla konkretnej typy użytkownika czy pracownika końcowego. I tutaj czeka nas olbrzymia rewolucja wydaje mi się, a jednocześnie ciekawostką jest to, jak będzie z adaptacją, bo, nawet obserwując to, od czego zacząłem tą rozmowę, gdzie Unia się broni pewnymi ustawami, co powstrzymuje ten rozwój, czy nawet adaptacja amerykańskich narzędzi, zachodnich narzędzi.

Łukasz:
Pytanie jest na ile w sytuacji, kiedy 90% społeczeństwa nie ma co robić i traci pracę, bo wszystko jest wyautomatyzowane, a te pozostałe 10 to tak naprawdę ludzie od pracy fizycznej, elektrycy, hydraulicy i cała reszta. Co wtedy? Bo pewnie się pojawią ruchy oddolne na blokowanie tego również na poziomie ustawodawstwa i znowu co wtedy? I to jest taka rzecz, która mnie zastanawia i nie potrafię na razie sobie tego wyobrazić. Natomiast jako optymista wydaje mi się, że przeskoczymy to w jakiś sposób, nawet te 10% nomenomen jakąś robotyką de facto, ale przeskoczymy to w jakiś sposób, kiedy większość ludzi będzie po prostu tymi zarządcami agentów i skilem będzie umiejętność opisania zadania nie na zasadzie make me rich, tylko słuchaj, mam taki pomysł, co myślisz, podbijamy piłeczkę. To fajnie jest pokazane w literaturze i filmie science fiction, na przykład w Marvelu, tak jak Tony Stark rozmawia z Jarvisem, albo jak John Travolta w Bitwie o Ziemię rozmawia z tym modelem, z tym hologramem AI w tej bibliotece kongresu. To są fajne takie, ja lubię, myślę, że to właśnie tak będzie wyglądać, żebyś miał takiego AI opiekuna, który cię przeprowadza przez wiele tematów i problemów i nawet te tematy biurokratyczne, których osobiście nie cierpię, sam ci to ogarnia czy rozwiązuje. Także to jest mega ciekawa koncepcja takiego, wiesz, prawie że anioła stróża, przynajmniej intelektualnie.

Krzysztof:
Tak, ja też bardzo cenię sobie to, że mogę stelegować na AI rzeczy, które niekoniecznie lubię albo o których mało wiem, bo to jest myślę też istotny element, który tutaj dotknąłeś. A więc również podobnie jak to jestem optymistą, nie obawiam się tych zmian, myślę, że one raczej wniosą więcej dobra niż zła. No oczywiście ten okres przejściowy, który towarzyszy każdej rewolucji, każdej zmianie jest trudny, wymaga pewnego zmiany sposobu myślenia, zmiany skillsetu, który programista powinien gdzieś tam w swoim narzędziowniku posiadać. Posiadać, tak, może postawienie bardziej na umiejętności miękkie, tego tematu dzisiaj nie poruszaliśmy, ale to też jest duża działka. Tak, tak, ale w końcu jestem też optymistą, wydaje mi się, że skończy się to pozytywnie dla nas wszystkich. Łukasz, chciałbym Ci bardzo podziękować za to spotkanie. Jak zawsze bardzo dobra i wnikliwa rozmowa, świetnie spędzony czas. Powiedz proszę na koniec, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchaczy odesłać.

Łukasz:
Piękne dzięki również. Wiesz co, zapraszam na mojego LinkedIna. Najlepiej złapać mnie na LinkedInie. Jak pozwolisz, to dołączymy linka do footnotesów i tam proszę mnie pingować, zapraszasz, messageować i możemy tą jakąś konwersację w różnej formie pociągnąć tam również ze słuchaczami.

Krzysztof:
Oczywiście link będzie w notatce do odcinka. Też zapraszam do podcastu, który Łukasz prowadzi. Jest to podcast anglojęzyczny, ale też jak najbardziej związany z naszą branżą. I też oczywiście podlinkujemy w notatce. Łukasz, dzięki jeszcze raz i do usłyszenia. Miłego dnia.

Łukasz:
Piękne dzięki. Pozdrawiam w Krzychu. Dzięki. Hej.

Krzysztof:
To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, Archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania, przemyślenia? Możesz się ze mną skontaktować na social mediach lub mailowo na krzysztof@porozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek Porozmawiajmy.it o wpływie kodu generowanego przez AI na jakość i dług techniczny. Dzięki za wspólnie spędzony czas. Do usłyszenia w kolejnym odcinku. Cześć!