JetBrains: pisanie kodu przez AI przestało być problemem, teraz liczy się kontrola i odpowiedzialność

Rozmowę o roli sztucznej inteligencji w wytwarzaniu oprogramowania przeprowadzono z Magdaleną Markowską, dyrektor regionalną na Europę Środkowo-Wschodnią (CEE) oraz Head of Fintech Europe w JetBrains. Tematem rozmowy były: praktyczne zastosowanie AI przy pisaniu kodu, jakość i bezpieczeństwo takiego kodu oraz nowe narzędzia JetBrains wspierające deweloperów, w tym agent Junie.

Weryfikacja ważniejsza niż szybkość

Markowska zwraca uwagę, że obecnie to nie prędkość tworzenia kodu stanowi główną przeszkodę, lecz zdolność firm do sprawdzenia, czy to, co powstało, jest bezpieczne, zgodne z przepisami i odpowiednio wysokiej jakości. Jak zauważa, przez długi czas barierą była szybkość pracy, a AI skutecznie ten problem rozwiązała – w jej miejsce pojawiły się jednak nowe wyzwania: precyzyjna kontrola i jasno określona odpowiedzialność.

Z badania JetBrains AI Pulse 2026 wynika, że aż 78% polskich programistów bierze czynny udział w przeglądach kodu, podczas gdy średnia globalna wynosi 61%. Zdaniem Markowskiej to pokazuje, że polscy specjaliści dobrze rozumieją, gdzie leży prawdziwe ryzyko.

Kod można dziś wygenerować w kilka minut. Pytanie brzmi: czy ktoś jest gotów wziąć za niego odpowiedzialność? I to właśnie weryfikacja, dostrzeganie szerszego kontekstu, krytyczne myślenie, stają się kompetencją, której dziś najbardziej brakuje organizacjom.

Magdalena Markowska, JetBrains

Szybszy kod nie znaczy szybszy produkt

Jak podkreśla Markowska, jednym z najbardziej kosztownych błędnych przekonań, z jakim spotyka się w rozmowach z klientami – zwłaszcza z sektora finansowego – jest założenie, że krótszy czas pisania kodu automatycznie przekłada się na szybsze wejście produktu na rynek. Samo pisanie kodu to jedynie fragment całego cyklu wytwarzania oprogramowania – architektura, testy, kontrola bezpieczeństwa, procesy decyzyjne i wdrożenie nadal wymagają czasu.

Dane pokazują, że 85% programistów odczuwa wzrost własnej produktywności dzięki AI, jednak korzyści na poziomie całej organizacji pojawiają się dopiero, gdy firma przebuduje cały proces wytwórczy, a nie tylko dołoży AI do istniejącego przepływu pracy. Markowska ostrzega, że samo przyspieszenie pisania kodu przy niezmienionej reszcie procesu może nawet wydłużyć czas dostarczenia produktu, bo weryfikacja, testy i poprawki muszą objąć większą liczbę zmian.

Dług technologiczny, compliance i brak jasnych zasad

Pytana o bariery organizacyjne, które mogą ograniczyć korzyści z AI, Markowska wymienia trzy powtarzające się wzorce niezależnie od branży. Pierwszym jest dług technologiczny – AI sprawdza się dobrze w nowych projektach, ale w dużych, starych i złożonych systemach, gdzie toczy się większość realnego biznesu, napotyka ograniczenia architektoniczne, których żaden prompt nie rozwiąże.

Drugą barierą są bezpieczeństwo i zgodność regulacyjna. W sektorze finansowym każda zmiana w kodzie musi przejść przez warstwy kontroli regulacyjnej, a AI może przyspieszyć samo pisanie, ale nie skraca procesu certyfikacji.

Trzecią są niejasne procesy decyzyjne – kto zatwierdza kod wygenerowany przez agenta i kto ponosi odpowiedzialność w razie awarii czy wycieku danych. Bez jasno zdefiniowanego modelu zarządzania AI te pytania, zdaniem Markowskiej, blokują skalowanie bardziej niż jakikolwiek problem techniczny.

Czym jest „odpowiedzialne wykorzystanie AI”

Dla JetBrains odpowiedzialne stosowanie sztucznej inteligencji opiera się na kilku filarach. Pierwszy to kontrola jakości – mechanizmy egzekwujące standardy bez względu na to, czy kod napisał człowiek, czy agent. Drugi to bezpieczeństwo i nadzór człowieka, bo podatności i błędne konfiguracje w kodzie tworzonym z pomocą AI pojawiają się statystycznie częściej niż w kodzie pisanym ręcznie – ktoś musi być w stanie przeczytać, zrozumieć i zatwierdzić efekt pracy AI.

Kolejny element to audytowalność, czyli możliwość odtworzenia, kto co zatwierdził i na jakiej podstawie, a także kwestia własności intelektualnej, istotna zwłaszcza przy kodzie generowanym przez modele trenowane na cudzych danych. Ostatnim filarem jest zgodność regulacyjna, szczególnie w kontekście unijnego AI Act, który w Europie wchodzi właśnie w fazę egzekwowania. Jak zaznacza Markowska, żaden z tych elementów nie jest opcjonalny – razem tworzą tzw. infrastrukturę zaufania.

