Po erze AI coding: czas na kontrolę, jakość i mierzalne efekty

Z Magdaleną Markowską, dyrektor regionalną na Central and Eastern Europe (CEE) i Head of Fintech Europe w JetBrains rozmawiam o:

• wykorzystaniu sztucznej inteligencji w tworzeniu oprogramowania,
• jakości i bezpieczeństwie tak powstającego kodu,
• nowych narzędziach JetBrains wspierających programistów, w tym agencie AI – Junie.

Czy prawdziwym ograniczeniem rozwoju AI w Software Development nie jest dziś tempo tworzenia kodu, lecz raczej zdolność organizacji do weryfikacji jakości, bezpieczeństwa i zgodności tego, co powstaje?

Myślę, że to faktycznie jedno z najważniejszych przesunięć w całej debacie o AI, i to nie tylko tworzeniu oprogramowania. Przez lata wąskim gardłem była szybkość. Sztuczna inteligencja skutecznie je wyeliminowała. Jednak w jej miejsce pojawiły się nowe bariery – precyzyjna weryfikacja i odpowiedzialność. Nasze badanie AI Pulse 2026 pokazuje, że 78% polskich deweloperów aktywnie uczestniczy w przeglądach kodu – wobec 61% globalnie. To nie przypadek. To dowód, że polskie środowisko doskonale rozumie, gdzie faktycznie leży 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.

Czy skrócenie czasu pisania kodu automatycznie oznacza szybsze dostarczenie produktu na rynek?

To jedno z najbardziej kosztownych nieporozumień, z jakimi spotykam się w rozmowach z klientami, szczególnie w sektorze finansowym. Czas pisania kodu to tylko jeden element cyklu wytwarzania oprogramowania. Architektura, testy, przegląd bezpieczeństwa, proces decyzyjny, wdrożenie – to wszystko wciąż istnieje i zajmuje czas.

Dane pokazują, że 85% programistów deklaruje wzrost osobistej produktywności dzięki AI. Ale korzyści na poziomie organizacji pojawiają się dopiero wtedy, gdy firma przebuduje cały proces, a nie tylko doda AI do istniejącego przepływu pracy. Szybsze pisanie kodu przy niezmienionej reszcie cyklu tworzenia oprogramowania może wręcz wydłużyć czas jego dostarczenia. Weryfikacja, testy i naprawy będą dotyczyć większej liczby zmian w kodzie.

Jakie bariery organizacyjne mogą pochłonąć korzyści z AI?

Widzę ich kilka i powtarzają się niezależnie od branży. Pierwsza to dług technologiczny. AI dobrze radzi sobie w nowych projektach, ale w dużych, starych, złożonych systemach – gdzie toczy się większość prawdziwego biznesu – napotyka ograniczenia architektoniczne. Ich żaden prompt nie rozwiązuje.

Druga bariera to bezpieczeństwo i Compliance. W sektorze finansowym każda zmiana w kodzie musi przejść przez warstwy kontroli regulacyjnej. AI może przyspieszyć pisanie, ale nie skraca procesu certyfikacji.

Trzecia to procesy decyzyjne. Trzeba odpowiedzieć sobie na takie pytania, jak: Kto zatwierdza kod wygenerowany przez agenta? Kto ponosi odpowiedzialność w przypadku awarii lub wycieku danych? Bez jasno zdefiniowanego modelu zarządzania AI te pytania blokują skalowanie bardziej niż jakikolwiek problem techniczny.

Jak definiujecie „odpowiedzialne wykorzystanie AI” w procesie wytwarzania oprogramowania?

Dla JetBrains odpowiedzialne wykorzystanie AI ma kilka niezbędnych elementów. Pierwszy to kontrola jakości, czyli mechanizmy, które egzekwują standardy niezależnie od tego, czy kod napisał człowiek, czy wygenerował agent.

Drugim są bezpieczeństwo i związany z nim nadzór człowieka. Mam tu na myśli podatności i błędne konfiguracje
w kodzie AI-assisted, które pojawiają się statystycznie częściej niż w kodzie pisanym ręcznie. Ktoś musi być w stanie przeczytać, zrozumieć i zatwierdzić wynik pracy AI.

Kolejnym elementem jest audytowalność, czyli możliwość odtworzenia tego, kto co zatwierdził i na jakiej podstawie. Dalej jest własność intelektualna, która jest szczególnie istotna przy generowaniu kodu przez modele trenowane na cudzym materiale.

I wreszcie zgodność regulacyjna, zwłaszcza w kontekście AI Act, który w Europie wchodzi w fazę egzekucji. Żaden z tych elementów nie jest opcjonalny. Razem tworzą tzw. infrastrukturę zaufania.

