DevTalk Trio S03E08 – Kto odpowiada za kod, którego nikt nie rozumie?

Implementowałem jakiś moduł, ktoś mnie pyta, jak się zachowa w takiej sytuacji. Ja mówię, a zachowa się w taki i w taki sposób. Czemu? Dlatego, że pisząc ten kod dosłownie linijka po linijce, budowałem sobie pewien obraz mentalny tego, jak to działa i ten obraz mentalny został ze mną na całkiem długo. Może teraz po 10 latach czy 15 nie byłbym w stanie powiedzieć, jak działają moduły jakiegoś tam systemu, ale pewnie dość szybko byłbym w stanie sobie to odtworzyć, a pewne rzeczy nawet do dzisiaj pamiętam. Natomiast, co ciekawe, przy pracy z LLM-ami ja, zwłaszcza, że pracuję głównie na tym etapie specyfikacji, bardzo często, przynajmniej ja osobiście, tego modelu mentalnego już nie mam. I na pytanie, jak zadziała ten moduł, który dopisałem w takim i w takim wypadku, mówię...

Nie wiem, muszę sprawdzić, zapytać LLM-a, przejrzeć kod i tak dalej, bo nie wiem, jak pewne rzeczy są zrobione. Wiem na przykład, że jak mamy workflow'y, to na poziomie workflow'u zapisuję sobie informacje o podmiocie tego workflow'u, czyli jaka osoba, jaki menadżer partycypuje w tym workflow'le, ale nie pamiętam, szczerze mówiąc, gdzie to zapisujemy. Wiem, że zapisujemy to w temporale, zapisujemy to w bazie danych, ale w którym miejscu? Nie wiem. I na pytanie, co się stanie, jeżeli takiego subjecta nie będzie? Mówię... Nie wiem, wydaje mi się, że nic, bo pamiętam taką rozkminę z czatem, że on nie zawsze musi być, ale nie wiem, jak to się zachowa. Czy tam jest pusty, czy jest jakiś domyślny, nie wiem.

I teraz pytanie, czy wy coś takiego po sobie widzicie, że właśnie często osoby, które implementują zmianę przy pomocy LLM-a, nie pisząc kodu, tylko tworząc tę specyfikację, nie znają tak naprawdę tego kodu. W takim stopniu, w jakim znaliby go, gdyby ten kod pisali od podstaw? To jest pierwsze pytanie. Ja zawsze lubię zadać dwa, a drugie, to czy wydaje wam się, że to ma jakieś konsekwencje realne? Poza tym, że na odpowiedzi na pewne pytania musimy poczekać dłużej. Ja nie wiem, czy się zgodzę z tezą, ale nie oznacza to, że na pewno się nie zgadzam. Chciałem tylko zauważyć jedną rzecz. Z mojego doświadczenia x lat temu bywały takie sytuacje, że w projektach o dużej skali, bo nawet nie bywały, tylko prawie zawsze były, w projektach o dużej skali były takie klasy, slash moduły, slash miejsca w systemie, które działały, więc nie dotykało się ich po prostu.

Albo wiedział tylko Sebastian. Tak jak powiedziałeś, ale Sebastian też bywał na urlopie. Sebastian tak naprawdę odszedł z roboty dwa lata temu i był jedyną osobą, która ten moduł od podszewki rozumiała. Dla mnie to nie jest do końca nowy problem, ale nie mówię, że taka była twoja teza. Powiedziałbym, że AI i LLM ten problem może skaluje? Industrializuje, tak można powiedzieć. On się stał powszechny teraz. Właściwie co tydzień jest częstszy, ale to nie jest nic nowego. To 15 minut po napisaniu kodu. Tak, to nie jest nic nowego. Wcześniej być może to był wyjątek, efekt rotacji, złych praktyk, długu technologicznego, który się nawarstwał latami, a teraz jest to normą od pierwszego dnia projektu albo 15 minut po komicie, tak jak powiedziałeś. To jest pierwsza rzecz, którą chciałem z mojego doświadczenia doprecyzować.

