DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie

Dzień dobry. Nazywam się Maciej Anisarowicz i jestem twórcą podcastu DevTalk, którego właśnie słuchasz. W zamierzchłych czasach robiliśmy eksperymentalne nagrania takiego cyklu DevTalk Trio, w którym to w trzy osoby nagraliśmy kilkanaście odcinków, które następnie puszczaliśmy regularnie. I te odcinki spotkały się z bardzo dużym zainteresowaniem i ciepłym przyjęciem. Wtedy występowałem ja wraz ze Sławkiem Sobutką i Andrzejem Krzywdą. A teraz przed Tobą trzeci sezon DevTalk Trio, gdzie znowu eksperymentalnie dajemy wypowiedzieć się innym ekspertom. Przed Tobą ekipa DNA Drogi Nowoczesnego Architekta oraz Architekta Jutra, czyli Kuba Kubryński, Łukasz Szydło i Kuba Pilimon. Enjoy!

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.

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.

Poczekaj, moim zdaniem głównym problemem są błędne założenia, które ten kod ma, swój wygenerowany kod, a nie bugi, tylko błędne założenia. Małe klasy problemów, które ktoś nazwie aplikacją, pewnie mogę w ten sposób zrobić. Większe części, które wymagają jakiegoś strategicznego podejścia, to fakt, że przy wyjściu z takiej pętli vibe kodowania będę miał tam bugi, moim zdaniem to jest najmniejszy problem. Większym problemem będzie to, że tam są kompletnie błędne założenia systemowe i architektoniczne. Wiesz co, ja się trochę nie zgodzę. Ale ja też się nie chcę zgodzić. Może, że nie nie zgodzić. Tylko teraz tak sobie jeszcze pomyślałem właśnie o tym vibe-kodowaniu, że jeżeli ja mam u siebie powiedzmy napisany plugin, tak jak ma Kuba u siebie w firmie, napisany plugin do cloda i mam tam powrzucane wszystkie skille, standardy robienia tego i tak dalej.

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.

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

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.

Po prostu, jakkolwiek, bez narzędzi. Ja mówię teraz o takim filozoficznym podejściu, czy, sorry, filozoficznym rozkminie, czy jak zmieniłem kod w 40%, to czy on nadal żyje To jest ten sam kod, czy nie? Dla mnie to jest ten sam kod, bo ja go nie oceniam tu i teraz, tylko oceniam go w historii, więc to, że ktoś go wymienił w stu procentach, to nie oznacza dla mnie, że to jest inny kod. Czujesz to wtedy. Tak, jest to Łódź Odyseusza, to już dawni filozofowie się zajmowali. Proszę cię bardzo. Więc to tak, ale jeszcze wracając do tego, co Kupa mówił. Czyli czy tak rzeczywiście będzie, że my będziemy mieli malutkie fragmenty, które będą tylko wyspecyfikowane i ja sobie stwierdzam, wiecie co, chciałbym, żeby to miało lepszy performance, trzepisz mi to z Java na Go, albo z Go na Rasta, albo na coś tam jeszcze innego.