Kiedy człowiek musi zostać w pętli decyzyjnej

Pytana o model „human in the loop”, Markowska zaznacza, że nie ma jednej uniwersalnej odpowiedzi, bo wszystko zależy od krytyczności systemu, obszaru funkcjonalnego i dojrzałości procesów testowych w danej organizacji. Można jednak wskazać pewne zasady ogólne.

Człowiek powinien zatwierdzać wynik AI zawsze, gdy zmiana dotyczy logiki biznesowej, bezpieczeństwa, danych wrażliwych lub publicznego API. Powinien ingerować, gdy coś w kodzie nie jest dla niego czytelne. Jeśli deweloper nie rozumie, co zatwierdza, nie powinien tego robić.

Magdalena Markowska, JetBrains

Jak dodaje, automatyzacja bez bieżącej ingerencji człowieka może działać w zadaniach rutynowych, dobrze pokrytych testami – takich jak refaktoryzacje, aktualizacje zależności czy generowanie testów jednostkowych. Całkowite wyłączenie człowieka z procesu ma sens tylko w środowiskach z dojrzałym systemem testów automatycznych i jasno określonymi granicami bezpieczeństwa, co w większości firm, z którymi współpracuje Markowska, wciąż pozostaje odległą perspektywą.

IDE jako infrastruktura odpowiedzialności

Środowisko programistyczne (IDE) przestało być zwykłym edytorem tekstu – jak mówi Markowska, to dziś przestrzeń przypominająca laboratorium i warsztat rzemieślnika, w której ostatecznie zapada decyzja o zatwierdzeniu kodu. Dlatego właśnie IDE staje się elementem infrastruktury governance.

Narzędzia takie jak Qodana, wbudowane bezpośrednio w środowisko programistyczne i zintegrowane z pipeline'em CI/CD, przenoszą inspekcję kodu z manualnego, podatnego na pominięcia przeglądu do zautomatyzowanego procesu wpisanego w cykl wytwarzania. Te same reguły jakości i bezpieczeństwa obowiązujące w całym projekcie są sprawdzane przy każdej zatwierdzanej zmianie, niezależnie od presji terminu czy składu zespołu. Markowska nazywa to zmianą fundamentalną: IDE przestaje być narzędziem indywidualnej produktywności, a staje się infrastrukturą odpowiedzialności.

Polska liderem w używaniu AI, ale nie we wdrożeniach firmowych

Raport McKinsey z czerwca 2026 roku wskazuje Polskę jako kraj z największą w Europie Środkowej luką między indywidualnym korzystaniem z AI a jej wdrożeniem na poziomie organizacji. 29% Polaków używa AI na co dzień, ale jedynie 8% firm stosuje ją w swojej działalności operacyjnej. Markowska tłumaczy tę różnicę przede wszystkim brakiem infrastruktury pomiarowej – firmy nie wiedzą, ile kosztuje AI w poszczególnych zespołach, które zastosowania faktycznie przynoszą efekty i kto odpowiada za wyniki.

Bez tej wiedzy korzyści indywidualne nie kumulują się w korzyści organizacyjne, bo po prostu brakuje mechanizmu, który by to umożliwił. Drugim problemem jest brak przebudowy procesów – AI dodana do istniejącego przepływu pracy nie zwiększa jego efektywności, zmienia ją dopiero przeprojektowanie procesów wokół samej AI.

Trzy powtarzające się błędy firm

Markowska wskazuje trzy wzorce, które powtarzają się w organizacjach rozczarowanych brakiem zwrotu z inwestycji w AI po kilku miesiącach. Po pierwsze, firmy traktują AI jak zwykły zakup narzędziowy zamiast zmiany procesowej – kupują licencje, deweloperzy zaczynają korzystać z nich indywidualnie, ale same procesy pozostają bez zmian.

Po drugie, firmy nie wiedzą, ile faktycznie wydają na AI ani czy te wydatki przynoszą rezultaty – koszty tokenów rosną, ale nikt nie potrafi wskazać, które projekty na tym skorzystały. Po trzecie, brakuje zdefiniowanej odpowiedzialności personalnej za wyniki wdrożenia. Jak zauważa Markowska, cytowane wcześniej badanie McKinsey pokazuje, że firmy osiągające realne korzyści finansowe z AI łączy jedna cecha – mierzą efekty i zmieniają struktury decyzyjne tak, by ktoś za nie odpowiadał.

Jakie wskaźniki mają sens

Markowska zaznacza, że JetBrains odradza mierzenie wpływu AI liczbą linii kodu czy czasem zaoszczędzonym na pisaniu – te metryki dobrze wyglądają w prezentacjach, ale nie mówią nic o wartości biznesowej.

