Eldorado się skończyło – i co teraz?

Chyba każdy z Was zna ten mechanizm: obejrzysz kilka filmów na jeden temat, a algorytm YouTube zaczyna Ci podsuwać kolejne i kolejne. Ja ostatnio oglądam sporo o AI, więc moja strona główna wygląda jak jedna wielka konferencja na temat przyszłości zawodu programisty. Dzięki temu mam okazję obserwować, jak bardzo różne bywają reakcje – i muszę przyznać, że wcale nie ma tam samego optymizmu.

Jedni tracą pracę, jeszcze więcej osób boi się o swoje stanowisko, a niemal każdy zadaje sobie pytanie, czy nasz fach ma w ogóle jakieś perspektywy. Pisałem już o tym w Programista w czasach AI i w Vibe Coder vs Software Engineer, ale temat nie chce się wyczerpać 🙂

Tym razem algorytm trafił w dziesiątkę. Film The Old Software Engineering Dream Is Officially Dead (otwiera się w nowej karcie) (po polsku: „stary sen inżyniera oprogramowania oficjalnie umarł” – autor: Stephane Moreau) oglądałem z dziwnym wrażeniem, że ktoś wyjmuje mi kolejne tezy prosto z głowy. Dlatego postanowiłem je tu zebrać i dorzucić do nich swoje 3 grosze.

Eldorado w twierdzy

Przez dekady bycie programistą kojarzyło się z czymś elitarnym – dla laika niemal na pograniczu magii. Typowy nerd zamykał się w swojej twierdzy samotności i pisał kod. Praca w IT była naszym Eldorado – złotym miastem, które gwarantowało dostatnie i wygodne życie.

I nagle okazuje się, że ta magiczna część pracy, czyli samo pisanie kodu, staje się czymś tanim i trywialnym. „Mag z twierdzy” z dnia na dzień stał się… no właśnie, kim? Dokładnie o tym jest ten film. Jego autor mówi wprost, że dawny model kariery – „odizoluj się na słuchawkach, pisz kod cały dzień i nie rozmawiaj z ludźmi” – robi się dla programistów coraz bardziej ryzykowny.

Tylko że ja nigdy się w tej twierdzy nie zamykałem. Nie postrzegam siebie jako skrytego introwertyka – wręcz przeciwnie. Gdy prowadziłem zespół frontowy, byłem raczej pośrednikiem i tłumaczem: z jednej strony starałem się zrozumieć biznes, jego specyfikę i wymagania, z drugiej pilnowałem uwarunkowań technicznych i jakości. Owszem, wciąż najchętniej pracuję zdalnie, kocham pracę z kodem i samotność mi nie przeszkadza. Ale nie wyobrażam sobie pracy w oderwaniu od szerszego kontekstu. Moim celem nigdy nie było samo pisanie kodu, tylko rozwiązanie realnego problemu – użytkownika albo firmy.

No dobra, to jakie to tezy?

#1 – kod to nie produkt

W filmie pojawia się prosty kontrast. Dwóch inżynierów dostaje to samo zadanie. Pierwszy spędza 3 dni na pisaniu wszystkiego od zera. Drugi poświęca godzinę na ustalenie, co dokładnie ma powstać, generuje pierwszą wersję z pomocą AI, a potem ją sprawdza i poprawia. Firma coraz częściej pyta już nie „czy kod został napisany?”, tylko „czy właściwa rzecz trafiła na produkcję?”.

Znamy to z własnego podwórka. Szlifowanie kodu, refaktoryzacja, optymalizacja – to wszystko ma ogromne znaczenie i nie zamierzam tego umniejszać. Ale potrzebny jest też balans i świadomość momentu, w którym coś jest „wystarczająco dobre”. Dziś lepiej wypuścić produkt nawet we wczesnej fazie, zebrać feedback i zacząć łapać płacących użytkowników, niż szlifować każdy detal, który nikogo nie obchodzi – i tylko generować koszty. Ktoś powie: zawodowa hańba, brak dumy z rzemiosła. Cóż – dumą rachunków się nie zapłaci, a nierentowny projekt trafia do kosza.

#2 – śmieci na wejściu, śmieci na wyjściu

