Juniorzy używają AI najwięcej. I dostają z tego najmniej.

W Science wyszło badanie, które zatrzymało mnie na dłużej niż większość innych rzeczy o AI w ostatnim półroczu. Daniotti, Wachs, Feng i Neffke z Complexity Science Hub w Wiedniu i Uniwersytetu w Utrechcie przeanalizowali 30 milionów commitów od 160 097 deweloperów na GitHubie z sześciu krajów (USA, Niemcy, Francja, Indie, Rosja, Chiny). Wytrenowali klasyfikator sieci neuronowej, który dla każdej funkcji w Pythonie ocenia, czy została napisana ręcznie, czy z istotną pomocą AI. Następnie modelami fixed-effects (porównującymi tę samą osobę w czasie) sprawdzili, jak adopcja AI wpływa na produktywność i eksplorację nowych obszarów.

Wniosek brzmi tak:

Juniorzy używają AI najwięcej. I dostają z tego najmniej. Cały zysk z AI w kodowaniu trafia do seniorów.

To nie jest opinia, ankieta ani marketing dostawcy narzędzi. To recenzowane badanie w jednym z najważniejszych czasopism naukowych na świecie, na danych behawioralnych w skali, której nikt wcześniej nie obrobił.

Chcę ten wpis poświęcić na trzy rzeczy: dokładnie pokazać, co badanie mierzy, jaki widzę mechanizm za tymi wynikami, i co z tego praktycznie wynika — osobno dla juniorów, dla seniorów bez AI i dla osób, które dziś decydują, czy zatrudnić młodego czy „obejść się AI-em”.

Piszę to z perspektywy programisty .NET/React na etacie, który po godzinach codziennie pracuje z Claude Code, buduje swoje projekty i testuje nowe narzędzia AI, jak tylko wychodzą. Nie jestem socjologiem, ekonomistą ani autorem badania. Liczby cytuję, mechanizm proponuję jako hipotezę, do osobistej weryfikacji u czytelnika.

Co dokładnie zmierzyli

Najpierw metoda — bo bez niej te liczby są tylko liczbami.

Klasyfikator został wytrenowany na ludzkich funkcjach Pythona z GitHuba i ich syntetycznych odpowiednikach. Syntetyki powstały w wyniku łańcucha dwóch dużych modeli językowych: pierwszy opisuje ludzki kod naturalnym językiem, drugi reimplementuje go na podstawie tego opisu. Tak powstaje zbiór par „ten sam pomysł, dwa źródła” — i klasyfikator uczy się je odróżniać. Następnie został zastosowany do 30 milionów commitów w latach 2019–2024.

Dla amerykańskiego podzbioru (100 097 deweloperów) badacze zastosowali model fixed effects. To prosty trick statystyczny — porównujesz tę samą osobę w różnych momentach, żeby wyeliminować wpływ stałych cech (talent, motywacja, miejsce pracy). Pytanie brzmi: kiedy ta sama osoba zaczyna używać AI więcej, co się zmienia w jej outputcie?

Wyniki pokazują, jak silnie AI rozszedł się po świecie i kto z tego czerpie korzyść.

Liczby, które trzeba mieć w głowie

Adopcja AI w kodzie (koniec 2024, % funkcji w Pythonie z istotną pomocą AI):

USA — 29% (lider, ale przewaga się kurczy)
Niemcy — 24%
Francja — 23%
Indie — 20% (silny skok)
Rosja — 15%
Chiny — 12%

Adopcja w USA według doświadczenia (z analizy fixed-effects):

Mniej doświadczeni (poniżej 6 lat na GitHubie) — AI w 37% kodu
Bardziej doświadczeni (13 lat i więcej) — AI w 27% kodu

Juniorzy używają AI ponad jedną trzecią częściej niż seniorzy. To w sumie nie zaskakuje — narzędzie nowe, młodzi szybciej je biorą, mają mniej oporów.

