[SYSTEM LOG]
> Initializing process: butlerian-jihad.sh
> Status: Spice flow interrupted. Connection lost.
> Warning: Mentat mode required. Machine-logic failure detected.
> Quote: "Thou shalt not make a machine in the likeness of a human mind."

Dżihad Butleriański w Twoim IDE

Awaria nawigacji na piaszczystej planecie

Zależność od AI jest jak jazda na GPS-ie przez miasto, w którym mieszkasz od dekady. Gdy system pada, nagle nie wiesz, gdzie jest północ. Ostatnia awaria narzędzi AI obnażyła erozję fundamentów: deweloperzy, zamiast władać językiem, zaczęli jedynie wybierać opcje z menu. Kiedy menu znika, zostajesz sam na sam z pustym plikiem .py i nagle dziesięć lat doświadczenia waży tyle, co nic.

W świecie Diuny uzależnienie od przyprawy pozwalało Nawigatorom Gildii widzieć ścieżki w bezpiecznej przyszłości. Bez niej – byli ślepi. Dzisiejszy programista, odcięty od autouzupełniania, przechodzi swój własny, cyfrowy głód odstawienny. Okazuje się, że budowaliśmy katedry, zapominając, jak trzymać młotek.

Nie chodzi mi o technofobiczną tyradę pod tytułem “za moich czasów to było prawdziwe programowanie”. Nie. Programowanie z AI jest szybsze. Po prostu jest. Problem zaczyna się wtedy, gdy narzędzie z asystenta zmienia się w protezę.

Co się dzieje, gdy Copilot milknie

Była awaria Copilota, która trwała prawie cały dzień. I to jest właśnie ten moment prawdy, którego nie przykryje żaden marketingowy slogan o produktywności. Bo co robi wtedy młodszy programista, który jeszcze nie zdążył wyrobić w sobie odruchu samodzielnego rozwiązywania problemów?

Czy potrafi:

  1. przeczytać komunikat błędu bez paniki,
  2. rozbić problem na mniejsze części,
  3. poszukać informacji poza oknem czatu,
  4. odsiać blogowego szamana od sensownej odpowiedzi,
  5. wdrożyć rozwiązanie we własnym projekcie i sprawdzić, czy naprawdę działa?

To nie jest złośliwość. To jest pytanie o fundamenty zawodu. Jeśli całe doświadczenie z debugowaniem sprowadza się do wklejenia stack trace’a do modelu i czekania na gotowca, to przy pierwszej większej awarii zostajesz bez mapy, bez kompasu i bez wyuczonych nawyków.

Starsi programiści też mogą w tę pułapkę wejść, tylko skutki bywają mniej widowiskowe. Im dłużej pracujemy z AI, tym łatwiej oddać mu nie tylko żmudne taski, ale też sam proces myślenia. A to już jest koszt, którego nie widać w żadnym dashboardzie.

Tokeny to też nowa wersja “budget exceeded”

Druga rzecz jest dużo mniej romantyczna, ale bardziej przyziemna: ekonomia. Dzisiaj firma daje Ci dostęp do AI, wszyscy się cieszą, velocity rośnie, slajdy na retro wyglądają pięknie. A potem przychodzi aktualizacja modelu, zmienia się cennik, rośnie ruch, ktoś źle ustawi limity i nagle okazuje się, że tokeny zostały zjedzone w pierwszym tygodniu miesiąca.

Co wtedy?

Czy programista, który na co dzień pracuje głównie z AI, potrafi wrócić do dokumentacji, przeczytać API, zrozumieć bibliotekę i napisać coś samodzielnie? Czy umie wejść do obcego kodu bez “wyjaśnij mi ten plik”? Czy potrafi dojść do rozwiązania bez nieustannego dopalacza?

To jest dla mnie ważniejsze pytanie niż to, czy model wygeneruje endpoint 20 sekund szybciej. Bo ograniczenia kosztowe, limity, awarie i zmiany vendorów nie są hipotetyczne. One są wpisane w ten krajobraz.

Mentat, nie wyznawca maszyny

Najbardziej niepokoi mnie nie to, że AI pisze kod. Najbardziej niepokoi mnie sytuacja, w której programista przestaje ćwiczyć mięśnie potrzebne do oceny tego kodu.

W pewnym sensie wracamy do starej prawdy: nie wystarczy dowieźć rozwiązanie. Trzeba jeszcze wiedzieć, dlaczego działa, gdzie się wyłoży i jak będzie wyglądało za pół roku, gdy ktoś inny otworzy ten moduł o 2:13 w nocy.

AI potrafi wygenerować bardzo dużo. Nie zawsze potrafi jednak utrzymać spójność projektu, kontekst biznesowy, niuanse domeny i konsekwencje decyzji rozłożone na wiele miesięcy. To wciąż jest miejsce, w którym powinien wejść człowiek.

Zasada Pareta dla epoki promptów

W moim odczuciu sensowny układ wygląda tak: niech AI odwali 80% brudnej roboty.

Niech:

  1. zrobi nudny boilerplate,
  2. podpowie szkic testów,
  3. porówna dwa podejścia,
  4. streści dokumentację,
  5. pomoże szybciej dojść do pierwszej działającej wersji.

Ale ostatnie 20% nadal należy do programisty.

To są te 20%, które decydują o jakości:

  1. czy rozwiązanie faktycznie pasuje do architektury,
  2. czy nie rozjeżdża stylu całego projektu,
  3. czy obsługuje edge case’y,
  4. czy nie wprowadza subtelnego długu technicznego,
  5. czy da się to utrzymać bez codziennego rytuału składania ofiary z tokenów.

To właśnie w tych ostatnich 20% siedzi rzemiosło. I być może właśnie ono stanie się najcenniejsze, gdy cała reszta będzie już tanio i masowo generowana.

O samym procesie szukania rozwiązań pewnie napiszę osobno, bo to jest dziś osobna kompetencja. Nie chodziło przecież nigdy o bezmyślne kopiuj-wklej ze Stack Overflow, tylko o umiejętność czytania wątków, wyciągania sensu z komentarzy, porównywania kontekstów i dostosowywania rozwiązania do własnego projektu. Dziś wiedza jest na wyciągnięcie ręki. Pytanie brzmi już nie tylko, czy ją znajdziesz, ale czy będziesz umieć z niej skorzystać.

Kiedy kończy się przyprawa

Przyprawa jest świetna, dopóki płynie. Poszerza percepcję, przyspiesza ruchy, pozwala widzieć więcej i dalej. Ale zawód programisty nie może być zbudowany wyłącznie na dostępie do niej.

AI jest pomocą. Czasem genialną. Czasem absurdalnie skuteczną. I tak, warto z niej korzystać. Byle nie oddać jej całego rzemiosła razem z odpowiedzialnością za efekt.

Bo kiedy kończy się przyprawa, zostaje tylko to, czego naprawdę się nauczyłaś albo nauczyłeś.

I dobrze byłoby, żeby to było coś więcej niż sprawne wpisywanie promptów.