DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie

Przed Tobą DevTalk. Programistyczny głos w Twoim domu. Dzień dobry, panowie. Witamy też nas wszystkich słuchaczy. Cześć. Dzisiaj chciałem poruszyć taki temat, który jak przeglądam te portale, o których Pilo mówił, że były fajne, a teraz po prostu są. To bardzo często ludzie mówią, że AI generuje gówno i kod, który wygeneruje AI jest dramatyczny i zaraz wszyscy będziemy nie robić nic innego, tylko poprawiać kod po LLM-ie. Long story short, ja się z tym absolutnie nie zgadzam i nie utożsamiam, ale temat jest.

I ciekawe jest w tym, jakie są wasze doświadczenia. Ja może zacznę. Ale zacznij Kuba, zacznij. Wydaje mi się, że ogólnie bardzo dużo z tego bierze się z nieumiejętnej pracy z LLM-ami. To jest trochę tak jak ludzie chodzą na siłownię, nie mają żadnego trenera, nie wiedzą co robią i narzekają, że nie mają efektów. Dziwne. Zaskoczyłeś mnie tym. I jakby trzeba wiedzieć, co się robi. Teraz, jeżeli są ludzie, którzy pracują z LLM na zasadzie vibe codingu. Dla mnie vibe coding to jest sytuacja, gdzie ja mówię LLM-owi zrób to i w tak zwanym trybie YOLO LLM to robi.

I nie wiem, co zrobił, jak zrobił, po co zrobił i jest jeden wielki dramat. No to oczywiście, że jakość tego będzie dramatycznie zła. Natomiast, jeżeli pracuję z LLM w sposób... Naprawdę sensowny, tak że jakby tworzę SPK, rozmawiam z tym LLM-em co ma zrobić, gdzie ma zrobić, jak ma to zaprojektować, gdzie ma się wpiąć w obecny system, czy ma zrobić tabelę łączącą, czy nie i tak dalej, no to jakby dostanę efekt, który jest jakby... Wprost proporcjonalny do mojego zaangażowania na etapie planowania tych zmian. Ciekaw jestem, czy Wy właśnie słyszycie głosy tego, że LLM tworzy słaby kod i zaraz wszyscy będziemy bardzo potrzebni, bo będziemy musieli poprawiać po kodzie, który przez najbliższe x lat będzie generowany przy pomocy kodeksa, kursora czy cloda.

Wszelkie prawa zastrzeżone. To ja może zacznę od takiego swojego doświadczenia, bo wydaje mi się, że ono jest trochę podobne do tego doświadczenia, które dużo ludzi ma, nie? Że jak zaczynasz pierwszy raz używać LLM-a do tego, żeby napisać kod, to masz jakieś proste zadanie. Jedno, drugie, trzecie, no bo takie ci przychodzi do głowy, tak? Chcesz sobie coś szybko poeksperymentować i nagle widzisz wow. On to rzeczywiście wszystko wygenerował tak, jak ja chciałem. Na początku zaczynasz od metody, później idziesz do klasy, później robisz sobie jakiś taki mały fragmencik, nie wiem, może jakąś aplikację typu ToDo czy zarządzanie taskami czy jakąś inną rzecz, która jest już gdzieś tam w repozytorach na GitHubie 36 tysięcy.

I ten LLM bardzo dobrze potrafi generować 37 tysiąc aplikacji do zarządzania projektami albo aplikacji jakichś tam, nie wiem, boardów czy, czy, czy stronek internetowych, nie? I myślisz sobie wow, nie? Rzeczywiście, będę teraz vibe kodował, bo, bo tylko mu napisałem cztery linijki prompta i, i już to mam. W momencie, kiedy zaczynasz używać tego do rozwiązywania problemów, które już nie są tak oczywiste, nie ma tak dużo rzeczy gdzieś tam w necie, no to nagle się okazuje, że ten prompt to nie wystarcza. Że ten vibecoding, który tak mi na początku działał i byłem tym zajarany przez pierwszy, nie wiem, miesiąc, półtorej miesiąca, może dwa miesiące, w zależności od mocy modelu, w zależności kiedy zaczynaliście, nie? Jak zaczęliście się bawić LLM-em rok temu, to jakby szybko dochodziliście do wniosku takiego, że vibecoding nie działa.