Jak powinien wyglądać rozsądny model „human in the loop” w zespołach programistycznych?

Nie ma jednej odpowiedzi, ponieważ zależy ona od kontekstu – krytyczności systemu, obszaru funkcjonalnego i dojrzałości procesu testowego w organizacji. Niemniej, można wskazać ogólne zasady.

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ć. Automatyzacja może działać bez bieżącej ingerencji człowieka przy dobrze pokrytych testami, rutynowych zadaniach – refaktoryzacjach, aktualizacjach zależności, generowaniu testów jednostkowych.

Natomiast całkowite wykluczenie człowieka z pętli ma sens wyłącznie w środowiskach, które dysponują dojrzałym systemem testów automatycznych i jasno zdefiniowanymi granicami bezpieczeństwa. W większości organizacji, z którymi pracuję, to wciąż odległa perspektywa.

Jaką rolę może odegrać środowisko programistyczne w zapewnieniu kontroli nad kodem współtworzonym przez AI?

IDE (Integrated Development Environment – przyp. red.) jest dziś czymś znacznie więcej niż edytorem tekstu. To przestrzeń stanowiąca laboratorium i warsztat rzemieślnika, gdzie na koniec zapada decyzja: zatwierdzam ten kod, czy nie.

I właśnie dlatego środowisko programistyczne staje się częścią infrastruktury Governance. Narzędzia takie jak Qodana, wbudowane bezpośrednio w IDE i zintegrowane z pipeline’em CI/CD, przenoszą logikę inspekcji kodu z manualnego, podatnego na pominięcia przeglądu do zautomatyzowanego procesu osadzonego w cyklu wytwarzania.

Te same reguły jakości i bezpieczeństwa, które obowiązują w całym projekcie, są weryfikowane przy każdym zatwierdzeniu zmian – niezależnie od presji terminu i składu zespołu. To zmiana fundamentalna. IDE przestaje być narzędziem indywidualnej produktywności, a staje się infrastrukturą odpowiedzialności.

Dlaczego przejście od osobistych korzyści z AI do mierzalnych efektów biznesowych całej organizacji okazuje się trudne?

Raport McKinsey z czerwca 2026 roku wskazuje Polskę jako kraj z największą w Europie Środkowej luką między indywidualnym korzystaniem z AI a adopcją na poziomie organizacji. 29% Polaków używa AI na co dzień, ale tylko 8% firm stosuje ją w działalności operacyjnej. Skąd ta różnica? Przede wszystkim z braku infrastruktury pomiarowej. Firmy nie wiedzą, ile kosztuje AI w poszczególnych zespołach, które zastosowania faktycznie przynoszą efekty i kto jest odpowiedzialny za wyniki.

Bez tej wiedzy korzyści indywidualne nie kumulują się w korzyści organizacyjne. Po prostu nie ma mechanizmu, który by to umożliwiał. Drugi problem to brak przebudowy procesów. AI dodana do istniejącego przepływu pracy nie zmienia jego efektywności. Zmienia ją dopiero wtedy, gdy firma przeprojektuje procesy wokół AI.

Jakie błędy najczęściej popełniają organizacje, które kupują narzędzia AI, ale po kilku miesiącach nie widzą wyraźnego zwrotu z inwestycji?

Widzę trzy powtarzające się wzorce. Po pierwsze, traktowanie AI jak zakupu narzędziowego zamiast zmiany procesowej. Firma kupuje licencje, deweloperzy zaczynają korzystać indywidualnie, ale procesy pozostają niezmienione.

Po drugie, firma nie wie, ile wydaje na AI ani czy te wydatki przynoszą wyniki. Koszty tokenów narastają, ale nikt nie potrafi powiedzieć, które projekty skorzystały, a które nie. Bez tej wiedzy nie ma możliwości skalowania tego, co działa.

Po trzecie, nie ma zdefiniowanej odpowiedzialności personalnej. Kto w organizacji odpowiada za wyniki wdrożenia AI? Jeśli nikt, to trudno mówić o mierzalnym ROI. Wspomniane przeze mnie wcześniej badanie McKinsey wskazuje, że firmy, które faktycznie czerpią korzyści finansowe z AI, łączy jedna cecha – mierzą efekty i zmieniają struktury decyzyjne tak, by były za nie odpowiedzialne.

Jakie wskaźniki JetBrains rekomenduje do oceny wpływu AI na proces tworzenia oprogramowania?

Zacznę od tego, czego nie rekomendujemy – liczby linii kodu i czasu zaoszczędzonego na pisaniu. To metryki, które wyglądają dobrze w prezentacji, ale nie mówią nic o wartości biznesowej.