Wpływ na produktywność (fixed-effects, USA, koniec 2024):

Seniorzy: +3.6% commitów kwartalnie, +2.7% nowych kombinacji bibliotek (eksploracja nowych domen technicznych)
Juniorzy: zero statystycznie istotnych korzyści — ani w commitach, ani w eksploracji

W skali amerykańskiej gospodarki te +3,6% przekładają się na 23–38 miliardów dolarów rocznie. Autorzy zaznaczają, że szacunek jest konserwatywny — błąd pomiaru zaniża prawdziwy efekt, więc rzeczywista wartość jest pewnie większa.

I jeszcze jedna liczba, która mi siedzi w głowie: w USA nie ma różnicy płci w adopcji AI. Kobiety i mężczyźni używają tych narzędzi równie często. To jeden z rzadkich pozytywnych sygnałów w tej analizie — bariera „ja się nie nadaję do AI” jest u juniorów obu płci tak samo (nie)istotna.

Dlaczego seniorzy zyskują, a juniorzy nie — uczciwa odpowiedź autorów

Tu muszę być uczciwy: autorzy nie podają jednoznacznego mechanizmu. Wprost piszą, że wymaga to dalszych badań. Sugerują tylko, że doświadczeni programiści lepiej wykorzystują AI do „wchodzenia w nowe domeny”, korzystając z nieznanych im wcześniej „klocków technicznych” — co zakłada, że bez bazy w starych domenach trudno te nowe ocenić.

Cytat Franka Neffke (jednego z autorów, w komunikacie Complexity Science Hub): „Generatywna AI nie wyrównuje automatycznie szans. Może pogłębiać istniejące przepaście.”

Cytat Simone Daniottiego (pierwszego autora): „Beginners hardly benefit at all” — początkujący prawie w ogóle nie korzystają.

To wszystko, co autorzy mówią wprost. Reszta to interpretacja — ich, moja, Twoja.

Dlaczego seniorzy zyskują, a juniorzy nie — moja interpretacja

Wzorzec, który widzę przy codziennej pracy z Claude Code, składa się z trzech elementów. Traktuję to jako hipotezę spójną z danymi z Science, nie jako twardą tezę.

Po pierwsze — AI generuje kod, ale ktoś musi ocenić, czy został poprawnie wygenerowany. Senior wie, kiedy „wygląda OK” znaczy „działa OK”, a kiedy znaczy „za trzy miesiące w produkcji wybuchnie”. Wie, czego NIE robić. Wie, kiedy AI bredzi z pewną siebie miną — bo widział już dziesiątki podobnych bredni od ludzi, dokumentacji i bibliotek, które obiecywały więcej niż dawały. Junior tej intuicji jeszcze nie ma. AI mu jej nie zbuduje, bo AI tej intuicji w sobie nie ma — generuje to, co jest statystycznie prawdopodobne, nie to, co jest słuszne w kontekście konkretnego systemu.

Po drugie — AI pomaga najbardziej w eksploracji. Wchodzeniu w nowe biblioteki, nowe domeny, nieznane API. Senior ma kotwice — zna inne biblioteki, podobne wzorce, klasyczne pułapki. Z tych kotwic odczytuje, czy nowe rozwiązanie ma sens. Junior nie ma kotwic. AI mu pokazuje „jak się to robi” — ale nie pokazuje, „kiedy się tego nie robi” i „dlaczego u nas akurat się tego nie robi”.

Po trzecie — AI to mnożnik, a mnożnik razy zero to nadal zero. Senior ma już produktywność, którą można pomnożyć. Junior najpierw musi zbudować to coś, co da się pomnożyć — kod, którego się nie wstydzi, system, który rozumie, decyzje, których broni. AI tego nie zbuduje za Ciebie, bo to są właśnie te uncodified, tacit skills, o których wspomina edytorka Science w streszczeniu redakcyjnym: tych umiejętności nie ma w treningowym datasecie i nie wpadnie żaden prompt, który je załatwi.

