Paradoks szybkiego pisania kodu

Żyjemy w dziwnych czasach. Wystarczy wrzucić opis funkcjonalności do ChatGPT, a po kilku minutach dostajemy działający kod. Dla programistów z dwudziestoletnim stażem to jednocześnie ekscytujące i niepokojące.

Szybkość jest oczywista. Niepokojące jest coś innego – trudniej to nazwać, ale realne. Gdy kod pojawia się natychmiast, znika coś, co trudno zmierzyć. A jednak to właśnie ta część procesu uczy najwięcej.

Wartość tarcia

W projektowaniu mówi się czasem, że „tarcie ma wartość”. Nie zawsze warto je eliminować – czasem ono właśnie tworzy doświadczenie.

Weźmy prosty przykład: wizualizator kart dziurkowanych. AI zrobi to w pięć minut. Ale jeśli napiszesz to sam, od zera, bez podpowiedzi i bez gotowych fragmentów, nagle projekt nabiera innego charakteru.

Zamiast kopiować logikę, musisz ją zrozumieć. Zamiast poprawiać błędy modelu, sam decydujesz, jak ułożyć dane. I to właśnie wtedy coś zostaje w głowie na dłużej.

Notatnik nie zniknął

Jeszcze niedawno wielu programistów zaczynało od kartki. Rysowali schematy, pisali pseudokod, zastanawiali się nad strukturą, zanim otworzyli edytor. To nie był dodatkowy krok – to był etap myślenia.

Dziś ten etap się skurczył. Najpierw generujemy kod, potem go poprawiamy. Ale to właśnie w fazie „przed kodem” rodziło się prawdziwe zrozumienie. Bez niej łatwiej pisać, trudniej rozumieć.

Metryki kontra rzemiosło

AI pozwala mierzyć produktywność w liniach kodu na godzinę i liczbie wdrożeń. Problem w tym, że te liczby nie pokazują, czy system jest dobrze zaprojektowany. Szybkość nie zastępuje intuicji.

Jeśli przez rok i osiem miesięcy nie rozwiążesz problemu samodzielnie, instynkt zaczyna zanikać. A gdy AI poda rozwiązanie błędne – a przy złożonej logice zdarza się to częściej, niż się wydaje – nie zawsze to zauważysz.

Ruch wolnego kodu

Rozwiązanie nie polega na rezygnacji z AI. Chodzi o to, żeby czasem świadomie z niego nie korzystać. Raz w miesiącu. Godzina. Projekt bez deadline'u i bez presji.

Może to być prosta gra, narzędzie do przetwarzania danych albo implementacja struktury od podstaw. Cel nie jest w tym, żeby udowodnić, że dasz radę bez AI. Chodzi o to, żeby pamiętać, co sam wnosisz do procesu: ciekawość, doświadczenie i umiejętność zadawania dobrych pytań.

Jak zacząć

Jeśli chcesz spróbować, zacznij od prostego ćwiczenia. Wyłącz asystenta. Ustaw timer. Wybierz mały projekt i napisz go ręcznie. Nie musisz nikomu tego pokazywać – chodzi o proces, nie o efekt.

Niektórzy robią to solo. Inni szukają ludzi, którzy robią podobnie. Ważne, żeby nie traktować tego jak powrotu do przeszłości, tylko jak świadomy dodatek do codziennej pracy.

Bo najlepszy kod nie powstaje najszybciej. Powstaje wtedy, gdy wiesz, co robisz.