Moreau opowiada o menedżerze, który prosi inżyniera o „uporządkowanie serwisu przed dużym wdrożeniem”. Inżynier spędza tydzień na refaktoryzacji i zostawia system w wyraźnie lepszym stanie. Problem w tym, że menedżerowi chodziło o naprawienie alertów – żeby wiedzieć, czy serwis nie pada w czasie premiery. Praca użyteczna, ale zupełnie nie ta.

Z AI jest identycznie. Napiszesz „popraw ten kod” i możesz dostać przebudowę połowy aplikacji, podczas gdy chodziło o jeden głupi błąd. AI wykona polecenie – ale ukrytej intencji nie wyczyta. Współpraca z AI uczy więc przede wszystkim jednego: znacznie ważniejsze niż kiedyś jest poświęcenie czasu na przygotowanie „wsadu”. Jeśli na wejściu będzie byle co, nie oczekujmy diamentu na wyjściu.

Autor filmu proponuje prosty test: zanim oddasz zadanie komukolwiek – człowiekowi lub maszynie – napisz w 2–3 zdaniach, jak wygląda „done” – czyli spodziewany efekt. Jeśli nie umiesz tego opisać, to jeszcze nie jesteś gotowy do delegowania. Brzmi banalnie, ale w praktyce potrafi oszczędzić godziny pracy. Ten sam wątek rozwinąłem zresztą we wpisie o Spec Driven Development (SDD) – jeśli ktoś ma ochotę zobaczyć, jak to można uporządkować w konkretną metodę.

#3 – puść to z rąk

Robienie wszystkiego samemu jest bardzo kuszące dla doświadczonego programisty. Przecież wytłumaczenie komuś problemu zajmie 20 minut, a sam naprawię go szybciej. Z taką pokusą walczyłem bardzo często, a delegowania zadań, dzielenia się pracą i oddawania „mojego” projektu w cudze ręce musiałem się po prostu nauczyć. Było trudno, ale wszystkim wyszło na zdrowie.

Bo prawda jest taka, że człowiek, który rozwiązuje wszystkie trudne problemy, to wąskie gardło. Zespół czeka na jego decyzje, review się wydłużają, inni się nie rozwijają. W branży ma to nawet swoją ponurą nazwę – bus factor, czyli ilu członków zespołu musiałoby wpaść pod autobus, żeby projekt stanął. Jeśli odpowiedź brzmi „1”, to mamy problem.

Podobnie jest z AI – i film ujmuje to dobrze: oddajemy wykonanie, nie decyzje. Co ma robić ten fragment systemu, kto może z niego korzystać, jak sprawdzimy, że działa – to zostaje po naszej stronie. Samo pisanie kolejnych linijek? Śmiało, niech piszą inni albo maszyna.

Ktoś powie: oddać pisanie kodu maszynie? Toż to herezja. Tylko że my już to przerabialiśmy. Kiedyś programiści pisali w asemblerze – mieli pełną kontrolę nad każdym rejestrem, każdym buforem i każdym bajtem. Gdy pojawiły się języki wyższego poziomu – od Fortrana i C po Javę – ze składnią o wiele bardziej przystępną dla człowieka, ówcześni fachowcy mogli się oburzać, że oddają kontrolę nad kodem maszynie – kompilatorowi. I co? Tych języków używamy do dziś, a mało kto zagląda w to, co kompilator wypluł. Jeśli działa, to działa.

Dziś przeżywamy podobną rewolucję. Znów mówimy komputerowi, co ma zrobić – tyle że w języku jeszcze bliższym człowiekowi, bo naszym własnym. A on to robi. Z jedną różnicą: kompilator jest przewidywalny, a AI nie zawsze, więc „jeśli działa” wymaga tu trochę więcej niż kliknięcia „uruchom”. Ale o tym za chwilę.

#4 – skąd wiesz, że to naprawdę działa?

Tu muszę się zgodzić ze wszystkimi malkontentami: review takiej ilości kodu, jaka dziś powstaje w kilka minut, to koszmar. Nikt nie przeczyta uważnie kilku tysięcy linijek na raz, choćby bardzo chciał.

Film opisuje scenariusz, który mógłby zdarzyć się w każdym zespole. AI robi nową funkcję, dopisuje testy, otwiera pull request. Wszystko przechodzi na zielono, kod wygląda sensownie, więc leci na produkcję. A po kilku dniach okazuje się, że użytkownicy widzą dane innych kont. Testy działały. Tylko nikt nie sprawdził, czy testują właściwe rzeczy.