Innymi słowy: nie chodzi o to, że juniorzy są gorsi. Chodzi o to, że są na innym etapie. AI nie skraca etapu, na którym jesteś. Może najwyżej pomóc Ci szybciej się w tym utwierdzić, jeśli weźmiesz je jako wymówkę, żeby nie myśleć samodzielnie.

Inne spojrzenie z konferencji — a może to juniorzy są tu w lepszej pozycji?

Niedawno usłyszałem na konferencji tezę, która brzmi dokładnie odwrotnie do wniosku z badania: to teraz jest moment dla juniorów, bo szybko adaptują się do nowych narzędzi, a seniorzy są niechętni i sceptyczni wobec AI. Czy ta teza jest błędna? Nie. Ale jest niekompletna. I, co ważniejsze, nie wyklucza tego, co pokazuje Science.

Dane potwierdzają oba zjawiska jednocześnie.

Stack Overflow Developer Survey 2025: doświadczeni programiści mają najniższy wskaźnik „highly trust” wobec AI (2,6%) i najwyższy wskaźnik „highly distrust” (20%). Juniorzy częściej traktują AI jako tutora i partnera do pracy; seniorzy podchodzą do niego bardziej ostrożnie. To w dużej części tłumaczy, dlaczego juniorzy używają AI w 37% kodu, a seniorzy w 27% — to nie tylko młodsze pokolenie, ale też różnica w zaufaniu.

Ale jest druga liczba, która zmienia obraz. Z analizy Fastly z 2025 roku: około jedna trzecia seniorów (10+ lat doświadczenia) mówi, że ponad 50% kodu, który wysyłają do produkcji, jest wygenerowane przez AI. U juniorów (0–2 lat) ten odsetek wynosi 13%. Różnica 2,5× — w drugą stronę niż w pomiarze „ile kodu w ogóle pisałem z AI”.

Czyli pełen obraz wygląda tak:

Juniorzy adoptują częściej, ale eksperymentalnie. Używają AI do nauki, do eksploracji, do generowania szybkich szkiców. Mniej tego trafia do produkcji w pełnej formie.
Seniorzy adoptują rzadziej, ale konkretniej. Gdy już używają, robią to z premedytacją — dokładnie wiedzą, do czego (bo wiedzą, gdzie jest ich własne wąskie gardło) — i przepuszczają output przez własne sito ocen, zanim coś trafi na produkcję.

To są dwie różne strategie adopcji, nie jedna lepsza i jedna gorsza. Tylko ta druga — strategia „rzadziej, ale konkretniej” — daje +3,6% commitów kwartalnie i 23–38 mld dolarów rocznej wartości w skali USA. Pierwsza — strategia „często, eksperymentalnie” — daje statystycznie zero, mierzone tymi samymi metrykami.

Więc konferencyjna teza ma rację co do adopcji. Badanie Science ma rację co do wyniku. To nie są sprzeczne tezy — to są dwa różne pomiary tego samego zjawiska. Junior, który chce zamienić swoją „przewagę adopcji” w realny wynik, musi nauczyć się tego, co senior umie z definicji: kiedy AI bredzi, jak to zauważyć i jak nie wpuścić tej bredni do produkcji.

To jest dokładnie ta umiejętność, której branża zaczyna od juniora wymagać — a wcześniej wymagała głównie od seniorów. O tym za chwilę.

Wymagania od juniora się zmieniły. To nowy zawód w starym opakowaniu.

Jeszcze 3-4 lata temu od juniora wymagało się głównie znajomości składni, frameworka, podstaw architektury i otwartości na naukę. Code review było etapem, na który „się dorastało” w pierwszych 1-2 latach. Decyzje techniczne podejmował tech lead albo senior z danego obszaru. Junior dowoził fragmenty według wytycznych.

