Czy juniora można już zastąpić LLM? A skąd będą pochodzić seniorzy? Opinie pracowników IT

Dzik zapytał product managera, QA managera i deweloperów, co myślą o zastąpieniu juniorów modelami LLM.

2 каментарыя

Liczba ofert pracy dla początkujących jest nadal niewielka, a niektórzy uważają, że juniorów można zoptymalizować za pomocą narzędzi low-code/no-code.

«Kiedyś popularna była transformacja Agile, teraz transformacja AI»

Andrzej, Product Manager z ponad 15-letnim doświadczeniem

— To, że zarządzający w IT zdecydowali: «Koniec z zatrudnianiem juniorów, ich pracę będą teraz wykonywać midzi i seniorzy z narzędziami AI» — to fakt. Widać to w liczbach.

Tak, juniorzy są potrzebni dla ciągłości. Ale firmy chcą ciąć koszty, dlatego temat AI wchodzi błyskawicznie.

Myślę, że najbliższe pół roku-rok będzie okresem testowym. Obecnie wiele firm próbuje zrozumieć, jak właściwie wykorzystywać AI — bo bez odpowiednich umiejętności nie przyniesie to pożądanego efektu. Na przykład niedawne badanie MIT pokazało, że 95% firm nie widzi wartości z wdrożenia AI — tylko około 5% pilotażowych programów AI osiągnęło szybki wzrost przychodów, a reszta praktycznie nie miała mierzalnego wpływu na zyski i straty (badanie oparto na 150 wywiadach z dyrektorami, ankiecie wśród 350 pracowników i analizie 300 publicznych wdrożeń AI — przyp. Dzika).

Kiedyś popularna była transformacja Agile, kiedy zespoły uczyły się pracować w nowy sposób, w bardziej kompaktowym formacie. Teraz mamy transformację AI, kiedy musisz nauczyć się pracować z nowymi narzędziami opartymi na LLM, Generative AI itd. Inną kwestią jest to, że niewielu product managerów nauczyło się pracować w nowy sposób.

Załóżmy, że wcześniej, aby wprowadzić na rynek nowy pomysł lub funkcję, ja jako product manager musiałem usiąść, przemyśleć, zbadać opinie użytkowników. Przejrzeć zgłoszenia do supportu, przeprowadzić badanie rynku, porozmawiać z użytkownikami, przejść się po dziale sprzedaży, marketingu; pójść do deweloperów, dowiedzieć się o ich długu technicznym. Następnie sformułować hipotezy i udać się z nimi do projektanta i dewelopera.

To ogromna praca, która zajmowała tygodnie i miesiące. Teraz ten cykl skrócił się do dni — dzięki narzędziom AI.

AI pomoże stworzyć arkusz Excel, przygotować pytania, przetestować je w «syntetycznym» wywiadzie jeszcze przed rozmową z prawdziwymi ludźmi; ustalać priorytety funkcji; zbadać semantykę odpowiedzi użytkowników, podpowiedzieć ich nastrój; znaleźć punkty bólu, w które warto uderzać, a nawet zaproponować nowe hipotezy. No i wreszcie, sformułować wymagania.

Te narzędzia zaczynają już występować w roli rozmówcy, który uzupełnia twoje spojrzenie na sytuację. Tak, oczywiście, trzeba je sprawdzać — ale to nadal wynik pracy, który można wykorzystać ponownie w jakimś procencie.

Powiedziałbym, że to już działa na 60%. Wcześniej poprosiłbym juniora o wykonanie tych zadań — a teraz radzę sobie sam, tylko z pomocą odpowiednich narzędzi.

Analitykom biznesowym wdrożenie narzędzi generatywnych również pomaga skrócić czas pracy o 20-30% — jeśli prawidłowo ich używają. Wszystko zależy tu od ludzi, kontekstu, dozwolonych na projekcie narzędzi AI i tego, jakimi danymi można się dzielić.

Czy zmniejszenie zatrudnienia juniorów to dobry pomysł? Zobaczymy z czasem. Tak, będą konsekwencje, ale biznes lubi na czymś oszczędzać i często nie widzi problemów, które pojawią się w przyszłości z powodu cięcia kosztów teraz.

Wniosek: tak, juniora można już zastąpić w określonych zadaniach i w zarządzaniu produktem.

