Mentionsy

DevTalk - Maciej Aniserowicz
DevTalk - Maciej Aniserowicz
28.03.2026 16:40

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

Przed nami ostatni odcinek DevTalk Trio, w którym Jakub Kubryński, Łukasz Szydło i Kuba Pilimon rozmawiają o tym, jak modele językowe zmieniają sposób myślenia i pracy programistów. Zastanawiają się, jakie mogą być długofalowe skutki decyzji podejmowanych przez LLM-y bez nadzoru oraz czy w procesie review ważniejszy jest sam kod, czy sposób jego powstawania. W tym […]

The post DevTalk Trio S03E08 – Kto odpowiada za kod, którego nikt nie rozumie? appeared first on DevTalk.

Szukaj w treści odcinka

Znaleziono 15 wyników dla "LLM"

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.

Nie wiem, muszę sprawdzić, zapytać LLM-a, przejrzeć kod i tak dalej, bo nie wiem, jak pewne rzeczy są zrobione.

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.

Powiedziałbym, że AI i LLM ten problem może skaluje?

W każdym razie, wracając do sedna, że ja właśnie dzięki LLM-owi...

To, co mi się nie podoba w takiej tendencji, jeśli chodzi o programowanie z LLM, to jest to, że jedna osoba to robi.

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%.

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.

Ja mówię, to jest bardzo dobre pytanie do naszego LLM-a.

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.

Rzeczywiście albo zapytajmy LLM'a, niech zerknie na ten kod, niech nam powie, co on uważa, albo

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?

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ć.

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.