4 min.
Część 1: Ewolucja roli i narodziny „programisty-architekta”
Narzędzia AI przestały być jedynie niewielkim wsparciem, a stały się niemalże “partnerami” w codziennej pracy specjalistów IT. Dlatego też w branży coraz głośniej mówi się o zjawisku vibe codingu. Ta technologiczna rewolucja niesie ze sobą jednak fundamentalne pytania - np. czy programista to wciąż autor, czy już tylko krytyczny recenzent pracy maszyn?
Przez cały cykl rozmawiamy z Jarkiem Kuśmierkiem, Engineering Director Cloud Platform w Google Cloud . Pytamy o to, jak zmiana z „pisania” na „redagowanie” wpływa na kulturę inżynieryjną, dlaczego w erze AI dwuwarstwowe code review staje się absolutnym fundamentem oraz jak w praktyce wygląda zarządzanie systemami w firmie, w której już 75% kodu powstaje przy wsparciu sztucznej inteligencji.
theprotocol.it: W ostatnich dwóch latach bardzo popularny stał się tzw. vibe coding. Jak Pana zdaniem zmienia to sam proces developmentu w porównaniu z klasycznym/ dotychczasowym podejściem?
Jarek Kuśmierek: Vibe coding to dla nas nie tyle moda, co zmiana paradygmatu - programista wyznacza kierunek i projektuje logikę aplikacji, zamiast poświęcać godziny na ręczne tworzenie powtarzalnych, schematycznych elementów. W Google obserwujemy to bardzo namacalnie u nas samych: już 75% naszego kodu powstaje przy wsparciu AI.
Zmiana nie polega na tym, że „AI pisze kod", tylko że programista zaczyna od intencji architektonicznej i prowadzi maszynę przez kolejne warstwy implementacji. Proces ten ewoluuje z fazy „pisania” w stronę „redagowania i weryfikacji”. Jeszcze ważniejszym etapem staje się code review. Ten proces nigdy nie był dla nas formalnością, zawsze stanowił fundament naszej kultury inżynieryjnej i kolektywnej dbałości o najwyższą jakość rozwiązań. W erze AI dochodzi jednak dodatkowy etap weryfikacji. Dawniej osoba A pisała kod, a osoba B go sprawdzała. Dziś to proces dwuwarstwowy: programista (Osoba A) najpierw sam robi pierwsze, krytyczne review tego, co wygenerowało AI. Dopiero po jego walidacji kod trafia do drugiej osoby (Osoby B) na tradycyjne sprawdzenie. W efekcie praca inżyniera wymaga dziś znacznie głębszego zrozumienia całości systemu, a nie tylko pojedynczych linijek kodu.
theprotocol.it: Czy uważa Pan, że narzędzia AI przesuwają rolę programisty bardziej w stronę “architekta”? Czy możemy wtedy mówić, że programista jest autorem? Jak to wygląda w praktyce w dużych organizacjach?
Jarek Kuśmierek: Zdecydowanie tak. Rola programisty ewoluuje w stronę architekta komponentów i systemów. Osoby stawiające pierwsze kroki w karierze przejmują odpowiedzialność za projektowanie mniejszych modułów, podczas gdy doświadczeni inżynierowie skupiają się na architekturze całych, złożonych ekosystemów. W dużych organizacjach autorstwo polega dziś na projektowaniu wysokopoziomowej logiki i orkiestracji przepływów pracy (agentic workflows), podczas gdy AI zajmuje się implementacją poszczególnych modułów. Programista staje się kuratorem kodu, który musi dbać o spójność całego zunifikowanego stosu narzędzi i zapewniać, że tworzone rozwiązania są bezpieczne i skalowalne. Warto pamiętać, że AI nie posiada świadomości ani własnych intencji. Dlatego developer, poza projektowaniem całości, staje się też audytorem detali. W Google dbamy o to, by oprogramowanie radziło sobie nie tylko w idealnych warunkach, ale przede wszystkim w sytuacjach skrajnych (corner cases). Model AI bez problemu wygeneruje bazę pod standardowy scenariusz. To człowiek musi jednak zadać pytania o wyjątki: co się stanie, gdy nagle padnie serwer? Jak kod zareaguje na awarię powiązanej aplikacji? Co jeśli użytkownik będzie miał złe intencje? Bezpieczeństwo i odporność systemu wciąż są w dużym stopniu w rękach człowieka.
theprotocol.it: Jak Pana zdaniem zmieni się struktura ról w IT w najbliższych 5–10 latach? Które role będą zyskiwać na znaczeniu, a które mogą zostać częściowo zautomatyzowane lub zniknąć?
Jarek Kuśmierek: Perspektywa 5–10 lat w IT to dziś niezwykle odległy horyzont, dlatego łatwiej jest przewidzieć, co wydarzy się w ciągu 2-3 lat. Zadania czysto odtwórcze, takie jak pisanie prostych testów czy podstawowa refaktoryzacja, zostaną w pełni zautomatyzowane, co pozwoli inżynierom skupić się na bardziej zaawansowanych wyzwaniach. Na znaczeniu zyskają przede wszystkim role związane z projektowaniem złożonych ekosystemów oraz specjaliści od bezpieczeństwa systemów autonomicznych. Warto jednak zachować zdrowy sceptycyzm wobec teorii, że sztuczna inteligencja wyeliminuje potrzebę posiadania głębokiej wiedzy technicznej. O ile tworzenie szybkich prototypów stanie się powszechnie dostępne, o tyle budowanie systemów produkcyjnych nie dopuszcza żadnych kompromisów. Każdy programista pracujący z AI musi dogłębnie rozumieć generowany kod, znać całą strukturę rozwiązań oraz precyzyjnie przewidywać, jak system zachowa się w sytuacjach skrajnych (corner cases). Z tego powodu zapotrzebowanie na inżynierów o silnych, technicznych fundamentach będzie wciąż bardzo duże.
theprotocol.it: Czy AI zmieni sposób, w jaki mierzymy produktywność developerów?
Jarek Kuśmierek: Linie kodu zawsze były złą metryką, AI tylko uczyniła ją bezsensowną. U nas dziś mierzymy trzy rzeczy.
Pierwsza: czas od pomysłu do działającego rozwiązania w produkcji i ilość pomysłów, które udaje się zrealizować w jednostce czasu.
Druga: ile czasu zespół odzyskuje na pracę kreatywną. W Google nasi inżynierowie spędzają mniej czasu na zrozumieniu nowego kodu oraz na testach jednostkowych - te godziny wracają na projektowanie systemów. Oszczędność czasu to jedno, ale prawdziwym miernikiem staje się jakość i trwałość (maintainability) kodu, szybkie pisanie jest bezużyteczne, jeśli tworzy systemy trudne w utrzymaniu.
Trzecia metryka to zmniejszenie błędów w produkcji. Tak wygląda nowa definicja produktywności. Do tego dodałbym fakt, że praca developerów jest pracą mocno kreatywną - i jako taka trudno poddaje się obiektywnemu mierzeniu.
theprotocol.it: Jakie są koszty, związane z utrzymaniem powstałego w ten sposób kodu?
Jarek Kuśmierek: Automatyzacja może obniżyć koszty utrzymania poprzez szybsze znajdowanie i poprawianie błędów. Jednak bez odpowiedniej dyscypliny, kod generowany masowo może zwiększyć dług techniczny. Jeśli pozwolimy na wdrożenie „AI spaghetti code” - kodu, który działa, ale jest niezrozumiały dla człowieka - koszty jego modyfikacji w przyszłości będą astronomiczne. Jeśli jednak utrzymamy odpowiednio wysoką jakość tworzonego w ten sposób kodu, koszty te nie wzrosną, a wręcz mogą zmaleć - z pomocą AI znacznie łatwiej i szybciej lokalizuje się przecież ewentualne błędy.
theprotocol.it: Jeśli kod wygenerowany przez AI doprowadzi do poważnego błędu lub wycieku danych, kto powinien ponosić odpowiedzialność?
Jarek Kuśmierek: Tu nie ma jednej odpowiedzi, odpowiedzialność rozkłada się warstwowo. Programista, który zaakceptował kod bez przeglądu, ponosi odpowiedzialność zawodową. Zespół, który dopuścił do produkcji rozwiązanie bez testów bezpieczeństwa, odpowiada za proces. Firma, która udostępniła produkt użytkownikom ponosi całościową odpowiedzialność za wszystkie aspekty produktu, i to ona zwykle płaci najwięcej. Dostawca narzędzia AI odpowiada za to, czy jego model nie miał znanych podatności i czy dane klienta nie wyciekły do treningu. W praktyce, kiedy dochodzi do incydentu, nie pada pytanie „kto napisał tę linijkę", tylko „jakie procesy, i/lub narzędzia zawiodły, że tego nie wyłapaliśmy ". I dlatego ludzki przegląd kodu generowanego przez AI (jak i automatyczne testy) nie jest formalnością, jest miejscem, gdzie odpowiedzialność staje się realna.