Nowa rzeczywistość w IT: co AI już zmieniła, a co to tylko hype
Od Copilota i ChatGPT do wszechobecnych asystentów w IDE i chmurze
Sztuczna inteligencja w IT przestała być ciekawostką z konferencji i stała się codziennym narzędziem pracy. GitHub Copilot, ChatGPT, modele wbudowane w JetBrains, VS Code czy narzędzia chmurowe w Azure, AWS i GCP sprawiły, że kodowanie z AI assistantem staje się nowym standardem, a nie wyjątkiem. Programiści, którzy jeszcze dwa lata temu generowanie kodu traktowali jako „magiczne sztuczki”, dziś regularnie powierzają narzędziom AI tworzenie szkieletów klas, testów jednostkowych czy zapytań do bazy.
Zmiany nie ograniczają się tylko do programowania. Wbudowane AI w narzędziach do zarządzania projektami, systemach ticketowych, dokumentacji technicznej czy monitoringu aplikacji wpływają na pracę całych zespołów IT: od supportu przez DevOps po analityków. Automatyzacja pracy programistów przestaje oznaczać „zastąpienie”, a coraz częściej oznacza „przesunięcie ciężaru zadań” – z odtwórczej implementacji na projektowanie rozwiązań i decyzje produktowe.
Mit, że „AI jest tylko gadżetem dla kilku geeków”, zderza się z rzeczywistością integracji modeli językowych w narzędziach biznesowych: Jira, Confluence, Office 365, Google Workspace, systemach CRM i ERP. W wielu firmach to nie jest już pytanie „czy włączyć AI”, tylko „jak ograniczyć ryzyko, skoro i tak wszyscy z tego korzystają”.
Różnica między „AI podpowiada” a „AI przejmuje część zadań”
W codziennej pracy programisty i innych specjalistów IT powstała wyraźna granica między AI jako asystentem a AI jako wykonawcą. W pierwszym scenariuszu traktujesz narzędzie jak superinteligentny autocomplete: podpowiedzi kodu, gotowe snippet’y, sugestie refaktoryzacji czy szybsze pisanie dokumentacji. Decyzja, co zaakceptować, wciąż należy do człowieka.
W drugim scenariuszu AI zaczyna przejmować całe zadania. Przykłady: wygenerowanie kompletnego CRUD-a z walidacją i testami, wygenerowanie całej specyfikacji API na podstawie kilku wymagań, automatyczne tworzenie skryptów migracji danych. Tu pojawia się różnica jakościowa: rola człowieka przesuwa się z „twórcy szczegółów” na projektanta i recenzenta. Osoba, która nie potrafi ocenić poprawności wygenerowanego rozwiązania, staje się tylko operatorem przycisku „generate”, a to rola dużo łatwiej zastępowalna.
Mit: „jak nauczę się dobrze promptować, to AI zrobi za mnie wszystko” – rozbija się o praktykę. Bez rozumienia architektury, ograniczeń technologii, wzorców projektowych i kontekstu biznesowego prompt-engineering jest sztuką ładnego zadawania pytań, ale nie przejmuje odpowiedzialności za skutki tych odpowiedzi.
Obszary IT najmocniej dotknięte automatyzacją
Automatyzacja związana z AI nie rozkłada się równomiernie. Najmocniej zmieniają się role i zadania, które wcześniej były powtarzalne, schematyczne i łatwo opisywalne tekstem. W praktyce najbardziej odczuwalne zmiany zachodzą w kilku obszarach:
Frontend – generowanie komponentów, styli, prostych interakcji, a nawet całych widoków na podstawie opisów tekstowych lub makiet.
Testy – automatyczne generowanie testów jednostkowych, integracyjnych, scenariuszy testów E2E i danych testowych; narzędzia AI znacząco przyspieszają pracę QA.
Dokumentacja – streszczanie, porządkowanie, generowanie dokumentacji API, README, changelogów na bazie commitów lub kodu źródłowego.
Support i helpdesk – chatboty pierwszej linii wsparcia, systemy rozpoznawania kategorii zgłoszeń, automatyczne odpowiedzi na proste pytania użytkowników.
W tych obszarach następuje wyraźne „spłaszczanie” zadań: AI radzi sobie dobrze z tym, co wcześniej zajmowało juniorów i midów. Nie oznacza to od razu likwidacji wszystkich etatów, ale zmienia strukturę pracy: mniej ręcznego klikania i przepisywania, więcej projektowania scenariuszy, priorytetyzacji i nadzoru.
Mit: „AI zabierze wszystkie etaty programistom” kontra rzeczywistość
W debacie publicznej króluje skrajność: albo wizja pełnej automatyzacji, albo „AI nic nie potrafi, więc nie ma czym się przejmować”. Jedno i drugie jest mylące. Fakty są mniej spektakularne, ale bardziej wymagające:
AI już teraz realnie podnosi produktywność programistów – przy dobrze ułożonych procesach można szybciej dostarczać funkcje i naprawki.
Firmy, które to wykorzystają, będą potrzebować mniejszej liczby osób do wykonywania tej samej ilości prostych zadań, ale więcej ekspertów od architektury, jakości, bezpieczeństwa i integracji.
Zawody w IT nie znikają hurtowo – raczej zmienia się ich profil kompetencyjny, a monotonne czynności są „wypyłowywane” przez AI.
Rzeczywistość jest bliżej scenariusza „przesuwania akcentów” niż „masowych zwolnień wszystkich programistów”. Wygrają ci, którzy zrozumieją, że praca w IT to już nie tylko implementacja, ale coraz bardziej umiejętność łączenia technologii, biznesu i współpracy z AI jako nowym uczestnikiem zespołu.
Mapowanie zawodów IT pod kątem wpływu AI
Główne role w IT i jak AI zaczyna je przekształcać
Rynek IT to nie tylko developerzy. Skutki wejścia AI widać w niemal każdej roli: od DevOpsów po UX. Mapując wpływ AI, łatwiej ocenić, które kompetencje są przyszłościowe, a które będą stopniowo wygaszane.
Project Manager / Product Owner – wsparcie w priorytetyzacji backlogu, analizie ryzyk, raportowaniu, komunikacji z interesariuszami.
UX / UI – generowanie wariantów projektów, testy A/B, analiza zachowań użytkowników w oparciu o duże zbiory danych.
Data / ML Engineer – automatyzacja części feature engineering, eksperymentów, monitorowania modeli.
Security / SecOps – wsparcie w analizie logów, wykrywaniu anomalii, generowaniu polityk i reguł bezpieczeństwa.
Mapując swoje miejsce na tej osi, łatwiej odpowiedzieć na pytanie: „Czy moja codzienna praca to głównie powtarzalne czynności, czy raczej decyzje, projektowanie i odpowiedzialność za wynik?”. Im bliżej tego drugiego bieguna, tym większa odporność na prostą automatyzację.
Jak AI zmienia zadania w poszczególnych rolach – przykłady z praktyki
Developerzy widzą zmiany najwcześniej. AI assistant w IDE proponuje całe funkcje, szablony klas, a nawet całe moduły. Backendowiec może wygenerować podstawowy serwis CRUD z walidacją, mapowaniem DTO i testami w kilka minut, zamiast godzin. Frontendowiec opisuje, jak ma wyglądać komponent formularza, a narzędzie generuje JSX/Vue/Angular, CSS i podstawową walidację.
Testerzy coraz częściej korzystają z AI do tworzenia pełnych scenariuszy testów na podstawie user stories, a także do generowania danych testowych i interpretacji raportów z narzędzi E2E. AI pomaga wychwycić luki w pokryciu testami, sugeruje dodatkowe przypadki brzegowe, podpowiada, jak zoptymalizować istniejące testy.
DevOps / SRE używają AI do pisania skomplikowanych pipeline’ów CI/CD, skryptów Terraform/Ansible, a także do wyjaśniania złożonych konfiguracji Kubernetesa. W sytuacjach incydentów AI może pomóc w szybszej analizie logów, korelowaniu zdarzeń i podpowiadaniu hipotez. Ostateczne decyzje dalej należą do człowieka, ale czas „od problemu do hipotezy” znacząco się skraca.
Analitycy delegują AI wstępne czytanie i streszczanie dokumentów, generowanie wstępnych modeli procesów, testowanie spójności wymagań. Zamiast ręcznie przepisywać i porządkować notatki z warsztatów, mogą skupić się na ocenie ryzyk, negocjowaniu zakresu i dopasowywaniu rozwiązań do realiów organizacji.
Kompetencje zastępowalne i te trudne do automatyzacji
W każdej roli można wskazać działania, które AI przejmie stosunkowo szybko, oraz takie, gdzie człowiek jeszcze długo będzie kluczowy. Prosty podział wygląda następująco:
projektowanie infrastruktury, zarządzanie kosztami i SLA
Analityk
streszczenia dokumentów, wstępne modele procesów
negocjacja wymagań, decyzje priorytetowe, komunikacja z biznesem
PM / PO
raporty statusowe, podsumowania, wstępne analizy ryzyka
zarządzanie interesariuszami, decyzje produktowe, kompromisy zakresu
Mit: „wystarczy być w roli, która jest trudna do zautomatyzowania, i można spać spokojnie”. W praktyce nawet te bardziej „ludzkie” zadania wymagają zrozumienia, jak zintegrować AI w proces. PM, który nie umie delegować części analizy AI, tylko przepisywać raporty ręcznie, będzie mniej efektywny od tego, który traktuje modele jako wsparcie w podejmowaniu lepszych decyzji.
Zawody „turbo-doładowane” vs zawody „spłaszczane” przez AI
Rozsądniej niż mówić o zawodach „znikających” jest mówić o zawodach „turbo-doładowanych” przez AI oraz takich, które są spłaszczane – czyli coraz mniej zróżnicowane i w dużej części wykonane przez narzędzia.
Turbo-doładowane: architekci, senior developerzy, eksperci od bezpieczeństwa, inżynierowie danych, MLOps, analitycy produktowi. AI zwiększa ich zasięg: mogą obsłużyć więcej systemów, analiz, decyzji.
Spłaszczane: junior developerzy robiący prosty frontend/backend, manualni testerzy wykonujący wyłącznie skrypty krok po kroku, support pierwszej linii, integratorzy kopiujący rozwiązania z tutoriali.
Zawody spłaszczane nie znikną całkowicie, ale konkurencja w nich wzrośnie, a płace mogą być pod presją. Zawody turbo-doładowane wymagają natomiast głębszej odpowiedzialności: decyzji o architekturze, jakości, bezpieczeństwie, etyce użycia AI. Często oznacza to przejście z „ręcznego wykonywania” do roli projektanta i strażnika standardów.
Kompetencje, których AI szybko nie przejmie
Trzy warstwy pracy IT: od problemu biznesowego do implementacji
Żeby zrozumieć, gdzie AI może wejść, a gdzie ma naturalne ograniczenia, dobrze jest rozbić pracę w IT na trzy główne warstwy:
Rozumienie problemu biznesowego – zrozumienie, o co naprawdę chodzi użytkownikom, jakie są cele firmy, jakie ryzyka i ograniczenia.
Projektowanie rozwiązania – dobór architektury, technologii, struktury danych, procesów i interfejsów.
AI najszybciej wchodzi w trzecią warstwę – implementację. Generowanie kodu, plików konfiguracyjnych, nawet testów czy dokumentacji jest naturalnym zastosowaniem modeli językowych. Druga warstwa – projektowanie – jest już trudniejsza, bo wymaga kontekstu organizacyjnego, kompromisów i odpowiedzialności za dług techniczny.
Najbardziej odporna na automatyzację jest pierwsza warstwa: rozumienie problemu. Rozmowa z interesariuszami, przełamywanie sprzecznych oczekiwań, identyfikowanie nieoczywistych ograniczeń (regulacje prawne, kultura organizacyjna, polityka wewnętrzna) to obszary, gdzie AI może co najwyżej pomóc przygotować się do rozmowy lub podsumować notatki. Decyzje i odpowiedzialność za kierunek nadal należą do człowieka.
Praca z niejednoznacznością i konfliktem interesów
Duża część pracy w IT polega na poruszaniu się w szarej strefie: wymagania są niepełne, interesariusze się nie zgadzają, a ograniczenia wychodzą „w praniu”. AI świetnie radzi sobie z tekstem, ale gorzej z napięciem między ludźmi i polityką organizacji.
Kluczowe kompetencje, których modele nie przejmą szybko, to między innymi:
Ustalanie priorytetów między sprzecznymi celami – sprzedaż chce „jak najszybciej”, compliance chce „jak najbezpieczniej”, a operacje „jak najtaniej”. Ktoś musi zdecydować, które ryzyko bierzemy na siebie i co komunikujemy zarządowi.
Moderowanie konfliktów – gdy dwa działy mają sprzeczne oczekiwania wobec systemu, potrzebna jest osoba, która wejdzie w tę relację, zrozumie motywacje i poszuka kompromisu. AI może zaproponować scenariusze, ale nie zbuduje zaufania.
Akceptowanie odpowiedzialności – decyzja, że „nie robimy tej funkcji, bo ryzyko prawne jest zbyt duże” albo „zmieniamy architekturę, bo inaczej nie dowieziemy skali”, nie jest tylko logicznym wnioskiem. To także gotowość do wzięcia na siebie konsekwencji.
Mit, że „jak AI będzie wystarczająco dobra, to sama zdecyduje na podstawie danych”, pomija fakt, że decyzje biznesowe rzadko są czysto techniczne. Dane są tylko jednym z wejść, obok polityki, reputacji, relacji z klientami czy strategii firmy.
Myślenie systemowe i rozumienie kontekstu organizacji
System IT żyje w organizacji, a nie w próżni. Zmiana w jednym miejscu potrafi wywołać nieoczywiste skutki w innym. AI może pomóc narysować diagram, ale spójne myślenie systemowe to inny kaliber kompetencji.
Przydatne, trudne do zautomatyzowania umiejętności to na przykład:
Łączenie kropek między systemami i działami – zrozumienie, że mała zmiana w procesie fakturowania wpłynie na raporty finansowe, workflow w sprzedaży i SLA supportu.
Ocena długofalowych skutków decyzji – AI może wskazać kilka wariantów architektury, ale ktoś musi ocenić, co to oznacza za dwa lata: vendor lock-in, koszty licencji, trudność rekrutacji specjalistów.
Projektowanie organizacji wokół systemu – zmiana technologii często wymaga zmiany ról, kompetencji i procesów. To już nie jest pytanie „jaki framework”, ale „jak ludzie będą ze sobą współpracować”.
Rzeczywistość jest taka, że im większa skala systemu, tym bardziej liczy się nie pojedynczy commit, tylko umiejętność zobaczenia całego układu naczyń połączonych. Tu AI jest pomocnikiem, nie strategiem.
Komunikacja, narracja i wpływ na decyzje
AI wygeneruje raport, slajdy czy zgrabne podsumowanie. To część pracy. Druga – często ważniejsza – to przekonanie konkretnych ludzi do działania na podstawie tych treści.
Silne, trudne do zastąpienia obszary to między innymi:
Budowanie narracji dla różnych odbiorców – inaczej tłumaczy się migrację do chmury CFO, inaczej zespołowi developerów, a jeszcze inaczej klientom. Ta sama decyzja, różne historie, inne akcenty.
Umiejętność słuchania i zadawania niewygodnych pytań – AI może wygenerować listę pytań warsztatowych, ale nie wyczuje, że ktoś coś przemilcza, że „wszyscy mówią tak, ale nikt w to nie wierzy” albo że problem leży poza deklarowanym zakresem projektu.
Budowanie autorytetu eksperta – ludzie nie ufają slajdom, tylko osobom, które za nimi stoją. Zaufanie i reputacja powstają latami, nie da się ich „wygenerować” promptem.
Mit, że „AI zabierze wszystkie prezentacje i raporty”, myli formę z procesem wpływu. Tworzenie slajdów to technikalia; realna władza kryje się w tym, kto ustala narrację wokół tych slajdów.
Jak AI zmienia codzienną pracę programisty (bez bajek marketingowych)
Programista z AI vs programista bez AI: faktyczna różnica
Różnica między osobą używającą AI a tą, która jej unika, nie polega dziś na tym, że jedna „nie pisze już kodu”. Bardziej na tym, ile czasu spędza na nudnej pracy, a ile na myśleniu o problemie.
Typowy dzień programisty z AI wygląda coraz częściej tak:
Projektuje rozwiązanie w głowie lub na kartce, a dopiero potem „rozbija” je z AI na konkretne moduły.
Prosi model o szkic klasy, algorytmu, testów, potem agresywnie je poprawia i dostosowuje.
Używa AI do tłumaczenia obcego kodu, refaktoryzacji, migracji między wersjami frameworków.
Przy wątpliwościach nie googluje 20 minut, tylko wkleja fragment i pyta o hipotezy błędu.
Programista bez AI nadal może dostarczać wartość, ale będzie częściej przegrywał tam, gdzie liczy się tempo eksperymentu i łatwość przebudowy koncepcji. Różnica nie jest czysto „produkcyjna”, tylko mentalna: kto traktuje AI jak „drugi mózg”, przestaje bać się pójścia kilkoma ścieżkami naraz.
Codzienne zadania, w których AI realnie pomaga
Zamiast marketingowego „AI robi wszystko”, lepiej spojrzeć na konkretne kategorie pracy, w których wielu developerów odczuło realną ulgę.
Boilerplate i klejenie warstw – kontrolery, DTO, mapowania, pliki konfiguracyjne, fabryki, powtarzalne wzorce repozytoriów. To świetny materiał dla modeli generatywnych, bo jest schematyczny.
Eksploracja nieznanych bibliotek – zamiast przekopywać się przez dokumentację, można poprosić AI o „minimalny przykład użycia”, a dopiero potem sięgać głębiej.
Debugowanie i hipotezy błędów – AI nie „naprawi” wszystkiego, ale często poda 3–4 rozsądne hipotezy, na co spojrzeć w pierwszej kolejności. Zamiast błądzić, dostajesz listę tropów.
Refaktoryzacja i porządki – podziały zbyt długich metod, usuwanie duplikacji, reorganizacja modułów. To nadal wymaga oka seniora, ale mechaniczna część idzie szybciej.
Testy – generowanie bazowych testów jednostkowych czy E2E pod istniejący kod, podpowiedzi przypadków brzegowych, które łatwo przeoczyć.
Rzeczywistość jest taka, że narzędzia AI najlepiej radzą sobie z tym, czego większość programistów nie lubi: powtarzalnością, wklepywaniem schematów, żmudną analizą dużych fragmentów obcego kodu.
Obszary, w których AI zawodzi albo wręcz przeszkadza
Są też zadania, gdzie ślepa wiara w AI kończy się stratą czasu lub ryzykiem.
Złożona architektura i integracje – AI może wygenerować „ładny” diagram, ale nie poniesie konsekwencji, gdy okaże się, że integracja z systemem legacy jest niewykonalna albo kosmicznie droga.
Bardzo specyficzna logika domenowa – w branżach regulowanych (finanse, medycyna, energetyka) drobne niuanse mają znaczenie prawne. Model nie ma intuicji domeny, bazuje na statystyce.
Bezrefleksyjne generowanie kodu – kopiowanie dużych bloków wygenerowanego kodu bez zrozumienia prowadzi do technicznego śmietnika. To nie jest problem samej AI, tylko kultury pracy „byle działało”.
Mit „AI wie lepiej, bo widziała więcej kodu niż ja” jest wygodny, ale fałszywy. Model nie „rozumie” kontekstu waszego systemu, historii decyzji, ograniczeń zespołu. On tylko dobrze przewiduje kolejne tokeny.
Rola seniora i architekta w świecie z AI
AI zmienia najbardziej życie osób, które już teraz pełnią role senior/tech lead/architekt. Nie dlatego, że „zabiera im pracę”, ale dlatego, że przesuwa granice tego, co można zrobić małym zespołem.
Seniorzy częściej niż kiedyś zajmują się:
Projektowaniem kontraktów i granic systemu – skoro kod wewnątrz można szybciej generować i wymieniać, rośnie znaczenie dobrego podziału domen i API między nimi.
Tworzeniem guardrails dla AI – konwencji kodu, linterów, testów kontraktowych, które „pilnują” jakości tego, co generuje model. To nowy wymiar standardów projektowych.
Mentoringiem w korzystaniu z AI – młodsi często albo nadużywają AI, albo się jej boją. Ktoś musi pokazać, gdzie generatywne narzędzia przyspieszają, a gdzie generują dług.
W dobrze prowadzonych zespołach senior spędza mniej czasu na pisaniu prostego kodu za juniorów, a więcej na projektowaniu i recenzowaniu pracy wspomaganej przez AI.
Źródło: Pexels | Autor: Pixabay
Szanse rozwojowe: w jakich kierunkach warto iść z AI u boku
Specjalizacja w integracji AI z produktami
Jednym z najbardziej oczywistych, ale wciąż niedoszacowanych kierunków jest AI enablement produktów – nie budowanie modeli od zera, tylko wbudowywanie istniejących modeli w realne systemy.
Konkretnie chodzi o takie kompetencje jak:
Projektowanie przepływów z LLM – kiedy zapytać model, jak sformatować odpowiedź, jak ograniczyć halucynacje, jak łączyć kilka zapytań w procesie.
Łączenie LLM z danymi firmowymi – RAG, wektoryzacja dokumentów, wybór tego, co może, a co nie może opuścić organizacji.
Bezpieczne logowanie i monitorowanie użycia – audyt zapytań i odpowiedzi, detekcja nadużyć, ochrona danych wrażliwych.
To nie jest jeszcze jedna „modna technologia”, tylko zbiór praktycznych umiejętności, które można wykorzystać w niemal każdym produkcie: od CRM, przez helpdesk, po systemy wewnętrzne.
Architektura i inżynieria danych pod AI
Modele generatywne są tym lepsze, im lepszy mają dostęp do danych i narzędzi. Kto potrafi przygotować dane i infrastrukturę pod AI, będzie miał co robić jeszcze długo.
W praktyce prowadzi to do rosnącego znaczenia takich profili jak:
Data Engineer / Analytics Engineer – budowa sensownych modeli danych, pipeline’ów, jakości danych. Bez tego AI tylko ładnie halucynuje.
MLOps / AI Platform Engineer – zarządzanie cyklem życia modeli, wersjonowaniem, monitorowaniem i kosztami. Zwłaszcza tam, gdzie w grę wchodzą modele własne lub fine-tuning.
Specjaliści od prywatności danych – łączenie kompetencji technicznych z prawnymi, aby AI pracowała na danych wrażliwych zgodnie z regulacjami.
Mit, że „AI zabije zawody data” jest odwrotnością rzeczywistości. To dane są paliwem dla AI – im bardziej firma inwestuje w AI, tym bardziej potrzebuje ludzi, którzy ogarną dane.
Product i UX ukierunkowane na interakcję z AI
Nowe produkty oparte na AI cierpią często na ten sam problem: technologia jest imponująca, ale użytkownik nie bardzo wie, jak z niej sensownie korzystać. Tutaj wchodzą specjalizacje łączące product/UX z rozumieniem AI.
Przykładowe, rosnące obszary:
Projektowanie interfejsów konwersacyjnych – nie tylko „chat obok aplikacji”, ale przemyślane flow pytań, sugestie promptów, wyjaśnienia, co system może, a czego nie zrobi.
Explainability w UX – pokazywanie użytkownikowi, skąd się wzięła rekomendacja, jakie są ograniczenia, jak może ją zakwestionować. Bez tego zaufanie szybko znika.
Badania użyteczności specyficzne dla AI – testowanie, jak ludzie interpretują odpowiedzi modelu, gdzie za bardzo mu ufają, a gdzie go ignorują.
To nie jest „UX jak zawsze plus AI”. Konieczne jest rozumienie, jak modele się mylą, gdzie są nieprzewidywalne i jak to przełożyć na bezpieczne, zrozumiałe doświadczenie użytkownika.
Bezpieczeństwo i ryzyko w świecie generatywnym
Każda nowa technologia otwiera nowe wektory ataku. Z AI nie jest inaczej: prompt injection, wycieki danych przez logi modeli, generowanie złośliwego kodu czy fałszywe treści to już nie teoretyczne zagrożenia.
Rozumieją klasyczne bezpieczeństwo i potrafią je rozszerzyć na scenariusze z AI (np. co się dzieje, gdy model ma dostęp do narzędzi wykonujących komendy).
Projektują polityki użycia AI w organizacji – jakie dane można wysłać na zewnątrz, jak wersjonować modele, jak audytować ich wpływ na decyzje.
Potrafią testować i atakować systemy AI (red teaming) – żeby znaleźć słabości, zanim zrobią to inni.
To szansa dla osób z backgroundem security, ale też dla developerów, którzy chcą iść w stronę inżynierii ryzyka, a nie tylko „pisania funkcji”.
Realne zagrożenia: gdzie można faktycznie przegrać z automatyzacją
Praca czysto odtwórcza i zależna od szablonów
Automatyzacja pracy „ticketowej” i utrzymaniowej
Druga kategoria realnie zagrożonych ról to wszelkie funkcje „ticket-driven”: support aplikacyjny, proste utrzymanie systemów, manualne wykonywanie powtarzalnych zadań opsowych.
Jeśli twoja codzienność to:
odhaczanie podobnych zgłoszeń w Jirze lub ServiceNow,
ręczne wykonywanie krok po kroku tej samej procedury (restarty, deploymenty, zmiany konfiguracji według szablonu),
odpowiadanie użytkownikom według gotowych skryptów,
to jesteś w grupie, gdzie AI plus klasyczna automatyzacja mogą dramatycznie zmniejszyć zapotrzebowanie na ludzi.
Nie chodzi tylko o generatywne modele. Spięcie zwykłych skryptów, narzędzi IaC i LLM, który podpowiada lub odpala „runbooki”, wystarczy, żeby znaczną część roboty mogła wykonać mniejsza liczba specjalistów.
Mit brzmi: „Support zawsze będzie potrzebny, bo użytkownicy są nieprzewidywalni”. Rzeczywistość: większość ticketów to kilka powtarzających się wzorców, które świetnie nadają się na automatyzację i chatboty L1/L2, a człowiek wchodzi dopiero wtedy, gdy coś wykracza poza schemat.
Silosy technologiczne bez kontaktu z domeną
Jest jeszcze jeden cichy, ale istotny obszar ryzyka: role zamknięte w wąskim, technologicznym silosie, bez głębszego rozumienia biznesu.
Przykład: „frontendowiec od pixel-perfect landing page’y” czy „gość od jednego frameworka backendowego”, który nigdy nie wnika, po co w ogóle powstaje dany system. Jeśli ktoś potrafi tylko zamieniać figmę na HTML/CSS/JS albo endpointy na CRUD, bez udziału w projektowaniu funkcjonalności, to AI ma do niego niebezpiecznie blisko.
Modele nie rozumieją biznesu, ale świetnie naśladują powtarzalne wzorce. Jeżeli twoja praca to tylko „podać parametry, dostać wynik”, to dokładnie w tej przestrzeni AI jest coraz tańszą alternatywą. Ratuje cię to, czego modelowi brakuje: osadzenie w kontekście, zdolność zadawania niewygodnych pytań, wpływ na kształt produktu.
Strategia „uczę się frameworka X i jakoś to będzie”
Popularne podejście: wybrać framework, przejść kurs, wejść na rynek jako „junior X developer” i liczyć, że zapotrzebowanie utrzyma się latami. To strategia obarczona coraz większym ryzykiem.
Powód jest prosty: większość kursów uczy schematów. Dokładnie tych, które AI potrafi generować już dzisiaj. W efekcie rośnie liczba osób, które umieją to samo (sklejać CRUD-y, prosty frontend, podstawowe API), a jednocześnie rośnie wydajność narzędzi, które robią to szybciej.
Mit: „wystarczy dobrze znać framework i zawsze znajdzie się praca”. Rzeczywistość: frameworki się zmieniają, a to, co trwałe, to kompetencje ponad-technologiczne: rozumienie architektury, danych, domeny, komunikacji w zespole. Framework staje się wymienną częścią, nie fundamentem kariery.
„Niskokosztowe” role bez rozwoju
AI najmocniej uderza tam, gdzie praca jest jednocześnie powtarzalna i tania. Firmom łatwiej wtedy eksperymentować: „spróbujmy zastąpić 5 juniorów jednym seniorem z AI, zobaczymy, co się stanie”.
Jeśli jesteś zatrudniony głównie dlatego, że „opłaca się mieć kogoś taniego do dłubaniny”, a nie dlatego, że wnosić unikalną perspektywę czy odpowiedzialność, to tak naprawdę jesteś na tej samej pozycji co usługa w chmurze – łatwo wymienialny koszt.
Brzmi brutalnie, ale to dobry barometr: gdybyś zniknął z zespołu, czy ktoś musiałby zmienić sposób pracy, czy tylko „znaleźć tańszego zamiennika”? AI przyspiesza ten proces uświadamiania, że część zadań to wyłącznie koszt operacyjny, który można ściąć narzędziami.
Strategia rozwoju 2–3-letnia: jak ułożyć plan uczenia się z AI
Rok 1: oswojenie narzędzi i budowanie nawyków
Na pierwszym etapie celem nie jest „zostać ekspertem od AI”, ale włączyć ją w codzienną pracę tak, żeby realnie zwiększać swoją przepustowość i jakość.
Praktyczny zestaw działań na 6–12 miesięcy:
Codzienne używanie asystenta AI do kodu – nie tylko autouzupełnianie, ale świadome proszenie o refaktoryzację, testy, alternatywne implementacje. Chodzi o wyrobienie odruchu: najpierw proszę AI o wersję 0, potem ją poprawiam.
Systematyczne dokumentowanie promptów – prowadzenie prostego repo lub notatnika z „dobrymi rozmowami z AI”: jak pytasz o testy, jak o diagnozę błędów, jak o design API. Z czasem budujesz własną „książkę kucharską”.
Mini-projekty z AI w roli współautora – np. mały serwis, wewnętrzne narzędzie, skrypt do automatyzacji własnej pracy. Ważne, żeby przejść przez pełny cykl: od pomysłu, przez projekt, po wdrożenie i utrzymanie.
Podstawy teorii działania modeli – nie doktorat z ML, tylko zrozumienie: co to jest LLM, tokeny, kontekst, halucynacje, RAG, fine-tuning. To później porządkuje intuicję, czego można wymagać, a czego nie.
Na tym poziomie twoją przewagą jest nie to, że „znasz wszystkie modele”, ale że potrafisz szybko przekuć narzędzie w konkretny rezultat i unikasz typowych pułapek (bezrefleksyjne kopiowanie kodu, ufanie odpowiedziom bez weryfikacji).
Rok 2: pogłębianie specjalizacji i wejście w AI-enabled produkty
Po oswojeniu narzędzi sensownie jest wybrać kierunek, w którym AI stanie się naturalnym rozszerzeniem twojej specjalizacji, a nie osobnym „hobby”. Dla różnych profili może to wyglądać inaczej.
Dla backendowca lub full-stacka dobrym zestawem kroków będzie:
Nauka wzorców integracji z API modeli – obsługa strumieniowania odpowiedzi, retry, limitów, cache’owania wyników, zarządzania kosztami.
Praktyczny RAG – zbudowanie 1–2 prostych systemów wyszukiwania semantycznego i odpowiedzi na dokumentach (np. wewnętrzna dokumentacja, regulaminy, wiki zespołu).
Monitoring jakości odpowiedzi – wprowadzenie metryk: kiedy model się myli, kiedy jest za wolny, jak użytkownicy reagują na jego błędy.
Dla frontendowca lub UX-owca:
Projektowanie interfejsów konwersacyjnych – od prostych promptów „pod maską” po bardziej złożone przepływy, gdzie użytkownik może doprecyzować zamiary, wycofać się, zobaczyć źródła.
Testy z użytkownikami pod kątem zaufania do AI – krótkie badania: gdzie ludzie za bardzo wierzą odpowiedziom, a gdzie ignorują przydatne sugestie.
Współpraca z zespołami danych – zrozumienie, jakie dane można eksponować użytkownikowi, a jakie muszą zostać w tle.
Dla osób z zacięciem data/ML:
Wejście w MLOps / LLMOps – narzędzia do śledzenia wersji modeli, promptów, datasetów, monitoringu produkcyjnego.
Eksperymenty z fine-tuningiem – małe, ale konkretne case’y: dostosowanie modelu do specyficznego żargonu firmy czy typu dokumentów.
Bezpieczeństwo danych i compliance – dogłębne poznanie regulacji (RODO, branżowe normy) w kontekście trenowania i używania modeli.
Mit powtarzany w wielu dyskusjach: „trzeba szybko przebranżowić się na ML inżyniera, bo tam są pieniądze”. Rzeczywistość: rynek bardziej potrzebuje ludzi, którzy potrafią połączyć AI z istniejącymi systemami i procesami niż kolejnej fali osób, które znają tylko notebooki i trenowanie modeli z tutoriali.
Rok 3: budowanie przewagi poprzez odpowiedzialność i decyzje
Po dwóch latach sensownego korzystania z AI i integracji z produktami można celować wyżej niż „sprawny wykonawca”. Chodzi o przesunięcie się w stronę roli, która decyduje, jak AI jest używana w organizacji.
Elementy takiej ścieżki:
Współprojektowanie roadmapy AI w firmie – definiowanie, gdzie AI ma największy zwrot (np. automatyzacja wewnętrznych procesów, wsparcie sprzedaży, helpdesk), a gdzie lepiej jeszcze poczekać.
Tworzenie standardów i guardrails – spisane zasady korzystania z AI: jakie dane wolno wysyłać na zewnątrz, jak dokumentować użycie modeli, jak zabezpieczać systemy przed prompt injection.
Ocena „build vs buy” – kiedy warto korzystać z gotowych API, kiedy budować własną platformę, a kiedy… w ogóle nie używać AI, bo klasyczna automatyzacja jest prostsza i tańsza.
Mentoring i edukacja zespołu – dzielenie się sprawdzonymi wzorcami korzystania z AI, tworzenie wewnętrznych warsztatów, podczas których ludzie uczą się na realnych przykładach z waszego kodu i domeny.
Na tym poziomie twoją przewagą nie jest to, że „świetnie promptujesz”, tylko że rozumiesz całość: od technologii, przez dane, po ryzyko prawne i społeczne. AI staje się jednym z narzędzi w twoim zestawie do projektowania systemów i organizacji pracy.
Codzienne mikro-nawyki, które robią różnicę
Plan 2–3-letni brzmi poważnie, ale w praktyce wygrywają drobne nawyki utrzymywane miesiącami. Kilka prostych praktyk, które realnie podnoszą szanse, że za parę lat będziesz po „dobrej” stronie automatyzacji:
Raz w tygodniu testuj nowe zastosowanie AI – niekoniecznie nowy model, raczej nowy sposób użycia: generowanie migracji, dokumentacji, skryptów do analizy logów, raportów dla biznesu.
Porównuj swoje rozwiązania z propozycjami AI – najpierw projektujesz sam, potem prosisz model o alternatywę i analizujesz różnice. To szybka forma code review z „wirtualnym sparring partnerem”.
Logujesz, gdzie AI cię zawiodła – nie po to, żeby narzekać, tylko żeby zrozumieć wzorce: w jakich typach zadań model ewidentnie nie dowozi i tam świadomie nie próbować go „na siłę”.
Uczysz się komunikować decyzje wokół AI – tłumaczyć nietechnicznym ludziom, dlaczego coś nie powinno być zautomatyzowane, mimo że „AI umie pisać kod”. To jest mięsień, który bardzo szybko zyskuje na wartości.
Mit: „AI wymaga nagłego, drastycznego przebranżowienia”. Rzeczywistość: w większości przypadków wygrywa stopniowa ewolucja sposobu pracy i rozszerzanie istniejących kompetencji o nowe narzędzia, zamiast wyrzucania wszystkiego do kosza i zaczynania od zera.
Świadome wybieranie branży i domeny
Plan rozwoju to nie tylko technologie, ale także wybór kontekstu, w którym pracujesz. Dwie osoby z tym samym zestawem umiejętności technicznych mogą mieć zupełnie inne perspektywy, jeśli jedna siedzi w produkcie, gdzie 90% pracy to generowanie raportów z szablonów, a druga w skomplikowanej domenie, gdzie kluczowe są decyzje biznesowe podparte kodem.
Jeśli jesteś na etapie, gdy możesz wybierać projekty lub firmy, opłaca się zwrócić uwagę na kilka sygnałów:
Jaki procent pracy to powtarzalne „przepisywanie schematów”? Im więcej takiej roboty, tym większe ryzyko, że z czasem zostanie zautomatyzowana.
Czy w projekcie jest miejsce na decyzje i myślenie koncepcyjne? Spotkania projektowe, dyskusje o architekturze, rozmowy z biznesem – to wszystko są strefy, w których AI jest raczej wsparciem niż zamiennikiem.
Czy firma inwestuje w dane i infrastrukturę pod AI? Tam, gdzie dane są bałaganem, AI zwykle kończy jako gadżet. Tam, gdzie ktoś poważnie podchodzi do jakości danych, rośnie zapotrzebowanie na ludzi, którzy to potrafią ogarnąć.
Zmiana projektu czy firmy to często najszybszy „skok jakości” w planie 2–3-letnim – łatwiej wejść w zdrowe środowisko, niż samotnie ciągnąć cały wózek transformacji AI w miejscu, które nie jest na to gotowe.
Opracowano na podstawie
The Future of Jobs Report 2023. World Economic Forum (2023) – Prognozy wpływu automatyzacji i AI na zawody, w tym IT
Generative AI and the Future of Work in America. McKinsey Global Institute (2023) – Analiza wpływu generatywnej AI na produktywność i strukturę pracy
GitHub Copilot Research: Quantifying AI’s Impact on Developer Productivity. GitHub (2022) – Badanie wpływu GitHub Copilot na szybkość i sposób pracy programistów