Nie odpowiedziałem na żadne z Twoich pytań, wiem na razie, bo nie mam odpowiedzi na żadne z tych pytań, ale chciałem doprecyzować pewnego rodzaju kontekst, który mi wpadł do głowy, jak Ty mówiłeś te inwokacje. Ja mam chyba wręcz trochę odwrotnie, bo ja przyznam się, nie piszę bardzo dużo kodu. To wiemy, nie musi się przyznawać, bo to nie jest jakby... Ale wy możecie wiedzieć, nie wszyscy słuchacze mogą wiedzieć, więc daję kontekst. A to czuć, wiesz, w rozmowie. To dobrze. Widać ten brak praktyki, takiego bycia z tym, no. Ktoś wam musi mówić, jak to trzeba zrobić i ja biorę na siebie po prostu to jarzmo, no i już trudno, już trudno. W każdym razie, wracając do sedna, że ja właśnie dzięki LLM-owi...

Więc dla mnie teraz jest wbrew pozorom właśnie prościej ten problem, o którym ty mówiłeś, że jakby nie ma tego modelu mentalnego. Okej, rzeczywiście ja go nie mam w pamięci, ale w cache'u on jest jakby tak blisko. To, co mi się nie podoba w takiej tendencji, jeśli chodzi o programowanie z LLM, to jest to, że jedna osoba to robi. Czyli dzięki temu, że jesteśmy w stanie rzeczywiście znacząco przyspieszyć, to w części film zaczyna to wyglądać tak, że właśnie jest jakiś jeden ziomek, który siada i po prostu z czatem leci, leci, leci i tylko on ma to w głowie. Moim zdaniem, my powinniśmy zacząć wypracowywać takie metody, które pozwalają nam ciągle pracować kolaboracyjnie.

Tak jak robiliśmy to wcześniej i właśnie zacząć używać AI w taki sposób, żeby on jakby wspierał ten sposób pracy, żeby też ta wiedza, o której ty mówisz, właśnie ten model koncepcyjny, żeby on był rozłożony po paru tam więcej osobach i na razie tyle. Wiesz co Łukasz, bo tutaj jeden i drugi się trochę ślizgnął po temacie. Jakby to, co ty mówisz, to mówisz o tym, że archeologia kodu jest prostsza i ja absolutnie nie mam wątpliwości, że tak, dużo łatwiej jest teraz zadać LLM-owi pytanie, co się stanie w takim wypadku, on mi przeanalizuje kod w trzy minuty i da mi odpowiedź, jak w złożonym monolicie to się dzieje i to jakby 100%. Natomiast ja się zastanawiam nad czymś innym.

Liczba oczywiście wyciągnięta prosto z dupy, ale chodzi o pewną ideę. I teraz jakby Na etapie tego researchu, na etapie pisania specki i tak dalej, oczywiście my część decyzji podejmujemy, powiedzmy 20-30 decyzji podejmę ja, bo LLM się mnie zapyta, co chcesz zrobić w takiej sytuacji, co możemy zrobić w tym, czy dopuszczamy taki case, to co Pilo mówił, też o tych pytaniach, które zadają mu jego skille. Część decyzji podejmie LLM i one się znajdą w tej specie, ja to zrewiłuję, ale mam takie wrażenie, nie mam na to twardych liczb, ale jakby mam takie wrażenie, że jest część decyzji, którą podejmuje LLM i nikt absolutnie nad tym nie panuje. One oczywiście nie są kluczowe, nie są newralgiczne, ale zdarza się czasem, że są jakieś takie edge case'y, które przeciekły gdzieś przez ten etap specyfikacji, bo nie były na tyle istotne, żeby znaleźć się w specyfikacji.

