Zaczynam mieć dziwne poczucie, że im więcej projektuję z Ai, tym mniej czasu spędzam na samym projektowaniu.
Kiedyś stworzenie rozbudowanej makiety wymagało wielu godzin pracy. Każdy ekran, interakcję czy zależność trzeba było zbudować, przemyśleć i poprawić.
Było to czasochłonne, momentami nudne i zapewne w dużej części zupełnie niepotrzebne ale miało jedną zaletę, którą zawsze doceniałem. Tworzenie było jednocześnie procesem rozumienia i synchronizowania tej wiedzy z innymi.
Kiedy budowałem kolejne elementy rozwiązania, siłą rzeczy musiałem zastanawiać się nad ich działaniem. W trakcie pracy odkrywałem zależności, których wcześniej nie przewidziałem. Zadawałem sobie pytania, które nie pojawiłyby się na etapie samego pomysłu, a inni korygowali mój kierunek tworząc nowe powiązania.
Dzisiaj coraz rzadziej buduję poszczególne elementy. Definiuję cel, kontroluję logikę, oceniam wynik. To, co wcześniej zajmowało kilka dni, potrafi powstać w kilkanaście minut. Nie muszę już ręcznie budować wszystkiego, co wymyśliłem.
Nareszcie!
Po latach przesuwania prostokątów, wyrównywania komponentów technologia wreszcie daje pole na logikę rozwiązania. Przecież czekałem na to tak długo…
Tylko że pojawia się pewien problem.
Rozwiązania zaczynają powstawać szybciej,
niż jesteśmy w stanie je wspólnie zrozumieć.
Coraz częściej patrzę na gotowy rezultat i zdaję sobie sprawę, że więcej czasu zajmuje mi przeanalizowanie wszystkich zależności, decyzji i konsekwencji, a następnie zbudowanie tego samego zrozumienia w zespole, niż zajęło mi stworzenie tego rozwiązania.
Rozumiem ogólny zamysł. W końcu to ja go zdefiniowałem. Rozumiem podstawowe procesy i wiem, jakie problemy chcę rozwiązać, ale niekoniecznie rozumiem już wszystkie szczegóły, zależności i konsekwencje.
AI potrafi zaproponować całe fragmenty rozwiązania, których nie opisałem wprost. Uzupełnia brakujące elementy, interpretuje intencje, tworzy własne założenia. Czasami bardzo trafne. Czasami zupełnie przypadkowe.
W efekcie dostaję coś, co wygląda na bardziej kompletne, niż jest w rzeczywistości, a ponieważ całość prezentuje się całkiem przekonująco, łatwo uznać, że skoro działa, to najwyraźniej wszystko jest w porządku.
Problem pogłębia się, kiedy takie rozwiązanie trafia do zespołu. Każdy widzi ten sam prototyp, ale niekoniecznie rozumie stojące za nim decyzje. To, co dla mnie jest oczywistym założeniem, dla programisty może być jedynie domysłem, a dla osoby odpowiedzialnej za biznes, zupełnie inną interpretacją.
Możemy patrzeć na ten sam prototyp,
a rozumieć / „widzieć” zupełnie inny produkt.
Przynajmniej do momentu, kiedy ktoś zada pierwsze naprawdę dobre pytanie.
W programowaniu od lat funkcjonuje pojęcie długu technologicznego. Możemy zbudować coś szybciej, korzystając z uproszczeń, za które później przyjdzie nam zapłacić.
Zaczynam dostrzegać podobny mechanizm w projektowaniu. Nazywamy go długiem poznawczym (Cognitive Dept1).
1 Margaret-Anne Storey, From Technical Debt to Cognitive and Intent Debt (ACM Queue, 2026)
Każde rozwiązanie, które powstało szybciej, niż zdążyłem je świadomie przeanalizować, może pozostawić po sobie pewną zaległość. Coś, czego jeszcze nie rozumiem. Decyzję, której konsekwencji nie sprawdziłem. Założenie, którego nawet nie zauważyłem.
Wszystko powstaje tak płynnie, że trudno znaleźć moment, w którym należałoby powiedzieć: stop, teraz muszę naprawdę zrozumieć, co właśnie stworzyliśmy. Zresztą po co się zatrzymywać, skoro możemy wygenerować kolejne pięć wariantów? W końcu produktywność rośnie. Liczba dostarczanych rozwiązań również. Tylko poziom naszego zrozumienia niekoniecznie nadąża za tym imponującym wykresem.
Przypomina mi się Solaris Stanisława Lema

Ludzkość bada tajemniczy ocean pokrywający odległą planetę. Powstają teorie, klasyfikacje, obserwacje i całe biblioteki opisujące jego zachowanie. Naukowcy wiedzą o nim coraz więcej. Potrafią nazywać zjawiska, opisywać struktury i dokumentować kolejne obserwacje, a mimo to fundamentalna natura oceanu pozostaje dla nich niezrozumiała.
W tej historii fascynuje mnie, jak Lem uchwycił przepaść pomiędzy zgromadzoną wiedzą, a prawdziwym poznaniem. Widać tu pewną analogię.
Możemy mieć coraz bardziej szczegółowe opisy naszych rozwiązań. Coraz więcej ekranów, dokumentacji, zależności, interakcji i scenariuszy działania. Możemy nawet poprosić AI, żeby wyjaśniło nam każdy fragment tego, co właśnie wygenerowało, ale opis nie jest jeszcze zrozumieniem.
Można wiedzieć bardzo dużo o tym, jak coś działa, i nadal nie rozumieć, dlaczego powinno działać właśnie w ten sposób.
Co więcej, samo wyjaśnienie wygenerowane przez AI może być równie przekonujące jak rozwiązanie, którego dotyczy.
Dostajemy więc opis, który tłumaczy wcześniejszy opis.
A jeśli nadal czegoś nie rozumiemy, możemy oczywiście poprosić o jeszcze dokładniejsze wyjaśnienie. Ocean Lema prawdopodobnie byłby zachwycony.
Przez lata staraliśmy się skracać czas potrzebny na przejście od pomysłu do gotowego rozwiązania. Budowaliśmy narzędzia, które miały uwolnić nas od powtarzalnych czynności. Automatyzowaliśmy procesy, rozwijaliśmy biblioteki komponentów, tworzyliśmy coraz lepsze środowiska projektowe. Wszystko po to, żeby mniej czasu poświęcać na wykonywanie, a więcej na myślenie.
Teraz wreszcie mamy narzędzia, które realizują tę obietnicę w stopniu, jakiego jeszcze niedawno trudno było sobie wyobrazić.
I co robimy z odzyskanym czasem?