Teraz fragmenty dowozi AI. A junior, który chce być wartościowy w zespole, musi od pierwszego dnia robić rzeczy, które wcześniej robił dopiero mid albo senior. Konkretnie:

Code review na kodzie wygenerowanym przez AI. Nie cudzym kodzie napisanym ręcznie, gdzie człowiek miał w głowie jakąś logikę. Kodzie, który wygląda dobrze, ale może nie robić tego, co miał, albo robi to niewłaściwie. To zupełnie inny rodzaj review niż klasyczne „czytam, czy logika trzyma się kupy” — bliżej testowania na białej kartce, „co tu się może zepsuć”.
Krytyczne myślenie wobec generatywnego outputu. Junior musi mieć w głowie dwa głosy naraz: „AI mówi, że to działa” i „ale skąd ja to wiem”. Bez tego drugiego głosu wpada w pułapkę „vibe coding” — Stack Overflow Developer Survey 2025 pokazuje, że 12% deweloperów przyznaje się do akceptowania outputu AI bez pełnego zrozumienia. To dokładnie ta grupa, która statystycznie nie zwiększa produktywności.
Pisanie testów na cudzą implementację. Gdy kod nie jest Twój, jedynym sposobem na zaufanie jest mierzenie. Pisanie sensownych testów to dziś podstawowa kompetencja juniora, nie nice-to-have. Wymaga rozumienia wymagań biznesowych, edge case’ów oraz architektury.
Dokumentowanie dlaczego, a nie co. „Co” robi kod, AI Ci powie z palcem w d****. „Dlaczego” akurat tak — nie. To wiedza w głowach ludzi, która znika z każdym off-boardingiem. Junior, który od pierwszego tygodnia spisuje kontekst decyzji, intencje i ograniczenia — buduje zasób firmy, a nie tylko swoją rolę. Pisałem o tym w kontekście vibe-dokumentacji wcześniej; tam dokładnie ten sam mechanizm jest osobną umiejętnością na wejście do branży.
Świadome promptowanie z kontekstem. Nie „napisz mi funkcję, która liczy XYZ”, tylko „w naszym systemie, który robi A i B, gdzie obowiązują takie konwencje, dla użytkownika typu X, napisz funkcję, która…”. Promptowanie to dziś osobna kompetencja, którą junior buduje od pierwszego tygodnia, nie po dwóch latach.
Komunikacja z biznesem albo z product ownerem. Skoro kod pisze AI, kluczowa wartość przesuwa się w kierunku: „rozumiem, czego biznes naprawdę chce, i umiem to przełożyć na specyfikację dla AI”. To była rola seniora albo tech leada. Dziś junior, który tę umiejętność ma, jest dwa razy bardziej wartościowy niż taki, który „tylko” dobrze koduje.
Ogarnianie wielu agentów na raz. Jeszcze rok temu używanie AI to było „jeden chat z ChatGPT obok IDE”. Dziś to coraz częściej kilka agentów Claude Code, Routine’y w nocy, hooki, skille. Junior, który to ogarnia od początku, ma realną przewagę nad seniorem, który dopiero teraz wchodzi w takie podejście — bo dla niego to jest pierwszy język, nie drugi.

To są umiejętności, których wcześniej od juniora nie wymagano. Część z nich była na liście „fajnie, jakbyś za rok ogarnął”. Teraz są na liście „musisz mieć już przy zatrudnieniu”.

To też jest powód, dla którego rynek juniorski tak mocno się skurczył. Nie dlatego, że juniorzy są mniej potrzebni — tylko dlatego, że „junior” w 2026 znaczy coś innego niż w 2022. Próg wejścia podniósł się o jakieś 2 lata doświadczenia.

Kontekst rynku pracy — to nie dzieje się w próżni

Badanie Science nie jest jedyne. W tym samym kierunku idą też inne dane.

