Wdrażanie AI w programowaniu: trudna część to nie technologia

Ostatnio coraz więcej firm przygotowuje się do wdrożenia narzędzi AI na masową skalę. Setki, czasem tysiące programistów lada moment usłyszą: oto wasze nowe narzędzia, oto szkolenie, oto miary którymi będziemy mierzyć adopcję. Standardowy scenariusz „transformacji”.

Trafiłem na przykład na ogłoszenie o pracę, w którym firma szukała osoby do kierowania takim właśnie przedsięwzięciem. Użyli nawet pięknego sformułowania: „AI-augmented craftsmanship” – „rzemiosło wspomagane AI”. Spodobało mi się. Oddaje coś prawdziwego – że programowanie, robione dobrze, jest rzemiosłem. Ale reszta ogłoszenia to był standardowy zestaw narzędzi „transformacyjnych”: golden paths, metryki DORA, zespoły wsparcia, dashboardy adopcji.

Problem jest taki, że wiemy już, że ten scenariusz nie działa. Większość tak prowadzonych „transformacji” kończy się porażką – nie dlatego, że narzędzia są złe albo miary nic nie pokazują, ale dlatego, że nie skupiają się na rzeczywistym problemie.

Zarządzającym wydaje się, że wdrażają nową technologię. W rzeczywistości proszą rzemieślników, żeby przestali uprawiać rzemiosło, które przez dekady ich definiowało.

To nie jest problem, który rozwiązują szkolenia i miary. To kryzys tożsamości.

Rzemiosło, które się zmienia

Co przez dekady czyniło programistę dobrym? Umiejętność projektowania efektywnych, eleganckich, algorytmicznie wydajnych rozwiązań. Umiejętność pisania czystego, eleganckiego, czytelnego kodu. Takiego, w którym nazwy zmiennych coś znaczą, klasy i metody są dobrze zaprojektowane, a inny programista może otworzyć plik pół roku później i zrozumie co się w nim dzieje.

To zresztą nie był tylko pragmatyzm. Ruch „Clean Code” był kwestią profesjonalnej dumy. Sztuka przekładania złożonej logiki na precyzyjną, piękną składnię – to właśnie odróżniało profesjonalistę od amatora, seniora od juniora. W ten sposób programiści wiedzieli, że są dobrzy w tym co robią.

Praca z narzędziami takimi jak Github Copilot a następnie Cursor to zmieniła. Przestajesz pisać kod i zaczynasz kierować jego tworzeniem – a pojawienie się agentów takich jak Claude Code, gdzie w ogóle nie patrzysz na kod chyba że musisz, czyni tę zmianę jeszcze głębszą. Opisujesz intencję, analizujesz projekt, dyskutujesz, zatwierdzasz plan, przeglądasz wynik, z rzadka wyłapujesz błędy, naprowadzasz AI kiedy zbłądzi. Dokładna znajomość składni ma mniejsze znaczenie – AI zna ją wystarczająco dobrze i analizuje kod szybciej niż jakikolwiek człowiek. Ważniejsza jest umiejętność dekompozycji problemów, projektowania samego procesu tworzenia, rozpoznawania kiedy zaproponowane rozwiązania są błędne, niebezpieczne albo po prostu subtelnie nie takie jak trzeba. I to coraz częściej nie na poziomie kodu ale koncepcji, planu.

To nadal jest wartościowa praca. Można nawet argumentować, że bardziej wartościowa. Ale to nie jest już to samo rzemiosło.

Programista, który spędził piętnaście lat (albo więcej!) na opanowywaniu zawiłości jakiegoś języka, który był dumny z pisania kodu tak czystego, że czytał się jak proza – ten człowiek słyszy teraz, że to co czyniło go znakomitym ma mniejsze znaczenie niż kiedyś. To nie jest uczenie się nowych narzędzi. To jest propozycja, żeby stać się kimś innym. Co gorsza, propozycja nie do odrzucenia.

Stare umiejętności, które znaczą więcej, nie mniej

Ale nowe rzemiosło nie powstaje od zera. Przenosi z tego starego więcej niż większość ludzi sądzi – tylko nie te elementy, których się spodziewają.

Rozumienie kodu nadal się liczy. Nadal czasem trzeba umieć przeczytać i ocenić to co AI wyprodukuje – a AI produkuje dużo i szybko. Jeśli nie potrafisz odróżnić dobrego kodu od złego to w tym nowym świecie jesteś wciąż bezużyteczny, a być może nawet niebezpieczny.

Ale jeszcze ważniejsza jest dyscyplina realizacji. Budowanie produktu jako serii małych zmian, z których każda jest w pełni UKOŃCZONA – technicznie kompletna, przetestowana, gotowa do wydania – nawet jeśli funkcjonalnie niekompletna. Czyli wytwarzanie przyrostowe i iteracyjne. To zawsze była dobra praktyka – teraz jest niezbędna, bo najgorsze co można zrobić to powierzyć duży system agentowi AI i pozwolić mu działać bez nadzoru. Efekty będą wyglądać imponująco i będą naszpikowane problemami, których nikt nie rozumie, bo nikt nie nadzorował kroków pośrednich.

