Prysznic w trakcie refaktoru. O iluzji kontroli i pętli LLM-ów
Gdy poczytasz azjatyckie media technologiczne, AI jest przedstawiane jako cudowny asystent: odda Ci cenny czas, wyręczy w nudnych sprawach, a Ty wreszcie zaczniesz żyć i robić to, co kochasz. Gdy włączysz amerykański nagłówek, AI zaraz zabierze Ci pracę, zyska świadomość i przejmie władzę nad światem.
A jak wygląda proza życia dzisiejszego programisty?
Wygląda tak: odpalasz Claude Code, Cursora czy innego Codexa, puszczasz złożony refaktor, po czym spokojnie idziesz obierać ziemniaki, gotować obiad albo brać prysznic.
Z jednej strony masz w sobie to błogie poczucie: „Wszystko idzie zgodnie z planem. Produktywność szybuje, praca robi się sama.” Z drugiej – gdzieś z tyłu głowy pojawia się cichy niepokój. To iluzja kontroli. Masz wrażenie, że wszystko jest pod nadzorem, choć coraz częściej obserwujesz proces bardziej, niż nim kierujesz.
Czarna skrzynka i ślepe zaufanie
Nawet jeśli znasz architekturę swojego projektu od podszewki i sam spędziłeś nad nim miesiące, przy odpowiednio dużym refaktorze praktycznie nikt nie jest już w stanie prześledzić linijka po linijce wszystkiego, co zrobił LLM.
Dostałeś diff na 1500 linii kodu rozsianych po 25 plikach. Człowiek zwyczajnie nie ma już przepustowości poznawczej, aby zweryfikować taki zakres zmian z taką samą dokładnością, z jaką kiedyś pisał kod własnoręcznie.
Co więc robimy? Ufamy.
- Przeszły testy jednostkowe? Przeszły.
- Aplikacja się buduje? Buduje.
- Code review niczego nie wychwyciło? Świetnie.
I właśnie tutaj zaczyna się naprawdę ciekawa pętla.
Absurd pętli: Model A kontra Model B
Każdy programista pracujący z AI prędzej czy później doświadczy tego paradoksu. Model A wykonuje refaktor, potem po kilku miesiącach Model B krytykuje wcześniejsze rozwiązania, a potem Model C robi to samo z jeszcze większą pewnością siebie.
Najbardziej ironiczne jest to, że każdy z tych modeli jest równie przekonany o swojej racji. LLM-y nie dążą do jednej, obiektywnej prawdy inżynieryjnej. Ich odpowiedzi są wynikiem statystycznych wzorców wyuczonych na danych treningowych.
Z malarza w dyrektora artystycznego
Przez dekady programista był malarzem. Dziś coraz częściej stajemy się dyrektorami artystycznymi. Mówimy agentowi, co ma powstać, korygujemy kierunek i akceptujemy efekt końcowy. A w czasie, gdy model wykonuje pracę, idziemy zrobić kawę, ugotować obiad albo wziąć prysznic.
Ceną za tę wygodę jest stopniowa utrata pełnej znajomości własnego kodu. Rynkowo może to być korzystne, ale inżyniersko oznacza coraz większy dług technologiczny.
Nie kodujemy już tak jak dawniej
Być może największą zmianą, jaką przyniosły LLM-y, nie jest szybsze pisanie kodu. Największą zmianą jest to, że po raz pierwszy w historii tworzymy oprogramowanie, którego autor nie zawsze jest w stanie w pełni prześledzić. I mimo to codziennie naciskamy Merge.