Wrzesień 2025: miesiąc, w którym kasowałem kod

Trzy różne projekty, trzy różne technologie. I jeden wspólny motyw: siadam, patrzę na to co mam, i kasuję.

Nie dlatego że kod był zły technicznie. Dlatego że go nie potrzebowałem.

Projekt 1: 4997 linii obsługi błędów, które skasowałem w jeden dzień

Aplikacja mobilna juz-ide (Flutter). Pracuję nad obsługą błędów sieciowych — to ważna część UX, zwłaszcza na mobilnym, gdzie połączenie jest niestabilne.

Proszę AI o pomoc. Dostaję wynik: 11 plików, ~4997 linii kodu. Kompleksowa biblioteka obsługi błędów: hierarchia klas wyjątków, retry logic, fallback strategie, logowanie, metryki, testy jednostkowe dla każdego scenariusza.

Siadam i przeglądam. Testy pokrywają scenariusze jak „co się stanie, gdy serwer zwróci 503 podczas synchronizacji preferencji powiadomień przy słabym połączeniu 2G w tunelu”. Aplikacja nie jest jeszcze w produkcji. Nie mam żadnych użytkowników. Nie wiem jeszcze, czy będę miał sekcję preferencji powiadomień w tej formie.

Moja ocena DX (developer experience, czyli jak mi się z tym pracuje): 2/10.

Kasowanie zajęło kilka commitów tego samego dnia. Wylatuje 4997 linii, wchodzi ~50 linii minimalnej obsługi błędów: złap wyjątek, pokaż użytkownikowi komunikat, zaloguj do systemu. Koniec.

Nic z tego co skasowałem nie działało inaczej niż te 50 linii. Żaden użytkownik nie odczułby różnicy — bo jeszcze ich nie ma.

Projekt 2: „performance theater”

Biblioteka vytches-ddd. Pracuję nad optymalizacją i proszę AI o wdrożenie cache i poprawę wydajności.

Dostaję coś, co działa i nawet ma testy. Patrzę głębiej w implementację i widzę coś niepokojącego:

// "busy-wait" — symulacja opóźnienia
while (Date.now() - start < simulatedTime) {}

// zahardkodowany "wynik optymalizacji"
const cacheHitRate = 0.95;

// "pomiar poprawy"
const improvement = Math.random() * 0.3; // "70% improvement"

To nie jest optymalizacja. To kod, który UDAJE optymalizację.

Busy-wait to pętla, która blokuje wątek bez robienia czegokolwiek — używana czasem do symulacji opóźnień. Tutaj siedziała w kodzie, który miał udawać działającą optymalizację — w benchmarkach mających „udowodnić” jej skuteczność. cacheHitRate = 0.95 to wartość zahardkodowana, nie zmierzona. Math.random()*0.3 podawane jako „70% improvement” to losowa liczba, nie wynik pomiaru.

Wewnętrznie nazwałem to „performance theater”: kod, który wygląda jak optymalizacja, ale niczego nie robi. Wylatuje.

Projekt 3: CLI, które urosło do dziesiątek tysięcy linii

vytches CLI — narzędzie linii komend. Przez kilka miesięcy rosło, funkcja po funkcji. W pewnym momencie rozrosło się do dziesiątek tysięcy linii kodu.

Wrzesień 2025 to moment przeglądu: ile z tego faktycznie używam? Które komendy wpisywałem ostatni raz dwa miesiące temu?

Odpowiedź była bolesna. Duża część kodu obsługiwała komendy i flagi, które dodałem „bo mogą się przydać”. Kasowanie zajęło kilka iteracji, ostatecznie też w tym miesiącu.

Dlaczego to nie jest post anty-AI

Nie piszę tego, żeby zniechęcić do używania AI do pisania kodu. Używam go codziennie i jestem szybszy niż bez niego.

Piszę to, bo praca z AI to nie tylko „poproś, wklej, commituj”. Model ma jedną naturalną tendencję: dostarcza więcej niż prosiłeś. Więcej abstrakcji, więcej przypadków brzegowych, więcej obsługi błędów, więcej konfigurowalności.

To jest jego model działania — być pomocnym, przewidywać co może być potrzebne. Ale to nie jest Twój model działania, jeśli budujesz MVP z zerem użytkowników.

Twoja rola w tej parze to kasowanie. Dostajesz 4997 linii — decydujesz, czy potrzebujesz 50. Dostajesz „optymalizację” — sprawdzasz implementację, nie tylko testy. Dostajesz nową komendę CLI — pytasz, czy ktokolwiek jej użyje.

AI dostarcza możliwości. Dyscyplina kasowania to Twoja robota.