Co naprawdę się zmieniło w ciągu ostatnich kilku lat
Jeszcze niedawno rynek IT żył narracją „braku rąk do pracy”. Firmy prześcigały się w ofertach dla programistów, a na konferencjach powtarzano, że „programista to zawód przyszłości”. Juniorzy wchodzili do branży względnie łatwo, a głównymi barierami były motywacja i czas poświęcony na naukę. Sztuczna inteligencja funkcjonowała raczej jako ciekawostka – kilka modeli do rozpoznawania obrazów, rekomendacje produktów, chat‑boty.
Po pojawieniu się generatywnej AI (ChatGPT, GitHub Copilot i dziesiątki podobnych narzędzi) rynek gwałtownie zmienił ton. Zamiast „braku rąk” pojawiły się nagłówki typu „AI zabierze pracę programistom”. W praktyce nie zaszła jedna wielka eksplozja, tylko seria mniejszych przesunięć w różnych obszarach – od sposobu pisania kodu, przez testowanie, po analizę wymagań. To wrażenie rewolucji jest mocno podkręcone marketingowo, ale realne skutki widać w codziennej pracy zespołów.
Najbardziej wymierna zmiana dotyczy automatyzacji prostych, powtarzalnych zadań. Tam, gdzie kiedyś programista spędzał kilka godzin na pisaniu boilerplate’u lub ręcznym przepisywaniu schematów, teraz wygeneruje większość kodu w kilka minut. Zyskuje przepustowość, ale traci iluzję, że samo „klepanie” kodu jest wysoką wartością. Model pracy coraz bardziej przesuwa się z „pisania” na projektowanie, recenzowanie i łączenie elementów.
Zmieniły się też wymagania wobec osób z doświadczeniem. Firmy coraz częściej oczekują, że mid lub senior nie tylko zna framework, ale też umie pracować z AI: tworzyć dobre prompty, krytycznie oceniać wyniki, wplatać narzędzia AI w proces wytwórczy i dbać o jakość tworzonego oprogramowania mimo przyspieszonego tempa. To już nie jest drobny „bonus do CV”, ale normalny element warsztatu.
Gdzie w IT AI uderza najmocniej, a gdzie prawie nie sięga
Generatywna sztuczna inteligencja najbardziej zmieniła te obszary, gdzie dużo się pisze – kodu, testów, dokumentacji, prostych skryptów. Narzędzia AI są idealne tam, gdzie zadania są powtarzalne, oparte na wzorcach i dobrze opisane w istniejących repozytoriach kodu i treści. To dlatego tak mocno odczuły ją:
zespoły frontendowe tworzące klasyczne panele administracyjne i formularze,
developerzy od prostych API i integracji typu CRUD,
osoby piszące dokumentację techniczną, manuale, skrypty migracyjne.
AI dużo słabiej radzi sobie tam, gdzie kluczowe jest głębokie zrozumienie domeny biznesowej lub działania systemu w niestandardowych warunkach. Systemy embedded, krytyczne systemy czasu rzeczywistego, oprogramowanie medyczne czy infrastruktura bezpieczeństwa to obszary, gdzie błąd ma bardzo wysoką cenę, a zachowanie systemu bywa słabo reprezentowane w publicznych danych. Modele językowe nie „rozumieją” w klasycznym sensie konsekwencji swoich propozycji, więc nadal potrzebny jest inżynier, który myśli modelami i ograniczeniami, a nie tylko składnią.
W tej samej grupie znajdują się zadania architektoniczne – projektowanie systemów rozproszonych, integracje między wieloma domenami, decyzje dotyczące skalowania, bezpieczeństwa czy kosztów chmurowych. AI potrafi podsunąć szkic diagramu, przykładową strukturę mikroserwisów czy pomysł na podział kontekstów, ale ciężar odpowiedzialności i tak spada na ludzi. Właśnie tu rośnie znaczenie ról, które łączą technologię z biznesem – architektów, tech leadów, inżynierów platform.
Juniorzy, midzi i seniorzy – kto odczuwa zmiany najmocniej
Najwięcej niepokoju panuje wśród osób na poziomie junior. Mit mówi: „AI jest lepsza od juniora, więc juniorzy są zbędni”. Rzeczywistość jest bardziej złożona. AI naprawdę potrafi wygenerować kod na poziomie porządnego juniora w prostych zadaniach. Nie potrafi natomiast przejąć odpowiedzialności, nauczyć się domeny firmy, prowadzić rozmów z biznesem, brać udziału w podejmowaniu decyzji. Problem polega na czym innym: wiele firm odkryło, że zespół midów i seniorów + AI może zrealizować część pracy, którą wcześniej delegowano do juniorów.
W efekcie rośnie rola midów i seniorów, ale zakres ich obowiązków przesuwa się z „samodzielnie napiszę wszystko” w stronę „zaprojektuję rozwiązanie, użyję AI do wygenerowania 60–70% kodu, a potem go poprawię, przetestuję i wkomponuję w całość”. Do tego dochodzi odpowiedzialność za jakość użycia AI – kontrola nad bezpieczeństwem danych, weryfikacja licencji, pilnowanie, by zespół nie popadł w bezrefleksyjne akceptowanie propozycji modelu.
Przesunięcie zachodzi także na poziomie ról hybrydowych. Rynek chętnie chłonie osoby, które łączą kompetencje techniczne i biznesowe: developerów rozumiejących produkt, analityków potrafiących prototypować z AI, PM‑ów, którzy umieją realnie ocenić, gdzie warto użyć automatyzacji, a gdzie pozostawić pracę ludziom. To te role będą najtrudniejsze do zautomatyzowania, bo obejmują nie tylko wiedzę narzędziową, ale też ocenę ryzyka, komunikację i odpowiedzialność.
Źródło: Pexels | Autor: Magda Ehlers
Popularne mity o AI i pracy w IT
„AI zabierze pracę wszystkim programistom”
Ten mit świetnie sprzedaje kliknięcia. Wystarczy dramatyczny nagłówek, parę slajdów z demo i już w głowach programistów rodzi się obraz przyszłości, w której jeden product owner rozmawia z AI, a resztę zespołu zwolniono. Tymczasem automatyzowane są głównie fragmenty zadań, a nie całe role. To duża różnica.
AI znakomicie radzi sobie z generowaniem boilerplate’u – komponentów, prostych endpointów, standardowych testów jednostkowych, konfiguracji pod znane stacki. Gorzej idzie jej rozwiązywanie problemów, których nikt wcześniej nie opisał publicznie lub które łączą wiele poziomów systemu. Prosty przykład: wygenerowanie modelu danych i CRUD‑owego API to zadanie idealne dla AI, ale zaplanowanie architektury systemu rozliczeń finansowych z uwzględnieniem audytów, wydajności, przepisów i wielu kanałów wejścia to zupełnie inna liga.
Rzecz, która naprawdę ulega zmianie, to popyt na określony poziom kompetencji. Junior, który umie tylko przepisywać tutoriale, ma dużo trudniej niż pięć lat temu, bo wiele z tych zadań jest już tańsze z użyciem AI. Jednocześnie rośnie zapotrzebowanie na osoby, które potrafią wykorzystać AI jako dźwignię – szybciej się uczą, szybciej dowożą wartość, potrafią utrzymać i rozwinąć systemy, które AI tylko „podszturchuje” kodem.
„AI jest tylko kolejnym narzędziem, więc nic się nie zmienia”
Drugi skrajny mit pojawia się często u doświadczonych inżynierów: „mamy już lintery, IDE, frameworki – AI to tylko kolejny gadżet, za rok wszyscy o nim zapomną”. Ten obraz też jest fałszywy. AI to narzędzie, ale takie, które drastycznie zwiększa przepustowość pracy. To tak, jakby zamiast śrubokręta dostać wkrętarkę z magazynkiem – niby nadal wkręcasz śrubki, ale tempo i sposób organizacji pracy już nie są te same.
AI zmienia:
tempo dostarczania – feature powstaje szybciej, więc rośnie presja na planowanie, testowanie i jakość; błędy także pojawiają się szybciej, jeśli proces jest słaby;
strukturę pracy – więcej czasu idzie na projektowanie, code review, ustalanie wymagań, mniej na ręczne klepanie powtarzalnego kodu;
wymagane kompetencje – pojawia się potrzeba projektowania promptów, oceny wyników i świadomego korzystania z modeli.
Mit, że „nic się nie zmienia”, bywa dla doświadczonych programistów groźniejszy niż strach juniorów. Bo osoby, które go kupują, często ignorują konieczność dostosowania swojego warsztatu. Po dwóch‑trzech latach okazuje się, że ich styl pracy jest reliktem: nie korzystają z automatyzacji, przez co są wolniejsi, a jednocześnie nie rozwijają umiejętności projektowych, które AI trudno zastąpić.
Między strachem a lekceważeniem – gdzie jest rozsądny środek
Media lubią czarno‑białe narracje. Codzienność zespołów IT jest dużo bardziej szara. Sprint z AI nie wygląda jak magiczny spektakl, w którym model sam pisze apki. Przypomina raczej prace warsztatowe: ktoś formułuje problem, AI generuje propozycję, zespół ją poprawia, testuje, usuwa błędy, dyskutuje architekturę. Czasem AI przyspiesza pracę dwukrotnie, a czasem tylko marnuje godzinę, bo model „zmyśla” i wprowadza w błąd.
Rozsądne podejście to uznanie, że AI jest realną dźwignią, ale z ograniczeniami. Osoba, która nauczy się efektywnie współpracować z narzędziami AI, zyska przewagę na rynku, bo będzie robić więcej i lepiej w tym samym czasie. Jednocześnie nikt rozsądny nie odda AI pełnej kontroli nad krytycznymi decyzjami w systemie bez nadzoru człowieka. Mit „AI zabierze wszystkim pracę” i mit „AI nic nie zmienia” są dwoma twarzami tego samego uproszczenia.
Jak AI zmienia codzienną pracę w różnych rolach IT
Programista / inżynier oprogramowania
Dla programisty generatywna AI jest jak super‑IDE z asystentem. Potrafi:
podpowiedzieć fragmenty kodu na podstawie kontekstu pliku,
przepisać funkcję do innego języka lub frameworka,
zapropnować testy jednostkowe dla istniejących metod,
przeprowadzić wstępną refaktoryzację z wyjaśnieniem kroku po kroku.
Zyskiem jest tempo – proste rzeczy pisze się dużo szybciej. Programista może skupić się na trudniejszych elementach: integracjach, projektowaniu struktur, optymalizacji wydajności. Zagrożeniem jest pokusa „ślepego klepania” tego, co podpowie model. Wtedy z inżyniera łatwo stać się operatorem narzędzia, który nawet nie orientuje się, jakie długi technologiczne właśnie wstrzyknął do bazy kodu.
Między mitem a rzeczywistością jest prosta zasada: AI nie zwalnia z myślenia. Jeżeli ktoś nie rozumie algorytmów, struktur danych i podstaw architektury, to AI pozwoli mu napisać coś szybciej, ale niekoniecznie lepiej. Jeżeli natomiast fundamenty są solidne, model staje się partnerem – podsuwa warianty, które inżynier potrafi ocenić i ulepszyć.
Tester / QA, DevOps, analityk, manager produktu
Testerzy, szczególnie ci zajmujący się automatyzacją, dostali do ręki potężne wsparcie. AI jest w stanie na podstawie scenariusza użytkownika zaproponować:
zestaw przypadków testowych, również edge case’ów,
szablony testów E2E w popularnych frameworkach,
generowanie danych testowych zgodnych z określonym wzorcem,
wstępną analizę logów w poszukiwaniu anomalii.
Rola QA przesuwa się z „ręcznego klikania” w stronę projektowania jakości: definiowania strategii testów, dobierania metryk, zarządzania ryzykiem. Model może wygenerować 100 scenariuszy testowych, ale ktoś musi ocenić, które są istotne biznesowo, a które tylko obciążą pipeline.
Dla DevOps i SRE AI jest przyspieszaczem w pisaniu skryptów, manifestów Kubernetes, konfiguracji CI/CD czy zapytań do systemów monitoringu. Potrafi zaproponować poprawki do plików YAML, dopasować konfigurację Nginx czy zasugerować reguły alertów. Jednocześnie nie ma pełnego obrazu infrastruktury: nie wie, jaki jest ruch w szczycie, jak zachowuje się aplikacja w awarii sieci, jak wygląda polityka bezpieczeństwa organizacji. Dlatego inżynierowie odpowiedzialni za infrastrukturę nadal muszą myśleć architektonicznie, traktując AI jako narzędzie do automatyzacji, a nie źródło decyzji.
Analitycy biznesowi i managerowie produktu zyskali możliwość szybkiego prototypowania koncepcji. AI pomaga w:
tworzeniu szkiców user stories i acceptance criteria,
symulowaniu dialogu z użytkownikiem na bazie istniejących danych,
przekształcaniu zebranych wymagań w bardziej techniczny język.
Tu pojawia się kolejny mit: że product owner „nie musi rozumieć technologii”, bo przecież „od tego jest zespół i AI”. W praktyce im lepiej rozumiesz ograniczenia architektoniczne, zależności między modułami czy koszty utrzymania, tym trafniej priorytetyzujesz backlog. Model może ułożyć przekonujący opis funkcji, ale nie zna pełnego kontekstu biznesowego, relacji w organizacji ani tego, jak decyzja produktowa zgra się z planami innych zespołów.
Przewagę zyskują osoby, które łączą strategiczne myślenie produktowe z umiejętnością zadawania precyzyjnych pytań AI. Zamiast pytać „wygeneruj pomysły na funkcje”, zawężają kontekst: segment użytkownika, kanał, ograniczenia prawne, docelową metrykę. Dostają mniej „fajerwerków”, za to więcej materiału, który faktycznie można wrzucić do roadmapy. Różnica jest podobna jak między burzą mózgów bez celu a warsztatem z dobrze postawionym problemem.
Zmienia się też styl komunikacji w zespołach. Skoro część „przekładu” między światem biznesu a kodem wykonują modele, rośnie znaczenie doprecyzowania założeń na starcie: definicji gotowości, kryteriów sukcesu, ryzyk. Tam, gdzie dawniej wystarczał ogólny opis feature’a, dziś przyspieszenie generowane przez AI wymusza większą dyscyplinę – bo błędna interpretacja rozmnaża się równie szybko jak poprawne rozwiązania.
Rynek IT przesuwa się więc od prostego „klepania zadań” w stronę pracy, w której liczy się kombinacja: rozumienie domeny, umiejętności techniczne i świadome korzystanie z AI. Kto nauczy się tej mieszanki, nie będzie się zastanawiał, czy model go zastąpi – raczej będzie wybierał, które fragmenty swojej pracy opłaca się delegować maszynie, a gdzie ludzka decyzja jest zbyt cenna, by ją oddać.
Źródło: Pexels | Autor: Pavel Danilyuk
Jakich umiejętności technicznych rynek będzie potrzebował bardziej, a jakich mniej
Na pierwszy rzut oka wygląda to prosto: „skoro AI pisze kod, programiści są mniej potrzebni”. Rzeczywistość jest subtelniejsza. Zmienia się przede wszystkim profil popytu – nie tyle liczba ludzi, ile miks kompetencji, za które firmy są skłonne płacić.
Kompetencje, których znaczenie rośnie
Najsilniej zyskują umiejętności, które trudno w pełni zautomatyzować, bo mocno zależą od kontekstu, decyzji i odpowiedzialności. W praktyce to kilka grup.
Jeżeli ktoś szuka pogłębionych analiz trendów dotyczących automatyzacji, chmury czy roli modeli językowych w pracy zespołów, dobrze jest sięgać po źródła, które nie tylko powielają nagłówki, ale pokazują praktykę – np. portale takie jak Harmony.edu.pl, gdzie można przeczytać więcej o AI w kontekście realnych zastosowań.
Architektura systemów i projektowanie rozwiązań
Modele świetnie radzą sobie z kodem na poziomie funkcji, gorzej – z całym systemem. Dlatego rośnie waga ludzi, którzy potrafią:
zaprojektować spójne API i podział na serwisy w sposób, który przetrwa rozwój produktu,
wybrać sensowną kombinację usług chmurowych pod konkretny przypadek użycia,
zaplanować obserwowalność, bezpieczeństwo i skalowanie od początku, a nie po serii awarii,
uwzględnić ograniczenia prawne i compliance w architekturze (RODO, dane zdrowotne, dane finansowe).
Mit: „architekt to ktoś, kto rysuje diagramy i nie dotyka kodu”. Rzeczywistość: w dobie AI architekt, który nie rozumie ograniczeń modeli i narzędzi, projektuje systemy nierealne lub nieopłacalne. Profil „hands‑on architect”, łączący projektowanie z kodowaniem i pracą z AI, staje się standardem, a nie fanaberią.
Inżynieria danych i MLOps / LLMOps
Skoro AI staje się elementem prawie każdej większej aplikacji, rośnie znaczenie ludzi odpowiedzialnych za dane i cykl życia modeli. Firmy szukają specjalistów, którzy:
projektują i utrzymują pipeline’y danych (ETL/ELT, strumienie, hurtownie i jeziorka danych),
rozumieją, skąd biorą się uprzedzenia w danych i jak je minimalizować,
potrafią wdrażać modele (klasyczne ML i LLM) do produkcji, monitorować je i aktualizować,
łączą modele z istniejącą infrastrukturą (feature stores, wektorowe bazy danych, cache, API).
Wersja „hype”: każdy musi zostać data scientist. Rzeczywistość: rusza lawina ról dookoła danych – od inżynierii danych, przez MLOps, po profile łączące analitykę biznesową z rozumieniem modeli. Niekoniecznie wszyscy trenują swoje sieci neuronowe, ale coraz więcej osób musi umieć pracować na danych jak na normalnym surowcu projektu.
Bezpieczeństwo, prawo i governance wokół AI
Automatyzacja zwiększa powierzchnię ataku. Pojawiają się wektory typu:
prompt injection (atak na aplikacje oparte o LLM),
wyciek danych wprowadzanych do zewnętrznych modeli,
nadużycia generatywnej AI do phishingu i socjotechniki,
zderzenie się systemów AI z nowymi regulacjami (np. EU AI Act).
Coraz większy popyt dotyczy ludzi, którzy łączą security engineering z rozumieniem mechaniki modeli i regulacji. W niejednym zespole bardziej niż kolejny „full‑stack od wszystkiego” brakuje osoby, która powie: „tej klasy danych nie wolno wypchnąć do tej chmury, bo naruszymy umowę z klientem”.
Integracje i osadzanie AI w produktach
Coraz więcej rozwiązań AI jest dostępnych jako usługa (API, SDK). To przesuwa zapotrzebowanie w stronę umiejętności:
budowania aplikacji typu „AI‑first” (chatboty domenowe, asystenci procesów, analityka tekstu),
łączenia różnych usług – LLM, wyszukiwanie wektorowe, klasyczne API biznesowe,
projektowania interakcji człowiek–AI (UX konwersacyjny, feedback loop, eskalacja do człowieka),
projektowania monitoringu jakości odpowiedzi i kosztów (tokeny, czasy odpowiedzi, błędy).
Tu pęka kolejny mit: że „AI w produkcie” to tylko wklejenie jednego endpointu do kodu. Zrobienie tego dobrze wymaga zarówno inżynierii, jak i myślenia o doświadczeniu użytkownika oraz ryzykach.
Kompetencje, które będą się automatyzować
Niektóre zadania nie znikną całkowicie, ale ich czasowy udział w pracy człowieka będzie spadał. Bardziej opłaci się zautomatyzować je narzędziami AI niż zatrudniać kolejne osoby tylko do nich.
Powtarzalne kodowanie i „klepanie CRUD‑ów”
Generatory kodu, szablony i LLM radzą sobie coraz lepiej z:
tworzeniem prostych endpointów CRUD na bazie opisu modelu danych,
generowaniem podstawowych testów jednostkowych i integracyjnych,
przerabianiem kodu między podobnymi frameworkami.
Tu zderzają się dwa światy. Z jednej strony juniorzy liczyli, że nauczą się jednego frameworka, po czym przez kilka lat będą „klepać kontrolery” i na tym się utrzymają. Z drugiej – firmy odkrywają, że większość tego powtarzalnego kodu da się wygenerować i zweryfikować znacznie taniej.
Nie oznacza to, że junior nie ma przyszłości. Oznacza, że start kariery przesuwa się w stronę ról, gdzie od początku trzeba rozumieć kontekst – domenę biznesową, architekturę, zależności między systemami – a nie tylko znać składnię i dokumentację frameworka.
Ręczne testowanie bez specjalizacji
Ręczne „przeklikiwanie” aplikacji webowych i mobilnych już dziś jest wypierane przez automatyzację. AI dodatkowo przyspiesza:
generowanie skryptów testów E2E z poziomu opisu scenariusza,
tworzenie danych testowych i mocków usług zewnętrznych,
wstępną analizę wyników testów i logów.
Rola testera, który wyłącznie klika po formularzach, będzie coraz rzadsza. Na znaczeniu zyskuje QA engineer – osoba, która projektuje strategię testów, automatyzuje je, integruje z CI/CD, a do tego rozumie ryzyka domenowe (np. finansowe, medyczne).
Manualne operacje na infrastrukturze
DevOps i SRE już od lat idą w stronę „infrastructure as code”. Dodanie AI do puli narzędzi tylko przyspiesza ten trend. Coraz mniej będzie miejsca na profile, które:
ręcznie konfigurują serwery na SSH bez repozytorium konfiguracji,
utrzymują skomplikowane systemy bez automatycznego monitoringu i alertingu,
powtarzalne zadania wykonują z terminala zamiast pisać skrypty lub playbooki.
Mit „sysadmina, który wszystko ma w głowie” staje się anachronizmem. Systemy są zbyt złożone, a tempo zmian zbyt duże. W praktyce inżynier infrastruktury musi dziś myśleć jak programista: automatyzować, wersjonować, testować. AI może napisać pierwszy draft playbooka Ansible, ale ktoś musi go osadzić w procesie i utrzymać.
Proste transformacje danych i raportowanie
Generatywna AI świetnie radzi sobie z:
przekształcaniem CSV / Excela w raporty i wizualizacje,
pisaniem zapytań SQL na podstawie opisu w języku naturalnym,
agregacją i tłumaczeniem wyników analiz na różne języki i formy.
To nie zabija analityków danych, ale zmienia ich profil. Miejsca ubywa dla ról, które ograniczają się do hurtowego „kopiuj–wklej” i budowania prostych dashboardów. Zyskują osoby, które interpretują wyniki, rozumieją ich wpływ na decyzje i potrafią zaprojektować eksperyment lub metrykę biznesową.
Nowy „stack kompetencji”: co warto rozwijać już teraz
Żeby sensownie zaplanować rozwój, wygodnie jest myśleć o kompetencjach jak o stacku: od fundamentów, przez narzędzia, po warstwę decyzyjną. AI dorzuca do tego jeszcze wymiar „współpracy z modelem”.
Poziom 1: solidne fundamenty techniczne
Paradoksalnie im silniejsze narzędzia, tym bardziej liczą się podstawy. AI jest jak kalkulator – przyspiesza liczenie, ale nie nauczy matematyki od zera, jeśli ktoś nie zna tabliczki mnożenia.
Na tym poziomie liczą się szczególnie:
Algorytmy i struktury danych – nie w wersji olimpijskiej, ale wystarczająco, by rozumieć, co generuje AI (złożoność, pamięć, typowe pułapki),
Podstawy architektury – wzorce projektowe, podział odpowiedzialności, warstwy, mikro‑ vs monolity,
Sieci / HTTP / API – bez tego trudno rozsądnie oceniać integracje z usługami AI czy chmurą,
Bazy danych – relacyjne, dokumentowe, a coraz częściej też wektorowe; rozumienie indeksów, transakcji, modeli danych.
Mit mówi: „z AI nie musisz się uczyć algorytmów, model zrobi to za ciebie”. W praktyce: jeśli nie rozumiesz, co AI wygenerowała, nie jesteś inżynierem, tylko operatorem. To także na tym poziomie pojawia się przewaga ludzi, którzy wciąż chętnie czytają dokumentację i RFC, a nie wyłącznie odpowiedzi modelu.
Poziom 2: swoboda w jednym ekosystemie i rozsądna znajomość innych
Rynek nadal lubi specjalistów, ale w wersji, która nie boi się granic własnej działki. Dobrą strategią jest:
wybrać jeden ekosystem jako „dom” (np. Java/Kotlin + Spring, JavaScript/TypeScript + React/Node, Python + ekosystem data/ML),
opanować go na tyle, by z AI tworzyć i diagnozować złożone projekty, a nie tylko „hello world”,
mieć przegląd sąsiednich światów – umieć przeczytać kod w innym języku, zrozumieć wzorce z innego frameworka, wykorzystać AI jako tłumacza między nimi.
AI bardzo ułatwia skakanie między językami i frameworkami. To z jednej strony pokusa „będę znać wszystko po trochu”, z drugiej – szansa na zbudowanie profilu T‑shaped: głęboka specjalizacja, uzupełniona o szeroki, ale płytszy przegląd reszty ekosystemu. Rynek coraz częściej nagradza takie osoby rolami typu tech lead, architect, staff engineer.
Poziom 3: świadoma współpraca z AI (prompting, krytyczne myślenie, ocena wyników)
Niezależnie od roli, praktyczne umiejętności pracy z modelami stają się nową warstwą stacku. Nie chodzi o „magiczne prompty”, tylko o kilka bardzo konkretnych nawyków:
Dawanie pełniejszego kontekstu – zamiast „napisz testy”, lepiej „napisz testy dla tej klasy, korzystając z JUnit 5, uwzględnij przypadki brzegowe X i Y, generuj tylko kod bez komentarzy”.
Iterowanie i zawężanie – pierwsza odpowiedź to szkic, nie wyrocznia. Dobre praktyki to: prośba o alternatywy, porównanie dwóch podejść, doprecyzowanie ograniczeń.
Weryfikacja i sanity check – sprawdzanie, czy odpowiedź trzyma się dokumentacji, logów, istniejącego kodu. Im większa stawka (bezpieczeństwo, dane klientów), tym ostrzejsza weryfikacja.
Praca na artefaktach – wrzucanie do modelu fragmentów kodu, logów, ticketów z Jiry czy dokumentów specyfikacji, żeby AI operowała na realnym materiale, a nie ogólnikach.
Osoby, które „gadają z AI jak z wyszukiwarką”, częściej dostają rozczarowujące wyniki. Ci, którzy traktują model jak juniora, ale z turbo‑przepustowością – dają mu kontekst, zadania i feedback – wyciskają z narzędzi znacznie więcej.
Poziom 4: umiejętności produktowo‑biznesowe
Automatyzacja technicznych zadań wypycha ludzi w stronę decyzji: co robić, a nie tylko jak. Nawet w rolach mocno technicznych zaczynają się liczyć kompetencje, które kiedyś kojarzyły się górnolotnie z „biznesem”:
Rozumienie domeny – np. finansów, logistyki, medycyny, e‑commerce. Im lepiej rozumiesz realne procesy, tym sensowniej wykorzystasz AI do ich wsparcia.
Myślenie w metrykach – jak mierzyć sukces funkcji, eksperymentu, optymalizacji? Co tak naprawdę znaczy, że „model działa dobrze”?
Projektowanie doświadczenia użytkownika – szczególnie przy produktach z AI, gdzie błędna odpowiedź może nie tyle „wyświetlić błąd”, co wprowadzić użytkownika w poważne kłopoty.
Priorytetyzacja – umiejętność powiedzenia „nie” projektowi, który jest efektowny, ale nie dowozi żadnej realnej wartości.
Mit powtarzany latami brzmiał: „programista nie musi rozumieć biznesu”. W świecie, w którym modele wyrównują poziom czysto technicznych umiejętności, to właśnie zrozumienie biznesu staje się jednym z najtrwalszych źródeł przewagi.
Do tego dochodzi komunikacja z osobami nietechnicznymi: product ownerem, sprzedażą, zespołem obsługi klienta. AI nie ogarnie za ciebie spotkania, na którym trzeba przełożyć „dziwne błędy w module płatności” na konkretny plan działań, estymaty i ryzyka. Mit, że wystarczy „dobrze kodzić i unikać ludzi”, zderza się tu z rzeczywistością – najciekawsze projekty lądują u osób, które umieją połączyć technologię z kontekstem biznesowym i potrafią to spokojnie wytłumaczyć.
Poziom 5: etyka, odpowiedzialność i odporność psychiczna
Przy projektach z AI rośnie znaczenie obszarów, które długo były traktowane jako „miękkie dodatki”: etyki, odpowiedzialności za skutki działania systemów oraz zwykłej odporności na presję. To już nie są abstrakcyjne rozważania, tylko bardzo praktyczne pytania: co zrobisz, gdy model wygeneruje treść potencjalnie szkodliwą? Gdzie postawisz granicę automatyzacji decyzji, od których zależy czyjeś zdrowie, kredyt, miejsce pracy?
Mocno upraszczający mit mówi: „to tylko narzędzie, odpowiedzialność jest po stronie biznesu”. W realnych zespołach decyzje techniczne – wybór danych treningowych, progów automatycznych blokad, sposobu wyjaśniania decyzji modelu – mają bezpośrednie konsekwencje dla użytkowników. Osoba, która potrafi nazwać te ryzyka, zaproponować zabezpieczenia i udokumentować kompromisy, zyskuje rolę partnera, a nie wykonawcy ticketów.
Do tego dochodzi zwykła odporność psychiczna. Tempo zmian, niepewność wokół roli AI, głośne dyskusje o „końcu programistów” potrafią solidnie podkopać motywację. Pomaga chłodniejsze podejście: traktowanie nauki jako stałego procesu, akceptacja, że co roku trzeba coś odpuścić i coś dodać, a także nawyk budowania sieci kontaktów – ludzi, z którymi można porozmawiać o dylematach, a nie tylko o kolejnych narzędziach.
Rynek IT z AI coraz mniej nagradza „samotnych ninja” i „rockstarów”, a coraz bardziej ludzi, którzy umieją działać odpowiedzialnie w złożonych systemach: technicznych, organizacyjnych i społecznych. To nie brzmi spektakularnie, ale to właśnie taki profil ma największe szanse przetrwać kolejne fale automatyzacji.
Jeśli więc AI ma coś „zabrać”, to głównie iluzję, że wystarczy raz nauczyć się jednego frameworka i przestać zadawać pytania. W zamian daje szansę na pracę, w której narzędzia wykonują coraz więcej rzemieślniczej roboty, a ludzie koncentrują się na decyzjach, odpowiedzialności i sensownym kierunku rozwoju produktów – pod warunkiem, że odważą się świadomie zmienić własny stack kompetencji.
Jak realnie rozwijać nowy stack kompetencji – praktyczny plan na 6–12 miesięcy
Lista kompetencji brzmi ciekawie, dopóki nie trzeba przełożyć jej na kalendarz. Zderzenie z codziennością wygląda tak: sprinty, produkcyjne pożary, trochę życia prywatnego – i nagle na naukę zostaje godzina tygodniowo. Da się jednak ułożyć sensowny plan, który nie zakłada „drugiego etatu po godzinach”.
Dobrym podejściem jest podzielenie rozwoju na kilka równoległych strumieni, zamiast skakania po kursach w zależności od nastroju. Przykładowy schemat na najbliższe 6–12 miesięcy może wyglądać tak:
1 blok „fundamenty” – np. algorytmy, sieci, architektura; 30–60 minut tygodniowo z książką, dokumentacją, zadaniami,
1 blok „ekosystem główny” – konkretne usprawnienia w języku / frameworku, którym zarabiasz,
1 blok „AI w praktyce” – eksperymenty z narzędziami i włączanie ich w bieżący projekt,
1 blok „meta” – przegląd tego, co działa, a co nie, korekta planu raz na miesiąc.
Mit podpowiada, że skuteczny rozwój to „intensywny bootcamp” raz na rok. W praktyce wygrywają osoby, które robią małe kroki konsekwentnie – choćby 3× po 25 minut tygodniowo, ale przez lata.
Wbudowanie AI w codzienny workflow zamiast „nauki AI po godzinach”
Największy błąd przy uczeniu się pracy z AI to traktowanie jej jak osobnego hobby: kurs tu, tutorial tam, a w realnym projekcie wszystko „jak dawniej”. Znacznie więcej daje podejście: każdą powtarzalną czynność w pracy przepuścić przez filtr „czy mogę tu użyć modelu?”.
Przykładowe miejsca, gdzie da się to zrobić bez rewolucji w zespole:
Code review „z asystą” – zanim poprosisz kolegę o CR, puszczasz swoje zmiany przez model z prośbą o znalezienie niejasności, dublowania logiki, potencjalnych bugów. Człowiek nadal ma ostatnie słowo, ale dostaje lepszą bazę.
Diagnoza błędów – wrzucanie stack trace’ów, fragmentów logów i konfiguracji do modelu z jasnym pytaniem „podaj 3 hipotezy przyczyny w kolejności od najbardziej prawdopodobnej” zamiast klasycznego googlowania po pojedynczych komunikatach.
Ujednolicanie stylu – generowanie propozycji refaktoryzacji pod przyjęte w projekcie standardy (nazywanie metod, podział na klasy, wzorce), z odniesieniem do fragmentów istniejącego kodu.
Przyspieszenie zadań „okołokodowych” – przygotowanie szkiców opisów ticketów, draftów dokumentacji technicznej, changelogów, które następnie poprawiasz ręcznie.
W jednym z zespołów backendowych sensowna zmiana zaczęła się od prostego nawyku: każdy nowy feature wymagał krótkiej konsultacji z modelem na etapie projektowania API i modelu danych. Nie zastąpiło to architekta, ale wyeliminowało część oczywistych potknięć i przyspieszyło dyskusje na przeglądach architektury.
Konsekwencja jest prosta: im więcej realnych, codziennych zadań „dotkniesz” AI, tym szybciej zbudujesz intuicję, gdzie narzędzie naprawdę pomaga, a gdzie tylko marnuje czas.
Budowanie „T‑shaped” w praktyce: jak poszerzać bez rozmywania specjalizacji
T‑shaped brzmi świetnie na slajdach, ale wielu osobom kojarzy się z byciem „od wszystkiego i od niczego”. Klucz leży w tym, żeby szerokość nie zjadała głębokości. Dobrze działa model falowy: okresy pogłębiania jednej specjalizacji przeplatane krótszymi „wycieczkami” w sąsiednie obszary.
Można to poukładać w prosty schemat:
60–70% czasu rozwojowego – na „rdzeń”: język + framework + typ aplikacji (np. systemy rozproszone, data pipelines, front‑end aplikacji produktowych),
20–30% czasu – na sąsiednie światy: jeśli jesteś backendowcem, to frontend lub data; jeśli analitykiem danych, to podstawy inżynierii danych,
10–20% czasu – na eksperymenty: nowy framework, narzędzie AI, inny paradygmat (np. funkcyjny), bez presji, że musisz w tym zostać.
Mit mówi: „AI sprawi, że liczyć się będą tylko generalistyczni full‑stackowie”. Rzeczywistość jest bardziej nudna: nadal potrzeba ludzi z głęboką ekspertyzą, ale tacy, którzy potrafią dogadać się z resztą świata i zrozumieć podstawy sąsiednich domen. To dokładnie ta kombinacja, którą AI wzmacnia, a nie zastępuje.
Przykładowe ścieżki rozwoju kompetencji w erze AI
Uogólnione rady są mało użyteczne, dopóki nie rozbiją się o konkretną rolę. W kilku typowych profilach rozwój „nowego stacku” będzie wyglądał trochę inaczej.
Ścieżka: backend developer
Dla backendowca AI oznacza mniej kopiowania boilerplate’u, a więcej myślenia o strukturze systemu. Sensowne akcenty rozwojowe to:
Architektura systemów rozproszonych – wzorce komunikacji, idempotencja, sagas, obsługa awarii; AI może pisać kod, ale nie wymyśli za ciebie, jak system ma zachowywać się przy częściowych błędach.
Obserwowalność – logowanie, metrics, traces, alerting; również w kontekście komponentów AI (czas odpowiedzi modeli, koszty zapytań, degradacja jakości).
Bezpieczeństwo i compliance – szczególnie przy integracji z zewnętrznymi API AI i przetwarzaniu danych wrażliwych.
Podstawy data/ML – nie po to, aby trenować własne modele, ale żeby rozumieć pipeline danych, wersjonowanie, walidację, deployment modelu jako elementu systemu.
Dobrą praktyką jest wzięcie odpowiedzialności za choć jeden „AI‑feature” w istniejącym systemie: od integracji z API modelu, przez monitoring jakości odpowiedzi, po metryki wpływu na biznes. To szybciej uczy realiów niż trzy kursy z „AI w Javie”.
Ścieżka: frontend / product engineer
Na froncie AI wchodzi na dwa sposoby: jako element produktu (asystenci, wyszukiwarki, personalizacja) oraz jako wsparcie warsztatu (generowanie komponentów, testów, kopii UI). Rozsądne obszary rozwoju to:
UX w produktach z AI – projektowanie komunikatów, obsługa niepewności odpowiedzi, interfejsy do poprawiania i korygowania wyników przez użytkownika.
Stan aplikacji i offline‑first – im więcej interakcji z backendem i modelami, tym bardziej liczy się solidne zarządzanie stanem i scenariusze błędów.
Performance i dostępność – AI nie rozwiąże za ciebie accessibility ani nie zoptymalizuje bundle’a.
Podstawy eksperymentowania – A/B testy, feature flagi, praca z metrykami produktu; szczególnie istotne przy funkcjach „inteligentnych”, które wymagają walidacji na żywych użytkownikach.
Ścieżka: data / ML / analytics
W obszarze data AI uderza najmocniej – część klasycznych zadań analitycznych wykonują teraz modele „out of the box”. Profil pracy zmienia się z „budowania modeli od zera” na „składanie rozwiązań, dobór danych i kontrolę jakości”. Kluczowe stają się:
Inżynieria danych – solidne pipeline’y, jakość danych, monitoring driftu; bez tego najlepszy model przestaje mieć sens po kilku tygodniach.
Evaluacja i MLOps – definicja metryk, walidacja na danych zbliżonych do produkcyjnych, deployment i wersjonowanie modeli.
Prompt engineering w wersji „produkcyjnej” – nie chodzi o chwytliwe prompty, tylko o systematyczne testowanie, szablony promptów, kontrolę kosztów i jakości.
Komunikacja wyników – przekładanie rezultatów modeli na decyzje biznesowe, scenariusze „co jeśli”, rekomendacje.
Mit w tej branży brzmi: „duży model rozwiąże wszystko, wystarczy go wywołać”. Rzeczywistość: 80% roboty to nadal dane, integracje, monitoring i dopasowanie rozwiązania do rzeczywistych procesów decyzyjnych w firmie.
Jak świadomie wybierać, czego nie rozwijać
W świecie, w którym każdego tygodnia pojawia się nowa biblioteka, framework i narzędzie AI, umiejętność odpuszczania jest równie ważna jak uczenia się. Zamiast gonić każdy trend, lepiej zadać sobie kilka chłodnych pytań przy każdej „nowince”:
Czy to rozwiązuje problem, który mam lub prawdopodobnie będę mieć? Jeśli nie widzisz zastosowania w swojej domenie w ciągu najbliższego roku, to raczej ciekawostka.
Czy opiera się na trwałych konceptach? Nowy framework UI bazujący na znanym modelu komponentów ma większą szansę przetrwać niż narzędzie „magicznie generujące cały projekt z prompta”.
Czy podnosi mój poziom abstrakcji, czy tylko wygodę? Nauka narzędzia, które działa jak „ładny wrapper” na coś, co już znasz, ma mniejszy zwrot niż zrozumienie poziom niżej (np. protokołów, modeli danych, zasad rozproszenia).
Przydatny filtr brzmi: „czy to jest skill, który pozostanie użyteczny nawet wtedy, gdy to narzędzie zniknie?”. Dobre fundamenty, zrozumienie architektury, praca z ludźmi czy świadoma współpraca z AI spełniają ten warunek. Sztuczki z jednego frameworka, egzotyczny język używany w dwóch firmach na świecie – niekoniecznie.
Mikro‑nawyki, które robią różnicę w świecie z AI
W dłuższym okresie nie wygrywają najbardziej spektakularne skoki, tylko zestaw niewidocznych z boku nawyków. Kilka z nich wyjątkowo dobrze „skaluje się” w środowisku, gdzie AI jest wszędzie.
Automatyczna dokumentacja decision logów – krótkie notatki, dlaczego podjęto taką a nie inną decyzję architektoniczną czy produktową. Dziś robisz to z pomocą AI (streszczanie dyskusji, porządkowanie punktów), jutro wracasz do tego po pół roku i nadal wiesz, o co chodziło.
Systematyczne zapisywanie promptów – nie „kolekcja magicznych zaklęć”, ale repozytorium skutecznych scenariuszy: jak prosisz model o generowanie testów, jak o refaktoryzację, jak o analizę logów. To zaczyna działać jak wewnętrzna biblioteka snippetów.
Regularne „sanity checks” – nawyk zadawania modelowi pytania odwrotnego („podaj argumenty przeciwnie”, „jakie są ryzyka tego podejścia”) zamiast przyjmowania pierwszej odpowiedzi jako planu.
Dzielenie się przykładami w zespole – raz na sprint pokazanie jednej małej rzeczy, którą AI przyspieszyła lub uprościła; buduje to wspólne know‑how i pomaga uniknąć dublowania eksperymentów.
To drobiazgi, ale w połączeniu z rosnącą mocą narzędzi robią wyraźną różnicę między osobą, która „czasem używa ChatGPT”, a kimś, kto faktycznie ma nowy, świadomy stack kompetencji.
Rynek pracy z AI: na co patrzą rekruterzy i menedżerowie
Przy rekrutacjach widać przesunięcie akcentów. Nadal liczą się projekty, technologie i GitHub, ale coraz częściej pojawiają się pytania: jak używasz AI, jak weryfikujesz wyniki, jak podejmujesz decyzje produktowe. Z zewnątrz wygląda to jak drobna korekta, ale ona tworzy czytelne sygnały.
Coraz bardziej zwraca uwagę, czy kandydat:
umie pokazać konkretne przykłady użycia AI w swojej dotychczasowej pracy: „tu AI wygenerowała początkowy moduł, tu poprawiałem podejście, a tu wykryłem błąd w jej odpowiedzi”,
rozumie ograniczenia modeli – potrafi wskazać sytuacje, w których nie polegałby wyłącznie na AI (bezpieczeństwo, krytyczne decyzje, dane wrażliwe),
myśli w kategoriach wartości biznesowej – potrafi odpowiedzieć, jak feature z AI przełożył się na konkretne metryki (czas obsługi, konwersję, odciążenie supportu),
potrafi pracować na cudzym kodzie i cudzych decyzjach – bo AI tym bardziej generuje kod, który nie jest „nasz”, ale trzeba go zrozumieć, poprawić, wpiąć w system.
Mit wciąż obecny w głowach części kandydatów: „wystarczy dopisać w CV: umiem pracować z AI”. Bez konkretów brzmi to jak „znam Git’a”. Rzeczywistość jest prosta – dużo lepiej działa jedno zdanie o tym, jak realnie wykorzystujesz modele w swoim projekcie, niż cała sekcja buzzwordów.
Jeśli rekruter słyszy tylko: „korzystam z Copilota”, to nic mu to nie mówi. Jeśli usłyszy: „w tym projekcie skróciliśmy czas code review dzięki szablonom promptów i checklistom, a ja pilnowałem, żeby AI nie przepychała niebezpiecznych zmian”, od razu wie, jak myślisz o narzędziach. Mit brzmi: „AI w CV to przewaga sama w sobie”. Rzeczywistość: przewagą jest umiejętność pokazania, że dzięki AI umiesz dowozić pracę szybciej, bez utraty jakości i z głową.
Coraz częściej liczy się też odporność na szum narzędziowy. Kandydat, który co trzy miesiące zmienia „główne stacki” pod modę, wysyła sygnał, że łatwo go rozproszyć. Zdecydowanie lepiej wypada ktoś, kto ma stabilny kręgosłup technologiczny, a AI traktuje jako rozszerzenie: potrafi opisać, jak automatyzuje rutynę, gdzie stawia granice i jakie ma własne procedury weryfikacji wyników. To pokazuje nie tylko skill, ale też dojrzałość.
Na rozmowach rekrutacyjnych przewagę mają osoby, które potrafią opowiedzieć historię: był problem, był pomysł na użycie AI, był eksperyment, były wnioski (także negatywne). Nie chodzi o to, żeby wszystko się udało – wręcz przeciwnie, rozsądny menedżer wie, że eksperymenty często zawodzą. Bardziej interesuje go, czy wyciągasz z tego lekcje i potrafisz następnym razem podejść do tematu sensowniej.
W tle przewija się jeszcze jedna obawa: „AI mnie zastąpi”. Na rynku pracy znacznie częściej odpadają nie ci, których „zastąpił model”, tylko ci, którzy zatrzymali się na poziomie powtarzalnych zadań i nie zbudowali wokół siebie szerszej wartości: rozumienia systemu, produktu, ludzi. Modele świetnie kopiują przeszłość. Ty możesz projektować przyszłe rozwiązania, łączyć kropki i decydować, którędy warto iść dalej.
Jeśli miałby zostać z tego tylko jeden wniosek, to taki: AI nie kasuje sensu rozwijania się w IT, tylko przesuwa środek ciężkości. Mniej liczy się biegłość w pojedynczym narzędziu, bardziej – elastyczny, krytyczny sposób pracy z całym ekosystemem. Kto nauczy się używać modeli jako „silnika pomocniczego”, a nie magicznej protezy, ten w najbliższych latach będzie miał na rynku pracy wygodnie dużo opcji.
Najczęściej zadawane pytania (FAQ)
Czy sztuczna inteligencja naprawdę zabierze pracę programistom?
AI zabiera głównie powtarzalne fragmenty pracy, a nie całe etaty. Generuje boilerplate, proste CRUD-y, testy jednostkowe czy konfiguracje pod popularne stacki. Tam, gdzie zadanie jest dobrze opisane w publicznych repozytoriach i oparte na schematach, AI radzi sobie świetnie.
Gorzej idzie jej w projektowaniu architektury, rozumieniu domeny biznesowej, podejmowaniu decyzji z konsekwencjami dla bezpieczeństwa i kosztów. Rzeczywisty trend jest taki: spada zapotrzebowanie na ludzi, którzy klepią rutynowy kod, rośnie za to popyt na osoby, które potrafią użyć AI jako dźwigni i wziąć odpowiedzialność za całość rozwiązania.
Jakie umiejętności w IT są dziś najmocniej wzmacniane przez AI, a jakie są relatywnie „bezpieczne”?
Najmocniej zautomatyzowane są obszary oparte na powtarzalnym pisaniu: frontend z klasycznymi panelami i formularzami, proste API i integracje CRUD, testy regresyjne, dokumentacja techniczna i skrypty pomocnicze. W tych miejscach AI potrafi wygenerować większość podstawowej pracy, a człowiek przesuwa się w stronę weryfikacji i integracji.
Relatywnie bezpieczniejsze są zadania wymagające głębokiego zrozumienia domeny i działania systemu: embedded, systemy czasu rzeczywistego, oprogramowanie medyczne, bezpieczeństwo, złożona architektura rozproszona. Tu AI może coś podpowiedzieć, ale bez inżyniera, który myśli modelami, ograniczeniami i ryzykiem, szybko kończy się to błędami o wysokiej cenie.
Jak AI wpływa na szanse juniora na rynku pracy IT?
Mit brzmi: „AI jest lepsza od juniora, więc juniorzy są zbędni”. W prostych zadaniach faktycznie bywa tak, że model wygeneruje kod na poziomie przyzwoitego juniora. Różnica jest jednak kluczowa – AI nie przejmie odpowiedzialności, nie wejdzie w kulturę firmy, nie ogarnie komunikacji z biznesem ani nie będzie rozwijać się w kontekście konkretnego produktu.
Problem juniorów polega raczej na tym, że część firm odkryła, iż zespół midów i seniorów wsparty AI może pokryć sporą część „juniorowej” pracy. To podnosi poprzeczkę na wejściu. Junior, który tylko odtwarza tutoriale, jest łatwy do zastąpienia. Junior, który rozumie podstawy domeny, potrafi sensownie używać AI, zadaje dobre pytania i jest w stanie samodzielnie doprowadzić zadanie do końca – nadal jest potrzebny, tylko musi szybciej dorastać.
Jakie kompetencje warto rozwijać, żeby nie przegrać z AI w IT?
Najlepiej łączyć dwie ścieżki: głębsze zrozumienie systemów i domeny oraz umiejętne korzystanie z AI. Coraz cenniejsze są umiejętności:
projektowania rozwiązań i architektury, zamiast samego pisania kodu linia po linii,
pracy z biznesem: zbieranie wymagań, przekładanie ich na język techniczny, ocena ryzyka i kosztów,
świadomego używania narzędzi AI – od pisania skutecznych promptów po krytyczną ocenę wyników i kwestie licencyjno‑bezpieczeństwowe.
W praktyce najlepiej radzą sobie osoby, które traktują AI jak „wkrętarkę z magazynkiem”: przyspiesza robotę, ale nie zastępuje myślenia o konstrukcji całej szafy. Sama biegłość w narzędziach bez rozumienia, co się buduje i dlaczego, będzie coraz mniej warta.
Czy AI to tylko kolejny gadżet typu nowy framework albo IDE?
To częsty mit wśród doświadczonych developerów. AI jest „tylko narzędziem” w tym sensie, że nie ma własnej woli, ale skala zmiany przepustowości pracy jest zupełnie inna niż przy przejściu na nowy framework. Funkcje, które kiedyś zajmowały dzień, można dziś szkicowo złożyć w godzinę, a to przesuwa presję na inne etapy procesu.
Zmienia się tempo dostarczania, struktura zadań i wymagane kompetencje. Więcej czasu trzeba przeznaczać na projektowanie, testowanie, przegląd kodu i dopinanie wymagań, mniej na ręczne klepanie powtarzalnych fragmentów. Ignorowanie tego zjawiska często kończy się czymś prostym: zespół, który umie dobrze korzystać z AI, po prostu dostarcza szybciej i taniej.
Jak w praktyce wygląda praca mida lub seniora z AI przy projekcie?
Rola doświadczonej osoby coraz bardziej przypomina „reżysera”, a nie „solowego wykonawcę”. Mid lub senior projektuje rozwiązanie, rozpisuje je na kroki, używa AI do wygenerowania 60–70% kodu, a potem go poprawia, dopasowuje do standardów zespołu, pisze testy i wkomponowuje w istniejący system. Do tego dochodzi czuwanie nad tym, żeby zespół nie przyjmował bezrefleksyjnie propozycji modelu.
Dochodzi też nowy obszar odpowiedzialności: bezpieczeństwo danych i licencje (co wysyłamy do modelu, jakie ryzyka akceptujemy), dobór narzędzi AI do procesu wytwórczego, tworzenie dobrych promptów bazowych dla zespołu. Senior, który ignoruje te tematy, oddaje pole komuś, kto potrafi połączyć technologię z praktycznym wykorzystaniem AI.
Jakie role w IT są najtrudniejsze do zautomatyzowania przez AI?
Trudniej ruszyć role, które łączą kompetencje techniczne i biznesowe oraz wymagają oceny ryzyka i odpowiedzialności. Chodzi m.in. o:
architektów systemów i inżynierów platform,
tech leadów prowadzących zespół i decyzje technologiczne,
developerów rozumiejących produkt i metryki biznesowe,
analityków oraz PM‑ów potrafiących sensownie wpleść AI w proces.
AI może podsunąć szkic diagramu architektury czy pomysł na podział mikroserwisów, ale nie przejmie odpowiedzialności za dostępność systemu finansowego, skutki błędnej integracji czy źle policzone koszty chmurowe. Właśnie w tych miejscach przewaga człowieka jest największa – pod warunkiem, że nie ogranicza się do klikania w narzędzia, tylko rozumie konsekwencje decyzji.
Bibliografia
The Future of Jobs Report 2023. World Economic Forum (2023) – Prognozy wpływu automatyzacji i AI na rynek pracy, w tym IT
Generative AI and the future of work in America. McKinsey Global Institute (2023) – Analiza wpływu generatywnej AI na zadania, role i produktywność
OECD Employment Outlook 2023: Artificial Intelligence and the Labour Market. OECD (2023) – Wpływ AI na zatrudnienie, automatyzację zadań i strukturę kompetencji