Jeśli chcesz pozostać konkurencyjny, radziłbym studiować narzędzia generatywne i uczyć się nowych podejść w pracy. Szczególnie ważne jest rozwijanie umiejętności relacji międzyludzkich.

«Radziłbym obecnym juniorom QA opanować tematy powiązane z AI»

Aleksander, Senior QA Engineering Manager z ponad 15-letnim doświadczeniem

— Niedawno nasza firma podjęła decyzję, że musimy iść w kierunku wdrożenia narzędzi AI do wszystkich procesów tworzenia i testowania, zakupiła licencje na różne agenty AI, LLM, IDE, wtyczki i uruchomiła program szkolenia pracowników.

Obecnie jesteśmy w procesie transformacji od około pół roku i doszliśmy do wniosku, że całkowite zastąpienie QA jako kategorii nadal nie jest możliwe. Ale zoptymalizowanie pracy lub wykonanie niektórych zadań QA — jak najbardziej.

Ostatecznie ze wszystkich narzędzi AI zachowaliśmy GitHub Copilot, który w wersji enterprise może działać zarówno jako wtyczka do czatu z LLM, jak i agent AI do analizy kodu źródłowego w repozytorium oraz generowania kodu lub zmian w kodzie bezpośrednio w środowisku deweloperskim. Między innymi, w celu analizowania wyników różnych narzędzi AI i modeli LLM, używamy Cursora i Claude Code jako dodatkowych środowisk deweloperskich.

Na podstawie doświadczeń z GitHub Copilot można powiedzieć, że już teraz jest całkiem przydatny do automatyzacji testowania i pisania testów API. Agent GitHub Copilot potrafi przeanalizować kod źródłowy w repozytorium i na podstawie opisanych instrukcji, wymagań lub tekstu scenariusza testowego stworzyć nowy test API, wprowadzając wszystkie niezbędne zmiany w kodzie projektu.

Jeśli chodzi o jakość kodu i dokładność oczekiwanych wyników, radzi sobie bardzo dobrze — na poziomie 85–90% skuteczności, nie gorzej niż junior QA, a czasem nawet lepiej i znacznie szybciej. W rezultacie mamy +75-80% do szybkości tworzenia testów API, co uważam za bardzo dobry wynik.

Unsplash

Ale z innymi rodzajami automatyzacji testów są jeszcze niuanse.

Pełna automatyzacja testowania UI lub aplikacji mobilnych okazała się na razie zbyt trudna dla testowanych przez nas agentów AI z różnymi modelami LLM — zarówno ze względu na złożoność istniejącego kodu, jak i niemożność dotarcia przez agentów AI do zawartości stron/ekranów aplikacji i wykonania wysokiej jakości wyszukiwania elementów. Gotowego rozwiązania tego problemu jeszcze nie znaleźliśmy, dlatego pracujemy nad opracowaniem własnego serwera MCP.

Przy użyciu GitHub Copilot do pisania testów UI jakość kodu i dokładność wyników pozostawiają jeszcze wiele do życzenia — mniej niż 40-50%, co uważam za słaby wynik. Junior «klepie» takie testy może nie szybciej, ale lepiej.

Z aplikacjami mobilnymi jest jeszcze trudniej, tam jakość kodu i dokładność wyników nie przekraczają 20-25%.

Myślę, że przy umiejętnym doborze i zastosowaniu narzędzi AI już teraz możliwe jest zautomatyzowanie większości prostych i średnio złożonych zadań w QA, co pozwoli wykluczyć większość juniorów QA z udziału w tym procesie.

Każdy biznes dąży do optymalizacji kosztów. Umownie mówiąc: po co firmie 50 juniorów jeśli zamiast tego można zatrzymać 5-10 midów, którzy z pomocą narzędzi AI wykonają tę samą ilość pracy?

Kolejnym sygnałem ostrzegawczym dla juniorów QA może być to, że firmy w ostatnim czasie coraz rzadziej są gotowe ryzykować i zatrudniać juniora QA — nawet jeśli ma doświadczenie z narzędziami AI i umie je obsługiwać. Przede wszystkim — z powodu braku głębokiego doświadczenia/wiedzy w dyscyplinie QA i niemożności analizowania jakości wyników dostarczanych przez różnych agentów AI i modele LLM (lub wykonują taką analizę w bardzo ograniczonym zakresie).

