@LondoMollari no więc mam trochę inne zdanie na ten temat:
Raz, że zgadzam się że już się LLMów nie pozbędziemy, dobre to jest, w przeciągu ostatniego roku, dwóch pisanie kodu z nimi poszło bardzo do przodu. Są oprócz tego świetnymi reviewerami, wyłapują mnóstwo szczegółów.
Jednak w zastąpieniu developerów w ogóle a juniorów w szczególności jest parę problemów:
-
Są niedeterministyczne. To NIE jest "kompilator specyfikacji", to jest narzędzie probabilistyczne, raz wypluje coś świetnego, raz gownianego. Możecie powiedzieć że da się to załatać na parę sposobów: więcej LLMów i tokenów, niech walczą o to kto lepiej programuje. No spoko, ale to tylko uśrednia wynik, a one są tak naprawdę: średnie. To narzędzie probabilistyczne, budowane na bazie kodu w sieci, który jest po prostu taki se. No to naprawimy to kontekstem, rulsami i skillami: no i z tym jest cała masa innych problemów: nie wszystko da się spisać, jak już da się spisać dużo to pojawia się problem skończonego kontekstu, a żeby spisać naprawdę wszystko trzeba mieć kupę lat doświadczenia na karku: co też zaczyna w którymś momencie mieć osobny problem, bo co bardziej doświadczony programista to nieco inne podejście, smak itp., nie ma jednej uniwersalnej odpowiedzi, a brak odpowiedzi tworzy burdel.
-
Pisanie kodu którego nie rozumieją ludzie. To ma dwa podproblemy: albo dlatego że prompter nie wie co LLM robi w ogóle i to się nazywa Vibe coding i jest tragedią samą w sobie, albo prompter wie ale nie ogarnia przy takim natłoku kodu które LLM jest w stanie naprodukować.
I tu dochodzimy do sedna sprawy. Jeśli ludzie nie będą wiedzieć o rozumieć co robi kod, to nie będą w stanie nawet wytłumaczyć dlaczego w tym miejscu jest jakieś restowe api, które blokuje port przy wystawieniu narzędzia do chmury, tyle że to nigdy nie miało wystawiać w ogóle jakichkolwiek portów.... Programowanie składa się z podejmowania bardzo wielu bardzo małych decyzji, ale te małe decyzje mają znaczenie często na wszystkich warstwach abstrakcji. Zostawienie ich automatom powoduje że albo powstaje coś niezgodnego w bardzo wielu drobnych szczegółach z pierwotną intencją (Vibe coding), albo coś na co tracimy multum czasu, żeby przejrzeć, poprawić po "dziecku", skorygować itp., bo jak się tego nie zrobi to pójdzie z kodem w krzaki. A to z kolei kosztuje czas, który ma szansę się zwrócić, ale często nie, albo jest to kosztem wiedzy o kodzie operatora (problem czarnej dziury w kodzie), zapełnia kontekst, który w którymś momencie staje się coraz bardziej brany pod uwagę wybiórczo przez narzędzie, a więc staje się bezużyteczny.
Moim zdaniem nie da się tak na dłuższą metę pisać kodu. Kończy się to tym, że co drugą stronę trzeba przeładowywać, MS Teams (#$!@$&!!) działa jak ostatni crap itp.
Wszyscy powinniśmy zwolnić. Docieramy do szczytu tego co te narzędzia oferują, a wykorzystujemy je jakby były znacznie lepsze niż są, a są wciąż takie se: dobre do prostych rzeczy, ale w większych podejmują mnóstwo dyskusyjnych decyzji, które nie kopią Cię w tylek od razu.
I wracając do tematu, potrzebujemy juniorów, bo wciąż nie jesteśmy, a moim zdaniem co najmniej długo nie będziemy (a na pewno nie powinniśmy) zrzucać całego kodu na LLMy.