IEEE Spectrum cytuje statystyki, które mówią same za siebie:

Pozycje entry-level w 15 największych firmach technologicznych w USA spadły o 25% z 2023 na 2024.
Zatrudnienie programistów w USA spadło o 27,5% między 2023 a 2025.
Stanowiska „software developer” (bardziej projektowe niż czysto kodujące) — tylko -0,3% w tym samym okresie.

W skrócie: rynek tnie tych, którzy zajmują się głównie pisaniem kodu pod dyktando — bo to właśnie miejsce, w którym AI wchodzi najmocniej. Trzyma tych, którzy projektują, decydują, integrują.

To jest dokładnie ten sam wzorzec co w badaniu Science, tylko widziany z drugiej strony. Pisanie kodu się komodyzuje. Decydowanie, co i jak napisać — nie.

Co z tego wynika dla Ciebie, jeśli jesteś juniorem

Cztery rady, które bym dał komuś, kto dziś zaczyna i czyta te liczby z lekkim ściskiem w żołądku.

Po pierwsze — nie ucz się szybciej promptować, naucz się ostrzej oceniać. Promptowanie to umiejętność z górnej pułki, ale dopiero wtedy, kiedy umiesz ocenić, co dostajesz. Bez tej oceny szybsze promptowanie oznacza szybsze generowanie kodu, którego nie rozumiesz. Ucz się oceniać. Czytaj cudze rozwiązania, debuguj produkcyjne incydenty, próbuj rozumieć, dlaczego ktoś coś zrobił tak, a nie inaczej. Pisz testy do każdej funkcji, której Ci AI naprodukuje — to jest dziś podstawowe narzędzie weryfikacji.

Po drugie — nie idź na skróty w trudnych rzeczach. Jeśli zadanie, które masz dzisiaj, jest trudne — zrób je sam. Nawet jeśli AI by to zrobiło w pięć minut. Trudne zadania to kotwice, do których za dwa lata zaczepisz się swoją intuicją. Bez tych kotwic AI da Ci szybkość, ale bez kontroli. To jest dokładnie ta pozycja, w której badanie pokazuje „zero benefitu”.

Po trzecie — opanuj umiejętności, których wcześniej od juniora nie wymagano. Listę masz wyżej, w sekcji o nowych wymaganiach: code review na kodzie AI, krytyczne myślenie wobec outputu, pisanie testów na cudzą implementację, dokumentowanie tego, dlaczego, świadome promptowanie z kontekstem, komunikacja z biznesem, ogarnianie wielu agentów. To są dziś umiejętności na wejściu, nie na 3-4 rok pracy. Im wcześniej je traktujesz jako swoje, tym mniej brutalna jest dla Ciebie zmiana rynku.

Po czwarte — wybieraj firmy, które świadomie inwestują w juniorów. Tych, gdzie senior siada obok i tłumaczy. Gdzie code review nie jest formalnością, tylko realnym stempelkiem na decyzjach. Firmy, które tną juniorów na argument „AI zrobi”, są dziś tańsze w obsłudze — ale za 3 lata nie będą miały komu przekazać systemu, kiedy senior odejdzie. Ty nie chcesz być juniorem w takiej firmie.

Czego nie radzę: rzucania programowania. Branża nie zniknie. Zmieniają się oczekiwania na wejściu — to prawda — ale ścieżka dalej istnieje. Tylko jest stromsza i wymaga innego nastawienia: „rozumiem, co robię” zamiast „zdążyłem to dowieźć”.

Czy w ogóle warto dziś zaczynać uczyć się programowania?

Dostaję to pytanie regularnie i rozumiem, skąd się bierze. Czytasz nagłówki „AI tnie 27% etatów programistów”, widzisz dane Science o juniorach z zerowym benefitem, słyszysz, że bootcampy nie dają już pracy w pół roku — i naturalnie zastanawiasz się, czy w 2026 ma jeszcze sens stawiać karierę na programowaniu.

