Dług technologiczny na sterydach: co AI robi z kodem, którego nie sprawdzasz
Dług technologiczny istnieje od lat 90. Ale czy definicja sprzed trzech dekad wciąż działa w świecie, gdzie kod generuje AI?Patryk Kiepel, Cloud Data Architect i Mateusz Salik, Senior Software Engineer rozmawiają z Błażejem Ksyckim o tym, jak AI zmienia charakter długu technicznego – i czy w ogóle można mówić o świadomym zaciąganiu długu, gdy kod generuje black box.Rozmawiamy o tym, czy dług zaciągnięty przez AI to nadal dług, czy zwykły bałagan, dlaczego refaktoryzacja spadła z 21% do 3,8% a duplikacja kodu wzrosła o 81%, co się dzieje, gdy agent wyłącza testy, żeby tylko przejść CI, czym jest dług kognitywny i czy za kilka lat młodzi programiści będą umieli ocenić kod, którego nigdy ręcznie nie pisali oraz kiedy tryb YOLO ma sens – i kiedy kończy się żart.Dla tych, którzy używają AI do kodowania i zastanawiają się, czy powinni się tym bardziej martwić.
Natomiast nie mówię, że tak nie będzie za 2-3 lata, że już powiedzmy dojdziemy do jakiegoś stanu ustalonego i będziemy mieli finalną wersję jakiegoś modelu do kodowania i będziemy go używać i będziemy w stanie stwierdzić, że ten efekt, który dostaniemy jest przewidywalny. No dobra, to jakby kontynuując ten twój wątek, Mateuszu, to powiedz mi, czy jesteś w stanie w ogóle powiedzieć mi, jakie czynniki, jakie cechy musiałyby być spełnione, żebyś ty się poczuł komfortowo z tym, że tak trochę zaufasz bardziej w ten output, który ci ten LLM generuje. Bez zaglądania już w kod.
Dobrze, a powiedz mi, bo ty jeszcze poruszyłeś taki aspekt jednej swojej poprzedniej odpowiedzi czarnej skrzynki, którą trochę reprezentuje LLM. Czy ta czarna skrzynka ma taką cechę statystyczną, że w sensie Im więcej jest użytkowników na końcu odbiorców tego, tym trochę jednak rośnie pewność przez to, że ta stabilność wyników osiąga jakieś takie plateau. Może nie jest idealnie, ale przynajmniej wiemy, w którym miejscu jesteśmy. Czy to trochę nie jest taki obraz? Chcielibyśmy w takim razie wziąć to w model statystyczny, że ci użytkownicy zgadzają się z tą odpowiedzią. Tak rozumiem to pytanie. Czy w inny sposób? W sensie, że jakby ty na bazie feedbacku tych użytkowników jesteś w stanie mniej więcej zaakceptować, jaki masz poziom zaufania do outputu, który płynie z tego modelu, nie?
Czy z wprowadzeniem LLM-ów, które same generują kod, przestaniemy umieć pisać kod? Ale z drugiej strony to jest taka dyskusja, którą mieliśmy w latach 60-tych. Czy z wprowadzeniem kalkulatora ludzie przestaną umieć liczyć? Albo czy z wprowadzeniem Wikipedii ludzie przestaną umieć czytać? Czy to nie jest w kółko ten sam temat, tylko w innym wariancie, Patryku? Troszkę jest, natomiast inflacja skilli technicznych jest zauważalna na rynku. Moim zdaniem, i to też wszystko jest tak zwanie, wiadomo, żyjemy w swojej bańce informacyjnej i każdy żyje w swojej bańce jakby w pracy.
Ale nie odpowiedziałem do końca na twoje pytanie, bo za wszelką cenę chciałem tutaj dodać trzy grosze. Jakbyś mógł je jeszcze przeformułować, to może bym spróbował. Przeformułować, bo mi tak zasadniczo chodziło o to, czy Jest trochę za czym płakać, w sensie czy są umiejętności, które teraz na przykład tracisz, bo przeniosłeś je do LLM-a, zwróciłeś je na walki LLM-a, a wcześniej były w Tobie, ale jakby nie płaczesz z tego powodu, w zasadzie możesz powiedzieć, że się cieszysz, bo ja na przykład zauważyłem u siebie, że coraz słabiej pamiętam jakieś specyfikacje bibliotek webowych, Pythonowych,
Powiedzmy, że jeszcze OpenAPI sobie sam napiszę. No ale sam sobie napiszę OpenAPI, wrzucę je w LLM-a, wygeneruj mi we flasku. Dziękuję, do widzenia. Ja się osobiście cieszę, że przestałem śledzić changelog flaska, bo to jest dla mnie czas stracony. Czy to jest dług kognitywny? Dla mnie nie, ale znowu zrobię Krzysiu Ibisz i biorę 200 złotych o kod kapitanów drużyn i słucham państwa, co wy sądzicie na ten temat. No to ja zacznę. Dla mnie jest to w pewnego rodzaju koszt utopiony, w sensie takim, że masz pewnego rodzaju lata życia, które spędziłeś nad doszlifowaniem warsztatu i w pewnym momencie bolicie, że masz te świetne, wyolowione, wyrzeźbione dłuta, które są perfekcyjne do tej roboty.
Zgadzam się. Dziękuję Wam za udział w dzisiejszym podcaście. Sądzę, że drodzy widzowie, możemy Was na koniec zostawić przede wszystkim z taką radą, że o ile może i możecie spróbować zaufać temu, co generuje LLM, to na pewno musicie wiedzieć, na czym to uruchamiacie. To był kolejny podcast z serii Data Driven, a moimi gośćmi był Patryk Kiepel i Mateusz Salik. Dzięki.
Pokazano wszystkie 6 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Diskussja na temat definicji dług technologicznego w erze AI i jej zgodność z oryginalną definicją.
Rozważania na temat rozróżnienia dług technologicznego od bałaganu i ewentualne zmiany w definicji.
Analiza spec-driven development jako potencjalnej metody zarządzania długiem technologicznym w erze AI.
Diskussja na temat wpływu AI na bałagan i potrzebę kontrolowania procesów w erze AI.
Analiza konsekwencji braku backup planu w kontekście długów technologicznych i AI.
Opowieść gościa o doświadczeniu z repozytorium i AI.
Porównanie umowy kredytowej z długiem technologicznym i potrzeba zrozumienia procesu AI.
Diskussja na temat jakości kodu wygenerowanego przez AI i możliwości jego recenzji.
Analiza statystyk duplikacji kodu i jej wpływ na dług technologiczny w erze AI.
Diskussja na temat konsekwencji rozwoju AI i jego wpływ na dług technologiczny i zarządzanie kodem.
Rozmowa koncentruje się na konsekwencjach wprowadzenia AI w proces programowania, w tym utratę umiejętności i dług kognitywnego. Debatują nad tym, czy młodzi programiści, pracujący z AI od początku, zdołają utrzymać krytyczny wzrok wobec kodu generowanego przez te narzędzia.
Rozmówcy omawiają problem jakości danych i wpływu na AI, podkreślając znaczenie semantyki i analizy wczesnej.
Rozmówcy omawiają strategie zmitygowania ryzyka w projektach AI, w tym mapowanie procesów biznesowych i unikanie YOLO podejścia.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
Dług technologiczny istnieje od lat 90. Ale czy definicja sprzed trzech dekad wciąż działa w świecie, gdzie kod generuje AI?
Patryk Kiepel, Cloud Data Architect i Mateusz Salik, Senior Software Engineer rozmawiają z Błażejem Ksyckim o tym, jak AI zmienia charakter długu technicznego – i czy w ogóle można mówić o świadomym zaciąganiu długu, gdy kod generuje black box.
Rozmawiamy o tym, czy dług zaciągnięty przez AI to nadal dług, czy zwykły bałagan, dlaczego refaktoryzacja spadła z 21% do 3,8% a duplikacja kodu wzrosła o 81%, co się dzieje, gdy agent wyłącza testy, żeby tylko przejść CI, czym jest dług kognitywny i czy za kilka lat młodzi programiści będą umieli ocenić kod, którego nigdy ręcznie nie pisali oraz kiedy tryb YOLO ma sens – i kiedy kończy się żart.
Dla tych, którzy używają AI do kodowania i zastanawiają się, czy powinni się tym bardziej martwić.