Z perspektywy zarządu bardziej wiarygodne są: skrócenie czasu przeglądów kodu, zmiana wskaźnika defektów trafiających na produkcję, średni czas naprawy błędu przy incydentach związanych z kodem oraz trendy długu technicznego mierzone narzędziami analizy statycznej. Do tego dochodzi koszt tokenów AI liczony na projekt i zespół, który pozwala sprawdzić, czy pieniądze trafiają tam, gdzie faktycznie powstaje wartość. Jak podsumowuje Markowska, metryki powinny mierzyć wynik, a nie samą aktywność.

Programista jako architekt systemów AI

Na pytanie, czy programista przestaje być przede wszystkim „koderem”, a staje się architektem i orkiestratorem systemów AI, Markowska odpowiada twierdząco i powołuje się na dane. Zapytani o kluczowe kompetencje w perspektywie najbliższych pięciu lat, polscy deweloperzy wskazują krytyczne myślenie, architekturę oprogramowania i zarządzanie systemami AI. Tylko 11% badanych uważa, że tradycyjne ręczne pisanie kodu zachowa dotychczasowe znaczenie.

Jak zaznacza Markowska, nie oznacza to, że umiejętność programowania traci na znaczeniu – wręcz przeciwnie, zmienia się jej charakter. Deweloper musi dziś rozumieć kod, którego sam nie napisał, oceniać jego jakość, weryfikować bezpieczeństwo i brać odpowiedzialność za decyzję o wdrożeniu, co wymaga głębszego rozumienia architektury systemu niż kiedykolwiek wcześniej. AI, jak podsumowuje, podnosi poprzeczkę dla deweloperów, a nie ją obniża.

Dlaczego Polska jest strategiczna dla JetBrains

Markowska wymienia kilka powodów, dla których JetBrains inwestuje w Polsce. Przede wszystkim chodzi o dojrzałość techniczną, dobre uczelnie i dobrze przygotowanych specjalistów z bogatym doświadczeniem – z badania AI Pulse 2026 wynika, że 82% polskich programistów ma co najmniej 6 lat doświadczenia zawodowego, wobec 64% w skali globalnej. Jak podkreśla, to społeczność, która nie uczy się podstaw, lecz wdraża zaawansowane rozwiązania.

Istotna jest też szybkość adopcji nowych technologii – polskie firmy chętniej sięgają po AI Coding Agents niż większość rynków europejskich. Markowska zwraca uwagę również na polski ekosystem fintechowy jako jeden z najdynamiczniejszych w regionie CEE, a sektor finansowy to dziś jeden z kluczowych obszarów wdrożeń AI w software developmencie. Z tego powodu JetBrains rozbudowuje w Warszawie centrum badawczo-rozwojowe, doceniając wyjątkową jakość inżynierów, z którymi współpracuje.

JetBrains Air Day Poland – nowa faza adopcji AI

Pytana o najważniejszą zmianę, jaką JetBrains chce pokazać liderom biznesu podczas konferencji JetBrains Air Day Poland, zaplanowanej na 3 grudnia, Markowska mówi, że AI w software developmencie wchodzi w nową fazę, wymagającą innego zestawu decyzji. Pierwszym etapem była adopcja – kupowanie narzędzi, testowanie, zachęcanie deweloperów do korzystania z nich. Ten etap, jak zaznacza, mamy już za sobą. Drugi rozdział to udowodnienie realnej wartości, a to wymaga decyzji organizacyjnych, nie technicznych.

Głównym tematem grudniowej konferencji będzie JetBrains Air – platforma do zarządzania AI w procesie wytwarzania oprogramowania. Jak mówi Markowska, to odpowiedź na pytanie, które coraz częściej słyszy od CTO i CFO.

wiemy, że nasi deweloperzy używają AI, ale nie wiemy ile to kosztuje, gdzie to działa i kto za to odpowiada

pytanie, które według Magdaleny Markowskiej zadają CTO i CFO

JetBrains Air łączy narzędzia deweloperskie, agentów AI i infrastrukturę wykonawczą w jeden zarządzany ekosystem, działający na trzech poziomach. Pierwszy to governance i kontrola – egzekwowanie polityk dostępu, zarządzanie tożsamością, weryfikacja operacji oraz, co kluczowe z perspektywy ROI, przypisywanie kosztów AI do konkretnych projektów i zespołów.

Drugi poziom to infrastruktura dla agentów AI, działająca niezależnie od tego, czy wykorzystywane są narzędzia JetBrains, czy zewnętrzne, takie jak Claude, Codex czy Gemini. Trzeci poziom to współdzielony kontekst semantyczny – mechanizm pozwalający agentom rozumieć architekturę całego systemu, a nie jedynie reagować na pojedyncze, izolowane polecenia.

Jak podsumowuje Markowska, JetBrains Air to nie kolejne narzędzie dla programistów, lecz infrastruktura pozwalająca organizacji zarządzać AI tak jak każdą inną inwestycją – z widocznością kosztów, mierzalnymi wynikami i jasno przypisaną odpowiedzialnością za efekty. To właśnie ma zostać pokazane liderom biznesu 3 grudnia.

https://itwiz.pl/produkt/magazyn-itwiz-7-8-2026/embed