Moja odpowiedź: tak, ma sens. Tylko warunki się zmieniły i trzeba je rozumieć przed startem.

Trzy rzeczy, na których oparłbym tę odpowiedź.

Po pierwsze — programowanie jako sposób myślenia nie idzie do lamusa. Idzie do lamusa „zawód kogoś, kto dostaje specyfikację i klepie kod”. To są dwie różne rzeczy. Umiejętność rozłożenia problemu, opisania go formalnie, zaprojektowania rozwiązania i weryfikacji — to kompetencje, które stają się coraz bardziej wartościowe. AI je amplifikuje, nie zastępuje. Osoba, która umie myśleć jak programista, jest dziś poszukiwana także w marketingu, operacjach, sprzedaży, nie tylko w działach IT. To jest większy rynek niż 5 lat temu, nie mniejszy.

Po drugie — obniżyła się bariera wejścia do robienia rzeczy, ale podniosła się bariera wejścia do pierwszej pracy. To paradoks, którego wiele osób nie dostrzega. Z AI w 3 miesiące zbudujesz funkcjonalną aplikację, którą rok temu pisałbyś rok. Ale na pierwszą pracę juniora, gdzie ktoś Cię od zera nauczy — będzie Ci trudniej niż było 3 lata temu. Wniosek: zacznij od tworzenia rzeczy dla siebie albo dla małej firmy, której pomożesz. Buduj portfolio realnych projektów, nie przepisywania tutoriali. Wejście do branży według klasycznej ścieżki „junior w korpo” jest dziś trudniejsze. Wejście w branżę bokiem — przez „ja zbudowałem coś, co działa i ma użytkowników” — jest łatwiejsze niż kiedykolwiek.

Po trzecie — ucz się inaczej niż uczyło się 5 lat temu. Mniej godzin na „naucz się składni Pythona”. Więcej godzin na „naucz się czytać cudzy kod, debugować nieswoje rozwiązania, projektować i testować”. To są umiejętności, które AI Ci uzupełnia, ale nie zastępuje. Klasyczne bootcampy „naucz się Reacta w 12 tygodni i znajdź pracę” — w starej formule mają już problem, bo „umieć Reacta” przestało wystarczać do zatrudnienia. Bootcampy, które dorzucają warstwę pracy z AI, code review, projektowania, debugowania — mają sens. Bez tej warstwy są po prostu nieaktualne.

Co konkretnie bym zrobił, gdybym dziś zaczynał:

Klasyczne fundamenty (algorytmy, struktury danych, podstawy systemów) — bez AI, na sucho. To są te kotwice, o których pisałem wyżej.
Jeden mały projekt zbudowany całkowicie samodzielnie, bez AI — żeby wiedzieć, jak to jest, gdy wszystko zależy ode mnie.
Drugi projekt zbudowany z AI — z premedytacją, świadomie, z code review na każdym etapie. Żeby zobaczyć, co AI dodaje, a co odbiera.
Wybór jednego obszaru, który mnie pasjonuje (web, dane, ML, embedded, gry) — i wejście w niego głębiej, niż wymaga stanowisko typu „junior do dowolnej pracy”. Specjalizacja to dziś przewaga konkurencyjna.
Codzienne code review cudzych pull requestów na GitHubie — w open source. To jest szkoła oceniania kodu, której nie zastąpi żaden tutorial.

Krótko: programowania uczyć się warto. Tak jak uczyło się go w 2020 roku — już nie warto.

Co z tego wynika dla Ciebie, jeśli jesteś seniorem bez AI

Krótko — to jest Twój moment. Dane są twarde, narzędzia dojrzałe, mnożnik czeka, a Ty masz dokładnie to, co badanie pokazuje jako warunek wejścia: doświadczenie, do którego AI ma się czepić. Każdy kwartał zwlekania to przewaga, którą oddajesz komuś z Twojego pokoju, kto już używa AI codziennie.

