W dyskusji o sztucznej inteligencji w programowaniu zbyt często zatrzymujemy się na najbardziej efektownym, ale też najpłytszym poziomie. Patrzymy na to, czy model napisze funkcję, poprawi błąd, wygeneruje test albo podpowie kilka linijek kodu. To oczywiście działa na wyobraźnię, bo kod pojawia się na ekranie niemal natychmiast, ale w prawdziwej pracy nad oprogramowaniem najwięcej czasu nie zawsze znika przy samym klepaniu znaków. Największy ciężar leży zwykle gdzie indziej. W zrozumieniu starego systemu, ustaleniu zależności, dopasowaniu zmian do architektury, przejściu przez testy, dokumentację, bezpieczeństwo, proces wdrożenia i wszystkie te firmowe ograniczenia, które od środka często chronią przed katastrofą.
Dlatego kiedy patrzę dziś na IBM Bob, nie widzę po prostu kolejnego asystenta kodowania. Widzę raczej próbę przesunięcia narzędzia z roli “sprytnego podpowiadacza” do roli narzędzia, które ma rozumieć cały rytm opracowywania, rozwijania i wreszcie dostarczania oprogramowania. Nie jest to bowiem twór kogoś, kto nigdy nie napisał linijki kodu i nie musiał rozwijać swojego oprogramowania. Tak przynajmniej twierdzi firma, utrzymując, że ten agent został opracowany od podstaw na podstawie analiz oraz zapotrzebowania klientów, a następnie wdrożony w działalność IBM i następnie dalej rozwijany oraz ulepszany.
IBM Bob nie chce być kolejnym chatbotem do kodu
Pod koniec kwietnia 2026 roku IBM udostępnił Boba globalnie i zaczął opisywać go nie jako kolejny generator kodu, lecz jako partnera AI dla całego procesu wytwarzania oprogramowania. Nie jest to bowiem zwykły generator kodu, lecz narzędzie wspierające pełny cykl SDLC, a więc planowanie, projektowanie, kodowanie, testowanie, wdrażanie, operacje i modernizację starszych systemów. Według ogłoszeń IBM z Boba korzysta już ponad 80 tys. pracowników firmy, a ankietowani użytkownicy deklarują średnio 45-procentowy wzrost produktywności.
W rozmowie ze mną Sławomir Kumka, dyrektor IBM Software Lab w Polsce, zwraca uwagę, że Bob nie jest narzędziem projektowanym z myślą o użytkowniku, który chce po pracy zapytać AI o fragment kodu do prywatnego projektu. IBM myśli o nim jako o platformie dla dużych organizacji, które chcą przebudować sposób pracy nad oprogramowaniem.
Bob jest dostępny dla naszych klientów jako platforma, którą mogą zainstalować i wdrożyć u siebie w organizacjach, a następnie na jej bazie zmieniać sposób, w jaki programują – mówi Sławomir Kumka, dyrektor IBM Software Lab w Polsce.
Dla mnie to ważny punkt wyjścia. Bob nie ma być bowiem byle czatem otwartym w drugiej zakładce przeglądarki. Ma być elementem procesu, czyli czymś wpiętym w firmowe role, narzędzia, polityki, dane, repozytoria, logi, testy i ograniczenia bezpieczeństwa. Jest to więc zupełnie inny poziom ambicji niż “wpisz prompt i odbierz linijki kodu”. Podobny kierunek zauważyłem już przy agentowych komputerach i lokalnej sztucznej inteligencji, gdzie sama moc modelu przestaje być najważniejszą opowieścią. Coraz częściej liczy się cały przepływ pracy. Nie tylko to, co AI potrafi wygenerować, ale też gdzie ta generacja trafia i kto ją sprawdza.
Największy problem zaczyna się tam, gdzie wchodzi praktyka
Agent pokroju IBM Bob nie próbuje odpowiadać na pytanie “jak zastąpić programistów”, tylko “jak ograniczyć cały chaos wokół programowania”. Podczas gdy pierwsza wizja żyje sobie w najlepsze w mediach społecznościowych, druga interesuje firmy, które mają dziesiątki repozytoriów, skomplikowane zależności, systemy pamiętające kilka epok technologicznych i ludzi bojących się ruszyć stary moduł, bo ostatnim razem po podobnej zmianie nagle przestał działać ważny proces biznesowy. IBM kieruje Boba przede wszystkim w stronę środowisk, w których sama produkcja kodu jest tylko fragmentem większego problemu.
Wiemy mniej więcej, do czego jeszcze Boba nie używać, a gdzie widzimy największe benefity. Dobrym przykładem są bardzo skomplikowane środowiska cloudowe, gdzie mamy dziesiątki serwisów, tysiące relacji i czasami jeden defekt powoduje, że system całkowicie przestaje działać – tłumaczy Sławomir Kumka.
Tutaj zaczyna się ta ciekawsza część historii. W dużym systemie problemem nie zawsze jest napisanie poprawki. Często najtrudniejsze jest znalezienie miejsca, w którym w ogóle trzeba zacząć szukać. Programista nie siedzi wtedy nad jedną funkcją, tylko nad śladem transakcji przechodzącej przez wiele usług, konfiguracji, zależności i logów. IBM Bob nie ogranicza się jednak wyłącznie do kodowania, jak to ma w zwyczaju wielu agentów AI dla programistów. Jednym z kluczowych przypadków jego użycia jest wsparcie w identyfikowaniu defektów. Zwłaszcza wtedy, gdy problem nie wynika z jednego oczywistego błędu, tylko z zachowania systemu jako całości.
Bob, znając kod użyty do zrealizowania produktu, wie, którą ścieżką idzie wykonanie danego programu. Mając logi z tysięcy serwisów, czasami idące w miliony, [Bob] potrafi wyłuskać i zawęzić obszar, który programista analizuje potem w ciągu godziny czy dwóch – wyjaśnia Kumka.
Czytaj też: Świat bez treści AI był lepszy. Dziś obawiam się o przyszłość Internetu
Jeżeli AI może zawęzić obszar poszukiwań w środowisku złożonym z dziesiątek albo setek usług, to przestaje być zabawką do szybkich odpowiedzi, a zaczyna przypominać swojego rodzaju zaawansowany filtr przez złożoność systemu. Filtr taki, który do niedawna mógł być utożsamiany z tym jednym wyjątkowym specjalistą w całej firmie o stażu przekraczającym wiek juniora, który jako jedyny wie, gdzie w ogóle zacząć pracę, aby rozwiązać jakiś problem.
Architektura zostaje po stronie człowieka
Podczas rozmowy najbardziej zaimponowało mi praktyczne podejście do tematu sztucznej inteligencji, która tylko pozornie nadaje się do wszystkiego. W praktyce jednak wcale taka nie jest.
Architektura na poziomie projektu długo jeszcze nie będzie dostarczana przez sztuczną inteligencję. Szkielet, zarys albo roadmapa – tak, bo to może być dobre narzędzie edukacyjne. Natomiast zaprojektowanie i zbudowanie architektury, która ma służyć jako rozwiązanie enterprise, absolutnie jeszcze nie na tym etapie – skomentował Sławomir Kumka.
Rzeczywiście AI może pomóc w analizie, zawężaniu problemu, edukacji, refaktoryzacji, dokumentacji i pracy z ogromną ilością danych. Może też przygotować szkic, podpowiedzieć kierunek albo pomóc człowiekowi szybciej wejść w nieznany obszar. Nie oznacza to jednak, że można jej oddać projektowanie architektury systemu, który ma działać latami, spełniać wymagania bezpieczeństwa, skalować się, przechodzić audyty i znosić zmiany organizacyjne. Nie chodzi przecież o narysowanie kilku prostokątów i strzałek. Architektura to decyzje, które będą odbijały się przez lata, jak nie całe dekady na kosztach utrzymania, bezpieczeństwie, łatwości rozwoju, zależnościach między zespołami i odporności firmy na awarie. AI może tu pomagać, ale odpowiedzialność za decyzję nadal zostaje po stronie człowieka.
Bob nie odpowiada za wszelką cenę
Jest jeszcze jeden element, którego w przypadku takich narzędzi nie wolno pomijać. AI w programowaniu często kusi pozorną pewnością. Pytamy o coś nieprecyzyjnie, dostajemy odpowiedź napisaną gładkim językiem, a dopiero potem, bo w kodzie, testach albo produkcji okazuje się, że model wcale nie zrozumiał problemu.
Nieważne, jak dobrze sztuczna inteligencja byłaby wyszkolona i jak dobrze rozumiałaby elementy systemu, jeżeli zadamy pytanie śmieciowe, tak czy inaczej dostaniemy śmieci na końcu. Cały czas funkcjonuje zasada Trash in, Trash out – mówi Sławomir Kumka.
Dlatego istotne jest nie tylko to, czy Bob potrafi wygenerować odpowiedź, ale też to, jak zachowuje się wtedy, gdy pytanie jest niepełne, źle postawione albo prowadzi w złą stronę. Według Kumki IBM próbuje unikać modelu, w którym narzędzie za wszelką cenę natychmiast udziela odpowiedzi.
Stworzyliśmy narzędzie, które w przeciwieństwie do innych rozwiązań tego typu nie stara się na siłę udzielić odpowiedzi natychmiast, ale buduje zestaw pytań, które naprowadzają je na to, w którą stronę powinno patrzeć – tłumaczy Kumka.
Pozornie wygląda to na detal, ale takie coś jest w moich oczach jednym z ważniejszych elementów całej układanki z wykorzystywaniem AI do programowania. Szybka odpowiedź bywa bowiem mniej wartościowa niż dobra diagnoza. Jeśli bowiem system sztucznej inteligencji nie rozumie pytania, to nie powinien udawać, że go rozumie. Zamiast tego powinien dopytać, zawęzić problem i dopiero wtedy ruszyć dalej. Model, który zawsze “coś” odpowie, łatwo robi wrażenie kompetentnego, ale w praktyce może tylko przyspieszać błąd. Narzędzie, które potrafi zatrzymać się i dopytać, jest dużo bliższe temu, jak wygląda prawdziwa praca nad złożonym systemem.
Enterprise potrzebuje kontroli, a nie tylko szybkości
IBM mocno podkreśla, że Bob wykracza poza generowanie kodu i ma obejmować zarządzanie, zgodność oraz bezpieczeństwo na każdym etapie pracy. Firma opisuje go przecież jako partnera do rozwoju oprogramowania na poziomie systemowym, a więc takiego, który ma pomagać zespołom szybciej dostarczać oprogramowanie, modernizować starsze systemy i jednocześnie utrzymać kontrolę wymaganą w dużych organizacjach. Jest to akurat kluczowe, bo różnica między AI dla prywatnego użytkownika a AI dla dużej organizacji zaczyna się tam, gdzie pojawiają się dane.
Kod, logi, dokumentacja, architektura systemów, błędy, zależności, dane klientów i konfiguracje środowisk nie są materiałem, który można bezrefleksyjnie wrzucić do dowolnego narzędzia chmurowego. Dlatego Bob nie ma być tylko “szybkim narzędziem”. Ma być narzędziem, którego działanie da się kontrolować. W tym kontekście szczególnie ważne jest podejście do kodu generowanego lub wspomaganego przez AI.
U nas w IBM nie ma czegoś takiego, że kod jest stworzony przez sztuczną inteligencję. On może być wspomagany. Natomiast by design kod wychodzi spod ręki programisty. Kod, który jest niezrozumiały, też jest dyskwalifikowany. Sztuczna inteligencja jest świetna w pisaniu w miarę zoptymalizowanego kodu, którego potem nikt nie rozumie – podkreśla Kumka.
Dobrze odcina to wszelkie fantazje o programiście, który tylko zatwierdza cudze rozwiązania. W takim modelu człowiek nie jest podpisem pod kodem wygenerowanym przez AI. Jest ostatnim odpowiedzialnym ogniwem procesu. Jeżeli nie rozumie, co zatwierdza, to cały ten system traci z automatu sens. Dobry kod nie jest bowiem tylko kodem, który działa. Musi być jeszcze zrozumiały, zdatny do utrzymywania przez cały cykl życia oprogramowania i bezpieczny do rozwijania przez ludzi, którzy nie siedzieli obok modelu w chwili jego generowania. Innymi słowy, era AI wcale nie zabiła zasad SOLID.
Szybciej nie zawsze znaczy lepiej
Warto przy tym zachować ostrożność wobec prostych obietnic produktywności. IBM podaje solidne liczby, a skala wewnętrznego użycia Boba robi wrażenie, ale historia narzędzi sztucznej inteligencji dla programistów już pokazała, że subiektywne poczucie przyspieszenia nie zawsze pokrywa się z mierzalnym efektem. Dobry kontrapunkt zapewnia tutaj badanie METR z 2025 roku. Doświadczeni programiści open source pracowali w nim na znanych sobie repozytoriach i spodziewali się, że AI skróci czas pracy. Wynik okazał się odwrotny, bo przy użyciu narzędzi AI zadania zajmowały im o 19 procent więcej czasu niż bez nich.
Czytaj też: Ja programuję gry, a oni samą materię. Spytacie pewnie, kto jest szczęśliwy?
Jest to ostrzeżenie przed naiwnym myśleniem, że samo wpięcie narzędzi AI do procesu automatycznie przyspiesza wszystko i wszystkich. W znanym, dobrze opanowanym przez programistów repozytorium model tego typu może wręcz przeszkadzać. Jednak w ogromnym, rozproszonym środowisku enterprise, gdzie problemem jest analiza milionów logów i zależności między usługami, może pomagać. Kluczowe jest więc nie samo “AI”, tylko miejsce, w którym zostaje użyte.
AI nie zabija programisty, ale obnaża, czym naprawdę jest programowanie
Czy Bob okaże się tak ważny, jak sugeruje IBM? Tego dziś nie przesądzałbym z pełnym przekonaniem. Rynek AI pełen jest narzędzi, które w pokazach wyglądają fenomenalnie, a rozbijają się na problemach codziennego użytku. Oczywiście nie wszystkie narzędzia są sobie równe, ale pracuję nad własnymi grami i doskonale wiem, że nawet samo wspomaganie się sztuczną inteligencją wymaga uwagi, a nie bezmyślnego kopiowania rozwiązań w ciemno.
Dlatego zresztą cieszę się, że nawet w tak skomplikowanych narzędziach pokroju IBM Bob znajduje się miejsce na rozsądek, a nie obiecywanie gruszek na wierzbie. Dziś bowiem nie chodzi już tylko o AI, która napisze szybciej kilka linijek. Chodzi o AI, która rozumie proces, ograniczenia, bezpieczeństwo, koszt, dane, logi i odpowiedzialność. Chodzi o narzędzie, które nie tylko “umie kodować”, ale pomaga człowiekowi odnaleźć się w systemach tak kompleksowych, że sama ich dokumentacja to lektura na wiele tygodni, jak nie miesięcy.
Czytaj też: Zrobili darmowe narzędzie, które zawstydza całą branżę. Sztuczna inteligencja może być “dobra”
Przyszłość programowania nie musi więc polegać na tym, że sztuczna inteligencja napisze aplikację od zera za każdego. Może polegać na czymś znacznie mniej efektownym, ale znacznie ważniejszym, bo na tym, że pomoże ludziom bezpiecznie ruszyć kod, którego bali się dotykać od dekady. Bob ma być zapowiedzią właśnie takiej przyszłości. Nie jako maszyna do produkowania kodu na akord, lecz jako narzędzie do bezpiecznego ruszania systemów, których złożoność przez lata stała się większym problemem niż samo programowanie.
