DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie

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.

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.

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.

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.