Jak zaczynacie się bawić LLM dzisiaj, to to chwilę dłużej zajmie, zanim napotkacie na ten problem, którego model nie jest w stanie rozwiązać, bo rzeczywiście nie da się ukryć, że modele są coraz lepsze. Ale prędzej, później dojdziecie do tego, bo będzie to problem, którego nie było w zbiorze. www.devtalk.com.pl I to jest ten moment, kiedy moim zdaniem to wipe kodowanie się kończy. I moim zdaniem dlatego o tych portalach, o których mówiłeś Kuba wcześniej, to jest to, że na początku jest mega hype i stwierdzamy, ja też tak miałem, ja na początku mówię, kurde, wszystko wygeneruje, wow.

Wszyscy. I problem taki, że o kurczę, zrefaktoryzujmy cały system, bo już wprowadzenie jakiejś tam jednej zmiany trwa miesiąc, czy półtorej miesiąca, czy kwartał i musimy po prostu napisać ten system od nowa, bo inaczej się nie da. To są problemy, z którymi duże firmy borykają się od lat. Nawet powiedziałbym, że od dziesiątek lat. I ten problem nie zniknie tylko dlatego, że kod został wygenerowany przez LLM-a. Bo jeżeli ktoś, kto właśnie sobie vibe koduje, to on będzie tworzył dokładnie taki sam... takie samo spaghetti. O, próbowałem znaleźć jakieś słowo cenzuralne. Takie samo spaghetti będzie generowało, jak taki właśnie... Jak kiedyś generowaliśmy, to się nic nie zmieni.

To nie jest vibe-kodowanie. Ale czy to nie wygląda podobnie, że ty dajesz naprawdę jakiegoś nieduży kawałek prompta i on jest w stanie ci wygenerować zgodnie z twoimi konwencjami fragment systemu, który spełnia te rzeczy? Wydaje mi się Łukasz właśnie, że tutaj mówimy o prawidłowym użyciu LLM-ów. Ja zadawałem pytanie o vibe coding. Vibe coding to jest dla mnie taki, robię sobie nowe repo na githubie, odpalam klot i jadę. Ja poczyniłem taką aplikację, żeby zobaczyć jak to będzie wyglądało, jakby bez właśnie standardów celowo po prostu, żeby zobaczyć jak to działa. Jest dramat tak naprawdę. To co dostałem to była kupa gówna. Nonstop pojawiały się jakieś błędy, poprawiłem te błędy, psuły się inne rzeczy, oczywiście miałem test wygenerowany, tylko te testy nic nie sprawdzały i tak dalej, więc ogólnie okazało się, że jakby tam nie było co refaktorować, to trzeba wyrzucić, poprosić LLM o wygenerowanie specyfikacji, wyrzucić i napisać od początku.

Więc jeżeli tak podchodzimy do pracy z AI-em, to to się nie zadziała. Ja zawsze mówię, że LLM jest jak senior w twoim projekcie. Taki LLM by design z cloud odpalony nie do końca. Nie, on jakby nie do końca jest jak senior albo taki senior, który ma już wszystko w dupę i nic mu się nie chce i robi no odwal się. Więc w tym kontekście, jeżeli tak ludzie pracują z LLM-ami, to faktycznie jakby rezultaty są słabe. I ja to mówię jakby jako osoba, która pracując jakby z LLM-ami na co dzień,

Realnie, ale zobacz Kuba, bo ja się z tobą w 100% zgadzam i z tą definicją vibe kodowania twoim też się zgadzam, ale to co ja chciałem powiedzieć, to chciałem powiedzieć to, że jeśli właśnie masz jakby tą wiedzę na temat twojego projektu, architektury i tak dalej ustrukturyzowaną, to ta interakcja z tym LLM-em ona dla osoby z zewnątrz, dla obserwatora, który nie wie co jest w środku, ona wygląda bardzo podobnie. Bo ktoś pisze niedużego prompta i jednej osobie generuje shit, bo robi vibe coding, a drugiej osobie ten sam prompt wygeneruje naprawdę fajnie działającą aplikację, dlatego że nie widać tych właśnie wszystkich skilli, tych wszystkich reguł, tych wszystkich elementów, które dokładamy do tych naszych systemów. Kto podejmuje decyzje na temat architektury i tego, w jaki sposób pewne czynności wykonywać?