Kolejna sprawa to testy. Testy mają większe znaczenie niż kiedykolwiek. A skoro AI potrafi generować testy, to tym mniej jest wymówek żeby je pomijać. Chodzi jednak o to, żeby ich nie pomijać, by wiedzieć jakie testy są potrzebne na danym poziomie abstrakcji, jak powinny być skonstruowane i co sprawdzać.

No i projektowanie. Z pomocą AI można „na żywioł” zrobić tylko małe zmiany. Wszystkie większe rzeczy wymagają przemyślenia, przygotowania starannych specyfikacji, projektów i planu implementacji. Zajmuje to dużo więcej czasu niż samo wygenerowanie kodu później – ale zasadniczo podnosi jakość rezultatu.

Zatem umiejętności, które przenoszą się do nowego świata to nie mistrzostwo składni, ale osąd inżynierski, myślenie architektoniczne i dyscyplina budowania rzeczy dobrze, małymi krokami. Programiści, którzy te umiejętności posiadają są cenniejsi niż kiedykolwiek – a większość dobrych programistów je ma, nawet jeśli nie wszyscy jeszcze to widzą.

Dlaczego dashboardy nie pomogą

Organizacje widzą opór wobec adopcji AI i myślą: więcej szkoleń, lepsze narzędzia, jaśniejsze miary. Rozwiązują nie ten problem z coraz większą precyzją.

Nie da się wyszkolić kogoś z kryzysu tożsamości. Inżynier, który się ociąga niekoniecznie jest luddystą. Może to być ktoś, kto trafnie postrzega, że to co czyniło go wartościowym, co czyniło go nim, zostaje właśnie określone jako „przestarzałe”. Kolejne szkolenia tego nie naprawią. Zielone dashboardy tego nie naprawią.

Co by faktycznie zadziałało

Po pierwsze, trzeba przestać udawać, że chodzi głównie o technologię. Narzędzia to łatwa część – już są dobre i szybko się poprawiają. Trudna część to wymiar kulturowy i tożsamościowy, który tradycyjne scenariusze transformacyjne kompletnie ignorują.

Zanim cokolwiek zaczniecie wdrażać musicie zrozumieć kulturę, z którą macie do czynienia. Co ci inżynierowie faktycznie cenią? Z czego są dumni? Co boją się stracić? Skąd naprawdę bierze się opór – czy to strach przed utratą pracy, czy coś głębszego? Jakie są tam plemiona i grupy?

To jest praca etnograficzna, nie zarządzanie projektem. Framework Estuarine Mapping Dave’a Snowdena oferuje tu przydatne podejście. Kluczowa intuicja: w każdym złożonym systemie pewne rzeczy da się zmienić a pewnych nie. Niektóre ograniczenia są jak skalne podłoże ujścia rzeki – nieusuwalne. Inne są jak łachy z piasku – przesuwają się jeśli przyłożysz odpowiednią siłę w odpowiednim miejscu. Większość wysiłków transformacyjnych traci ogromną energię na walkę ze skalnym podłożem ignorując jednocześnie piaskowe łachy. Najpierw zatem zmapuj teren. Skup się wyłącznie na tym, co faktycznie da się zmienić.

I nie rób tego mapowania w ramach „sesji strategicznej” z konsultantami. Zaangażuj ludzi żyjących w tej kulturze. W tym sceptyków. Zwłaszcza sceptyków – oni często widzą rzeczy, których entuzjaści nie dostrzegają.

Żeby nowe rzemiosło się przyjęło ludzie muszą widzieć w nim rzemiosło, w którym mogą rosnąć – a nie degradację z „prawdziwego programowania” do „nadzorowania maszyny”. Powtórzę: to jest problem narracyjny, problem tożsamościowy. Nie rozwiążą go narzędzia ani szkolenia.

Brakująca kwalifikacja

Organizacje podejmujące tę transformację potrzebują liderów, którzy rozumieją trzy rzeczy.

• Tradycyjne programowanie – na tyle głęboko, by rozumieć z czego inżynierowie mają zrezygnować, by dzielić ich żal za rzemiosłem, które się zmienia, by być wiarygodnym.
• Narzędzia AI – z praktycznym, własnoręcznym doświadczeniem, nie tylko z prezentacji sprzedawców.
• I co najważniejsze: dynamikę kulturową i zmianę tożsamości – jak grupy i plemiona faktycznie funkcjonują, dlaczego ludzie opierają się zmianom, które z poziomu gabinetu prezesa wyglądają na korzystne w sposób oczywisty.

Te ogłoszenia o pracę, które widzę na stanowiska związane z tą transformacją pokrywają dwa pierwsze punkty. Trzeciego nie widziałem nigdzie. To smutne, bo oznacza, że duża część firm napotka ogromne trudności i nie wykorzysta dobrze potencjału „rzemiosła wspomaganego AI”.