Mój wykres aktywności na GitHubie za 2025 rok wygląda tak, jakby należał do dwóch różnych programistów. Pierwsza połowa roku jest niemal pusta. W drugiej znalazło się ponad 4000 commitów.
Nie dostałem nagle więcej wolnego czasu. Nadal łączyłem etat z pobocznymi projektami. Zmieniło się coś innego: tarcie między pomysłem a działającą wersją. Zacząłem znacznie poważniej korzystać z narzędzi AI do programowania.
Ta liczba wymaga jednak precyzji. Sama liczba commitów nie jest miarą produktywności. Cztery tysiące commitów nie dowodzą czterech tysięcy wartościowych ulepszeń ani wysokiej jakości kodu. Wykres pokazuje natomiast realną zmianę mojego rytmu pracy: dużo regularniej budowałem, iterowałem i doprowadzałem rzeczy do działającego stanu.
Prawdziwym wąskim gardłem była energia potrzebna do rozpoczęcia eksperymentu
W side projectach wracał ten sam problem: pierwsza użyteczna wersja często znajduje się za dużą ilością rutynowej pracy. Routing, walidacja, skrypty, testy, konfiguracja i cleanup potrafią zużyć momentum, zanim w ogóle wiadomo, czy pomysł jest wart rozwijania.
Wcześniej odkładałem eksperymenty, gdy pierwszy działający rezultat wyglądał na kilka wieczorów setupu. Narzędzia AI coding nie usunęły tej pracy, ale obniżyły koszt first pass i skróciły drogę do wersji testowalnej.
Największą korzyścią nie było więc szybsze pisanie. Była nią niższa activation energy: więcej pomysłów faktycznie docierało do momentu, w którym mogłem zebrać prawdziwe dane.
Jak zmienił się mój workflow w Node.js
Nie zastąpiłem procesu developmentu oknem chat. W side projectach Node.js używałem DeepSeek jako drugiej pary rąk do jasno ograniczonych zadań: przygotowania pierwszej implementacji, czytania nieznanego kodu, proponowania testów, analizy stack trace, dzielenia dużego refactoru i sprawdzania założeń deploymentu.
- Scaffolding: pierwsza nudna wersja handlerów, walidacji, skryptów lub testów.
- Code reading: śledzenie requestu lub wartości przed zmianą.
- Refactoring: dzielenie mechanicznych zmian na małe, łatwe do review diffy.
- Debugging: tworzenie kilku hipotez z logów.
- Verification: szukanie edge case'ów i regresji po uruchomieniu happy path.
Im jaśniejsze były inputy, outputy, constraints i istniejące konwencje, tym łatwiej było zweryfikować wynik. Niejasne taski częściej prowadziły do wiarygodnie brzmiącej, ale złej abstrakcji.
Dlatego output AI traktowałem jak candidate patch, a nie końcową odpowiedź. Type checking, testy, build i realny flow były dowodem; pewny ton nie.
Gdzie DeepSeek pomagał najbardziej — a gdzie nie
DeepSeek był dla mnie użyteczny przede wszystkim dlatego, że mogłem wielokrotnie używać go przy konkretnych zadaniach programistycznych. Mogłem poprosić o first pass, odrzucić część, podać prawdziwy błąd, zawęzić scope i szybko iterować.
Nie nazywam tego benchmarkiem. Nie przeprowadziłem kontrolowanego badania wszystkich konkurencyjnych modeli, a lineup modeli zmienia się szybko. Uczciwe stwierdzenie jest węższe: DeepSeek pasował do mojego workflow na tyle dobrze, że zacząłem używać AI assistance znacznie częściej.
Najlepiej działał tam, gdzie feedback był tani: funkcja, testy i realny błąd. Gorzej radził sobie z nieopisanym kontekstem produktu i subtelnymi trade-offami architektonicznymi. Wtedy płynna odpowiedź mogła sprawić, że złe założenie wyglądało na gotowe rozwiązanie.
AI zmieniło koszt eksperymentowania
Największa poprawa nie polegała na tym, że „AI pisze kod, więc development stał się automatyczny”. Wiele małych elementów stało się po prostu na tyle tanich do sprawdzenia, że warto było spróbować. Funkcja, która wcześniej wyglądała jak zbyt dużo setupu, mogła stać się prototypem, zanim straciłem zainteresowanie pomysłem.
To rozróżnienie jest ważne. AI obniżyło koszt dojścia do wersji, którą da się przetestować. Nie usunęło architektury, decyzji produktowych, deploymentu ani potrzeby poprawnego działania. Wygenerowana implementacja może być błędna; poprawny build może zepsuć się w runtime; wdrożony prototyp może nadal być słabym produktem.
Dla mnie największą praktyczną korzyścią był rozpęd. Gdy widziałem już cały system działający, znacznie chętniej dalej go poprawiałem.
Czego wymagałby mocniejszy benchmark
Dla reprodukowalnego benchmarku zapisywałbym dokładne wersje modeli, stałe zadania programistyczne, snapshoty repozytorium, prompty, raw output, czas, zaakceptowane i odrzucone patche, review time, wyniki testów oraz rework.
Mierzyłbym też coś więcej niż commity: czas od pomysłu do zweryfikowanej wersji, defekty, rollbacki i przepisaną pracę. Bez tego kontekstu 4000 commitów pokazuje aktywność i zmianę zachowania, nie jakość software.
Co się dla mnie zmieniło
2025 był rokiem, w którym przestałem traktować każdy side project jak górę setupu, którą muszę ręcznie pokonać. AI sprawiło, że pierwsza działająca wersja stała się wystarczająco tania, bym częściej docierał do etapu, na którym naprawdę liczą się decyzje produktowe.
Dlatego druga połowa mojego wykresu GitHub wygląda tak inaczej. Nie dlatego, że AI dało mi więcej godzin w ciągu dnia, ani dlatego, że każda wygenerowana linia była dobra. Zmniejszyło tarcie, przez które wcześniejsze pomysły umierały, zanim stały się realne.
W 2026 bardziej interesuje mnie mniej efektowna połowa równania: dopracowanie workflow, poważniejsze mierzenie jakości i pilnowanie, żeby szybszy development dawał lepsze oprogramowanie, a nie tylko więcej commitów.