Czy to były decyzje podjęte Przez zespół, tak jak u Ciebie, który to wszystko spisał i wrzucił do skilli? Czy to są decyzje podejmowane przez LLM-a na podstawie jakichś, kurczę, losowych repozytoriów na Githubie, bo to z jego wag wynika i dlatego on wygenerował coś takiego? Dokładnie tak. No i teraz jakby właśnie trochę to, do czego dążę, to jest powiedzenie, że jakby generator długu technicznego w formie LLM-a jakby nie zależy od LLM-a, tylko zależy od tego, jak tego LLM-a używasz. Jeżeli faktycznie w swoim repozytorium masz zbudowane standardy, czyli mówisz mu co robić, czego nie robić, masz opisane to wszystko, robisz review tego i tak dalej, to kod, który dostaniesz będzie sensowny.

Z mojego doświadczenia też LLM lepiej działa w aplikacji, która jest napisana Przez człowieka ma pewną strukturę, setup i tak dalej, niż takiej, którą tworzy od zera. Budowałem dwie aplikacje, takie Production Ready od zera z LLM-em. Dużo musiałem na początku interweniować, bo cały mechanizm na przykład, wiecie, trzymania właśnie sekretów. Nie na tej zasadzie, że sekrety wyciekną, ale uporczywie próbował mi te sekrety trzymać w zmiennych systemowych. Ja tego nie potrzebuję, mam mechanizm zarządzania sekretami. Okej, okej. I znowu te zmienne systemowe, nie? Czy to na przykład nie występuje w momencie, kiedy już mam 30 propertiesów i jakby on dokłada 31. Więc to było dla mnie na przykład szokiem, nie?

Że zacząłem świeżą aplikację i on tą świeżą aplikację mimo wszystkich standardów zrobił po prostu, może nieźle, ale jakby w sposób daleki od optymalnego, nie? Kwestia, wiecie, konfiguracji security, nie? Mówię, no nie tak jakby, no nie, jakby zróbmy jakiś security config, tam wrzućmy te rzeczy. Ok, no i jakby dalej tego nie robi. Trzyma to gdzieś w jakiś binach rozproszony, więc jakby to było dla mnie takie szokujące, że jakby superprosta rzecz, Greenfield jakby robi źle. Natomiast jakby tak, wydaje mi się, że podsumować to można trochę tak, jak Łukasz mówił, że jeżeli jakby chcesz pracować z LLM, chcesz, żeby on był twoim przyjacielem, to zadbaj o ten cały ekosystem, który jest dookoła. Który pozwoli temu LLM-owi jakby wiedzieć, jakby jak ma robić i wtedy ty musisz tylko zadbać o to, co ma robić, nie?

Plus dbać o to, że jeżeli znajdziesz jakieś błędy, tak jak wczoraj mówiłem o tym Transoloco, nie umiem tego kurde wymówić, jakaś biblioteka reactowa, no to właśnie jeżeli zrobisz jakiś błąd, dostajesz komentarz w code review, no to pierwsze co robisz, to poprawiasz i mówisz jakby... LLM-ie, zapamiętaj to na przyszłość, czyli trochę tak, jak mamy dobre praktyki pracy z błędami. Ktoś mi zgłasza błąd, jaka jest pierwsza rzecz, którą robię? Piszę test, który mi ten błąd odtworzy i będzie czerwony, dopóki tego nie poprawię. Tutaj ciekawa rzecz, jak uczyłem mojego LLM-a, żeby z tym pracował, To jak mu kazałem coś takiego zrobić, to wygenerował mi test, który przechodził jak był błąd, czyli sprawdzał, że błąd istnieje.

Tylko że ja mówię, okej, wygeneruj mi test, który potwierdzi istnienie błędu. No więc on generował test i on był zielony jak błąd był. Jak błąd poprawiłem, to test zaczął failować. Nie do końca o to chodzi, drogi LLM-ie. Natomiast mamy taką pewną praktykę już jako doświadczeni deweloperzy, gdzie mamy błąd, odtwarzamy błąd testem, albo jeżeli jest test, który tego nie wyłapuje, poprawiamy asercję, potem poprawiamy kod, mamy od razu, jakby test przechodzi, mamy potwierdzenie, że to, co zrobiliśmy jest prawidłowe. To jest pewien nawyk i taki sposób pracy, flow pracy, który mamy. I tak samo jakby pracując z LLM-ami, też musimy dbać o pewne rzeczy, że jeżeli jest jakiś błąd i LLM poprawił ten błąd, to ta pętla feedbackowa moja do LLM-a musi być super krótka. Ja od razu mówię, zobacz, przegapiłeś tutaj, albo to zrobiłeś źle.