Z perspektywy zarządu najbardziej wiarygodne są: skrócenie czasu przeglądów kodu, zmiana wskaźnika defektów trafiających na produkcję, średni czas naprawy błędu w przypadku incydentów powiązanych z kodem oraz trendy długu technicznego mierzone narzędziami analizy statycznej.

Do tego dochodzi koszt tokenów AI na projekt i zespół, który pozwala odpowiedzieć na pytanie, czy pieniądze są wydawane tam, gdzie faktycznie tworzona jest wartość. Metryki powinny mierzyć wynik, a nie aktywność.

Czy programista przestaje być przede wszystkim „koderem”, a staje się architektem i orkiestratorem systemów AI?

Tak, i dane to potwierdzają. Zapytani o kluczowe kompetencje w horyzoncie najbliższych pięciu lat, polscy deweloperzy wskazują: krytyczne myślenie, architekturę oprogramowania i zarządzanie systemami AI. Tylko 11% uważa, że tradycyjne ręczne pisanie kodu zachowa dotychczasową wagę.

Nie oznacza to, że umiejętność programowania przestaje być ważna – wręcz przeciwnie. Ale 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. To wymaga głębszego rozumienia architektury systemu niż kiedykolwiek wcześniej. AI podnosi poprzeczkę dla deweloperów – nie obniża jej.

Co sprawia, że Polska jest dla JetBrains rynkiem strategicznym i jaką rolę mogą odegrać polscy specjaliści?

Poczyniliśmy inwestycje w Polsce z kilku powodów. Przede wszystkim jest to dojrzałość techniczna, świetne uczelnie, odpowiednio przygotowani specjaliści z pokaźną praktyką. Nasze badanie AI Pulse 2026 pokazuje, że 82% polskich deweloperów ma co najmniej 6 lat doświadczenia zawodowego, wobec 64% globalnie. To społeczność, która nie uczy się podstaw, ona wdraża zaawansowane rozwiązania.

Równie istotna szybkość adopcji. Polskie firmy są bardziej otwarte na AI Coding Agents niż większość rynków europejskich. W kontekście Polski nie można pominąć ekosystemu fintechowego. Z mojej perspektywy jest on szczególnie istotny: Polska ma jedną z najdynamiczniejszych scen FinTech w regionie CEE. Sektor finansowy jest zaś dziś jednym z kluczowych obszarów wdrożeń AI w software developmencie.

Rozbudowujemy w Warszawie centrum badawczo-rozwojowe właśnie dlatego, że jakość inżynierów, z którymi współpracujemy, jest wyjątkowa.

Jaką najważniejszą zmianę chcecie pokazać liderom biznesu na konferencji JetBrains Air Day Poland 3 grudnia?

Chcemy podkreślić, że AI w software developmencie weszła w nową fazę. Wymaga ona innego zestawu decyzji niż dotychczas. Pierwszym etapem była adopcja: kupowanie narzędzi, testowanie, zachęcanie deweloperów do korzystania z nich. Ten etap jest za nami. Drugi rozdział to udowodnienie wartości. Tu liderzy biznesu mają do odegrania kluczową rolę, bo to wymaga decyzji organizacyjnych, nie technicznych.

Co będzie głównym tematem konferencji?

Głównym punktem naszej grudniowej konferencji będzie JetBrains Air – platforma do zarządzania AI w procesie wytwarzania oprogramowania. To odpowiedź na pytanie, które słyszę od CTO i CFO coraz częściej: „wiemy, że nasi deweloperzy używają AI, ale nie wiemy ile to kosztuje, gdzie to działa i kto za to odpowiada”.

JetBrains Air łączy narzędzia deweloperskie, agentów AI i infrastrukturę wykonawczą w jeden zarządzany ekosystem. Działa na trzech poziomach. Pierwszy to Governance i kontrola – egzekwowanie polityk dostępu, zarządzanie tożsamością, weryfikacja operacji i, 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 korzystacie z narzędzi JetBrains, czy zewnętrznych, takich jak Claude, Codex czy Gemini.

Trzeci to współdzielony kontekst semantyczny. Jest to mechanizm, który pozwala agentom rozumieć architekturę całego systemu, a nie tylko odpowiadać na izolowane polecenia.

To nie jest kolejne narzędzie dla programistów. To infrastruktura, która pozwala organizacji zarządzać AI jak każdą inną inwestycją: widocznością kosztów, mierzalnymi wynikami i jasną odpowiedzialnością za efekty. I właśnie to chcemy pokazać liderom 3 grudnia.