Scenka otwierająca: gdy junior widzi, że „AI pisze za niego kod”
Wyobraź sobie junior developera, który pierwszego dnia pracy dostaje od team leada polecenie: „Od dziś piszesz wszystko z Copilotem. Zacznij od skonfigurowania sobie środowiska z asystentem AI”. Zamiast ekscytacji pojawia się lekki strach – skoro narzędzie przewiduje i uzupełnia większość linii, to po co w ogóle ta cała nauka programowania?
Po drugiej stronie open space’u siedzi architekt z dziesięcioletnim stażem. Dla niego AI w IDE to wybawienie: przestaje tracić czas na boilerplate’y, ma więcej przestrzeni na myślenie o architekturze, bezpieczeństwie, długie rozmowy z biznesem. Junior widzi, jak jego zadania „znikają”, architekt widzi, jak jego praca staje się bardziej strategiczna.
Ten rozdźwięk dobrze pokazuje, co faktycznie dzieje się na rynku pracy w IT. Sztuczna inteligencja nie „zjada programistów” jako jednolitej grupy. Przesuwa środek ciężkości kompetencji: od klepania powtarzalnego kodu do projektowania rozwiązań, rozumienia systemów, zadawania właściwych pytań i łączenia klocków – w tym klocka o nazwie „AI”.
Zmiana rozgrywa się na kilku osiach jednocześnie: pojawiają się nowe role, część starych zanika albo kurczy się do nisz, rosną inne typy umiejętności (techniczne i miękkie), a w codziennej pracy developera, testera czy DevOpsa generatywne modele stają się narzędziem równie oczywistym, jak Git. Kto nauczy się wykorzystywać AI do wzmacniania swoich decyzji i kodu, ten buduje przewagę. Kto zostanie na etapie „boję się, że mnie zastąpi” – ten ryzykuje, że wizja sama się spełni.
Jak AI realnie wchodzi do IT: od hype’u do codziennych narzędzi
Proste uporządkowanie pojęć: klasyczne ML, generatywna AI i modele językowe
Słowo „sztuczna inteligencja” bywa wrzucane do jednego worka, ale w codziennej pracy IT mamy do czynienia z kilkoma różnymi klasami rozwiązań. Zrozumienie, co jest czym, pomaga lepiej planować własne kompetencje i projekty.
Klasyczne uczenie maszynowe (ML) to modele, które przewidują liczby lub kategorie na bazie danych. W IT pojawia się to m.in. w systemach rekomendacji (np. sugerowanie ticketów w Jirze do konkretnego zespołu), w systemach antyfraudowych czy mechanizmach przewidywania obciążenia serwerów. Dla developera oznacza to np. integrację gotowego modelu przez API, a dla DevOpsa – uwzględnienie tych przewidywań w autoskalowaniu.
Generatywna sztuczna inteligencja (generative AI) to modele, które potrafią tworzyć nową treść: tekst, obraz, kod, a nawet dźwięk. Modele językowe, takie jak GPT, Claude czy Llama, stały się już pierwszą linią wsparcia przy:
- generowaniu szkiców kodu i testów,
- pisaniu dokumentacji technicznej,
- tłumaczeniu z jednego języka programowania na inny,
- tworzeniu scenariuszy testowych czy skryptów migracyjnych.
Systemy rekomendacyjne i predykcyjne to często mieszanina klasycznego ML i reguł biznesowych. W zespołach IT przejawiają się np. jako podpowiedzi w IDE (jak Copilot), inteligentne podpowiedzi konfigów w narzędziach CI/CD czy elastyczne alerty w monitoringach, oparte na anomaliach, a nie sztywnych progach.
Konkretne narzędzia AI w IT, które naprawdę zmieniają dzień pracy
Większość firm technologicznych nie trenuje własnych modeli od zera. Korzystają z gotowych usług i produktów, które wchodzą w dotychczasowe narzędzia. Kilka grup rozwiązań szczególnie mocno wpływa na role w IT:
- Asystenci kodu: GitHub Copilot, Amazon CodeWhisperer, TabNine, Codeium. Podpowiadają kod w IDE, generują funkcje, piszą testy jednostkowe, sugerują refaktoryzacje.
- Chatboty generatywne: ChatGPT, Claude i inne interfejsy do LLM – używane jako „superwyszukiwarka” i „drugi mózg” do rozwiązywania problemów technicznych, tłumaczenia dokumentacji, generowania skryptów.
- AI w code review: narzędzia potrafią zrobić wstępny code review, wyłapać typowe błędy, zasugerować poprawki stylu i bezpieczeństwa.
- AI w CI/CD i DevOps: systemy do przewidywania awarii, analiza logów pod kątem anomalii, proponowanie zmian w konfiguracjach Kubernetes, optymalizacja kosztów w chmurze.
- AI w QA: generowanie przypadków testowych, automatyczne tworzenie skryptów do Selenium/Cypress, analizowanie logów z testów, wykrywanie regresji na podstawie zachowań użytkowników.
Dla programisty oznacza to, że coraz rzadziej zaczyna od pustego pliku. Dla testera – że coraz więcej czasu poświęca na projektowanie scenariuszy, a mniej na klikanie. Dla DevOpsa – że zamiast śledzić dziesiątki dashboardów, dostaje skondensowane sugestie, co może pójść źle.
Obszary, gdzie sztuczna inteligencja już zmieniła workflow w IT
Współpraca człowiek–AI nie jest już teoretycznym hasłem. Widać ją na każdym etapie cyklu życia oprogramowania.
Development: generowanie boilerplate’ów, tworzenie adapterów, konwersja starych modułów, dopisywanie logowania i obsługi błędów. AI świetnie radzi sobie z powtarzalnym, mało kreatywnym kodem, który wcześniej zajmował juniorów przez długie dni.
Testy i QA: automatyczne rozpoznawanie elementów na stronie przy testach end-to-end, generowanie danych testowych, analiza różnic między wersjami aplikacji pod kątem ryzyka regresji. Tester przesuwa się w stronę projektanta scenariuszy i „adwokata użytkownika”, a nie osoby „od klikania”.
DevOps i SRE: modele analizujące logi, metryki i trace’y pod kątem anomalii; narzędzia sugerujące zmiany w konfiguracji autoskalowania; systemy przewidujące, kiedy należy wykonać maintenance. Zespół nie patrzy już wyłącznie w wykresy, ale rozmawia z AI jak z kolegą od monitoringu: „pokaż mi, co się działo tuż przed skokiem latency”.
Support i helpdesk: chatboty rozwiązują prostsze zgłoszenia, triage ticketów odbywa się automatycznie, pierwsza linia wsparcia w wielu firmach stała się mieszanką ludzi i AI. Zespół supportu zajmuje się trudnymi przypadkami, eskalacjami, integracją z biznesem.
Analityka i BI: generowanie zapytań SQL na podstawie pytań w języku naturalnym, automatyczne tworzenie dashboardów, AI do czyszczenia danych. Analityk bardziej pilnuje poprawnego modelu biznesowego niż samego „klepania zapytań”.
Jak rozpoznać, że AI stała się standardem, a nie gadżetem
W wielu organizacjach AI jest jeszcze „zabawką”: kilku entuzjastów bawi się ChatGPT, ktoś wprowadził Copilota „do przetestowania”. W innych – to już niepisany standard wpisany w proces. Różnica dla pracowników IT jest ogromna.
Organizację z dojrzałym podejściem do AI rozpoznasz po kilku sygnałach:
- są spisane zasady korzystania z AI (co wolno wrzucać, czego nie, kwestie RODO, tajemnicy przedsiębiorstwa),
- narzędzia AI są zintegrowane z pipeline’em (CI/CD, monitoring, repozytoria), a nie używane „po cichu”,
- bezpieczeństwo i compliance mają swoje zdanie o AI, a nie udają, że temat nie istnieje,
- szkolenia z AI są częścią rozwoju pracowników, zamiast zostawiać ich z hasłem „radźcie sobie sami”.
W takim środowisku umiejętność pracy z AI jest traktowana jak każda inna kompetencja techniczna. To dobry znak dla kariery: można się jej nauczyć, jest mierzalna i doceniana.
Zmieniające się role w IT: co wygasa, co rośnie, co się przekształca
Funkcje o wysokim ryzyku automatyzacji w świecie AI
Niektóre zadania w IT szczególnie mocno nadają się do automatyzacji. To głównie prace powtarzalne, dobrze opisane regułami, powtarzające się w tysiącach podobnych wariantów.
Proste kodowanie CRUD (formularze, walidacje, podstawowe operacje na bazie) to klasyczny przykład. Generatywna AI radzi sobie z tym świetnie, często lepiej niż początkujący developer. Jeśli ktoś przez kilka lat robi wyłącznie takie projekty, bez rozwijania architektury czy rozumienia domeny, jego pozycja na rynku staje się krucha.
Ręczne testy bez automatyzacji, polegające na odhaczaniu check-listy w aplikacji webowej lub mobilnej, to kolejne zagrożone pole. AI potrafi generować skrypty, adaptować je do zmian UI, a także wykonywać testy wizualne. Tester, który nie wejdzie w automatyzację, projektowanie testów, analizę ryzyka, będzie miał coraz mniej ofert.
Powtarzalny support pierwszej linii – reset haseł, standardowe instrukcje, odpowiadanie na najczęstsze pytania – w dużej części przenosi się do chatbotów i samoobsługowych portali. Zespół helpdesk przesuwa się w kierunku rozwiązywania złożonych problemów i koordynowania automatyzacji, zamiast wykonywania prostych działań.
Klasyczne role, które przekształcają się w „AI-augmented”
Znacznie ciekawszy niż znikające stanowiska jest jednak obszar ról, które zmieniają swój charakter. To tam powstają najciekawsze ścieżki kariery.
Developer w świecie AI przestaje być tylko „twórcą kodu”. Staje się projektantem rozwiązań, operatorem modeli, osobą odpowiedzialną za jakość promptów i integrację AI z istniejącą architekturą. Więcej czasu spędza na czytaniu, recenzowaniu i refaktoryzacji kodu generowanego przez narzędzia, a mniej na pisaniu prostych funkcji od zera.
Tester / QA engineer coraz częściej pracuje jako „AI QA specialist”: wykorzystuje narzędzia AI do generowania setów testowych, testów mutacyjnych, analizowania pokrycia. Zaczyna rozumieć sposób działania modeli, ich typowe błędy, sposoby testowania systemów, które nigdy dwa razy nie zachowują się identycznie.
Analityk biznesowy / product owner ma dostęp do AI, która potrafi analizować feedback użytkowników, zgłoszenia z supportu, dane z logów. Dzięki temu może lepiej uzasadniać priorytety, projektować funkcje z myślą o integracji z AI i świadomie zarządzać oczekiwaniami biznesu: gdzie AI się sprawdzi, a gdzie nie.
DevOps / SRE staje się opiekunem nie tylko klastra Kubernetes, ale i pipeline’ów MLOps: monitoruje wydajność modeli, dba o retraining, kontroluje koszty zapytań do API modeli, pilnuje zgodności z politykami bezpieczeństwa.
Nowe i rosnące role w ekosystemie IT związane z AI
Wraz z dojrzewaniem rynku pojawiły się nowe specjalizacje. Część z nich brzmi dziś modnie, ale kryje się pod nimi realny zakres obowiązków.
- Prompt engineer – osoba specjalizująca się w projektowaniu promptów i interakcji z modelami generatywnymi. W praktyce często łączy kompetencje analityka, developera i UX-owca: projektuje, jak użytkownik rozmawia z AI, jak wygląda kontekst, jakie są ograniczenia i zabezpieczenia.
- ML engineer – łączy świat data science z inżynierią oprogramowania. Odpowiada za trening, wdrażanie i utrzymanie modeli, optymalizację infrastruktury, integrację z systemami produkcyjnymi.
- MLOps engineer – specjalista od „DevOps dla modeli ML”: zarządza pipeline’ami trenowania, wersjonowaniem modeli i danych, monitorowaniem jakości predykcji.
- AI product owner / AI product manager – prowadzi produkty oparte na AI, rozumie możliwości i ograniczenia modeli, potrafi dobrać use case’y i zbudować roadmapę, która ma sens biznesowy.
- AI ethic specialist / responsible AI officer – zajmuje się kwestiami uprzedzeń w danych, przejrzystością decyzji, zgodnością z regulacjami (jak AI Act), komunikacją z użytkownikami, gdy AI podejmuje istotne decyzje.
- Data steward – opiekun danych w organizacji: dba o jakość, spójność, sposób oznaczania, zasady dostępu. Kluczowy, gdy dane stają się paliwem dla wielu modeli.
- AI evangelist / AI champion – rola często nieformalna, ale coraz częściej spisywana: osoba, która wdraża zespół w narzędzia AI, robi wewnętrzne warsztaty, zbiera dobre praktyki i rozkleja je po organizacji.
Przykład firmowej transformacji: mniej manual testerów, więcej „AI QA specialist”
W jednej z polskich firm produktowych zespół QA liczył kilkanaście osób, głównie manual testerów, którzy ręcznie sprawdzali scenariusze w aplikacji webowej. Po wejściu nowych funkcjonalności i rosnącej presji na szybsze releasy zarząd zdecydował, że potrzebna jest mocna automatyzacja. Zespół wdrożył narzędzia AI do generowania skryptów testowych i analizy regresji.
W ciągu kilkunastu miesięcy:
- część prostych testów regresyjnych została w pełni zautomatyzowana, a ich projektowaniem zajęły się narzędzia AI wspierane przez dwóch doświadczonych QA,
- kilku manual testerów przebranżowiło się wewnętrznie na role „AI QA specialist” – zaczęli projektować scenariusze, nadzorować generowane testy i analizować wyniki, zamiast klikać po interfejsie,
- nowe osoby do zespołu rekrutowano już z myślą o pracy z AI: wymagano znajomości narzędzi do automatyzacji i podstaw programowania, a nie tylko doświadczenia w ręcznym testowaniu.
Nie obyło się bez trudnych momentów. Kilka osób uświadomiło sobie, że nie chce iść w stronę automatyzacji ani pracy z kodem – dla nich firma zaproponowała inne ścieżki, np. wsparcie użytkowników czy dokumentację. Z kolei ci, którzy „weszli w AI”, po kilku miesiącach byli w stanie samodzielnie projektować strategie testów dla nowych modułów i współdecydowali o tym, kiedy produkt jest gotowy do releasu.
Ciekawa zmiana zaszła też w relacji z developerami. Zamiast wysyłać długie listy bugów, QA potrafili podeprzeć się raportami wygenerowanymi przez narzędzia AI: heatmapy ryzyka, analizę miejsc w kodzie najczęściej dotykanych przez regresję, hipotezy przyczyn. Rozmowy na refinementach przestały się kręcić wokół tego, „czy zdążymy wszystko przetestować”, a bardziej wokół tego, „jak zaprojektować feature, żeby był testowalny i dobrze obsługiwany przez automaty”.
Po roku zarząd nie mówił już o „projekcie AI w QA”, tylko o nowym standardzie pracy. Manualne testy zostały tam, gdzie naprawdę miały sens: w eksploracji, testowaniu edge-case’ów, pracy na nieoczywistych scenariuszach użytkownika. Cała reszta była w dużej mierze obsługiwana przez połączenie frameworków testowych i modeli generatywnych, które QA traktowali jak codzienne narzędzie, a nie magiczną nowinkę.
Jak reagować na „AI zabierze mi pracę”: trzy typowe strategie
Na wewnętrznym czacie firmowym ktoś wrzuca filmik, jak Copilot w minutę generuje cały kontroler. Kilku juniorów zaczyna żartować, że „to koniec programistów”, ale po chwili śmiech cichnie i pojawia się pytanie: to co my tu właściwie jeszcze robimy? Team lead widzi, że jeśli teraz nie poprowadzi rozmowy, strach sam sobie dopisze resztę historii.
Reakcje na AI w zespole zwykle mieszczą się w trzech wzorcach.
- Ignorowanie: „To moda, zaraz przejdzie” – osoby w tym trybie nadal robią wszystko ręcznie, unikają nowych narzędzi i po roku nagle odkrywają, że ich skillset jest „sprzed AI”.
- Panikowanie: ciągłe śledzenie newsów, kurs za kursem, skakanie po narzędziach, ale bez realnej zmiany sposobu pracy. Dużo hałasu, mało efektu.
- Świadome oswajanie: spokojne eksperymenty, wybranie paru procesów do usprawnienia, liczenie zysków i strat, poprawianie nawyków. Z zewnątrz wygląda to wręcz nudnie, ale po kilkunastu miesiącach te osoby są „tymi od AI”, choć nie spędziły ani godziny na panice.
Różnicę robi nie deklaracja „interesuję się AI”, tylko to, jak często realnie używasz narzędzi i czy przekładasz efekty na decyzje zawodowe: jakiej technologii się uczysz, w jakie projekty się włączasz, jak rozmawiasz z przełożonym o celach.
Kluczowe kompetencje techniczne w erze AI: co naprawdę ma znaczenie
Głębokie rozumienie fundamentów zamiast pamięciówki z frameworków
Junior, który dotąd szlifował głównie „stack X + framework Y”, nagle widzi, że model generatywny pisze kod w tym samym frameworku, często szybciej i bez googlowania. Różnica nie polega już na tym, kto szybciej klepie funkcje, tylko kto rozumie, dlaczego ten kod ma taki kształt.
Fundamenty stają się mocną walutą:
- architektura systemów – wzorce architektoniczne, granice kontekstów, podział na serwisy, integracje; AI pomoże napisać kod w mikroserwisie, ale nie zdecyduje, czy mikroserwis ma sens w danym przypadku,
- paradygmaty programowania – obiektowe, funkcyjne, reaktywne; świadomość ich plusów i minusów pozwala tak prowadzić AI, by generowała kod spójny z resztą systemu,
- złożoność i algorytmy – nie chodzi o pamięciowe wkuwanie struktur danych pod rekrutacje, ale o praktyczne czucie: kiedy prosty algorytm jest „wystarczająco dobry”, a kiedy generowany kod wymaga optymalizacji.
Im lepiej rozumiesz fundamenty, tym częściej używasz AI jak asystenta, a nie jak orakla. Zadajesz lepsze pytania i szybciej wyłapujesz nonsensy w odpowiedziach.
Praca z kodem, który nie jest „twój”
W jednej z ekip backendowych wprowadzono zasadę, że większość nowych funkcji powstaje w parach: człowiek + AI. Po dwóch sprintach okazało się, że problemem nie jest samo generowanie kodu, tylko to, co dzieje się potem – utrzymanie i zrozumienie fragmentów napisanych „wczoraj przez model”.
Kluczowe stają się umiejętności:
- czytania i diagnozowania cudzego kodu – code review, szybkie ogarnianie flow, rozumienie, gdzie włożyć logowanie czy guardy,
- projektowania czytelnych interfejsów – tak, by nawet jeśli wnętrze funkcji jest w 80% wygenerowane, interfejs modułu został świadomie zaprojektowany przez człowieka,
- refaktoryzacji – rozbijanie „zup kodu” od AI na sensowne komponenty, usuwanie duplikacji, porządkowanie nazewnictwa.
Developer, który umie układać i upraszczać kod, będzie miał pracę również wtedy, gdy połowa plików w repo powstanie z pomocą modeli.
AI‑native debugging: diagnoza z asystentem, ale na twoich zasadach
Coraz więcej IDE pozwala zaznaczyć fragment kodu, kliknąć „Explain” i dostać opis działania lub propozycję poprawki. Kuszące jest przyjąć każde rozwiązanie „bo AI tak powiedziała”. To krótkotrwałe przyspieszenie, które potem mści się w produkcji.
Zdrowy workflow wygląda inaczej:
- Samemu formułujesz hipotezę: co może być przyczyną błędu, gdzie warto zajrzeć w logi, jakie dodasz asercje.
- Prosisz AI o weryfikację lub alternatywy, a nie o „magiczne rozwiązanie”.
- Testujesz kilka scenariuszy, patrzysz na efekty uboczne zmian, dopiero potem mergujesz.
Debugging w erze AI to umiejętność prowadzenia dialogu z narzędziem: „Sprawdź mój tok rozumowania”, „Zaproponuj inny sposób logowania”, „Pomóż mi prześledzić przepływ danych przez te serwisy”. To nadal ty jesteś osobą, która stwierdza, że błąd faktycznie został usunięty.
Inżynieria promptów dla deweloperów, a nie poetów
Prompt engineering często kojarzy się z wymyślaniem kreatywnych formułek. W praktyce w IT przypomina raczej projektowanie API: określenie kontraktu, kontekstu i oczekiwanego formatu wyjścia.
Dla programisty przydatne są przede wszystkim trzy umiejętności:
- precyzyjne definiowanie zadania – zamiast „napisz mi funkcję do walidacji formularza” raczej „wygeneruj funkcję walidującą te pola, z tymi zasadami, w tym frameworku, z uwzględnieniem i18n, bez logiki UI”,
- utrzymywanie kontekstu – doklejanie do promptu fragmentów kodu, kontraktów API, przykładów wejścia/wyjścia, zamiast liczenia na to, że model „się domyśli”,
- systematyczne iterowanie – traktowanie promptu jak kodu: poprawiasz go na podstawie wyników, trzymasz wersje, dzielisz się szablonami z zespołem.
W wielu firmach wygrywają nie ci, którzy „znają AI”, tylko ci, którzy mają kilka dobrych, sprawdzonych promptów do powtarzalnych zadań: generowania testów, migracji schema, pisania skryptów do ETL.
W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: Sztuczna inteligencja w antywirusach: jak nowa technologia wykrywa zagrożenia.
Bezpieczeństwo i prywatność w świecie „wszechobecnej” AI
Programista, który bezrefleksyjnie wrzuca do modelu fragmenty produkcyjnego kodu, dane klientów czy klucze API, prędzej czy później wyląduje na rozmowie z działem bezpieczeństwa. Integracja AI z procesem wytwórczym oznacza też nowe obowiązki techniczne.
Przydają się szczególnie:
- podstawy secure codingu – świadomość OWASP Top 10, typowych wektorów ataków, błędów uprawnień; AI potrafi podpowiedzieć, jak coś zabezpieczyć, ale równie chętnie proponuje nieaktualne lub naiwne rozwiązania,
- rozumienie polityk danych – co wolno wysłać do zewnętrznego API, jakie trzeba zastosować anonimizacje, kiedy trzeba używać modeli on-premise,
- praca z logowaniem i audytem – projektowanie systemów tak, by decyzje AI dało się prześledzić: requesty, odpowiedzi, wersje modeli, parametry.
Jeśli umiesz połączyć wykorzystanie AI z wymaganiami działu bezpieczeństwa i compliance, szybko stajesz się osobą „odpowiedzialną za bezpieczne AI” w zespole – a to rzadkie i cenne połączenie.
Kompetencje miękkie i meta‑umiejętności, których AI nie przejmuje
Decyzyjność i branie odpowiedzialności za rezultat
Team lead na daily słyszy: „AI wygenerowała ten algorytm, więc go wdrożyliśmy”. Po tygodniu okazuje się, że część zamówień zniknęła z kolejki, bo model źle obsłużył edge-case. Nikt nie czuje się winny, bo „to przecież AI tak zrobiła”.
AI nie ma pojęcia o SLA, karach umownych ani reputacji produktu. Ktoś musi podjąć decyzję: „Tak, ten kod jest wystarczająco dobry, żeby trafić na produkcję”. To wciąż człowiek:
- negocjuje zakres feature’a z biznesem,
- decyduje, kiedy „done” faktycznie znaczy „gotowe do użytkowania”,
- bierze na siebie tłumaczenie, dlaczego nastąpiła awaria i co zrobiono, by się nie powtórzyła.
Umiejętność przyznania „to była moja decyzja, poprawimy proces tak i tak” jest trudna do zastąpienia jakimkolwiek modelem.
Komunikacja techniczna: tłumaczenie między światami
W projektach AI pojawia się nowy rodzaj rozmów: diffy konfiguracji modeli, dyskusje o jakości danych, ryzyku halucynacji. Biznes często słyszy to wszystko jako „nowe, dziwne słowa”. Ktoś musi przełożyć je na język decyzji: terminy, budżety, kompromisy.
Przydają się kompetencje:
- upraszczania złożonych tematów – „Model nie ma wystarczająco przykładów takich zgłoszeń, więc pomyli je z innymi – potrzebujemy miesiąca na zebranie lepszych danych”,
- stawiania granic – „Nie, AI nie zastąpi jeszcze całego działu supportu, ale może przejąć tę konkretną kategorię zgłoszeń”,
- facylitacji dyskusji – prowadzenia spotkań, gdzie przy jednym stole siedzi prawnik, product manager, inżynier ML i designer.
Im więcej AI w produkcie, tym częściej pojawiają się