Wpis użytkownika konrad1 w Hydepark

@kodyak dziękuję:)

@konrad1 ale nie dostaniesz odpowiedzi bo nikt tam niczego nie zatwierdzi. To taka mała otucha na brak odpowiedzi szczegolnie w sierpniu 😉

@kodyak chciałbym mieć taki luz i komfort $ żeby nie musieć, uwierz mi :grinning:

@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:

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

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

@DKK
W Asemblerze dało się coś napisać optymalnie, lub nie. C rozwiązywał ten problem, że powtarzalne rzeczy były wyniesione do języka, przez co programista mógł zaufać, że wszystko co zapewnia język jest optymalnie zaimplementowane - a przynajmniej sporo lepiej, niż napisałoby się samemu. Z AI jest taki problem, że jego działanie nie jest deterministyczne, więc nie wiesz czy rozwiązanie będzie optymalne, czy nie - ale to też nie ma większego znaczenia. Ale mogę też nie mieć racji, bo asemblera tylki kilka razy widziałem na oczy.

Obecnie granica miedzy Junior/Mid/Senior jest bardzo zatarta, a pracować można w każdej technologii bez jej znajomości. Myślę, że biorąc średnio ogarniętą osobę z ulicy można z niej zrobić ~programistę~ operatora AI w kilka dni. Obecnie jeszcze jest stan przejściowy, że zespół programistów ma narzędzie, ale raczej będzie dążyć to do tego, że operator (w liczbie pojedynczej) będzie tylko rozdzielał zadania.

Jak dla mnie ten rozwój jest bardzo niepokojący i nie zrozum mnie źle. Z jednej strony jest to ekscytujące, że jeszcze w tamtym roku pisałem normalnie kod, obecnie mogę napisać do AI "Stwórz story dotyczące dodania funkcjonalności do hejto, które umożliwi zalogowanym użytkownikom zmianę adresu email w ustawieniach konta", kliknąć ENTER i to tyle. AI stworzy story, opisze go, wyceni, zaimplementuje zmiany na wielu repozytoriach, napisze różnego rodzaju testy, zbuduje, odpali, przetestuje na działającej aplikacji, wrzuci PR, a Ty się tylko pod tym podpiszesz, jak już dopijesz kawę. Bardziej dociekliwi zerkną w kod, mniej dociekliwi przetestują ręcznie.

No ale co jest w tym przerażające? A no to, że obecnie AI mógłby wykosić 99% stanowisk, które uzupełniają komórki w excelu, czy pogrubiają literki w wordzie. A rozwój robotów też nie daje motywacji, żeby przekwalifikowywać się na coś bardziej ambitnego, do czego trzeba kilku lat przyuczenia się, bo te stanowiska też potencjalnie mogą zostać wykoszone. Jak nic włącza się foliarz mode on, że większość ludzi będzie tylko zbędnym zasobem zużywającym cenne, skończone zasoby planety.

@HmmJakiWybracNick Założę się, że jak C zastępował asemblera to też były takie argumenty. Ta wiedza kodowania popularnych i typowych algorytmów przestanie być potrzebna tak jak kiedyś dobrze napisany kod w aseblerze przez człowieka zastąpiony kompilatorami C. To jest niestety/na szczęście rozwój. Założę się drugi raz, że otworzą się nowe możliwości, a jakby nie było koderzy to raczej ludzie niegłupi więc dostosować się do rynku będą potrafili.

@konrad1

tylko że ja to naprawdę lubie... :grinning:

Problem jest taki, że nawet jak załapiesz robotę, to nie będziesz kodził. Będziesz operatorem AI, jest to wygodne, ale nie daje żadnej frajdy, a jeszcze mniej okazji na rozwój. A powiem więcej, człowiek traci masę wiedzy, bo jej nie wykorzystuje. Wszystko co było fajne w programowaniu, to AI to właśnie rozpierdolił. Teraz nie liczy się jakość, tylko żeby działało.

@LondoMollari poziom CC jest jak dla mnie zdecydowanie wyższy niż przeciętnego juniora. Bez problemu udaje mi się klepać PRki z typowo devowa robota, gdzie nie mialem w tym w ogóle doświadczenia wcześniej, kwestia dobrego prompta i zrozumienia, który context bedzie wartościowy dla bota

@konrad1 czyli junior ma obecnie być DevOpsem xd

@LondoMollari tylko to jest właśnie problem. Juniorów można wyciąć na rzecz jakiegoś bota z urojeniami. Na krótszą metę to zadziała, tylko nikt nie zadaje ważniejszego pytania- kto potem zastąpi seniorów, jak ci się wreszcie zwolnią, albo zwyczajnie przyjdzie ich czas i emerytura? Copiloty z pewnością tego nie pociągną, i wtedy managerstwo z pewnością zakrzyknie "awansujemy midów!". Konia z rzędem temu, który pierwszy takiego geniusza uświadomi na spotkaniu, że prędzej jego starą jak midów, których sobie nie wyszkolili, bo stwierdzili, że juniorzy to zbędny koszt do zredukowania. Firmy JESZCZE w szerszej perspektywie tego nie rozumieją, ale spokojnie- już powoli do nich zaczyna docierać absurd tego w co wpadli. Bardzo powoli, ale zaczyna, tak sam jak to było z cloudem z +rok temu

@konrad1 Dorzuć terraforma, jeśli chcesz iść w tematy distributed systems, bo zarządzanie infrastrukturą przyjdzie z tym tak czy siak w każdej firmie, poza bardzo dużymi korporacjami. Kafka jest moim zdaniem niszowa, i warto rozszerzyć stack.

@LondoMollari W dużej części się zgadzam, szczególnie że samo klepanie kodu przestaje być dużą przewagą. Nie jestem tylko przekonany do tezy, że junior/mid jako taki znika. Bardziej wygląda mi to na podniesienie poprzeczki - junior ma dziś oprócz kodowania rozumieć system, DB, deployment, debugging, trochę architektury i jeszcze sprawnie korzystać z AI. Czyli zakres „juniora” z 2026 to momentami pół mida z 2020 :grinning: :D

Sam zresztą próbuję teraz iść właśnie w tę stronę - backend Java + Kafka/distributed systems, więcej system designu i używanie AI jako narzędzia. Najgorszy jest tylko paradoks: żeby zdobyć doświadczenie w tych rzeczach, najpierw ktoś musi człowieka zatrudnić :D

Nawet powiem szczerze bym to rzucił, posłuchał rad typu: przebranżowij się, tylko że ja to naprawdę lubie... :grinning: a czas swoje też pokaże