Cena prędkości, czyli programowanie wczoraj i dziś
Kiedyś to było, dziś już nie ma
Pamiętam czasy, kiedy do rozpoczęcia przygody z programowaniem wystarczał “jakiś” komputer, “jakiś” edytor tekstu i trochę wolnego czasu. Nie było inteligentnych asystentów, agentów AI ani modeli językowych, które potrafiły wygenerować połowę aplikacji na podstawie kilku zdań.
Był za to kod. Dokumentacja. Metoda prób i błędów. I sporo cierpliwości.
Moja droga zaczynała się od najprostszego Notatnika. Później pojawił się Notepad++, którego kolorowanie składni i rozpoznawanie typów plików to był przeskok jakościowy.
Następnie przyszedł czas na Eclipse. Męka z instalacją Javy i wyborem odpowiednich pluginów szybko nagradzana była działającym debuggerem oraz testami SimpleTest, a później PHPUnit, które dało się uruchomić prosto z IDE. Nie wszystko działało od razu. Czasem samo przygotowanie środowiska zajmowało pół dnia. Ale właśnie dzięki temu zaczynało się rozumieć i czuć jak profesjonalista.
Z czasem pojawiły się coraz bardziej rozbudowane IDE. IntelliJ IDEA, PhpStorm, Visual Studio Code. Autouzupełnianie, refaktoryzacja, integracja z systemami kontroli wersji, testami i debuggerami. Coraz więcej rzeczy działało niemal od razu.
Co łączyło większość tych narzędzi?
Można było z nich korzystać za darmo. Oczywiście nie ze wszystkich i nie zawsze w pełnym zakresie, ale się dało, a brak karty kredytowej nie stanowił żadnej bariery wejścia.
Komputer kupowało się raz
Mój pierwszy komputer, na którym programowałem, miał procesor Pentium 166 MMX i 8 MB RAM. Był sztos. Później przychodziły kolejne generacje procesorów, coraz więcej pamięci RAM, szybsze dyski i większe monitory. W końcu komputery z procesorami Core i5 i kolejnymi generacjami coraz wydajniejszych układów.
Rosły też wymagania. Prosty edytor ustępował miejsca rozbudowanemu IDE. Jedna aplikacja zamieniała się w kilka usług, bazę danych, cache, kolejki i kontenery Dockera.
Ale sam model finansowy pozostawał podobny. Kupowałeś komputer raz. Korzystałeś z niego przez kilka lat. Jeśli sprzęt stawał się zbyt wolny, modernizowałeś go albo kupowałeś kolejny. Był to wydatek jednorazowy. Nie musiałeś co miesiąc zastanawiać się, czy opłacić kolejny abonament, żeby zachować dotychczasową wydajność pracy.
Dziś komputer to w zasadzie terminal, a chmura stanowi naturalne środowisko do uruchamiania, a nawet testowania. Kod budujemy, testujemy i uruchamiamy na serwerach, a coraz częściej piszą go też modele działające gdzieś w centrum danych. Moc obliczeniową, za którą kiedyś płaciło się raz przy zakupie komputera, dziś wynajmuje się na godziny albo w miesięcznym planie.
Największą inwestycją był czas
Oczywiście programowanie nigdy nie było całkowicie darmowe. Komputer kosztował, prąd i internet też, ale najważniejszą inwestycją pozostawał czas. Godziny spędzone na czytaniu dokumentacji, analizowaniu błędów, eksperymentowaniu i próbach zrozumienia, dlaczego coś nie działa.
Czasami rozwiązanie problemu zajmowało cały wieczór, tyle że tamten wieczór nie był stracony. Przy okazji poznawałeś mechanizm działania biblioteki, języka, frameworka albo systemu operacyjnego, więc następnym razem podobny problem rozwiązywałeś szybciej. Po kilku latach miałeś w głowie całkiem solidny model tego, jak działa oprogramowanie, i ta wiedza zostawała z tobą.
Wystarczyły motywacja, komputer i trochę wolnego czasu, żeby systematycznie inwestować w siebie, praktycznie bez dodatkowych kosztów finansowych.
Dzisiaj bez karty ani rusz
Przeskoczmy do teraźniejszości.
Mamy narzędzia, o których kilkanaście lat temu mogliśmy tylko pomarzyć. Modele językowe potrafią pisać kod, generować testy, analizować błędy, przygotowywać dokumentację, a nawet samodzielnie realizować wieloetapowe zadania. Cały agentowy system możemy postawić na wirtualnym serwerze w chmurze, a wszystkim zarządzać praktycznie z tableta.
Teoretycznie nigdy nie było łatwiej zacząć programować. Ale czy na pewno?
Dzisiaj coraz częściej pojawia się zupełnie inny koszt, czyli abonament za produktywność.
Jeden model do codziennego programowania. Drugi do trudniejszych problemów. Edytor zintegrowany z AI. Agent działający w terminalu. Kolejne narzędzie do automatyzacji.
Nie wszystkie są płatne i nie każdy ich potrzebuje. Jednak im intensywniej korzystasz z AI, tym szybciej zaczynasz dostrzegać limity, różnice jakościowe między modelami i potrzebę przechodzenia na droższe plany.
Kiedyś ograniczała cię głównie wydajność komputera i własne umiejętności.
Dzisiaj możesz mieć świetny komputer, a mimo to zastanawiać się, czy wystarczy ci limit tokenów na dokończenie zadania.
Co więcej, płacenie niekoniecznie kończy się na jednym abonamencie. Narzędzia ewoluują, pojawiają się nowe modele, nowe integracje i kolejne obietnice zwiększenia produktywności.
Jeden serwer przestaje wystarczać, więc bierzesz następny, no i abo na ten drugi model. Aa, no i na GitHubie osiągasz limit, a w zasadzie to jeszcze musisz opłacić dostęp do maila i do pakietu biurowego, bo w pakiecie był ten fajny duży dysk, który już jest w połowie zapełniony jakimiś zdjęciami i filmami z wyjazdów. I tak nigdy nie masz czasu ich posprzątać, a ostatnio przeglądałeś je jakieś 18 miesięcy temu.
Zamiast jednorazowego kosztu sprzętu mamy rosnącą liczbę kosztów cyklicznych.
Robimy więcej. Ale czy rozumiemy więcej?
To chyba najbardziej interesująca zmiana.
Dzięki AI jesteśmy w stanie realizować znacznie więcej zadań w tym samym czasie.
Kod powstaje szybciej. Testy generują się automatycznie. Refaktoryzacja, która kiedyś zajmowała kilka godzin, może zamknąć się w kilkunastu minutach.
Problem w tym, że szybkość tworzenia kodu nie jest tym samym co szybkość zdobywania wiedzy.
Kiedy samodzielnie implementowałeś rozwiązanie, musiałeś przynajmniej w pewnym stopniu zrozumieć jego działanie. Dzisiaj możesz zaakceptować kilkaset linii kodu, których nie przeanalizowałeś nawet pobieżnie.
I aplikacja będzie działać.
Przynajmniej przez jakiś czas.
Z samą szybkością też nie jest tak prosto. W badaniu METR z lipca 2025 roku [1] 16 doświadczonych programistów open source pracowało z AI o 19% wolniej, a mimo to byli przekonani, że AI przyspieszyło ich o 20%. Sam METR zaznacza dziś, że te wyniki są nieaktualne, a w kolejnym badaniu z lutego 2026 [2] uważa, że AI najpewniej już przyspiesza pracę. Rozjazd między tym, jak szybko nam się wydaje, że pracujemy, a tym, jak jest naprawdę, jest jednak wart zapamiętania.
Dochodzi jeszcze problem retencji wiedzy. Jeżeli codziennie realizujesz kilkukrotnie więcej zadań, ale większość szczegółów delegujesz do AI, ile z tego rzeczywiście zostaje w głowie?
Anthropic sprawdził to [3] na 52 programistach, w większości juniorach, którzy mieli napisać dwie funkcje z użyciem nieznanej im biblioteki Pythona. Grupa korzystająca z AI uzyskała potem w teście wiedzy średnio 50%, a grupa pisząca samodzielnie 67%. Przy tym z AI skończyli zadanie tylko o około dwie minuty szybciej, a ta różnica nie była nawet istotna statystycznie.
I to ciekawe, bo tak samo można się zastanowić, czy po miesiącu potrafisz wyjaśnić architekturę rozwiązania, które sam zatwierdziłeś, albo zmienić coś bez użycia modelu. Myślę, że może być z tym problem. Coraz częściej jesteś jedynie operatorem procesu, którego szczegółów nie rozumiesz. To widać już dziś i będzie tylko gorzej.
Nie twierdzę, że każdy programista powinien ręcznie pisać każdą linijkę kodu. Sam korzystam z automatyzacji i widzę jej ogromną wartość. Zastanawiam się jednak, czy nie zaczynamy mylić produktywności z kompetencją.
Tony dokumentacji, której nikt nie czyta
Jest jeszcze jeden paradoks.
Narzędzia AI miały ograniczyć ilość pracy związanej z pisaniem i czytaniem dokumentacji. Tymczasem zaczynamy produkować ogromne ilości dodatkowego tekstu.
Pliki z instrukcjami dla agentów, opisy architektury, reguły projektowe, konteksty, plany implementacji, podsumowania sesji, dokumenty definiujące zachowanie modeli.
AGENTS.md, CLAUDE.md i dziesiątki innych plików.
Coraz więcej dokumentacji tworzonej przez AI, przeznaczonej głównie do konsumpcji przez inne AI. Część z niej jest naprawdę użyteczna. Problem pojawia się wtedy, gdy zaczynamy dokumentować wszystko, bez zastanowienia, albo agenci zaczynają notować zbyt dużo informacji. Potrzeba utrzymania spójności zacznie szybko stanowić niezły procent wszystkich przepalanych tokenów.
Do tego dochodzi brak ustabilizowanych standardów pracy.
Jedni używają agentów w IDE, inni w terminalu. Jedni budują rozbudowane systemy reguł i umiejętności agentów, inni preferują proste prompty. Każdego miesiąca pojawia się kolejne narzędzie, które ma zmienić sposób tworzenia oprogramowania. Zbudowanie naprawdę efektywnego środowiska pracy wcale nie jest takie proste, jak sprzedają to materiały promocyjne dużych firm. A to sprawia, że bez solidnych podstaw technicznych łatwo pomylić skomplikowane środowisko z dobrym środowiskiem.
Jeden gorszy dzień i projekt skręca w złą stronę
W klasycznym programowaniu zmęczenie zwykle oznaczało spadek tempa pracy.
Przy pracy z agentami AI zmęczenie wcale nie musi spowalniać pracy, ale może oznaczać coś znacznie gorszego.
Wyobraź sobie dzień, w którym jesteś rozkojarzony, zmęczony albo zwyczajnie nie masz ochoty analizować kolejnej implementacji.
Agent proponuje rozwiązanie. Wygląda sensownie. Akceptujesz.
Później kolejne. I następne.
Wszystko przechodzi testy. Kod się kompiluje. Funkcjonalność pozornie działa.
Tyle że gdzieś po drodze pojawiła się niepotrzebna abstrakcja, błędna decyzja architektoniczna albo zależność, której nikt świadomie nie zaplanował. Nagle agent zabezpiecza zwykły formularz na stronie na wypadek, gdyby jeden użytkownik wysłał go 100 razy na sekundę. Dokłada obsługę współbieżnych zapisów i kolejne połączenia do Redisa. Teoretycznie taki problem może zaistnieć, ale umówmy się, przy formularzu praktycznie nigdy się nie wydarzy.
Ponieważ kolejne zadania budowane są na poprzednich, ten kuloodporny kod zaraz zostaje obudowany kilkoma innymi warstwami. Po kilku dniach okazuje się, że projekt poszedł w zupełnie innym kierunku i rozwiązuje nierealistyczne problemy, czyli trochę inaczej, niż zamierzaliśmy, a z prostej klasy zrobiła się przekombinowana biblioteka, ogarniająca nieistniejące przypadki.
AI potrafi bardzo szybko rozwijać dobre rozwiązanie. Ale równie szybko potrafi je przekombinować i obudować zbędnym kodem.
I właśnie dlatego rola człowieka nie znika. Zmienia się jej charakter.
Coraz mniej czasu spędzamy na samym pisaniu kodu, a coraz więcej powinniśmy poświęcać na ocenę decyzji, architektury i konsekwencji proponowanych rozwiązań.
Tylko skąd brać umiejętność ich oceniania, jeśli nigdy nie nauczyliśmy się samodzielnie ich tworzyć?
Czy początkujący programista powinien zaczynać od AI?
Systemy informatyczne to dziś bardzo złożone twory. Jeżeli zaczynasz “programowanie” od delegowania wszystkiego do AI bez zrozumienia podstawowych konceptów, nie będziesz potrafił ocenić rozwiązania, które AI ci proponuje, a ilość elementów, którą wygeneruje, szybko potrafi przytłoczyć. I może to jest ok przy prostej stronie internetowej, być może nawet przy prostej aplikacji mobilnej, którą robisz hobbystycznie, albo przy jakimś demo. Ale czy weźmiesz za to odpowiedzialność na produkcji, jeśli chcesz stworzyć produkt dla kogoś innego?
Nowoczesnych narzędzi nie trzeba ignorować ani sztucznie utrudniać sobie życia. Ważna jest kolejność. Najpierw warto nauczyć się podstaw, czyli języka, struktur danych, debugowania, testowania, HTTP, baz danych, podstaw architektury i zasad działania aplikacji. Napisać kilka rzeczy samodzielnie, popełnić błędy i zrozumieć, dlaczego jedno rozwiązanie działa, a inne nie. Dopiero później stopniowo oddawać powtarzalne czynności automatyzacji.
AI może być przy tym znakomitym nauczycielem, bo potrafi tłumaczyć skomplikowane zagadnienia, wskazywać błędy i pomagać w nauce. Gorzej, kiedy zastępuje sam proces uczenia się. Jeśli znasz podstawy, AI zwiększa twoje możliwości. Jeśli ich nie znasz, możesz stać się całkowicie zależny od jego odpowiedzi.
Wczoraj inwestowaliśmy czas. Dzisiaj kupujemy prędkość.
Nie chciałbym wracać do czasów, kiedy konfiguracja debuggera potrafiła zająć pół dnia, a znalezienie błędu wymagało przekopania się przez kilkadziesiąt stron dokumentacji. Dzisiejsze narzędzia są obiektywnie potężniejsze i pozwalają pojedynczemu programiście realizować rzeczy, które kiedyś wymagały całego zespołu.
Ta zmiana ma jednak swoją cenę i nie chodzi tylko o abonamenty. Kiedyś naturalnym produktem ubocznym tworzenia oprogramowania było zdobywanie wiedzy, a dziś nikt tego nie gwarantuje. Można budować więcej, szybciej i taniej w przeliczeniu na wykonaną pracę, a jednocześnie coraz mniej rozumieć z tego, co powstaje.
Dlatego bardziej niż szybkość generowania kodu liczy się według mnie umiejętność oceny, jaki kod w ogóle powinien powstać, i rozumienie konsekwencji własnych decyzji. Do tego nadal potrzebna jest wiedza, a tej nie da się po prostu wykupić w miesięcznym abonamencie.
Źródła