Osobiście widziałem przykłady, gdy zamiast 200-300 linii oczekiwanego kodu zmian junior QA z narzędziami AI otrzymywał 1200 linii kodu poprzez szablonową generację kodu. Co więcej, zaproponowane rozwiązanie było nieoptymalne i miało «zepsute» wzorce. Szybko, ale nieefektywnie — w dłuższej perspektywie grozi to dużymi problemami.

W przypadku specjalistów senior/lead sytuacja jest zupełnie inna. Tutaj narzędzia AI naprawdę pomagają. Optymalizują rutynę, przyspieszają proces pisania kodu bez widocznej utraty jakości kodu i wyników, uwalniając jednocześnie więcej czasu na inne zadania i sprawdzanie kodu tych samych specjalistów mid-level, którzy są jeszcze potrzebni w obecnej hierarchii QA.

Uważam, że z czasem możliwości osób bez doświadczenia/juniorów QA, aby dostać się do IT i testowania QA oraz automatyzacji w szczególności, będą się tylko pogarszać. Liczba ofert pracy i liczba osób potrzebnych w tej dziedzinie już maleje.

Myślę, że bardzo szybko za pomocą narzędzi AI zostanie zaspokojony istniejący popyt na testowanie API i automatyzację, następnie — testowanie UI i automatyzację, a potem już dotrą do aplikacji mobilnych i bardziej złożonych rzeczy. Postęp wcześniej czy później zrobi swoje.

Co radziłbym obecnym juniorom QA? Opanować tematy powiązane z AI, na przykład rozwijać się w kierunku testowania agentów AI i modeli LLM. To staje się konieczne do zapewnienia stabilności i oceny jakości wyników pracy narzędzi AI.

AI Models Testing to teraz bardzo świeży i perspektywiczny temat, którym zajmuje się dosłownie kilka osób w kilku małych startupach.

«Jest jeszcze pesymistyczny scenariusz»

Ilya, Senior FullStack PHP & JS/TS z 11 latami komercyjnego doświadczenia

— Częściowo można zastąpić. Junior zawsze potrzebuje jasnych instrukcji do wykonania zadania, weryfikacji i pomocy w jego wykonaniu.

Ta sama praca jest wykonywana przy użyciu LLM — tylko generuje ono kod szybciej niż junior i prawie za darmo.

W największych firmach juniorzy zawsze byli zatrudniani z perspektywą rozwoju do poziomu mida. Zmniejszenie liczby ofert w takich firmach to konsekwencja zmniejszenia budżetów. Po co brać juniorów, gdy na rynku jest wystarczająco dużo midów i seniorów?

Osobiście używam LLM od półtora roku, ostatnio coraz aktywniej. Najpierw ChatGPT, potem Copilot, teraz — Supermaven do «autouzupełniania» i Cursor.

W pracy używam przede wszystkim do tworzenia nowych stron: LLM świetnie je generuje zgodnie ze starymi. Na każdej generacji oszczędzam co najmniej godzinę czasu, czasem jest to dwa razy szybciej, niż gdybym robił to sam.

Większość czasu zajmuje sprawdzanie wyniku, drobny refactoring, naprawianie błędów. Na szczęście LLM popełnia dość mało błędów, bywają generacje, po których wszystko od razu działa.

Do prostych algorytmów zawsze staram się używać LLM. Tak, sam mogę to napisać w 15-30 minut, ale z LLM zajmuje to sekundy i jeszcze minutę na sprawdzenie wizualne.

AI nie radzi sobie zbyt dobrze z frontendem, ponieważ nie może przetestować wygenerowanego layoutu (a przynajmniej nie znalazłem takiej usługi). Dlatego doprowadzenie layoutu do ideału i późniejsze poprawki — tylko człowiek. Na tym etapie można to spokojnie powierzyć juniorowi.

Z naprawianiem błędów AI również ma problemy. Można wszystko wyjaśnić, a model i tak naprawia nie to, próbuje szukać błędu tam, gdzie go nie ma… Próbowałem kilka razy, ale mam w tym małe doświadczenie, nawet nie próbuję powierzać naprawy błędów maszynie, bo wcześniejsze doświadczenia są negatywne.

PHP też nie umie debugować. A może i JS nie umie, przynajmniej Cursor mi tego nie proponował. A to oznacza, że debugowanie — to nadal zadanie dla człowieka.

