Mentionsy Mentionsy
Data Driven by Future Processing
Data Driven by Future Processing

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

13.10.2026 ·1 godz 23 min · 13 rozdziałów

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ć.

34:34 · Konsekwencje rozwoju AI 6

I wtedy ten kontekst jesteśmy w stanie ograniczyć. Tylko, że my musimy mieć nad tym kontrolę, musimy wiedzieć co chcemy mieć na wyjściu i jakby ten kontekst odpowiednio zbudować, żeby on był w miarę mały, dopóki jesteśmy ograniczeni tym rozmiarem kontekstu. Tak jak powiedziałeś, tutaj później może to problemem nie być. Tak samo jak kiedyś programowaliśmy w językach niższego poziomu, bo te zasoby były istotne. Później się pojawił C-Sharp Java. Już się nie przejmowaliśmy np. pamięcią. Pojawiły się narzędzia jak Garbage Collector, które się tym zajmują za nas. No i to nie jest teraz najważniejsze. Skupiamy się bardziej na dostarczaniu wartości biznesowej. Ja myślę, że tutaj to będzie szło dwutorowo.

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 po prostu, jeżeli go używa miliony ludzi na świecie, to wychodzimy z założenia, że no ej, ktoś by to zgłosił, nie? Garbage Collector nie jest niczym nowym, on istnieje sobie od lat 60-tych. Z tego co kojarzę, to on był chyba pierwszy raz zaimplementowany w Lispie, więc to też są inne czasy. No co warto nadmienić, no gdy on powstawał, to nie było tak, żeby wszyscy stwierdzili, o super, będziemy z niego tylko korzystać. On miał mnóstwo, mnóstwo przeciwników i ludzie robili, nie, no słuchajcie, tutaj mogą wycieki pamięci, może się stać coś takiego, że program podczas wykonywania zacznie się zatrzymywać. No i obecnie jest dokładnie tak samo, w sensie widzimy te ryzyka, my jesteśmy w stanie mniej więcej je opanować, no ale to potrzeba czasu do tego, żeby

Cały ekosystem przyzwyczaił się do nowego paradygmatu. My jeszcze istniejemy tak naprawdę w rozstroju między jednym a drugim, więc nie można powiedzieć, że będzie to używane jako niższa warstwa abstrakcji by default, dlatego że nie wiemy, czy to jeszcze wejdzie w standard i jak zostanie to ułożone. O, w ten sposób to odpowiem. Jeżeli mogę coś dodać, ja tutaj dostrzegam jedną taką podstawową różnicę, wydaje mi się, że garbage collector Nie wiem, można by pójść dalej, idę, nie? Podobny przykład. Kiedyś, może ja już nie programowałem w notatniku, ale te idee były coraz lepsze, coraz więcej oferowały, coraz więcej rzeczy robiły za nas, nie?

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.

Pokazano wszystkie 6 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.