Jedna konkretna rzecz, od której zacząłbym: wybierz jeden projekt, w którym dziś najbardziej tracisz czas na „rzeczy mechaniczne” — boilerplate, refaktory, testy, dokumentację, integracje z nieznaną biblioteką. Włóż w to AI na tydzień, nie na godzinę. Zobacz, co Ci wychodzi i co Ci nie wychodzi. To nie jest decyzja „wszystko albo nic” — to jest decyzja „spróbuję jeden konkretny case z premedytacją”.

I jeszcze jedno — Twoje doświadczenie się nie dewaluuje. Wręcz przeciwnie. Badanie pokazuje, że wartość seniora rośnie, bo do niej dołącza wartość AI, którą umiesz okiełznać. Luka, którą widać na rynku w warstwie juniorskiej, jest w warstwie seniorskiej brakiem podaży, nie nadwyżką.

Co z tego wynika dla Ciebie, jeśli zarządzasz zespołem

Najtrudniejsza część tego wpisu. Bo to są decyzje, które zwracają się dopiero za 3 lata.

Pokusa jest oczywista: AI tnie koszty, juniorzy są wolni i drodzy w nauce, więc zatrudnijmy mniej młodych, podniesiemy próg wejścia, niech seniorzy z AI dowiozą resztę. W krótkim terminie matematyka się zgadza. W dłuższym — nie.

Trzy konkretne ryzyka, które bym sobie wypisał na ścianie:

Pipeline talentu wysycha. Seniorzy nie biorą się z chmury. Każdy senior, którego dziś masz, kiedyś był juniorem, którego ktoś wziął i nauczył. Jeśli w branży wszyscy zamienią młodych „na AI”, za 5 lat seniorów będzie tyle, ilu jest dziś — minus ci, którzy odeszli. Plus zero. To jest matematyka, której nikt nie obejdzie.
Twój zespół seniorów się zestarzeje, a Ty tego nie zauważysz. Bo dzień po dniu wszystko będzie działać, AI będzie dowoził, projekty będą szły. A potem przyjdzie dzień, w którym kluczowy człowiek odchodzi do konkurencji albo na emeryturę i nie ma komu tego przekazać. To jest dokładnie ten sam wzorzec, który ostatnie 15 lat dotykał firm utrzymujących systemy w COBOL-u i SAP-ie. Tylko teraz cykl jest szybszy.
Konkurencja, która zatrudnia juniorów teraz, za 3–5 lat będzie miała midów i seniorów wyhodowanych na AI od pierwszego dnia. Ci ludzie nie tylko będą umieli kodować — będą umieli kodować z AI w sposób, którego Twoi seniorzy uczą się dziś metodą prób i błędów. To jest przewaga kulturowa, której nie nadrobisz w pół roku.

Co bym zrobił na Twoim miejscu? Nie tnij juniorów na siłę. Zmień, jak ich onboardujesz. Dopisz do programu naukę pracy z AI od pierwszego tygodnia — ale w tej samej objętości co dotychczasowe podstawy: czytanie cudzego kodu, code review, debugowanie. Wymagaj tłumaczenia, dlaczego AI coś zaproponowała — nie tylko „działa, mergeuję”. To pierwsza wersja procesu, w której junior nie marnuje AI, a AI nie marnuje juniora.

Co z tego wynika dla edukacji i kursów (krótka uwaga)

Po pierwsze — bootcampy w starym formacie („przyjdź na 3 miesiące, naucz się Reacta, dostaniesz pracę”) tracą rację bytu. Nie dlatego, że Reacta nie warto się uczyć, tylko dlatego, że „naucz się składni” już nie wystarczy do zatrudnienia. Muszą dorzucać warstwę oceny, decyzji, pracy z AI, wchodzenia w czyjeś projekty. To jest inna szkoła i inny kurs.

