Twój następny kolega z zespołu to będzie AI. 30 tys. programistów IBM pracuje z Bobem na co dzień
Bob nie pije kawy, nie chodzi na urlop i nie ma problemu z wejściem w dziesięcioletni, niedokumentowany monolit złożony z setek tysięcy linii kodu. Zmienił IBM-a na lepsze. To samo możliwe jest w twojej firmie.
Wyobraź sobie, że zaczynasz nową pracę. Twój menedżer mówi ci, że w ciągu tygodnia masz samodzielnie ogarnąć bazę kodu liczącą kilkaset tysięcy linii, napisaną przez kilkanaście rotujących się zespołów przez ostatnią dekadę, z dokumentacją na poziomie „po co dokumentować, przecież to oczywiste". Takie sytuacje nie są w dużych firmach technologicznych żadną egzotyką - to codzienność. I właśnie w tej codzienności IBM postanowił zmienić coś bardzo konkretnego.
Od nieco ponad roku IBM wdraża wśród własnych deweloperów narzędzie o nazwie Bob. Nie jest to kolejny kopilot robiący za wyszukane narzędzie do autouzupełniania ani chatbot przebrany za asystenta programisty. Bob to, jak IBM go określa, partner AI działający na poziomie całego cyklu wytwarzania oprogramowania - od projektowania architektury, przez pisanie kodu, po wdrożenie i utrzymanie. Skala wdrożenia jest dziś jednym z największych tego typu eksperymentów w historii korporacyjnej informatyki: ok. 30 tys. programistów IBM aktywnie używa Boba, 95 proc. z nich włączyło go zaraz po onboardingu, a 65 proc. sięga po niego codziennie.
Liczby są imponujące, ale prawdziwie interesujące jest to, co za nimi stoi: jak wygląda biuro programisty, gdy AI staje się częścią jego codziennego rytmu pracy? Co się zmienia, a co nie?
Problem, który Bob ma rozwiązać - a nie jest trywialny
Dlaczego IBM w ogóle stworzył własne narzędzie zamiast kupić licencję na dostępne już rozwiązania od dostawców AI? Odpowiedź tkwi w naturze pracy w dużej korporacji technologicznej. Oprogramowanie korporacyjne rzadko jest uporządkowane. To kilkadziesiąt wzajemnie powiązanych repozytoriów, systemy legacy pisane w językach, które młodsi deweloperzy znają tylko z Wikipedii (COBOL, RPG, stare dialekty Java), dziesiątki mikroserwisów, własne pipeline'y CI/CD, procesy compliance i bezpieczeństwa, których naruszenie kończy się audytami regulatorów. W takim środowisku narzędzie, które rozumie tylko jeden plik naraz i podsuwa inteligentne autouzupełnienianie jest jak luksusowy długopis przy próbie przepisania Encyklopedii Britannica.
Badania METR z początku ubiegłego roku pokazały coś przewrotnego: deweloperzy używający dostępnych wtedy asystentów AI spodziewali się 24 proc. wzrostu produktywności, a w praktyce przy złożonych, enterprise'owych bazach kodu pracowali o 19 proc. wolniej niż bez AI. Nie dlatego, że AI było bezużyteczne - ale dlatego, że istniejące narzędzia nie rozumiały kontekstu systemu. Generowały kod, który wyglądał poprawnie w izolacji, ale się nie kompilował albo łamał zależności w innym repozytorium.
IBM zaprojektował Boba dokładnie pod ten problem. Różnica architektoniczna jest fundamentalna: Bob nie pracuje na poziomie pliku, ale na poziomie całego repozytorium - a właściwie wielu repozytoriów naraz. Zanim zaproponuje jakąkolwiek zmianę buduje sobie model całego systemu: warstwy architektoniczne, zależności między komponentami, konfiguracje, polityki bezpieczeństwa. Dopiero z tym kontekstem przystępuje do działania.
Jak wygląda dzień pracy z Bobem
Bob żyje w IDE i w terminalu. Nie zmusza do przejścia do przeglądarki ani do zewnętrznej aplikacji - integruje się z VS Code i innymi edytorami, a BobShell działa bezpośrednio w konsoli.
Kilka trybów pracy determinuje do czego Bob jest używany w danym momencie. Tryb Plan to etap, zanim w ogóle ruszy się kod - Bob analizuje repozytorium jako system, identyfikuje wzajemne powiązania i proponuje plan zmian w postaci czytelnej listy kroków. Tryb Code to właściwe implementowanie - Bob pisze, refaktoryzuje lub modernizuje kod z uwzględnieniem architektury całego projektu. Tryb Ask służy do pytań - „co robi ta funkcja?", „dlaczego ta zależność tutaj istnieje?", „jakie są implikacje zmiany tego interfejsu?". Tryb Advanced obsługuje złożone, wieloetapowe zadania, gdzie Bob orkiestruje serię czynności z walidacją i punktami akceptacji między krokami.
W praktyce wygląda to tak: deweloper opisuje naturalnym językiem co chce osiągnąć. Bob nie rzuca od razu kodu - najpierw proponuje plan, który programista może przejrzeć, zatwierdzić lub zmodyfikować. Dopiero po akceptacji Bob przystępuje do zmian. Każda zmiana jest audytowalna, każde decyzja wyjaśniona.
Onboarding: tygodnie skrócone do dni
Jeden z najbardziej namacalnych przypadków użycia Boba to onboarding nowych pracowników. Każda duża firma technologiczna zna ten scenariusz: nowy deweloper siada przed ogromną bazą kodu, nie ma dokumentacji albo jest nieaktualna, a jedyni ludzie którzy naprawdę rozumieją architekturę są na urlopach albo już dawno odeszli do innych firm.
Zespół tworzący IBM Guardium - platformę do zarządzania bezpieczeństwem danych - miał dokładnie ten problem przy budowie nowej platformy danych. Zespół musiał szybko zrozumieć, udokumentować i uzgodnić architekturę systemu między wieloma kontrybutorami. Bob wygenerował wyjaśnienia architektury, dokumentację i przeprowadził deweloperów przez wbudowane w codebase workflow - raportowany wzrost produktywności wyniósł 85 proc., a praca, która normalnie zajmuje cztery tygodnie została wykonana w jeden dzień. To nie „literówka”: cztery tygodnie skróciły się do jednego dnia.
Program Director Product Management w IBM, Mat Rodkey, demonstrując Boba analitykowi RedMonk, pokazał właśnie ten przypadek - nowy pracownik, zero znajomości codebase'u, i Bob jako przewodnik po architekturze systemu. Typowe enterprise'owe pytania w stylu „dlaczego ta klasa jest tu, a nie tam" czy „jakie są konsekwencje zmiany tego API" przestają wymagać godzin archeologii w historii commitów.
Podobną historię opisuje japońska firma NI+C, która utrzymywała systemy IBM i (AS/400) z programami RPG działającymi niezmiennie przez ponad dekadę. Specyfikacja tych systemów istniała wyłącznie w głowach starzejących się inżynierów - nie było żadnej dokumentacji. Bob za pomocą funkcji Explain przeanalizował złożone programy RPG, rozszyfrował wielopoziomowe struktury warunkowe i wygenerował dokładną dokumentację projektową, włącznie z diagramami Mermaid wizualizującymi przepływy procesów. „Wygenerowana dokumentacja projektowa była tak dokładna, że zdumiewała nawet doświadczonych inżynierów, którzy próbowali innych narzędzi AI i uważali je za zbyt ograniczone do praktycznego zastosowania” - podsumowali przedstawiciele firmy.
Modernizacja legacy systems: tygodnie w godziny
Oprócz onboardingu to właśnie modernizacja starych systemów jest miejscem, gdzie Bob generuje najbardziej spektakularne wyniki. I to jest też obszar, gdzie IBM - jako firma z gigantyczną zainstalowaną bazą legacy software'u u klientów - miał szczególny interes w stworzeniu skutecznego narzędzia.
APIS-IT, chorwacka firma świadcząca usługi IT dla administracji publicznej, potrzebowała zrefaktorować dziesięcioletni serwis .NET SOAP do nowoczesnej architektury REST API na .NET 8. Manualna transformacja tego rodzaju zajmuje zazwyczaj kilka tygodni, a ryzyko regresji jest wysokie. Z Bobem cały serwis został przepisany w 5-6 godz. pracy rozłożonej na iteracyjne sesje - z zerowymi błędami kompilacji i pełną zgodnością z nową architekturą. „Wszystko, co myślałem, że będzie problemem, Bob rozwiązał” - ocenił deweloper projektu.
Jeszcze bardziej efektowna historia pochodzi z firmy Blue Pearl, południowoafrykańskiego dostawcy usług IT. Potrzebowali przeprowadzić migrację swojej platformy do dopasowywania konsultantów z Java 11 do Java 25 LTS. Standardowy czas modernizacji takiego projektu: kilka tygodni. Z Bobem - trzy dni, przy zachowaniu jakości produkcyjnej. Firma zaoszczędziła ponad 160 godz. inżynierskich i przy okazji zidentyfikowała 15-20 potencjalnych projektów modernizacyjnych u własnych klientów.
Wewnątrz IBM analogiczne wyniki osiągnął zespół IBM Maximo (oprogramowanie do zarządzania zasobami). Modernizacja dużych, silnie powiązanych ze sobą baz kodu przyniosła ok. 55 proc. wzrostu produktywności - praca zajmująca wcześniej tygodnie skurczyła się do godzin.
Compliance: 30 dni w 2 dni
Jest jeszcze jeden obszar, który w korporacyjnym świecie pożera czas programistów w sposób szczególnie demotywujący: procesy compliance i bezpieczeństwa. Audyty, mapowanie wymagań regulacyjnych na kod, dokumentowanie zmian pod FedRAMP, HIPAA, PCI - to praca żmudna, powtarzalna i niezbędna zarazem.
IBM Concert & FedRAMP - wewnętrzny projekt IBM - miał cykl walidacji compliance trwający 30 dni. Był w pełni manualny i tworzył opóźnienia przy każdym release'ie. Bob zautomatyzował mapowanie wymagań compliance, generowanie dokumentacji i walidację bezpośrednio w workflow deweloperskim - 30 dni skróciło się do 2, a oszczędność na każdym projekcie compliance szacowana jest na 84 tys. dol.
Bob realizuje tu coś, co IBM nazywa podejściem „shift left" - zamiast sprawdzać bezpieczeństwo i zgodność po wdrożeniu (lub gorzej: po incydencie) kontrole są wbudowane w proces pisania kodu. Agent bezpieczeństwa w Bobie monitoruje kod na bieżąco, wykrywając podatności i antywzorce i od razu proponując gotowe patche. To trochę jak korektor w edytorze tekstu, tyle że zamiast ortografii sprawdza podatności klasy SQL injection.
Bobalytics, czyli AI, która uczy się siebie samej
Jedną z mniej oczywistych, ale technicznie ciekawych cech Boba jest moduł Bobalytics - system ciągłej samoptymalizacji. Bob nie korzysta z jednego stałego modelu językowego. W zależności od zadania wybiera optymalny LLM spośród dostępnych: Claude od Anthropic, Mistral, Meta Llama, IBM Granite. To semantic routing - inteligentne kierowanie różnych typów zapytań do różnych modeli w zależności od ich charakterystyki.
Bobalytics zbiera dane o skuteczności wykonanych zadań, kosztach i jakości wyników, a następnie automatycznie dostosowuje strategię wyboru modeli i formułowania promptów. IBM stosuje model pass-through pricing, co oznacza, że każda optymalizacja bezpośrednio przekłada się na niższe koszty dla klientów. W praktyce: im dłużej Bob działa w organizacji, tym lepiej działa i tym taniej działa.
Ciekawostka: 45 proc. własnego kodu produkcyjnego platformy Bob zostało wygenerowane przez samego Boba. Firma dosłownie użyła swojego produktu do budowy tego produktu.
Dla kogo to jest - i czy to jest dla każdego
Warto być szczerym: Bob jest przede wszystkim narzędziem enterprise’owym. Nie jest to wtyczka dla freelancera piszącego strony w WordPressie ani dla indie develope'ra robiącego grę w Unity w weekend. Jego przewaga przejawia się w złożonych środowiskach - wielkich bazach kodu, skomplikowanych zależnościach, środowiskach regulowanych, wielozespołowych projektach z latami historii.
Dla tego profilu użytkownika - a jest to kilkadziesiąt milionów programistów na świecie pracujących w bankach, ubezpieczalniach, firmach przemysłowych, agencjach rządowych, dużych domach software'owych - Bob adresuje problem, który inne narzędzia tylko częściowo rozwiązują. Koordynacja zmian między repozytoriami, kontekst całego systemu, orkiestracja wieloetapowych zadań z walidacją, wbudowany compliance - to jest przestrzeń, gdzie Bob ma realną przewagę projektową.
Jednocześnie dane rynkowe pokazują szerszy trend, którego Bob jest częścią. Do końca bieżącego roku 84 proc. deweloperów używa lub planuje używać narzędzi AI w swojej pracy, a 51 proc. profesjonalnych programistów sięga po AI codziennie. Rynek asystentów do kodowania wyceniany był przez Gartnera w ubiegłym roku na 3-3,5 mld dol.
Chcesz poznać Boba od środka?
Jeśli po lekturze masz ochotę zobaczyć, jak Bob działa w praktyce - nie tylko na slajdach i czytając case study - dobrym kolejnym krokiem są szkolenia organizowane przez TD SYNNEX we współpracy z IBM. To okazja żeby przejść przez konkretne scenariusze użycia, zobaczyć typowy workflow z Bobem w enterprise’owym środowisku i zadać własne pytania ludziom, którzy na co dzień wdrażają to rozwiązanie u klientów.
Aktualne terminy i formaty szkoleń (warsztaty, kursy online, sesje techniczne) są na stronie TD SYNNEX Academy poświęconej IBM. Najbliższy webinar poświęcony Bobowi odbędzie się 22 maja - jeżeli chcesz lepiej zrozumieć, jak wygląda praca dewelopera ramię w ramię z tym AI‑owym „kolegą z zespołu” to warto się tam zapisać.
Ta skala mówi, że coś się naprawdę zmieniło
Są momenty, kiedy branżowe trendy przeskakują z fazy eksperymentu w fazę nowego standardu. Elektryczność w fabrykach, Internet w redakcjach, chmura w centrach danych. Te momenty rzadko wyglądają spektakularnie - pojawiają się jako seria praktycznych decyzji podejmowanych przez inżynierów, którzy mają konkretny problem do rozwiązania.
IBM wdrożył Boba wśród 30 tys. własnych deweloperów - nie jako pilotaż, nie jako proof of concept, ale jako codzienne narzędzie pracy. 95 proc. aktywacji nie jest wynikiem przymusu ani hype'u - to znak, że narzędzie jest wystarczająco użyteczne, żeby ludzie chcieli go używać z własnej woli. A 45 proc. średniego wzrostu produktywności, przy całym krytycznym dystansie do wszelkich liczb tego rodzaju, jest miarą, której nie da się zbagatelizować.
Dla programistów oznacza to nie koniec zawodu - ale jego redefinicję. Deweloper z Bobem spędza mniej czasu na pisaniu boilerplate'ów, ręcznym generowaniu dokumentacji i ślęczeniu nad starym kodem bez dokumentacji, a więcej na architekturze, decyzjach projektowych i rozwiązywaniu problemów, których AI jeszcze nie potrafi samodzielnie sklasyfikować. Awans w hierarchii zadań - od rzemiosła do inżynierii systemowej - to nie jest zła perspektywa.
Bob jest dostępny w ramach programu early access pod adresem ibm.com/products/bob.