Podpisał się in blanco. Gdzieś tam i trochę zastanawiam się właśnie, jaka to jest skala. Ja widzę tą skalę, bo właśnie jak np. Marek czy ktoś z zespołu mnie pyta, a jak ktoś zachowa w tym przypadku, bo taki kod zrobiłeś? Ja mówię, to jest bardzo dobre pytanie do naszego LLM-a. Mogę ja je zadać, możesz ty je zadać, jak teraz siedzisz i sprawdź. I coraz częściej widzę takie sytuacje, gdzie kiedyś jak pisałem kod, to przez x tygodni po napisaniu tego kodu wiedziałem, jak się zachowa. Z głowy byłem w stanie odpowiedzieć. I zastanawiam się teraz właśnie, jakie są konsekwencje tego i czy poza tym, że nie umiem odpowiedzieć, ok, no archeologię robię super sprawnie, ale czy to ma jakieś konsekwencje na sam sposób powstawania tego kodu? Wydaje mi się, że ty je pewnie jawnie lub podświadomie niwelujesz tym procesem, o którym mówiłeś wcześniej, czyli całym code review specki i tak dalej, całym workflow'em.

Czy to, że są pewne decyzje, które podejmuje LLM bez pytania kogokolwiek o to i te decyzje nam przeciekają przez ten nasz proces i subagenty gdzieś tam to weryfikują, ale jednak rzadko człowiek nie patrzy na te pewne decyzje. Czy to ma jakieś negatywne bądź pozytywne konsekwencje, czy nie? Ja tu się niestety z bólem, z bólem, trochę zgodzę z Pilem. Bo tak, jak my robimy review kodu, To co my właściwie do tej pory reviewujemy? Jak ja kiedyś dawno robiłem review. Nie, żartuję, review akurat robię trochę częściej. Tylko ci powiem, Łukasz, że to zależy od tego ile jest kodu.

To swego czasu Marcin Zajączkowski bardzo mówił dużo o testach mutacyjnych i zdarzało mu się tak, że odpalał PIT-a, zmieniał kod produkcyjny w projekcie, a testy jak przychodziły, tak przechodzą. I to też jest bez sensu, bo takie testy dają ci tak naprawdę złudne poczucie bezpieczeństwa. Mówisz, o mam test, no dobrze, ale ten test ma assert true, nie? Na true i jakby niekoniecznie zadziała, więc tutaj też trzeba uważać i tak naprawdę to, czy te testy dobre powstały, to też jest element review. To jest to, co Pilo mówił, że on też sprawdza na przykład, czy ta strategia testowania, którą przyjął LLM, do tego ma sens, czy ona testuje to, co ja wiem, że może wybuchnąć, nie? I to trochę na moim doświadczeniu Co chcę przetestować?

Alele mi zrobi kod, który testuje czy serializacja z Jasona z Rabbita działa. Działa zawsze dobrze, a jak coś to potrzebuję jeden test, a nie test per kolejka czy per wiadomość. I w innych miejscach muszę się skupić. Więc wydaje mi się, że to jakby znowu, to code review jest teraz super istotne i moim zdaniem code review na etapie pracy z LLM jest dużo ważniejsze niż było przed pracą z LLM, zwłaszcza jak mieliśmy doświadczony zespół, każdy wiedział co ma robić. Teraz to, że ktoś ma wiedzieć, co ma robić i to, że Pilo wrzucił kod, to wcale nie znaczy, że ten kod jest dobry, bo może Pilo w ogóle go nie zobaczył, bo mu się nie chciało review'ać i stwierdził, a wrzucę Kubryńskiemu i Szydło, niech oni sobie sprawdzą, bo ja już jestem zmęczony. I to się dzieje. Ja się zgodzę tylko z tym, że rzeczywiście warto robić review testów, szczególnie tych, które sprawdzają poprawność.

Ale odpowiedz sobie sam, bo nam się i tak nie przyznasz teraz. Ile w ciągu ostatniego roku miałeś testów na to, które sprawdzają, czy nie ma gdzieś przypadkiem n plus 1 selektów? Sam, czyli na tak zwanym poza antenie. No właśnie. I teraz wiesz, to jest klucz. Nawet ktoś powiedział, że nie mam. To pytanie, czy to dobry pomysł. No i właśnie widzisz, teraz mówi, że testy, performance, pisanie tego, a kluczowa rzecz, która zabija systemy, N plus 1, które jest super popularne i nawet LLM z mojego doświadczenia, który ma wszystkie skille JPA itd. Chyba gdzieś tego Entity Grapha nie wstawi i wyciąga potem N plus 1, żeby wyciągnąć to. Standard. To jest właśnie Code Review.