Po drugie — kursy „jak promptować lepiej” mają sens tylko dla osób, które już umieją oceniać output. Dla juniora, który nie umie ocenić, lepszy prompt oznacza większą skuteczność w tworzeniu nieprzemyślanego kodu. To jest inna mapa niż „jak wejść do branży”.

Sam buduję teraz kurs Claude Code dla nietechnicznych — i to jest dla mnie podpowiedź, że warstwa „ocena tego, co AI wypluło” musi być w nim grubsza niż warstwa „jak ładnie poprosić”.

Ograniczenia tego badania (bo zawsze jakieś są)

Żebym był uczciwy do końca — Science jest szanowanym pismem i wierzę w ich recenzje i publikacje, ale to badanie, jak każde, w którym ktoś postawił jakąś konkretną tezę i metodologię, ma swoje ograniczenia. Trzy najważniejsze.

Tylko Python na GitHubie, tylko open source. Kod komercyjny w prywatnych repozytoriach może wyglądać inaczej. Inne języki też. Wzorzec może być silniejszy lub słabszy w innych ekosystemach.
Mierzą wolumen commitów, nie jakość kodu. „Wzrost produktywności o 3,6%” to wzrost outputu, nie wartości biznesowej. Może być tak, że juniorzy też produkują więcej kodu z AI — tylko ten kod jest częściej cofany albo psuje produkcję. Tego badanie nie mierzy.
Brak danych o spillover effects — czyli o tym, jak AI używane przez seniora wpływa na juniora w tym samym zespole (np. przez code review, mentoring, kopiowanie wzorców). Może się zdarzyć, że junior, który pracuje obok seniora z AI, korzysta na tym bardziej niż junior, który używa AI sam. Tego nie wiemy.

Autorzy zaznaczają też, że błąd pomiaru biasuje wyniki w dół — czyli prawdziwy efekt produktywności jest pewnie większy niż 3,6%. To jednak dotyczy seniorów. Dla juniorów „zero” pozostaje zero, niezależnie od metodologii — bo to jest zero, a nie liczba zaniżona o pewną wartość.

Ogólny kierunek wyniku — seniorzy zyskują, juniorzy nie — jest spójny z innymi badaniami z poprzedniego roku (m.in. analizami MIT, Stanford AI Index oraz danymi Revelio Labs cytowanymi w mediach). Konkretne procenty mogą się jeszcze przesunąć w kolejnych badaniach. Wzorzec — moim zdaniem — nie.

Jedna rzecz do zapamiętania

Jeśli miałbyś wyjść z tego wpisu z jednym pomysłem — niech to będzie ten:

AI to mnożnik. Nie zastępstwo dla doświadczenia, nie skrót do seniorstwa, nie sposób na „dowiezienie projektu bez znajomości tematu”. Tylko mnożnik tego, co już potrafisz ocenić.

Dla seniora — to brzmi jak superpower. Dla juniora — jak zadanie domowe. Dla zarządzającego — jak decyzja, której nie chce Ci się dziś podejmować, bo zwróci się za 3 lata.

Wszystkie trzy są prawdziwe.

A Ty?

Interesuje mnie Twoja perspektywa, szczególnie jeśli jesteś dziś:

juniorem, który próbuje się odnaleźć w branży zmieniającej zasady wejścia w trakcie gry,
osobą rozważającą, czy w ogóle warto teraz zaczynać programowanie — i którą te liczby zatrzymały,
seniorem, który dopiero rozważa, jak na poważnie wpuścić AI do swojej pracy,
albo osobą, która podejmuje decyzje o zatrudnianiu i widzi te liczby pierwszy raz.

W komentarzach pod tym wpisem albo pod postem na LinkedIn — chętnie odpowiem. Jeśli temat jest dla Ciebie pilny i wolisz porozmawiać 1:1 zamiast publicznie, oferuję konsultacje — link na stronie.