Naucz się na przyszłość. I to, co LLM-y robią, często robią takie do's and don'ts. Dosłownie tworzą mark danych, to źle, to dobrze, to źle, to dobrze i tworzą sobie taki jakby zbiór danych, który pozwala im jakby się rozwijać. To mi przypomniało pewną historię. Nie wiem, czy się zgodzicie z tym, że jest taka narracja teraz, można ją widzieć, że w świecie AI to kod być może stanie się jednorazowy, bo... Jeżeli jest taki, jaki jest, to ja przecież mogę go zrefaktoryzować w jakiś sposób. Znaczy, sorry, nie muszę refaktoryzować, tylko mogę właśnie wyrzucić moduł, poprosić AI o napisanie od zera. Tylko że dostaniesz po prostu innego rodzaju gówno prawdopodobnie, jeżeli zrobisz to na pałę. Inne trochę, ale nadal będzie jakościowo w podobnym... Do czego ja zmierzam?

I problemy mogę sobie, w cudzysłowie, owinąć wokół głowy. I za każdym razem, jak szukam buga, to mam swoją prywatną listę do's and don'ts, żeby wiedzieć w przyszłości po prostu, z czym się mierzyć. Być może ta lista była w głowie, nie wiem, być może była na kartce papieru lata 70. Teraz po prostu, to co mówił Kuba, ta lista jest zapisana do instrukcji LLM-a, który faktycznie mógłby teraz napisać ten moduł lepiej, ale tylko dlatego, Wiem, że wcześniej było gówno i co było dokładnie w tym gówniane i co mogę powiedzieć, żeby już w przyszłości się nie wydarzyło. To jest inkrementalny przyrost wiedzy, a nie po prostu wy-wipe kodowanie czy z-wipe kodowanie od nowa. Tak, to ja dodam jedną rzecz, że jak ktoś nie chce czytać tej książki z lat 70., to jest świetna prezentacja Grega Younga, gdzie on po prostu siedzi na krześle w jakichś takich sandałach i robi wykład bez żadnych slajdów, w którym właśnie mówi, że on to nazywa chyba disposable modules albo disposable software, że powinno być to tak napisane, żebyś ty nie musiał w ogóle modyfikować kodu.

I generuj nowy kod pod spodem. Jeżeli ta specka jest genialnie zrobiona, a jakby z mojego doświadczenia jakość przekładania specyfikacji na kod, LLM-y są tutaj niezłe. To nie jest jakby wąskie gardło. Wąskie gardło to jest przygotowanie dobrego speka. Więc jeżeli miałbym LLM-a, który byłby genialny w konwersji speka na kod, To faktycznie pytanie, czy ten kod, to może nie to, żebym, wiesz, w Github Action miał generowanie kodu i go nie oglądał, ale może faktycznie jakby ten, jakby... Czas życia kodu, bo teraz jakby tworzymy kod, ten kod żyje latami, nie? Może tak naprawdę to podejście takie spec-driven spowoduje, że kod będzie żył bardziej miesiącami albo tygodniami i będzie wyrzucany i zastępowany nowym kodem i dług techniczny nie będzie problemem, bo ten kod tak naprawdę tylko go nie oglądam, a idąc za Elonem Muskiem, no mam w ogóle binarkę i w ogóle nie widzę tego kodu.

A teraz jak kto robi LLM, to ja naprawdę jestem mnóstwo w stanie rzeczy zembedować w kodzie i nawet jak robię jakąś modyfikację, to jestem w stanie jakby kontrolować obie te zmienne, bo mam to wszystko w jednym miejscu i mogę robić zarówno LLM-em, jak i mogę robić manualnie w tych miejscach precyzyjnych, gdzie potrzebuję, jeśli ciągle będę chciał to zrobić. I tak i nie, być może to jest temat na osobno. Może powinniśmy zakończyć, słuchajcie, tak jak każdy taki bullshit wygenerowany przez AI, to nie dług techniczny jest problemem, to dług poznawczy. Dobre? Tak, dobrze kończymy, tak jakby, wiesz... Masz absolutną rację, Kilo. To jest świetny pomysł. Przepraszam, bo pełniłem błąd. Dobra, słuchajcie, dzięki wielkie.