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

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.

Ja już ufam, że ten kod jest zbieżny ze specką. Wiem, na jakie elementy tego kodu zwrócić uwagę, przeglądam sobie testy itd., ale to już nie jest takie review linia po linii. Ja już bardzo ogólnie sprawdzam i na takie review poświęcam godzinę, a nie pewnie 20 godzin, które powinienem poświęcić, żeby to zrobić po bożemu. Natomiast jakby ja zastanawiam się nad czymś innym. Czy przez to, że ja nie wchodzę już w takie bardzo niskopoziomowe szczegóły tego kodu, ergo dlatego nie mam tego modelu mentalnego, czy to ma jakieś konsekwencje długofalowe? Dlatego, że oczywiście my robiąc implementację musimy podjąć, dajmy na to 100 decyzji.

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.

Zapewne w tym workflow'e są, jeżeli powstaje jakiś kod, to najpierw jest kontrakt jakichś testów, I one przechodzą, one są dobrze napisane, jest agent, który weryfikuje zgodność ze specką, jest agent, który weryfikuje sensowność testów, czy one cokolwiek sprawdzają. Być może do testów mutacyjnych, nieważne. Jest pewnego rodzaju workflow, który ubezpiecza ciebie na to, że jeżeli później w git blamie jest Kuba Kubryński, to mimo że tej linijki nigdy nie widziałeś, bo nie przejrzysz całości implementacji, tylko przejrzysz być może kluczowe punkty, To jesteś na tyle bezpieczny, że i tak to wrzucisz do maina czy też do mastera. Jasne, co ciekawe my też komitujemy te wszystkie reviews, specki, wyniki, weryfikacji tych wszystkich agentów, które sprawdzają np.