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

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!

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.

I dopiero po... W naniesieniu poprawek na ten high level design mamy coś, co pozwala na rozpoczęcie fazy deweloperskiej, jeszcze nie implementacji. Drugim krokiem, bo to był pierwszy, jest przygotowanie specki. I znowu tę speckę przygotowuje jedna osoba. Ta specka ląduje w repo. Jakub Kubryński, Łukasz Szydło, Kuba Pilimon, DevTalk. Najbardziej newralgiczny moment review, bo błędy popełniane na etapie review specyfikacji się jeden w jeden przełożą na błędy na poziomie kodu i potem tak naprawdę dopiero trafia ten finalny kod, który bardzo często jest na tyle duży, że przejrzenie jego już jest jakby trudne.

I tam też trochę tak było, że rozumiem model, tak jak nazwałeś mentalny, pewnego rodzaju klasy złożoności i rozwiązania jakiegoś tam modułu, jak to jest zrobione. Ale ja nigdy, przynajmniej ja, nigdy nie pamiętałem, jaka jest każda linijka, wręcz czasami nigdy nie widziałem. I też nie byłem w stanie odpowiedzieć na pytanie, jak to się zachowa, jeżeli stanie się sytuacja X, ale wiedziałem, jak w bardzo łatwy sposób odtworzyć sytuację X. Na przykład testem jakiegokolwiek tam typu. I teraz, czy jeżeli ja mogę odtworzyć taką samą sytuację, jeszcze szybszym cache'em użyję tej analogii, której Łukasz użył. Zapytam jakiegoś narzędzia, które mi to powie, a później to zweryfikuję.

production readiness, code quality itd. One lądują w repo, więc ja jestem w stanie sobie potem zobaczyć np. I teraz już nie, ale na początku zdarzały nam się takie sytuacje, gdzie wiecie Kloss był jakby genialny w zostawianiu metody, która miała w sobie to do i twierdził, że wszystko zrobił. Dopiero potem subagent, który to reviewował mówi, ale tu jest jeszcze to do, tu popraw i tak dalej. To zdarzało się, że np. z jakiegoś powodu w tych chorobach wieku dziecięcego jakaś np. faza walidacji się nie odpaliła. I potem byłem w stanie wejść w status orkiestracji tego agenta i zobaczyć, że tego faktycznie nie ma. I potem nawet byłem w stanie na tym kodzie odpalić ponownie tę walidację i coś naprawić. Natomiast znowu zastanawiam się, może do Łukasza pytanie lepsze, bo Łukasz lubi takie pytanie niesprecyzowane, takie miałkie, bez jednej dobrej odpowiedzi.

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.

Im mamy większą ilość tych rzeczy, tym tak naprawdę ten efekt, o który Ty mówisz, o co mi chodzi? Chodzi mi o to, że ja już nie muszę wtedy Jakub Kubryński, Łukasz Szydło, Dostaliśmy możliwość zrobienia tego i moim zdaniem powinniśmy z tego korzystać. Więc dla mnie połączenie tych dwóch elementów, czyli naprawdę sporego zestawu testów, które możemy robić, plus to, co mówiliśmy na początku, że ja jestem w stanie z tym cache'em mieć, jeżeli ktoś przyjdzie do mnie i zada mi to pytanie, to ja mogę mu na dwa sposoby odpowiedzieć.

Rzeczywiście albo zapytajmy LLM'a, niech zerknie na ten kod, niech nam powie, co on uważa, albo Just do it, nie? Po prostu powiedz mu ten case, który tam chcesz zrobić, to po prostu powiedz mu, żeby on to zaimplementował i zobacz, nie? Napisz tam, powiedz mu, każ mu napisać te testy i jest, nie? Więc mi się wydaje, że właśnie jeżeli przesuniemy to... W tę stronę wykorzystamy to, że mamy teraz bardzo dużo kodu możemy pisać, to wykorzystajmy go do tego właśnie, żeby pisać tych rzeczy, których zawsze nam brakowało, na które nigdy nie mieliśmy czasu, które zastępowaliśmy Code Review. Moim zdaniem właśnie Code Review to nie jest rzecz, która jest może inaczej. Są tylko niektóre elementy, które my musimy rzeczywiście reviewować, a większość z nich da się zautomatyzować. Tylko wiesz co Łukasze, nie jestem wcale przekonany, że to, że jesteśmy w stanie pisać dużo testów znaczy, że powinniśmy pisać dużo testów, bo one też mają overhead na deployment naszego systemu.

I teraz to, że ja mogę napisać testy wydajnościowe to super, ale muszę mieć ekosystem do odpalenia tych testów wydajnościowych. Mogę sobie napisać testy, które plikają mi po guju, ale te testy trwają swoje. One jakby nie są idealne. Zdarza się, że one jakby wiesz... Jakub Kubryński, Łukasz Szydło, Kuba Pilimon, DevTalk. Takich, które są, ale w zasadzie jak je wywalisz, to za dużo nie tracisz.

I zainwestowały bardzo dużo w Developer Experience, które mają bardzo ekstensywne testy. Nie wiem czy wszystkie, ale wydaje mi się, że to jest naprawdę bardzo dobry kierunek i moim zdaniem w tym kierunku powinniśmy dążyć. Mi na przykład w jednym z projektów, w których teraz jestem tego brakuje i na pewno będę dążył do tego, żeby tego typu rzeczy się pojawiły. To ja podsumuję. Trochę mamy różne opinie jak zwykle i dobrze. Tutaj chyba znowu wychodzi to, że ja z Pilo mamy większe doświadczenie po prostu i Łukasz jest jeszcze na etapie życzeniowym z niektórymi kawałkami. Podsumowując, rozumiem, że tak naprawdę to, gdzie się zgadzamy, to że review tego procesu wytwórczego i tego, w jaki sposób agenty pracują z kodem, jak reviewują kod, na co zwracają uwagę, że to jest tak naprawdę dźwigniowe i na tym powinniśmy się skupiać i to nasze review powinno tak naprawdę