To pytanie wraca w każdej rozmowie o nauce programowania i prawie zawsze dostaje jedną z dwóch bezużytecznych odpowiedzi: „tak, za dwa lata" albo „nie, to tylko autouzupełnianie". Obie są przewidywaniami, a przewidywania nie pomagają podjąć decyzji dzisiaj. Da się odpowiedzieć inaczej: opisując, co już się zmieniło.

Co realnie się zmieniło

Zmieniła się cena pierwszej wersji. Rzecz, która kiedyś wymagała tygodnia i znajomości frameworka, powstaje teraz w godzinę i bez niej. To jest prawdziwa zmiana, nie marketing — i to ona odpowiada za całe wrażenie, że zawód znika.

Nie zmieniło się natomiast to, ile kosztuje utrzymanie tej rzeczy przy życiu: poprawianie, gdy przestaje działać, zmienianie, gdy wymagania się przesuwają, i odpowiadanie za nią, gdy coś pójdzie źle. Pierwsza wersja to zawsze była mniejsza część pracy — teraz jest jeszcze mniejszą.

Bariera wejścia się przesunęła, nie zniknęła

Kiedyś bariera stała na składni: żeby cokolwiek zrobić, trzeba było umieć zapisać to w języku, którego się nie zna. Ta bariera faktycznie padła. Nowa stoi na ocenie: dostajesz działający kod w piętnaście sekund i musisz stwierdzić, czy jest dobry — a to jest trudniejsze niż napisanie go, bo wymaga rozumienia bez pisania.

przed modelamiz modelami

Napisanie pierwszej wersji

5/5
1/5

Tu spadek jest dramatyczny i to on robi całe wrażenie.

Znajomość składni języka

5/5
2/5

Ocena, czy rozwiązanie jest dobre

3/5
5/5

Rośnie: kodu przybywa szybciej, niż da się go przeczytać.

Wiedza, jak to działa pod spodem

4/5
4/5

Odpowiedzialność za skutki

5/5
5/5
Ocena własna trudności poszczególnych części pracy, przed upowszechnieniem modeli i po nim. Dwie rzeczy staniały gwałtownie, jedna zdrożała, dwie nie drgnęły — i to te trzy ostatnie decydują dziś o tym, czy zbudujesz coś, co przetrwa kontakt z użytkownikami.

Kto na tym traci, a kto zyskuje

Traci ten, kogo cała wartość polegała na przepisywaniu znanych wzorców — bo to jest dokładnie ta część, którą model robi dobrze i tanio. Zyskuje ten, kto potrafi powiedzieć, co ma powstać i rozpoznać, kiedy powstało coś innego. Ta druga umiejętność nie ma nic wspólnego z liczbą znanych języków.

Trzy sytuacje, w których widać to najlepiej

Zamiast prognozować, warto spojrzeć na to, co już widać. Zmiana nie rozłożyła się równo: uderzyła najmocniej tam, gdzie praca polegała na składaniu znanych elementów, i prawie wcale tam, gdzie polega na rozstrzyganiu, co ma powstać.

  1. Proste strony na zlecenie

    Najmocniej dotknięte. Landing z formularzem był kiedyś dniem pracy, a dziś klient złoży go sam w godzinę. Wartość przesunęła się na to, czego model nie zrobi: dobranie treści, zmierzenie skutku i utrzymanie tego przez rok.

  2. Rozwijanie cudzego, dużego systemu

    Dotknięte najmniej. Model nie zna tego systemu, a największa część pracy to zrozumienie, dlaczego coś jest zrobione tak, a nie inaczej — i co się zawali, gdy to ruszysz.

  3. Pierwszy własny projekt

    Sytuacja najbardziej myląca: wejście jest łatwiejsze niż kiedykolwiek, a droga od „działa u mnie" do „działa u ludzi" nie skróciła się ani o dzień. Łatwo pomylić jedno z drugim i uznać, że jest się dalej, niż się jest.

Co to znaczy dla kogoś, kto zaczyna dziś

Praktycznie: zaczynaj od budowania rzeczy, ale nie akceptuj niczego, czego nie umiesz opowiedzieć własnymi słowami. To jedno kryterium wystarczy na pierwsze miesiące — jest proste do sprawdzenia i odsiewa wszystkie sytuacje, w których projekt rośnie szybciej niż Twoje rozumienie. Gdzie dokładnie się to załamuje, opisujemy w tekście od czego zacząć, żeby nie utknąć w drugim tygodniu.

I rzecz, którą łatwo przeoczyć: praca z modelem to praca tekstem. Zamiast pisać kod, piszesz zdania — dłuższe i po polsku. Dlatego tempo pisania nie przestało mieć znaczenia, tylko przeniosło się gdzie indziej, o czym mówi tekst o vibe codingu a pisaniu bezwzrokowym. Ile z tego naprawdę wynika dla zawodowca, policzyliśmy w WPM programisty.