Dlatego warto przestawić się na inny sposób weryfikacji – mniej „czy kod jest ładny”, więcej „czy robi to, co zakładaliśmy”. I tu podejście SDD jest dla mnie bardzo ciekawe: jasno deklarujemy wymagania, opisujemy funkcjonalność, przypadki brzegowe i testy, a potem cyklicznie sprawdzamy, czy to, co powstaje, rzeczywiście realizuje założone działanie. Nie ufamy samemu faktowi, że testy przechodzą.

Do tego dochodzi prosta zasada z filmu, którą od razu wziąłem sobie do serca: nie merguj kodu, którego nie umiesz wyjaśnić innemu inżynierowi. Nie musisz napisać każdej linijki – ale musisz wiedzieć, co ona robi i co może pójść nie tak.

#5 – „zrobiło to AI” nie jest wymówką

Ostatnia teza z filmu to chyba ta najważniejsza. Jeśli zatwierdzasz zmianę wygenerowaną przez AI, to odpowiadasz za jej skutki. Odpowiedź „kod wygenerowało AI, testy przeszły, nie wiem, czemu się zepsuło” po prostu nie wystarczy.

Moreau podaje całkiem fajną alternatywę – zdania, które da się powiedzieć na głos: „zatwierdziłem tę zmianę”, „przeoczyłem błąd w review”, „naprawiliśmy”, „dodaliśmy test, żeby się nie powtórzyło”. Odpowiedzialność nie oznacza winy za każdy błąd. Menedżer przecież nie pisze osobiście wszystkich bugów, a odpowiada za to, co dowozi jego zespół. Jak już pisałem we wcześniejszym wpisie – z wielką mocą wiąże się wielka odpowiedzialność, a AI daje nam tej mocy całkiem sporo.

Zaufanie i awanse biorą się z wiedzy technicznej tylko po części. Przychodzą głównie wtedy, gdy ludzie wiedzą, że w razie kłopotów ta konkretna osoba zareaguje, pomoże ogarnąć sprawę i wyciągnie wnioski.

No dobrze, a co teraz?

Tak na poważnie – coś się skończyło, ale nie w tym sensie, w jakim straszą nagłówki. Film wcale nie twierdzi, że programiści stają się zbędni – zmienia się za to definicja dobrej pracy inżynierskiej. Najbardziej narażeni są ci, którzy chcieliby pozostać wyłącznie wykonawcami zadań i trzymać się z daleka od kontekstu produktu, ryzyka i odpowiedzialności.

Reszta nie ma powodu do paniki – o ile potrafi ustalić, co zbudować, zorganizować wykonanie, ocenić jakość i odpowiedzialnie zareagować, gdy coś pójdzie nie tak.

Dla mnie to nawet dobra wiadomość. Bo okazuje się, że ten „miękki” kawałek roboty, który przez lata uważano za dodatek do prawdziwego programowania – rozmowy, zrozumienie biznesu, dzielenie się pracą – staje się sercem tej pracy. Kod robi się tani. Zrozumienie, co i po co budujemy, wcale.

Czy to znaczy, że trzeba rzucić kod i zostać menedżerem? Absolutnie nie. Można dalej mieć karierę typowo techniczną i kochać grzebanie w kodzie – ja sam kocham. Tyle że planowania, komunikacji i odpowiedzialności za rezultat nie da się już całkiem wyciąć z grafiku. Z wielu rzeczy można zrezygnować, z rozmów z ludźmi już nie.

Eldorado, w którym wystarczyło pisać kod, się skończyło. Ale złoto nie zniknęło – przeniosło się tam, gdzie trzeba rozumieć problem i brać za niego odpowiedzialność.

Dla tych, co wolą obejrzeć

Jeśli chcecie sprawdzić, czy film rzeczywiście mówi to samo, co ja usłyszałem – trwa ponad 12 minut i jest po angielsku:

Odtwórz film: The Old Software Engineering Dream Is Officially Dead – Stephane Moreau

A jak to wygląda u Was? Czujecie, że Eldorado się kończy, czy może uważacie, że to wszystko jest mocno przesadzone? Dajcie znać w komentarzach, czy u Was też wieje chłodem w złotym mieście – jestem ciekaw Waszych spostrzeżeń 🙂

PS. Dla tych, którym po lekturze zrobiło się smutno: powstała Pieśń o utraconym El Dorado (otwiera się w nowej karcie) – w wersji dla branży IT – polecam 🙂