Ale ku mojemu zdziwieniu okazało się, że drobne poprawki w jakimś losowym miejscu projektu LLM wykonuje szybciej od człowieka.

Mam projekt średniej wielkości. Ponieważ pracuję z nim tylko 2 lata, a ogółem mam 4-5 projektów, nie znam wszystkich szczegółów. Dałem LLM do zrobienia poprawkę — i w ciągu minuty ją wprowadziła. Chociaż spędziłbym około 10 minut tylko na zorientowaniu się, gdzie w ogóle znajduje się ten kod. Zdecydowałem, że wyszukiwanie kodu lepiej powierzać LLM, jest to dla niej łatwiejsze.

Był też jeden błąd związany ze składnią. Kod był po prostu składniowo niepoprawny. Na froncie layout «płynął» z powodu jakiegoś cudzysłowu. Programista nie zauważył, dla mnie też nie było to zbyt jasne, ale LLM błyskawicznie naprawiła ten problem.

Co do kształcenia juniorów i perspektyw — zbyt złożone pytanie i dla mnie nieaktualne. Z jednej strony myślę, że juniorom czy uczniom powinno się zabraniać korzystania z LLM, aby sami uczyli się kodować. Z drugiej strony, za 20 lat prawdopodobnie nikt nie będzie ręcznie pisał kodu.

W rezultacie będzie jak z pisaniem na papierze. To przestarzała, mało potrzebna umiejętność, ale ludzie i tak uczą się tego dla ogólnego rozwoju. Z programowaniem w przyszłości będzie tak samo: w szkole i na uniwersytecie będą zmuszać do samodzielnego programowania, a w pracy 90% kodu będzie pisało LLM.

Dla mnie logiczne jest, że w przyszłości może powstać niedobór juniorów i midów, ponieważ po prostu powinien zmniejszyć się napływ chętnych do wejścia do IT. I tak, będzie brak seniorów, gdy zwiększy się liczba projektów oprogramowania i budżety.

Unsplash

Programowanie nie stoi w miejscu: pojawią się nowe języki, nowe frameworki, programiści w takiej czy innej formie będą potrzebni.

Ale to optymistyczny scenariusz, który opiera się na doświadczeniach z przeszłości. Jest jeszcze pesymistyczny, w którym AGI pojawi się w przyszłym roku. Powiedzmy, będą super-inteligentne agenty i być może nowa fala redukcji programistów. Ale na razie to fantastyka.

«Operator ze znajomością specyfiki i tak jest potrzebny»

Wiktor, Senior PHP Developer z 8-letnim doświadczeniem w IT

— Myślę, że ktoś musi uruchamiać i wyjaśniać AI istotę zadania, a następnie sprawdzać poprawność i prawidłowość działania. To znaczy, w każdym przypadku potrzebny jest operator.

Tyle że junior później rozwinie się dalej w mida (jeśli się nie rozleniwi). Ogólnie rzecz biorąc, tak czy inaczej, operator ze znajomością specyfiki jest potrzebny.

Ja na stałe codziennie używam Github Copilot do zwiększenia wydajności pracy. Na przykład do pisania dokumentacji technicznej dla aplikacji API. Jednak w każdym przypadku trzeba przejrzeć każdą linijkę i sprawdzić jakość, a do tego potrzebne jest już wypracowane doświadczenie. Dlatego operator AI musi sprawdzać jakość i funkcjonalność kodu.

Ogólnie rzecz biorąc, z prostymi rutynowymi zadaniami AI ratuje każdego dnia, ale na dzień dzisiejszy i tak trzeba go stale weryfikować.

Próbowałem pisać złożone zadania (duże i skomplikowane zapytanie SQL) za pomocą Groka — nie dał rady. Doszło do cyklicznych błędów — poprawiając jeden, robił drugi i tak w kółko. Musiałem sam składać po kawałku.

Tak, myślę, że w przyszłości będzie brakować seniorów. Senior, moim zdaniem, tym się różni, że ma doświadczenie w rozwiązywaniu nie tylko typowych zadań, ale także rzadkich, złożonych nietypowych problemów, których rozwiązań nie ma na forach czy w książkach o programowaniu.

To jak wyższe wykształcenie dwóch studentów: jeden po prostu chodził na zajęcia dla dyplomu, a drugi wnikał w każdy wykład — który z nich zostanie na stanowisku umownego seniora. Myślę, że z LLM będzie tak samo.

