Mentionsy
DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie
Rozmawiamy o tym, jak profesjonalnie budować oprogramowanie z LLM-ami, zamiast bawić się w vibe coding. Z tego odcinka dowiesz się: Jak daliśmy się nabrać na magię AI i dlaczego pierwszy sukces z LLM-em to pułapka; Co się dzieje, gdy tworzymy nową aplikację z AI bez narzuconych standardów; Czy w erze AI musimy wrócić do koncepcji […]
The post DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie appeared first on DevTalk.
Szukaj w treści odcinka
To bardzo często ludzie mówią, że AI generuje gówno i kod, który wygeneruje AI jest dramatyczny i zaraz wszyscy będziemy nie robić nic innego, tylko poprawiać kod po LLM-ie.
Wydaje mi się, że ogólnie bardzo dużo z tego bierze się z nieumiejętnej pracy z LLM-ami.
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.
Natomiast, jeżeli pracuję z LLM w sposób...
Naprawdę sensowny, tak że jakby tworzę SPK, rozmawiam z tym LLM-em co ma zrobić, gdzie ma zrobić, jak ma to zaprojektować, gdzie ma się wpiąć w obecny system, czy ma zrobić tabelę łączącą, czy nie i tak dalej, no to jakby dostanę efekt, który jest jakby...
Ciekaw jestem, czy Wy właśnie słyszycie głosy tego, że LLM tworzy słaby kod i zaraz wszyscy będziemy bardzo potrzebni, bo będziemy musieli poprawiać po kodzie, który przez najbliższe x lat będzie generowany przy pomocy kodeksa, kursora czy cloda.
Że jak zaczynasz pierwszy raz używać LLM-a do tego, żeby napisać kod, to masz jakieś proste zadanie.
I ten LLM bardzo dobrze potrafi generować 37 tysiąc aplikacji do zarządzania projektami albo aplikacji jakichś tam, nie wiem, boardów czy, czy, czy stronek internetowych, nie?
Jak zaczęliście się bawić LLM-em rok temu, to jakby szybko dochodziliście do wniosku takiego, że vibecoding nie działa.
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.
I ten problem nie zniknie tylko dlatego, że kod został wygenerowany przez LLM-a.
Wydaje mi się Łukasz właśnie, że tutaj mówimy o prawidłowym użyciu LLM-ów.
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.
Ja zawsze mówię, że LLM jest jak senior w twoim projekcie.
Taki LLM by design z cloud odpalony nie do końca.
Więc w tym kontekście, jeżeli tak ludzie pracują z LLM-ami, to faktycznie jakby rezultaty są słabe.
I ja to mówię jakby jako osoba, która pracując jakby z LLM-ami na co dzień,
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.
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?
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.
Z mojego doświadczenia też LLM lepiej działa w aplikacji, która jest napisana
Budowałem dwie aplikacje, takie Production Ready od zera z LLM-em.
Natomiast jakby tak, wydaje mi się, że podsumować to można trochę tak, jak Łukasz mówił, że jeżeli jakby chcesz pracować z LLM, chcesz, żeby on był twoim przyjacielem, to zadbaj o ten cały ekosystem, który jest dookoła.
Który pozwoli temu LLM-owi jakby wiedzieć, jakby jak ma robić i wtedy ty musisz tylko zadbać o to, co ma robić, nie?
LLM-ie, zapamiętaj to na przyszłość, czyli trochę tak, jak mamy dobre praktyki pracy z błędami.
Tutaj ciekawa rzecz, jak uczyłem mojego LLM-a, żeby z tym pracował,
Nie do końca o to chodzi, drogi LLM-ie.
I tak samo jakby pracując z LLM-ami, też musimy dbać o pewne rzeczy, że jeżeli jest jakiś błąd i LLM poprawił ten błąd, to ta pętla feedbackowa moja do LLM-a musi być super krótka.
I to, co LLM-y robią, często robią takie do's and don'ts.
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,
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.
Więc jeżeli miałbym LLM-a, który byłby genialny w konwersji speka na kod,
A teraz jak kto robi LLM, to ja naprawdę jestem mnóstwo w stanie rzeczy zembedować w kodzie i nawet jak robię jakąś modyfikację, to jestem w stanie jakby kontrolować obie te zmienne, bo mam to wszystko w jednym miejscu i mogę robić zarówno LLM-em, jak i mogę robić manualnie w tych miejscach precyzyjnych, gdzie potrzebuję, jeśli ciągle będę chciał to zrobić.
Ostatnie odcinki
-
DevTalk #141 – O technologii w służbie bezpiecz...
03.04.2026 10:41
-
DevTalk Trio S03E08 – Kto odpowiada za kod, któ...
28.03.2026 16:40
-
DevTalk Trio S03E07 – Taktyczne wzorce projekto...
26.03.2026 10:04
-
DevTalk Trio S03E06 – Czy AI odbiera nam umieję...
24.03.2026 09:33
-
DevTalk Trio S03E05 – Vendor lock-in i widmo dy...
18.03.2026 10:28
-
DevTalk Trio S03E04 – Poprawianie kodu po LLM-ie
16.03.2026 16:02
-
DevTalk Trio S03E03 – DDD w erze LLM
13.03.2026 09:15
-
DevTalk Trio S03E02 – Czy Twój SaaS przetrwa er...
11.03.2026 10:17
-
DevTalk Trio S03E01 – Czy AI zastąpi programistów?
09.03.2026 10:14
-
DevTalk #140 – O Salesforce CRM ze Stanisławem ...
02.03.2026 17:31