Punkt wyjścia – jak wygląda dzisiejszy rozwój oprogramowania z AI i bez AI
Typowy cykl SDLC w praktyce zespołu developerskiego
Cykl życia oprogramowania w większości firm wygląda podobnie, niezależnie od branży. Najczęściej mamy wariant zwinny, oparty o sprinty, a w środku wciąż te same etapy: analiza wymagań, projekt rozwiązania, implementacja, testowanie, wdrożenie i utrzymanie. Różnice wynikają głównie ze skali i dojrzałości procesów, a nie z samej struktury prac.
W klasycznym podejściu bez wsparcia AI generatywnej większość czasu zabiera implementacja – pisanie kodu, klejenie integracji, obsługa edge-case’ów. Dużo energii idzie także w ręczne testowanie, pisanie testów automatycznych i aktualizację dokumentacji, która niemal zawsze odstaje od stanu faktycznego.
W wielu zespołach analiza wymagań jest skrócona do minimum: kilka historyjek w Jirze, parę spotkań z biznesem, trochę komentarzy w Confluence. Brakuje spójnego przełożenia wymagań na architekturę i decyzje techniczne. Efekt: ciągły dług technologiczny, poprawki w trakcie sprintu i spora ilość „gaszenia pożarów”.
Gdzie już dziś generatywna AI realnie pomaga
W ciągu ostatnich dwóch lat generatywna AI mocno weszła do codziennej pracy programistów. Narzędzia takie jak GitHub Copilot, ChatGPT, Codeium czy Tabnine wspierają pisanie kodu, proponują całe funkcje, klasy, a nawet gotowe testy. Różnica w produktywności przy codziennych zadaniach jest widoczna nawet po tygodniu pracy z takim narzędziem.
Typowe zastosowania obecnie to:
uzupełnianie kodu na podstawie komentarzy i istniejących fragmentów (AI pair programming na poziomie IDE),
generowanie testów jednostkowych dla istniejących funkcji,
przepisanie kodu z jednego frameworka do innego (np. z Express na Fastify),
tłumaczenie kodu między językami (np. z Pythona na Go),
Coraz więcej narzędzi wspiera także testowanie i utrzymanie. Pojawiają się asystenci, którzy analizują logi, proponują potencjalne przyczyny błędów, generują skrypty naprawcze czy migracje baz danych. W środowiskach CI/CD AI może sugerować poprawki na poziomie PR, wskazywać smelly code, a nawet automatycznie odrzucać niebezpieczne zmiany.
Ograniczenia obecnego podejścia z AI
Obecna generatywna AI pracuje w ograniczonym kontekście. Model widzi fragment pliku, czasem kilka plików, ale nie pełen system i całą historię decyzji architektonicznych. Brakuje mu też zrozumienia domeny biznesowej – wie, „jak zazwyczaj pisze się taki kod”, ale nie „co jest ważne dla tego konkretnego klienta”.
Najczęstsze problemy to:
halucynacje – AI wymyśla nieistniejące funkcje, biblioteki czy endpointy API, które „brzmią sensownie”, ale nie mają pokrycia w kodzie,
brak świadomości bezpieczeństwa – generowanie kodu z podatnościami typu SQL injection, XSS, brak walidacji inputu,
brak spójności architektonicznej – AI generuje rozwiązania niepasujące do wzorców domenowych w systemie,
kopiowanie błędnych wzorców – model bazuje na danych treningowych, gdzie sporo kodu jest po prostu słabej jakości.
Dodatkowo pojawia się warstwa prawna i compliance: część firm blokuje wysyłanie kodu do chmury, bo obawia się wycieku IP. Dochodzą kwestie licencji kodu generowanego przez model oraz zgodności z regulacjami (np. RODO, regulacje branżowe). To wszystko ogranicza możliwość pełnego zaufania do AI w procesie wytwarzania.
Jak AI już teraz zmienia role w zespole
Dla juniorów generatywna AI jest zarówno szansą, jak i ryzykiem. Z jednej strony mogą szybciej pisać działający kod i uczyć się z przykładów generowanych na bieżąco. Z drugiej – grozi im, że staną się tylko „operatorami Copilota”, bez realnego zrozumienia, co się dzieje pod spodem. Bez mentora i dobrej kultury code review łatwo wpaść w pułapkę bezrefleksyjnego klepania promptów.
Dla midów AI to przyspieszacz rutyny: mniej czasu na boilerplate, więcej na rozwiązywanie złożonych problemów. Seniorzy i architekci zaczynają natomiast używać AI do szybkiego prototypowania wariantów architektonicznych, generowania spike’ów technicznych czy porównywania podejść. Coraz częściej rola seniora to „kierownik jakości konwersacji z AI”: ustawia standardy, jak używać narzędzi, czego nie akceptować i gdzie zawsze wymagana jest manualna weryfikacja.
Czym faktycznie jest AI generatywna w kontekście developmentu
Modele LLM w praktyce programisty
Modele językowe (LLM) to algorytmy, które uczą się przewidywać kolejne tokeny (fragmenty tekstu lub kodu) na podstawie poprzedniego kontekstu. Z punktu widzenia developera nie trzeba znać szczegółów matematyki ani architektury transformera. Wystarczy rozumieć, że to statystyczny model przewidujący „co tu zwykle występuje” w podobnych sytuacjach.
W kontekście kodu działa to podobnie jak autouzupełnianie w IDE, ale na sterydach. Model był trenowany na ogromnej ilości publicznego kodu, dokumentacji i tekstu, więc zna typowe wzorce: jak wygląda kontroler w Springu, jak napisać prosty handler w AWS Lambda, jak skleić zapytanie SQL czy napisać test w Playwright. Gdy dostaje fragment kodu, dopowiada resztę na podstawie tego, co najczęściej widział.
Kluczowe jest zrozumienie, że model nie „rozumie” problemu jak człowiek. Nie ma świadomości, nie ma intencji, nie dba o Twój budżet czy SLA. Ma tylko jedno zadanie: wygenerować najbardziej prawdopodobną kontynuację sekwencji. Cała magia i cała pułapka generatywnej AI w programowaniu bierze się z tego prostego faktu.
Autocomplete na sterydach vs realne rozwiązywanie problemów
AI generatywna dla kodu często bywa opisywana jako „autocomplete na sterydach”. To dobre porównanie na start, ale za mało, jeśli chcemy poważnie wykorzystywać ją w developmentcie. Autocomplete uzupełnia fragmenty, AI potrafi zaproponować całe podejście do problemu: strukturę modułów, podział na warstwy, zestaw wzorców projektowych.
Różnica ujawnia się przy zadaniach koncepcyjnych. Gdy opiszesz w promptcie wymagania biznesowe, ograniczenia i istniejącą architekturę, model może zasugerować kilka scenariuszy implementacji, wypunktować plusy i minusy, podsunąć gotowe „szkielety” kodu. To nie jest już tylko dokańczanie linii, ale udział w procesie projektowym.
Jednocześnie nie wolno zapominać, że model nie ma realnej wiedzy o kontekście firmy: nie zna Waszych priorytetów, nie wie, że bezpieczeństwo jest ważniejsze niż szybkość, albo że macie zespół z konkretnymi kompetencjami. Bez Twojego filtra i decyzji AI może produkować efektowne, ale kompletnie nietrafione rozwiązania.
Zadania, w których AI generatywna już dziś jest mocna
Patrząc na codzienną praktykę zespołów developerskich, generatywna AI sprawdza się szczególnie dobrze w kilku typach aktywności:
generowanie kodu szablonowego – klasy DTO, mappingi, powtarzalne endpointy CRUD, konfiguracja frameworków,
tworzenie testów – jednostkowych i prostych integracyjnych, opartych na istniejących funkcjach i klasach,
refactoring stylistyczny – zmiana stylu kodu, porządki według ustalonego style guide, usuwanie oczywistych antywzorców,
tłumaczenie między językami i frameworkami – przy zachowaniu struktury, ale z dostosowaniem do idiomów nowej technologii,
generowanie przykładowych danych – seedy do baz, fikcyjne JSON-y testowe, pliki konfiguracyjne.
W takich zadaniach programista często tracił długie godziny na monotonną pracę. AI w naturalny sposób przejmuje ten ciężar, a człowiek może skupić się na bardziej wymagających fragmentach: logice domenowej, aspektach niefunkcjonalnych, rozmowach z biznesem.
Obszary, gdzie AI nadal zawodzi
Z drugiej strony są zadania, które w najbliższych 5 latach nadal będą mocno ludzkie. Złożona logika domenowa, negocjowanie kompromisów między wymaganiami, decyzje architektoniczne – tutaj AI jest raczej „konsultantem pomocniczym” niż partnerem decyzyjnym.
Przykładowe problemy:
złożone reguły biznesowe – systemy billingowe, rozliczenia podatkowe, skomplikowane workflow w korporacjach; AI szybko generuje kod, ale łatwo gubi niuanse,
projektowanie architektury rozproszonej – wybór stylu (monolit vs mikroserwisy vs modulith), rozkład odpowiedzialności, strategia komunikacji,
kompromisy niefunkcjonalne – jak pogodzić wydajność z bezpieczeństwem, prostotę z elastycznością, tanie wdrożenie z łatwą eksploatacją,
praca z niejednoznacznymi wymaganiami – sytuacje, gdy klient sam nie wie czego chce, a trzeba mu pomóc to nazwać i ustrukturyzować.
Generatywna AI często tworzy „idealny” kod dla abstrakcyjnego scenariusza, który nie pasuje do realnego biznesu. W tym miejscu rola doświadczonego developera lub architekta jest nie do zastąpienia – i w perspektywie 5 lat nie widać przełomu, który by to zmienił.
Najbliższe 5 lat – realistyczne scenariusze zmian w procesie wytwórczym
Od narzędzia wspomagającego do współautora w pipeline’ach
W horyzoncie pięciu lat generatywna AI najprawdopodobniej przejdzie drogę od „dodatku w IDE” do pełnoprawnego uczestnika pipeline’ów CI/CD. Dziś korzystamy z niej głównie podczas pisania kodu. Za kilka lat będzie obecna na każdym etapie – od analizy wymagań, przez implementację, aż po monitoring produkcji.
Warto też podejrzeć, jak ten temat rozwija więcej o Informatyka — znajdziesz tam więcej inspiracji i praktycznych wskazówek.
Można spodziewać się, że narzędzia AI będą:
automatycznie analizować pull requesty, proponować poprawki i odrzucać zmiany łamiące standardy,
generować testy na podstawie historii błędów i logów produkcyjnych,
wykrywać regresje nie tylko na poziomie testów, ale także metryk biznesowych,
wspierać migracje technologiczne (np. przesiadki na nowe wersje frameworków).
Rola narzędzi CI/CD przestanie ograniczać się do odpalania skryptów i raportowania statusu. Pipeline stanie się miejscem, w którym AI podejmuje część decyzji operacyjnych, a człowiek definiuje zasady gry i kontroluje wyjątki.
Jak zmieni się struktura sprintu i pracy w zespole
Obecnie w typowym sprincie duża część zadań to ręczna „rzeźba”: implementacja, pisanie testów, dostosowywanie do istniejącej architektury. Przy szerokim wykorzystaniu AI generatywnej rozkład pracy przesunie się w stronę projektowania rozwiązań, weryfikacji i integracji.
Można oczekiwać, że w sprintach pojawi się więcej zadań typu:
definicja wymagań wraz z przykładami (user stories wzbogacone o scenariusze, dane wejściowe i oczekiwane outputy),
projektowanie kontraktów API i modeli danych,
przegląd i dostosowanie kodu generowanego przez AI,
konfiguracja i trenowanie wewnętrznych asystentów (np. modelu znającego domenę firmy).
Część zadań implementacyjnych zostanie skondensowana: zamiast trzech tasków (implementacja, testy, dokumentacja) będziesz mieć jeden task „zaprojektuj, zweryfikuj i zintegrowany feature z AI”. Główna wartość dodana człowieka przeniesie się w kierunku jakości decyzji, nie liczby napisanych linii kodu.
Modele współpracy z AI: pair programmer, reviewer, analityk, QA
Generatywna AI może pełnić wiele ról równocześnie – wszystko zależy od tego, jak ją osadzisz w procesach. Kilka najbardziej prawdopodobnych modeli na najbliższe lata:
AI pair programmer – integracja w IDE, która nie tylko podpowiada kod, ale także proponuje alternatywy, wskazuje potencjalne błędy i sugeruje testy,
AI reviewer – bot w systemie kontroli wersji, który analizuje PR, komentuje pod kątem bezpieczeństwa, wydajności i zgodności ze standardami,
AI analityk wymagań – narzędzie, które z rozmów z klientem (tekst, zapis spotkań) wyciąga wymagania, proponuje user stories i scenariusze testowe,
AI QA – system generujący przypadki testowe, analizujący logi i zgłoszenia błędów, priorytetyzujący regresje.
W dobrze poukładanej organizacji te role będą ze sobą spięte. Przykładowo: AI analityk wyprowadza wymagania, AI pair programmer korzysta z nich przy generowaniu kodu, AI reviewer sprawdza spójność implementacji z wymaganiami, a AI QA domyka pętlę feedbacku na podstawie zachowania użytkowników.
Przykładowy dzień developera za 3–5 lat
Wygląd dnia pracy programisty już się zmienia, a w horyzoncie 5 lat różnica będzie wyraźna. Realistyczny scenariusz:
Jak może wyglądać dzień developera za kilka lat
Rano nie zaczynasz od Slacka ani maila, tylko od panelu z „deską sterowniczą” dla feature’ów. Asystent AI zaciąga dane z Jiry, repozytorium, logów i monitora APM. Na jednym ekranie widzisz:
propozycje priorytetów zadań na dziś (z komentarzem: z czego wynikają),
PR-y, które Twoja AI już przeanalizowała i oznaczyła jako „low risk” lub „high risk”,
alerty z produkcji wraz z sugestiami poprawek i szacowanym wpływem na biznes.
Przed pierwszym commitem doprecyzowujesz wymagania. Zamiast suchej user story typu „Jako użytkownik chcę filtrować listę produktów”, masz konwersację z asystentem:
podajesz kilka konkretnych scenariuszy użycia,
AI generuje kontrakt API, modele danych i edge case’y,
wspólnie czyścicie listę – eliminujesz zbędne warianty, dodajesz specyficzne dla Twojej domeny.
Dopiero wtedy przechodzisz do kodu. IDE ma zasilony kontekst: user story, kontrakty, przykłady danych, ograniczenia niefunkcjonalne. Twoja praca to głównie:
pisanie „szkieletów” funkcji i klas,
opisywanie w komentarzach intencji i ograniczeń,
zadawanie precyzyjnych pytań: „zapropnuj 3 warianty implementacji tej strategii cachowania, biorąc pod uwagę X i Y”.
Po lunchu skupiasz się na przeglądzie. Część PR-ów już ma komentarze wygenerowane przez AI reviewera. Zamiast manualnie wychwytywać oczywistości, patrzysz, czy:
AI nie przeoczyła kontekstu domenowego,
sugerowane zmiany nie kłócą się z roadmapą architektoniczną,
kompromisy („trochę wolniej, ale bezpieczniej”) są świadome.
Dzień kończysz krótką sesją z AI analitykiem jakości. Przeglądacie razem najważniejsze błędy z produkcji, nowe wzorce w zachowaniach użytkowników, nietypowe spadki metryk. Na tej podstawie dopisujesz 1–2 nowe scenariusze testowe do backlogu i aktualizujesz wytyczne dla AI QA, żeby kolejne regresje tego typu wyłapywała wcześniej.
Źródło: Pexels | Autor: Daniil Komov
Jak AI generatywna zmieni role w zespole developerskim
Programista: z „piszącego kod” do „kuratora rozwiązań”
Najbardziej oczywista zmiana: coraz mniej czasu spędzasz na ręcznym wpisywaniu kodu, coraz więcej na decydowaniu, które z wygenerowanych rozwiązań mają sens. Zadanie programisty zacznie przypominać pracę kuratora:
definiowanie problemu i ograniczeń (prompty, przykłady, kontrakty),
ocena i selekcja wygenerowanych propozycji,
łączenie outputów AI z istniejącą architekturą i standardami zespołu,
pilnowanie spójności domenowej i technicznej.
Na znaczeniu zyska umiejętność „rozmawiania z systemem” – jasnego formułowania intencji, zadawania pytań naprowadzających i budowania krótkich pętli feedbacku. Dobra praktyka: przy bardziej złożonych funkcjach zawsze generować 2–3 warianty i świadomie wybierać, zamiast brać pierwszy wynik.
Senior i architekt: mniej „super-programista”, więcej „projektant decyzji”
Seniorzy i architekci już dziś rzadziej siedzą w kodzie, częściej w decyzjach. AI ten trend przyspieszy. Zadania seniora przesuną się w stronę:
projektowania „guardrails” – reguł, których AI nie powinna łamać (bezpieczeństwo, wzorce architektoniczne, standardy stylu),
projektowania workflowów z AI – jakie narzędzia, gdzie w pipeline, z jakimi uprawnieniami,
oceny ryzyka związanego z automatyzacją (co można zautomatyzować w 90%, a co lepiej zostawić ludziom),
mentoringu w zakresie pracy z AI – review nie tylko kodu, ale też promptów i sposobu korzystania z narzędzi.
Architekt stanie się „reżyserem” wielu agentów AI. Będzie projektował nie tylko komponenty i serwisy, lecz także to, jak różne modele komunikują się ze sobą i z ludźmi. Przykładowo: jak AI analityk przekazuje wiedzę AI programiście, a ta dalej AI QA.
QA i tester: z „klikacza” do inżyniera jakości systemowej
Manualne klikanie regression suites będzie szybko znikać. Nie dlatego, że testowanie nie jest potrzebne, tylko dlatego, że:
AI potrafi wygenerować setki wariantów danych wejściowych pod jedną funkcję,
frameworki E2E łatwo zasilisz scenariuszami z dokumentacji i logów,
anomaly detection na produkcji w wielu przypadkach zastąpi statyczne przypadki testowe.
Rola QA przesunie się w stronę:
definiowania kryteriów jakości (co znaczy „dobrze” w tej domenie),
projektowania strategii testów (gdzie AI generuje, gdzie człowiek sprawdza),
analizy danych z produkcji i przekuwania ich w nowe testy,
kontroli „ślepych plamek” AI – miejsc, gdzie generacja jest zawodna.
Dobry tester będzie kimś, kto rozumie cały system: od UX, przez backend, po infrastrukturę i metryki biznesowe. Narzędzia generatywne będą mu pomagały, ale to on ustali, co ma być mierzone i testowane.
Product owner i analityk: mniej dokumentów, więcej pracy z narracją
AI świetnie radzi sobie z przelewaniem ustaleń na user stories, diagramy, przypadki testowe. PO i analityk przestaną być „tłumaczami na Jirę”, a częściej będą:
facylitatorami rozmów z biznesem,
osobami, które dbają o spójne zrozumienie problemu w zespole,
kuratorami backlogu generowanego przez AI (priorytety, powiązania, zależności),
strażnikami celów produktowych – czy to, co generuje AI, rzeczywiście dowozi wartość.
Praktyczna zmiana: mniej czasu na przepisywanie notatek ze spotkań do systemu zadań, więcej na doprecyzowywanie edge case’ów, scenariuszy i kryteriów sukcesu, które potem zasilą narzędzia generatywne.
Obszary, które AI przejmie najszybciej – od kodu do testów i dokumentacji
Monotonna implementacja CRUD i warstw pośrednich
Warstwy, w których logika biznesowa jest minimalna, są najprostszym celem automatyzacji. Chodzi o:
endpoints typu CRUD,
mappery DTO ↔ encje,
proste walidacje danych wejściowych,
powtarzalne adaptery do zewnętrznych API.
Już dziś takie elementy można generować z definicji kontraktów (OpenAPI, GraphQL schema, DSL domenowy). W ciągu kilku lat standardem stanie się podejście „contract first + AI generator”, gdzie:
człowiek projektuje kontrakt i ograniczenia,
AI generuje implementację zgodną ze style guide i architekturą,
pipeline automatycznie weryfikuje zgodność z kontraktem i podstawowymi testami.
Testy jednostkowe i regresyjne z logów
Każdy, kto próbował ręcznie dopisać testy do istniejącej bazy kodu, wie, jak żmudne jest to zajęcie. AI szybko przejmie:
generowanie testów jednostkowych z istniejących funkcji i klas,
aktualizację testów po zmianach API (np. dodanie parametru, zmiana typu),
budowanie zestawów regresyjnych z realnych logów – dane wejściowe i wyjściowe z produkcji.
Praktyczny przykład: po każdym większym incydencie produkcyjnym pipeline będzie tworzył paczkę nowych testów na bazie requestów, które wywołały błędy. Tester skupi się na ocenie, które z nich mają sens i jak je uogólnić, AI zajmie się resztą.
Dokumentacja techniczna i przykłady użycia
Dokumentacja jest naturalnym polem do generacji. Modele językowe świetnie łączą kod z opisem w języku naturalnym. Zmiany, które już widać i które się pogłębią:
ciągła generacja docs z kodu i commitów (opis endpointów, parametrów, zmian),
tworzenie snippetów „how to” na bazie realnego użycia API w repozytoriach,
dostosowanie dokumentacji do odbiorcy – inny poziom szczegółowości dla juniora, inny dla seniora lub partnera zewnętrznego.
Dobry standard pracy: traktować dokumentację jako interfejs dla AI. Im lepiej opisana domena i kontrakty, tym trafniejsze podpowiedzi i generacja kodu. Dokumentacja przestanie być „przykrym obowiązkiem”, a stanie się jednym z głównych źródeł przewagi zespołu nad generatywną „średnią rynkową”.
Legacy code to dziś jeden z największych hamulców w organizacjach. Generatywna AI przyspieszy:
półautomatyczne migracje między frameworkami (np. Angular → React, Spring MVC → WebFlux),
wydzielanie modułów z monolitu,
uporządkowanie zależności i usuwanie martwego kodu.
Proces będzie wyglądał inaczej niż „refactor Friday”:
AI buduje mapę zależności i proponuje logiczne moduły,
architekt zatwierdza lub koryguje podział,
generator przygotowuje „paczkę zmian”,
pipeline waliduje zgodność zachowania (testy, metryki funkcjonalne),
zespół skupia się na trudnych przypadkach i decyzjach architektonicznych.
Miejsca, gdzie człowiek pozostanie kluczowy – decyzje, odpowiedzialność, etyka
Definiowanie problemu i granic rozwiązania
Modele generatywne działają świetnie, gdy problem jest jasno zdefiniowany. W realnym biznesie bywa odwrotnie: wymagania są rozmyte, interesariusze ciągną w różne strony, dane są niekompletne. Tu rola człowieka jest nie do zastąpienia. Do kluczowych zadań należą:
wybieranie, czego nie robić w danym sprincie,
ustalanie kompromisów między szybkością a jakością,
ochrona przed „overengineeringiem” generowanym przez zbyt ambitne modele.
AI może zaproponować setki opcji, ale nie rozumie kosztu politycznego, utraty zaufania klienta czy zmęczenia zespołu. Takie decyzje nadal będą po stronie ludzi.
Odpowiedzialność za systemy, które wpływają na ludzi
Im więcej AI w kodzie, tym częściej pojawiają się pytania: kto jest odpowiedzialny, gdy coś pójdzie źle? Systemy scoringu kredytowego, medyczne, rekrutacyjne, rekomendacyjne – wszędzie tam konsekwencje błędów są realne dla użytkowników. Potrzebne będą:
jasne łańcuchy odpowiedzialności (kto podpisuje decyzje o wdrożeniu),
procesy „human-in-the-loop” przy krytycznych decyzjach,
audyty rozwiązań generowanych przez AI – techniczne i etyczne.
Developerzy i liderzy techniczni będą musieli umieć powiedzieć „nie” lub „stop” także wtedy, gdy model generuje „ładne” rozwiązania, które są jednak prawnie lub etycznie ryzykowne.
Projektowanie doświadczenia użytkownika i języka produktów
AI może napisać tekst, zaproponować layout, wygenerować flow. Nie czuje jednak frustacji użytkownika, który trzeci raz widzi ten sam komunikat błędu, ani wstydu klienta, który musi w formularzu podać delikatne dane. Projektowanie doświadczenia użytkownika, tonu komunikatów i mikrointerakcji to nadal domena ludzi.
W praktyce oznacza to m.in.:
świadome projektowanie reakcji systemu na błędy i wyjątki,
pilnowanie, by AI nie generowała komunikatów zbyt technicznych lub zbyt „cukierkowych”,
dbałość o dostępność (a11y) i inkluzywność treści.
AI pomoże w wariantach, tłumaczeniach, testach A/B. Kierunek i ramy powinien wyznaczać człowiek.
Budowanie kultury pracy z AI
Narzędzia generatywne zmienią nie tylko kod, ale też kulturę zespołów. Ktoś musi zadbać o to, żeby:
AI była wsparciem, a nie narzędziem kontroli nad ludźmi,
juniorzy nadal uczyli się myślenia, a nie tylko „klepania promptów”,
zespół miał świadomość ograniczeń modeli i umiał zgłaszać problemy.
Liderzy techniczni zyskają nowy obszar odpowiedzialności: edukację w zakresie krytycznego podejścia do AI. Dobre praktyki: regularne review „faili” AI, sesje dzielenia się tym, co zadziałało i co nie, wspólne ustalanie zasad korzystania z modeli (co wolno wysyłać, czego nie, jak anonimizować dane).
Nowe kompetencje programisty i lidera technicznego w erze generatywnej AI
Umiejętne korzystanie z AI: od prostych promptów do projektowania interakcji
Projektowanie interakcji człowiek–AI w codziennym developmencie
Proste „napisz funkcję X w języku Y” szybko przestanie wystarczać. Programista będzie projektował całe mini-rozmowy z AI: krok po kroku zawężanie problemu, doprecyzowanie założeń, iteracyjne recenzje kodu. To bardziej praca z asystentem niż z wyszukiwarką.
Praktyczna zmiana polega na budowaniu własnych „szablonów współpracy” z modelem. Zamiast jednego, dużego promptu – sekwencja interakcji:
najpierw doprecyzowanie kontekstu domenowego i ograniczeń,
potem generacja wariantów rozwiązania,
na końcu wspólne przejście po edge case’ach i testach.
Dobrą praktyką staje się też dzielenie promptów na dwie klasy: operacyjne (konkretne zadanie w kodzie) i strategiczne (sprawdzenie podejścia architektonicznego, listy ryzyk, pomysły na uproszczenia). Inaczej rozmawia się z AI jako z „junior developerem”, a inaczej – jak z „architektem-konsultantem”.
Umiejętność oceny jakości odpowiedzi modelu
Najważniejsza kompetencja: krytyczne czytanie tego, co zwraca model. Nie chodzi tylko o znalezienie błędów składniowych. Trzeba wykrywać:
ciche założenia sprzeczne z rzeczywistą domeną,
nieuzasadnione uproszczenia (np. brak obsługi wyjątków, brak zabezpieczeń),
niepotrzebne komplikowanie rozwiązania.
Przydaje się własna, szybka checklista oceny wygenerowanego kodu:
czy nie wprowadza „magii”, której zespół nie rozumie.
W praktyce wiele zespołów zacznie używać AI nie do jednorazowej generacji, ale do ciągłej rewizji: „oceń ten kod względem naszych zasad X, Y, Z, zaproponuj minimalny, sensowny refactor”. To wymaga od programisty umiejętności formułowania kryteriów jakości, a nie tylko proszenia o „ładniejszy kod”.
Łączenie domeny biznesowej z możliwościami modeli
Generatywna AI jest tak dobra, jak opis systemu, który dostaje. Programista, który rozumie zarówno technologię, jak i biznes, będzie w stanie przekuć wymagania domenowe na materiał treningowy i kontekst dla modeli. To konkretne czynności:
upraszczanie i strukturyzowanie języka biznesu (słowniki pojęć, taksonomie, DSL),
wyszukiwanie powtarzalnych wzorców decyzji, które można częściowo zautomatyzować,
oznaczanie fragmentów logiki, które muszą pozostać pod bezpośrednią kontrolą człowieka.
Przykład: w systemie ubezpieczeniowym AI nie powinna samodzielnie zmieniać zasad taryfikacji. Ale może proponować warianty reguł, wykrywać niespójności i wskazywać segmenty klientów o nietypowym zachowaniu. Rolą developera jest podpięcie takich propozycji w proces decyzyjny, a nie oddanie pełnej kontroli.
Nowa rola lidera technicznego: kurator ekosystemu AI w zespole
Lider techniczny przestaje być wyłącznie „strażnikiem architektury”. Dochodzi rola kuratora narzędzi AI: wyboru, integracji i nadzoru nad sposobem korzystania. W praktyce oznacza to:
dobór modeli i pluginów do konkretnych projektów (zamiast jednego, uniwersalnego narzędzia),
definiowanie standardów promptowania i pracy z asystentami,
dbanie o bezpieczeństwo danych przekazywanych do modeli,
ustalanie, gdzie AI może generować kod automatycznie, a gdzie tylko sugerować zmiany.
Lider techniczny staje się też „tłumaczem” między działem bezpieczeństwa, prawnym i zespołem developerskim. Gdy organizacja wprowadza ograniczenia w korzystaniu z chmury lub zewnętrznych LLM, to on projektuje architekturę wewnętrznych asystentów, proxy i filtrów.
Projektowanie wewnętrznych narzędzi AI dla zespołu
Kolejna kompetencja to budowanie własnych „koprocesorów” AI dla firmy. Zamiast używać ogólnych chatbotów, zespoły zaczną tworzyć wyspecjalizowane asystenty:
przeszkolone na wewnętrznej dokumentacji i kodzie,
z wbudowaną świadomością architektury i konwencji,
z ograniczeniami dostępu zgodnymi z uprawnieniami w organizacji.
Technicznie to połączenie kilku elementów: wektorowe wyszukiwanie po repos, plugin do IDE, API do modeli oraz warstwa polityk bezpieczeństwa. Programista z kompetencjami w tym obszarze staje się mnożnikiem produktywności całego działu, nie tylko swojego zespołu scrumowego.
Praca z danymi treningowymi i feedbackiem do modeli
Generatywna AI nie kończy się na wywołaniu API. Trzeba zadbać o cykl zwrotny: co się dzieje z odpowiedziami modelu, jak mierzyć ich jakość, jak je poprawiać. Tu pojawiają się nowe zadania dla developerów i liderów:
oznaczanie przypadków, w których model zawiódł (hallucinations, błędy domenowe),
budowa prostych interfejsów do „labelowania” danych przez ekspertów biznesowych,
definiowanie metryk jakości (nie tylko accuracy, ale np. czas decyzji, liczba poprawek, satysfakcja użytkownika wewnętrznego).
W większych organizacjach powstaną mini-zespoły MLOps/LLMOps, ale to developerzy będą codziennymi dostawcami feedbacku: przez commit messages, komentarze w PR, tagowanie problematycznych generacji. Umiejętność „mówienia językiem danych” (jak zakodować problem tak, by dało się go później analizować) stanie się standardem.
Świadome łączenie klasycznego inżynierowania z AI
Przez najbliższe lata projekty będą hybrydą: część modułów powstanie w klasyczny sposób, część – z większym udziałem AI. Programista musi umieć świadomie wybierać technikę do problemu. Prosta mikro-checklista przy planowaniu zadania:
czy problem ma dobrze zdefiniowane wejścia i wyjścia,
czy istnieją twarde wymagania niezawodności (np. transakcje finansowe),
czy biznes dopuszcza probabilistyczny charakter odpowiedzi (np. rekomendacje),
czy posiadamy dane i kontekst do sensownej pracy modelu.
Na tej podstawie można zdecydować: klasyczny algorytm, model ML zarządzany poza kodem, czy integracja z LLM. Samo „bo AI jest modne” nie wystarczy – trzeba umieć uzasadnić wybór pod kątem utrzymania, audytu i kosztów.
Rozwijanie „meta-umiejętności” programisty
Rzemiosło developerskie się zmieni, ale kilka umiejętności zyska jeszcze większe znaczenie:
myślenie algorytmiczne – nie po to, by pisać każdy algorytm od zera, ale by rozumieć, co model uprościł lub pominął,
modelowanie domeny – zrozumiała struktura domeny to paliwo dla AI; kiepski model domenowy = kiepskie generacje,
komunikacja pisemna – precyzyjne opisywanie problemów, założeń i decyzji jest teraz istotne także dla maszyn, nie tylko dla ludzi,
umiejętność uczenia innych – tłumaczenie kolegom, jak skutecznie korzystać z AI i gdzie są pułapki.
Programista, który potrafi szybko przejść od niejasnego wymagania do dobrze zdefiniowanego problemu z ograniczeniami, będzie korzystał z AI znacznie skuteczniej niż ktoś, kto tylko zna syntaksę promptów.
Praktyczne nawyki pracy z AI w zespole
Oprócz twardych kompetencji ważne są drobne nawyki, które rozkładają się na cały dzień pracy. Kilka przykładów, które dobrze działają w praktyce:
rozpoczynanie tasku od krótkiej sesji z AI: „pomóż mi wypisać wszystkie edge case’y tego feature’a”,
podczas code review – prośba do AI o alternatywne rozwiązania i wspólne omówienie w zespole,
po każdym incydencie – generacja analizy „5x why” i checklisty prewencyjnej, którą człowiek dopracowuje,
utrzymywanie „repo promptów” w projekcie: sprawdzone szablony interakcji z AI dla powtarzalnych zadań.
Takie drobiazgi robią różnicę w ciągu kilku miesięcy. Zespół wypracowuje własny styl współpracy z modelami – spójny, przewidywalny i powtarzalny, a nie oparty na indywidualnych „sztuczkach” pojedynczych osób.
Odpowiedzialność za etyczne wykorzystanie AI nie spadnie wyłącznie na dział prawny. Liderzy techniczni będą musieli łączyć twardą ocenę techniczną z pytaniami o skutki społeczne i długofalowe. W praktyce oznacza to między innymi:
stawianie pytań o możliwe nadużycia funkcji zasilanych AI (np. profilowanie użytkowników, manipulacja treścią),
pilnowanie, by projekty uwzględniały mechanizmy rezygnacji, odwołania czy wyjaśnienia decyzji modelu,
kształtowanie standardów logowania i audytu decyzji, tak by dało się później wytłumaczyć, co się wydarzyło.
Dochodzi też obszar edukacji. Liderzy będą inicjować warsztaty z „etyki w praktyce”: nie teoretyczne dyskusje, tylko konkretne przypadki z własnych systemów. „Czy powinniśmy pokazywać tę rekomendację?”, „Czy ten scoring jest sprawiedliwy dla wszystkich grup użytkowników?”. Takie rozmowy staną się częścią architektury tak samo jak decyzje o frameworkach.
Najczęściej zadawane pytania (FAQ)
Jak generatywna AI zmieni codzienną pracę programisty w najbliższych 5 latach?
Największa zmiana dotknie „środka” SDLC: implementacji, testów i utrzymania. Coraz większa część kodu szablonowego, integracji, konfiguracji i prostych testów będzie generowana automatycznie na podstawie krótkich opisów lub istniejących fragmentów kodu. Programista przesunie się z roli „piszę wszystko ręcznie” do roli „projektuję rozwiązanie, weryfikuję i koryguję wynik AI”.
Codziennością stanie się też używanie asystentów w IDE i CI/CD: sugestie poprawek w PR, propozycje refaktoryzacji, analiza logów z produkcji z gotowymi hipotezami przyczyn błędów. Zespół będzie mniej klepał boilerplate, a więcej czasu poświęci na logikę domenową, decyzje architektoniczne i rozmowy z biznesem.
Czy generatywna AI zastąpi programistów?
W perspektywie 5 lat nie. Zastąpi natomiast część zadań wykonywanych przez programistów, szczególnie tych powtarzalnych i szablonowych. Kodowanie „od zera” prostych CRUD-ów, klasy DTO, powtarzalne konfiguracje czy proste testy jednostkowe w dużej mierze przejmą narzędzia AI.
Rosnące znaczenie będzie mieć umiejętność pracy z AI: formułowanie sensownych promptów, ocena jakości zaproponowanego rozwiązania, wykrywanie luk w bezpieczeństwie czy niespójności architektonicznych. Zawód programisty przesunie się w stronę roli projektanta, weryfikatora i „reżysera” całego procesu, a nie wyłącznie osoby piszącej kod linijka po linijce.
Jakie zadania wciąż będą wymagały człowieka mimo rozwoju AI?
AI ma duży problem z głębokim zrozumieniem domeny biznesowej i kontekstu organizacji. Dlatego po stronie ludzi nadal zostaną: modelowanie domeny, podejmowanie decyzji architektonicznych z uwzględnieniem ograniczeń biznesowych, kompromisy koszt–jakość–czas, projektowanie API i kontraktów między systemami, a także priorytetyzacja wymagań.
Poza tym człowiek będzie kluczowy tam, gdzie błędy są bardzo kosztowne: bezpieczeństwo, zgodność z regulacjami, krytyczne ścieżki biznesowe. Tu AI może pomagać (np. jako dodatkowe „oczy” w code review), ale nie powinna mieć ostatniego słowa.
Jak wykorzystać generatywną AI w zespole developerskim już teraz?
Dobry start to trzy obszary: generowanie boilerplate’u, testów i refaktoryzacja stylistyczna. W praktyce oznacza to używanie asystentów (Copilot, ChatGPT, Codeium itp.) do tworzenia klas DTO, mappingów, endpointów CRUD, konfiguracji frameworków, a także do pisania jednostkowych testów dla istniejących funkcji. Daje to szybki, mierzalny zysk czasu.
Drugi krok to wsparcie przy analizie i utrzymaniu: proszenie AI o wyjaśnienie fragmentów legacy kodu, przygotowanie draftów dokumentacji technicznej, generowanie seedingów danych czy przykładowych payloadów do testów. Ważne jest wprowadzenie jasnych zasad: co można generować automatycznie, co zawsze przechodzi code review i gdzie AI służy tylko jako inspiracja.
Jak zmieni się rola juniora, mida i seniora przez generatywną AI?
Junior szybciej zacznie dowozić działający kod, ale ryzykuje, że będzie tylko „operatorem Copilota”. Dlatego musi mieć mentora, regularne code review i zadania wymagające samodzielnego myślenia, nie tylko poprawnego wpisania promptu. Dobra praktyka: najpierw spróbuj sam, potem porównaj swoje podejście z tym, co proponuje AI.
Mid będzie mniej czasu spędzał na powtarzalnej pracy, a więcej na rozwiązywaniu złożonych problemów, integracjach i optymalizacji. Senior z kolei coraz częściej będzie „kierownikiem jakości konwersacji z AI”: ustali standardy korzystania z narzędzi, decyduje, które obszary automatyzujemy, a gdzie potrzebna jest manualna weryfikacja, i używa AI do szybkiego prototypowania podejść architektonicznych.
Jakie są największe ryzyka używania generatywnej AI w developmentcie?
Kluczowe ryzyka to halucynacje (AI wymyśla nieistniejące funkcje, endpointy, biblioteki), podatności bezpieczeństwa (np. brak walidacji, podatność na SQL injection lub XSS), niespójność z istniejącą architekturą oraz kopiowanie złych wzorców z danych treningowych. W praktyce może to oznaczać kod, który „na demo działa”, ale na produkcji powoduje problemy wydajnościowe lub bezpieczeństwa.
Dodatkową warstwą są kwestie prawne: ograniczenia w wysyłaniu kodu do chmury, ochrona IP, licencje wygenerowanego kodu, zgodność z RODO i regulacjami branżowymi. Minimalna „checklista bezpieczeństwa” to: jasna polityka firmowa dot. AI, włączone code review dla całego kodu generowanego, skanery bezpieczeństwa w CI oraz unikanie wrzucania w prompt wrażliwych danych.
Czy AI generatywna potrafi projektować architekturę systemu?
AI potrafi zaproponować szkic architektury na podstawie opisu wymagań i istniejącego kodu: podział na moduły, warstwy, dobór typowych wzorców projektowych, ogólną strukturę API. Jest szczególnie przydatna do porównywania wariantów („monolit vs mikroserwisy”, „event-driven vs REST”) i wypunktowania plusów oraz minusów każdego podejścia.
Nadal jednak nie zna realiów konkretnej firmy: kompetencji zespołu, ograniczeń budżetowych, istniejącej infrastruktury, tolerancji na ryzyko. Dlatego jej propozycje trzeba traktować jako punkt wyjścia do dyskusji, a nie gotowy projekt do wdrożenia 1:1. Dobry wzorzec pracy: poproś AI o 2–3 alternatywne podejścia, wybierz z nich elementy pasujące do Twojego kontekstu i dopiero wtedy przejdź do szczegółowego projektowania.
