Patrz na kod z wysokości, a nie z poziomu klawiatury

Nie patrz na problem tylko z poziomu kodu. W ten sposób tracisz najcenniejszą część swojej roli.

Nie zrozum mnie źle. Kod nadal jest ważny. To jest źródło prawdy o działaniu systemów. Nadal trzeba go rozumieć. Nadal trzeba umieć ocenić jego jakość, sens i konsekwencje. Ale coraz częściej samo pisanie kodu nie jest już miejscem, w którym powstaje największa wartość. Twoja przewaga w organizacji czy też na rynku pracy.

Kod to tylko jedna warstwa układanki

Bycie programistą od dawna nie polega wyłącznie na znajomości języka, frameworka i kilku dobrych praktyk. Natomiast jakoś nam to uchodziło na sucho, prawda? To my byliśmy tymi szamanami co wiedzą jak to rozmawiać z komputerami.

A teraz przyszedł inny szaman. Poteżniejszy. Który może pracować szybciej, lepiej i bez przerwy (oczywiście mowa o AI…).

Dlatego teraz nie ma co, trzeba rozumieć produkt. Trzeba rozumieć przynajmniej część biznesu w jakim się obracamy. Trzeba umieć rozmawiać z ludźmi, dopytywać, precyzować oczekiwania, czasem sprzedać pomysł. Nie ma lekko.

I właśnie dlatego coraz mniej przekonuje mnie patrzenie na ten zawód wyłącznie jak na “pisanie kodu”.

Kod jest narzędziem.

Nie celem samym w sobie.

Kropka.

Czasem najlepszy kod to ten, który w ogóle nie powstał

Pierwszą rzeczą, nad którą warto się zastanowić na start, to jaki ja problem rozwiązuje. A potem, czy ten problem w ogóle trzeba rozwiązywać za pomocą kodu?

W niektórych przypadkach odpowiedź może brzmieć: nie.

Bywa, że na etapie proof of concept dużo lepszym ruchem jest użycie gotowego narzędzia, komponentu, automatyzacji albo istniejącego rozwiązania niż budowanie wszystkiego od zera.

Nie chodzi tylko o klasyczne biblioteki czy frameworki. Chodzi również o narzędzia no-code, gotowe komponenty zewnętrzne czy systemy, które pozwalają osiągnąć efekt przy dużo mniejszym koszcie utrzymania.

Sam widziałem sytuację, a nawat byłem jej częścią, w której zamiast tworzyć dedykowany frontend pod konkretny problem, zespół skorzystał z gotowego rozwiązania w postaci Looker Studio. Mniej pracy, mniej własnego kodu, a efekt nadal dowoził wartość. Nie musieliśmy nic pisać. A interesariusze biznesowi byli zadowoleni.

I właśnie taki rodzaj “lenistwa” uważam za zdrowy.

Nie lenistwo rozumiane jako unikanie odpowiedzialności. Bardziej jako szukanie najtańszej sensownej drogi do rezultatu.

Czyli klasycznie “zdolny, ale leniwy”.

AI jeszcze mocniej przesuwa środek ciężkości

Druga rzecz jest jeszcze ważniejsza.

AI już dziś pisze kod i będzie robić to coraz lepiej.

Nie oznacza to automatycznie, że programiści przestają być potrzebni. Oznacza raczej, że zmienia się miejsce, w którym tworzy się ich przewaga.

Jeśli agent potrafi zaimplementować sporą część taktycznej roboty, to rośnie znaczenie tego, kto potrafi dobrze przygotować problem do implementacji.

• Kto potrafi rozbić większy temat na mniejsze moduły.
• Kto potrafi narysować granice.
• Kto umie zdecydować, które elementy powinny być od siebie oddzielone.
• Kto rozumie, jakie decyzje są strategiczne, a jakie wyłącznie wykonawcze.

I właśnie dlatego coraz bardziej widzę przyszłość programisty nie jako “klepacza kodu”, ale jako projektanta problemu i granic, w których kod ma powstać.

A może to się już nie będzie nazywało zawodem programisty? Może będzie to “problem designer” albo “solution architect”? Nie wiem. Czas pokaże.

Jeśli źle rozpiszesz problem, AI tylko szybciej utrwali zły kierunek

To jest chyba najważniejszy punkt tego wpisu. AI nie jest magicznym filtrem, który naprawi błędne myślenie projektowe.

One je może tylko spotengować.

Jeśli źle zrozumiesz domenę, źle postawisz granice albo pomieszasz koncepty, agent bardzo często zrobi dokładnie to, o co go poprosisz. Szybko. Grzecznie. I bez większego oporu.

Czyli dom wybudowany, ale szkoda, że na działce sądziada.

AI nie jest partnerem biznesowym. To raczej bardzo sprawny wykonawca, który wkładu “z góry”. Oczywiście płynącego od nas, programistów.

I właśnie tutaj widać, jak bardzo rośnie znaczenie pracy strategicznej.

Wyobraź sobie prostą domenę produktu, który może być dostępny, niedostępny albo nadal widoczny mimo braku możliwości zakupu. Jeśli źle opiszemy model i pomieszamy pojęcia, agent spokojnie zaimplementuje nam logikę, która technicznie “działa”, ale semantycznie jest fatalna. Na przykład zacznie oznaczać niedostępność produktu na podstawie przypadkowego fragmentu identyfikatora, bo tak wynikało z nieprzemyślanego kontraktu wejściowego.

I potem płacz i lament, bo AI nie działa.

Coraz bardziej liczy się rola problem solvera

Dlatego mam poczucie, że zawód programisty nie zniknie nagle, ale będzie stopniowo zmieniał środek ciężkości.

Coraz mniej będzie chodziło o samo wytwarzanie kodu, a coraz bardziej o rozumienie problemu, projektowanie modułów, decyzje architektoniczne i delegowanie pracy tam, gdzie da się ją sensownie zautomatyzować.

To trochę przypomina sytuację, w której dawniej senior albo architekt rozpisywał kierunek, a realizację taktyczną delegował dalej. Tyle że dziś część tej realizacji może przejmować agent.

Ale odpowiedzialność za sens nadal zostaje po naszej stronie. Bo wszystko rozchodzi się teraz o odpowiedzialność właśnie.

Co robić? Jak żyć?

Im szybciej zaakceptujemy, że nie samym kodem człowiek żyje w tej branży, tym lepiej.

Dla naszego dobra.

Nie oznacza to rezygnacji z jakości technicznej. Oznacza raczej, że warto podnieść wzrok trochę wyżej. Ponad klawiaturę. Ponad kod (co za koincydencja, nieprawda? Mój blog się tak nazywa, więc musiałem to wykorzystać 😅).

Zanim zaczniesz pisać albo zlecać pisanie kodu, warto zadać sobie kilka pytań.

• Czy ten problem w ogóle wymaga własnej implementacji?
• Czy granice modułów są dobrze wyznaczone?
• Czy model domenowy ma sens?
• Czy to, co delegujesz, jest już naprawdę dobrze zrozumiane?

Bo bardzo możliwe, że właśnie tam będzie dziś powstawać największa wartość pracy programisty. Jeszcze bliżej biznesu. Jeszcze bliżej produktu. Jeszcze bliżej problemu.