Za Dantem, wszystkim, którzy marzą o tym, żeby dalej po prostu klepać kod, powiedziałbym dziś “porzućcie wszelką nadzieję, wy, którzy tu wchodzicie”.

Bo czas programowania, jakie znamy, tzn. polegającego na manualnym pisaniu oprogramowania, właśnie się kończy. I wszyscy to wiedzą, ale mało kto chce to rzeczywiście przyznać.

Branża IT sprowadziła rolę wielu programistów do maszynek przerabiających tickety na kod. Tyle że dzisiaj jest to proces możliwy do niemal całkowitego zautomatyzowania.

Mam poczucie, że trochę wszyscy udajemy, że tak nie jest. Udajemy, że przeklejanie tasków do Claude Code czy Codexa to nadal praca wykonywana przez nas.

No tyle że nie, tak nie jest. Jeśli jedynym zadaniem specjalisty jest implementacja dokładnie wg postawionych wcześniej założeń, a tę implementację wykonuje AI, to kim staje się w tej sytuacji specjalista? Nadzorcą?

Zrobiliśmy z siebie nadzorców, bo nadal bardzo wierzymy, że my, ludzie, jesteśmy lepsi, że musimy być częścią procesu, bo zauważymy coś lepiej niż maszyna.

Tylko rzeczywistość temu przeczy. Z uwzględnieniem wystarczającego kontekstu, specyfikacji technicznej i standardów już dziś można bardzo szybko i bardzo tanio wytworzyć dobrej jakości oprogramowanie, praktycznie nieodróżnialne od pracy wysoce doświadczonego człowieka.

W tym tygodniu przeprowadziłem eksperyment, żeby sprawdzić tę hipotezę. 30 skomplikowanych tasków z dostępem do pełnej wiedzy o produkcie i wymuszeniem skrupulatnych standardów technicznych. Najwięcej pracy wymagało właśnie spisanie całej tej dokumentacji. Praca w modelu spec-driven development z Opus 5.5 + Codex jako reviewer.

Efekt? Parę godzin czekania i wszystko gotowe. W środku - dokładnie to, czego oczekiwałem, od architektury, struktur danych, aż po wygląd 1:1 ze wzorcem. Na dokładkę wszystko podzielone na commity i PR-y zgodnie z narzuconym standardem. A gdy coś było niejasne - agent wracał z decyzją do mnie.

Z perspektywy formy i jakości tej pracy nie czułem istotnej różnicy względem pracy z typowym “klepaczem”, pomijając oczywiście skrajnie krótszy czas implementacji. Natomiast dużo więcej czasu pochłonęło w tym eksperymencie planowanie, analizowanie i podejmowanie decyzji (w mojej opinii przymioty pracy inżyniera przyszłości).

Przy czym… ktoś może zobaczyć efekty tej pracy i powiedzieć - “ale ja bym to napisał lepiej!”. Nie wątpię, tylko większość programistów by nie napisała.

Trzeba sobie to szczerze powiedzieć - większość z nas jest, bądź będzie, gorsza od AI w kwestii implementacji.

Większość branży IT nie pracowała przy wybitnych problemach technicznych wymagających naprawdę dogłębnej wiedzy i doświadczenia, a raczej przy tworzeniu 67. CRUD-a, 21. panelu administracyjnego i 37. landing page’a.

Nie sądzę jednak, że to oznacza koniec inżynierii oprogramowania jako takiej.

Rewolucja, w której jesteśmy, wreszcie przesunie skupienie inżynierów ze sposobów pisania funkcji i nazywania zmiennych na projektowanie całych systemów, pracę bezpośrednio z produktem i problemami biznesowymi, przekładając to wszystko na specyfikacje i decyzje techniczne implementowane niemal wyłącznie przez AI.

Co ważne - to wszystko dalej jest programowaniem, tylko po prostu innym*.

* Nota bene, to też nie jest vibe coding, bo on z założenia wyklucza jakąkolwiek wiedzę techniczną.

Tylko co w takiej sytuacji z nowicjuszami? Czy ktoś, kto dopiero napisał swojego pierwszego hello worlda, może w ogóle liczyć na zdobycie pracy w wymarzonym zawodzie, gdy dziś stawia mu się wymagania jak seniorowi parę lat temu?

Co jeśli nie będzie mógł? Czy najpierw wspięliśmy się po drabinie, a teraz z góry możemy tylko patrzeć, jak ta się pali?

Otóż… prawie. Bo jedna drabina faktycznie się już dopala, ale obok stoi nowa.

Zasadnicze pytanie brzmi tu tak: czy można nauczyć się inżynierii oprogramowania, nie znając dogłębnie języków programowania?

Moim zdaniem - można. Tak jak można było nauczyć się tworzyć strony internetowe, nie znając Assembly i nawet nie mając pojęcia, jak działa komputer.

Stąd po nowej drabinie juniorzy nie będą się wspinać, przerabiając setki ticketów, tylko ucząc się tego, co dotąd było domeną najbardziej doświadczonych programistów. Stara drabina wymagała pisania kodu, nowa - rozwiązywania problemów. Paradoksalnie wracamy tym samym do tego, czym IT było 20-30 lat temu - skupiskiem specjalistów-generalistów.

W 2024 opublikowałem wpis pt. “Za 5 lat programistów zastąpi AI”, w którym opisałem, że zmiany, które widzimy, to wejście na kolejny poziom abstrakcji w tworzeniu oprogramowania.

Branża IT przeszła drogę od ustawiania żarówek, przez przepinanie kabelków, po języki nisko- i wysokopoziomowe, biblioteki, frameworki, aż po programowanie z pomocą języka naturalnego, czyli moment, w którym jesteśmy dzisiaj.

Prawdopodobnie nie jest tak, że manualne programowanie zniknie całkowicie. Szczególne optymalizacje, poprawki bezpieczeństwa, bardzo specyficzne i nietypowe problemy będą mogły nadal stawiać potrzebę pisania kodu ręcznie.

Ale to raczej nie dotknie nikogo, kto na co dzień pracuje z tradycyjnymi problemami biznesowymi.

Dlatego jeśli ktoś chciałby dziś nadal tworzyć z pomocą swojej klawiatury “kraftowe oprogramowanie”, to, owszem, może próbować, ale będzie konkurować z rzeszą inżynierów zdolnych dowieźć wielokrotnie większą wartość w skrajnie krótszym czasie. A to dość… nierówna walka.