Jeśli student celuje w IT, LLM to najlepszy podręcznik do przyswajania materiału. Używać w pracy tylko tam, gdzie już sam robiłeś ręcznie. W takim przypadku doświadczenie będzie się budować, a LLM będzie dobrym pomocnikiem.

Jak nowicjusze mogą teraz zwiększyć swoją wartość na rynku pracy? Dobre pytanie, chyba trzeba je zadać rekruterom. Przebijałem się do IT przez pół roku, ale to było już 6-8 lat temu.

Wydaje mi się, że obecnie najlepszym wskaźnikiem jakości juniora jest jego portfolio. Na rozmowach kwalifikacyjnych można korzystnie opisać swoje projekty z punktu widzenia zdobytego doświadczenia, pokazać rozmówcy jakość swojego myślenia (łatwiej opowiedzieć o swoim projekcie niż o wymyślonym na poczekaniu).

Tak, mówię przede wszystkim o projektach hobbystycznych. Nawet będąc już midem, projekty osobiste zmuszają do zagłębienia się w technologie. To jak własny samochód — gdy się zepsuje, trzeba zajrzeć pod maskę. A to już cenne doświadczenie.

Dla studenta czy juniora to będzie gęsty las, ale przejście choćby kawałka takiego lasu i pokazanie go rekruterowi — od razu plus 100 punktów.

«Czy w przyszłości może być brak seniorów? Mogę tylko na to liczyć. Osobiście będzie mi to ogólnie korzystniejsze»

Vlad, Senior Software Engineer, Fullstack (Python, Go, JS itd.) z 15-letnim doświadczeniem

— Junior wyrośnie na mida i odejdzie do innej firmy, ponieważ zmiana pracy prawie zawsze jest korzystniejsza niż nowe stanowisko w tej samej firmie. A LLM nigdzie się nie wybiera.

Używam LLM maksymalnie — do pisania kodu i testów, tłumaczeń na inny język; korygowania UI. Omawiam z Claude i ChatGPT architekturę nowych funkcji. Używam do tworzenia interaktywnych demo swoich pomysłów. Coraz częściej używam ChatGPT zamiast Google do wyszukiwania informacji.

Szybko naszkicować MVP jakiejś nowej funkcji — w ogóle super. Ale potrzebna jest kontrola i trzeba mieć wystarczająco dużo doświadczenia, aby rozumieć, kiedy LLM dało akceptowalny wynik, a kiedy lepiej go wyrzucić i pisać samemu.

Nie mogę ślepo ufać LLM, więc najwyraźniej lepiej zawsze powierzać zadanie człowiekowi, a dalej on już decyduje, jakich narzędzi używać.

Osobiście mam dość pesymistyczne spojrzenie na juniorów. Odpowiem z zastrzeżeniem, że w naszej firmie nie ma juniorów od około 10 lat.

Prawdopodobnie zależy to od poziomu juniora. Rozmawiałem ze znajomymi na ten temat, jaki poziom reprezentują juniorzy w ich firmach. Niektórym można było dać zadanie i sami je rozwiązywali. A gdzieś juniorzy są na takim poziomie, że LLM już piszą kod lepiej i można im dawać na wejściu krótszy prompt niż początkującemu.

Był zabawny przypadek, kiedy junior po kilku rozmowach telefonicznych i wyjaśnieniach nadal nie mógł napisać testu, który poprawnie testuje to, co trzeba. Tymczasem Copilot (nie najinteligentniejszy LLM) potrafił to zrobić od pierwszego zapytania.

Czy w przyszłości może zabraknąć seniorów? Trudno powiedzieć, zbyt wiele czynników na to wpływa. Mogę tylko na to liczyć. Osobiście będzie mi to ogólnie korzystniejsze, jeśli seniorów będzie mniej w wyniku zaprzestania zatrudniania juniorów.

Mam 15 lat doświadczenia i pierwsze 11-12 lat, wydaje mi się, upłynęło w warunkach powszechnego braku seniorów, a branża IT miała się dobrze.

W teorii oczywiście wszyscy troszczymy się o branżę i lubimy konkurencję, ponieważ napędza ona rozwój. Ale w praktyce każdy stara się stworzyć monopol, tylko nie wypada o tym mówić głośno.


Читать на dev.by