Kod jest tani. Zrozumienie nadal kosztuje. Co AI naprawdę zmienia w pracy programisty

Najpierw oddałem AI drobne zadania

Zmiana nie przyszła w formie jednej decyzji. Najpierw oddałem AI zadania, które były małe, przewidywalne i zwyczajnie nudne: napisanie wyrażenia regularnego, poprawienie zapytania SQL, dopisanie testu do znanej funkcji, przeniesienie tego samego warunku przez kilkanaście plików. Model oszczędzał po kilka minut. Czasem godzinę. Nic, co wyglądałoby jak zmiana zawodu.

Potem zacząłem dawać mu pierwsze wersje całych fragmentów: klienta API, migrację danych, prosty panel, refaktor modułu, którego nie chciałem rozgrzebywać ręcznie. Nadal ja określałem zadanie i sprawdzałem wynik, ale punkt startu przesunął się z pustego pliku na cudzą propozycję. Cudzą... choć wygenerowaną.

Dziś najczęściej używam Claude do przeszukiwania repozytorium, przygotowania pierwszej implementacji, mechanicznych zmian i szukania przyczyny błędu. Rzadziej pytam „jak napisać tę funkcję?”. Częściej opisuję rezultat, ograniczenia i miejsca, których model nie powinien dotykać. Potem czytam diff. To nadal programowanie, tylko coraz mniej przypomina samo pisanie kodu.

Szersze dane pokazują ten sam kierunek, chociaż nie aż tak jednolity. W badaniu Stack Overflow z 2025 roku 84% respondentów deklarowało, że używa narzędzi AI w procesie tworzenia oprogramowania albo planuje ich używać. GitHub już w lutym 2023 roku podawał, że Copilot generował średnio 46% kodu w plikach, w których był włączony. Ten wynik bywa później cytowany jako „46% całego kodu”, co jest wygodnym skrótem i jednocześnie lekkim oszustwem. Pomiar dotyczył użytkowników Copilota oraz plików objętych jego działaniem.

Gartner przewiduje, że do 2028 roku 90% programistów w przedsiębiorstwach będzie używać asystentów kodowania AI. Według tej samej prognozy praca ma przesuwać się od implementacji w stronę orkiestracji, projektowania systemów i kontroli wyników.

Brzmi znajomo. Tylko prognoza nie mówi jeszcze, jak duża będzie ta zmiana ani kto rzeczywiście na niej zyska.

Programista nie zniknął. Przesunęła się praca

Łatwo dziś opisać programistę jako osobę, która już nie pisze kodu. Pisze polecenia i zatwierdza to, co zrobił agent. To dobrze wygląda na slajdzie, gorzej opisuje prawdę.

W tym samym badaniu Stack Overflow większość respondentów nie określała swojej pracy jako vibe coding. Agenci też nie byli jeszcze narzędziem powszechnym. Część programistów korzysta z autouzupełniania, część rozmawia z modelem o architekturze, a część deleguje całe zadania. Te sposoby pracy wrzuca się do jednego worka, chociaż różnią się poziomem kontroli i ryzykiem.

Najbardziej widoczna zmiana dotyczy proporcji. Mniej czasu zajmuje napisanie pierwszej wersji. Więcej czasu pochłania określenie zadania, dostarczenie kontekstu, ocena wyniku i poprawianie rzeczy, które są prawie dobre. To ostatnie jest ważne. Kod ewidentnie zły odrzuca się szybko. Kod prawie poprawny wygląda rozsądnie, przechodzi część testów i zużywa uwagę dokładnie tam, gdzie człowiek ma jej najmniej.

Przez ostatnie dekady za miarę produktywności programisty uważano sprawność w pisaniu kodu: znajomość składni, bibliotek i algorytmów. Narzędzia LLM sprawiły, że „czysty kod” stał się towarem powszechnym.

Być może dlatego praca z AI często wydaje się szybsza, nawet kiedy pomiar pokazuje coś innego. Pisanie jest męczące w prosty sposób. Czekanie na model, czytanie odpowiedzi i wydawanie kolejnych poleceń daje wrażenie postępu. Pasek się rusza. Agent coś robi. Miły wieczór, dopóki po trzeciej poprawce nie zauważysz, że naprawił objaw i przeniósł błąd dwa katalogi dalej.

Koszt tokenów schodzi do Excela

Przez pierwsze lata narzędzia do kodowania AI sprzedawano jak abonament. Stała opłata, duży limit, używaj ile chcesz. To pasowało do etapu eksperymentów. Firma kupowała licencje, programiści sprawdzali, co działa, a dział finansowy widział jedną pozycję na fakturze.

Ten okres się kończy. Modele wykonują dłuższe zadania, czytają większe repozytoria, uruchamiają testy i wracają do problemu kilka razy. Koszt jednej sesji bywa mały, ale skala przestaje być mała. Gartner w maju 2026 roku podniósł prognozę światowych wydatków na AI do 2,59 biliona dolarów w 2026 roku, o 47% więcej niż rok wcześniej. Większość tej kwoty pochłania infrastruktura. CFO i tak zobaczy trend.

Pojawią się więc metryki. Koszt tokenów na funkcję. Koszt agenta na pull request. Liczba zaakceptowanych linii kodu. Być może nawet „procent zaufania” do wygenerowanej zmiany, bo dashboard zniesie wszystko, jeśli tylko dostanie liczbę z jednym miejscem po przecinku.

Problem zaczyna się wtedy, gdy metryka przestaje opisywać koszt i zaczyna sterować zachowaniem. Zespół rozliczany z tokenów ograniczy iteracje, wybierze tańszy model albo zaakceptuje pierwsze działające rozwiązanie. Koszt spadnie. Liczba poprawek po wdrożeniu może pójść w drugą stronę... i wtedy ktoś zbuduje kolejny dashboard. Z kolei zespół rozliczany z ilości linijek kodu i użycia AI zacznie generować kod dla generowania kodu. Tłumaczyć komentarze w kodzie na 144 języki (pozdrawiam kolegę). Koszt wzrośnie…. i wtedy ktoś zbuduje kolejny dashboard.

Zaufanie nie mieści się w procencie

Największy problem z AI w programowaniu nie dotyczy samego generowania kodu. Dotyczy zaufania.

W Stack Overflow Developer Survey 2025 narzędziom AI ufało 33% respondentów, a 46% deklarowało brak zaufania do ich poprawności. Najczęstsza frustracja była jeszcze bardziej konkretna: 66% programistów wskazało odpowiedzi „prawie poprawne”. 45% uznało, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu, niż powinno.

Te liczby opisują doświadczenie użytkowników, nie jakość każdej zmiany. Mimo tego trafiają w sedno. Model rzadko zachowuje się jak losowy generator. Zwykle daje rozwiązanie spójne, dobrze nazwane i lokalnie sensowne. Błąd siedzi w założeniu, którego nie widać: inny model uprawnień, nieobsłużona konkurencja zapisów, zła interpretacja domeny, metoda z dokumentacji sprzed dwóch wersji.

Nie istnieje jednak jeden procent zaufania do kodu. Zaufanie jest skrótem dla dowodów, które zebraliśmy. Czasem dowodem jest wiedza autora. Czasem testy. Innym razem analiza statyczna, ograniczone wdrożenie, monitoring albo możliwość szybkiego wycofania zmiany. Każdy z tych elementów może zawieść. Razem zmniejszają ryzyko.

Ekspert ma przewagę, bo szybciej zauważa błędne założenia. Nie musi jednak wiedzieć więcej od modelu w każdym szczególe. To nierealny standard. Współczesne systemy od dawna składają się z warstw, których nikt w zespole nie rozumie w całości. Programista nie zna implementacji systemu operacyjnego, kompilatora, bazy danych i wszystkich zależności. Nadal potrafi budować odpowiedzialnie, jeśli rozumie ich kontrakty i granice.

AI wygeneruje 10 wersji tej samej funkcji w minutę. Ale to inżynier musi wiedzieć, dlaczego dziewięć z nich wywoła wyciek pamięci albo deadlock na produkcji przy 10 000 zapytań na sekundę.

Testy nie kończą rozmowy

Łatwo powiedzieć: mamy testy, więc problem zaufania jest rozwiązany. Nie jest. Ale równie łatwo popaść w drugą skrajność i uznać, że testy sprawdzają wyłącznie to, co system robi, a nie sposób, w jaki to robi. To też nieprawda.

Testy mogą wykrywać problemy z wydajnością, współbieżnością i bezpieczeństwem. Testy właściwościowe (property-based tests) sprawdzają całe klasy danych wejściowych. Fuzzing rzuca w system przypadkami, których autor nie przewidział. Testy obciążeniowe pokazują, że rozwiązanie działające dla stu rekordów rozpada się przy stu tysiącach. Analiza statyczna wyłapuje część błędów jeszcze przed uruchomieniem kodu.

Tyle że zestaw testów nadal jest modelem naszych oczekiwań. Nie sprawdzi warunku, którego nikt nie zapisał. Agent może też wygenerować implementację i testy oparte na tym samym błędnym założeniu. Wszystko będzie zielone. Błąd dostanie oficjalne potwierdzenie jakości.

Dlatego pytanie „czy są testy?” niewiele mówi. Ważniejsze jest, skąd wzięły się wymagania, kto próbował podważyć rozwiązanie i co zobaczymy po wdrożeniu. Testy są częścią dowodu.

Moltbook i jeden brakujący przełącznik

Na początku 2026 roku Moltbook, sieć społecznościowa dla agentów AI, stał się idealnym materiałem na opowieść o vibe coding. Założyciel publicznie mówił, że nie napisał ani jednej linii kodu. Miał wizję architektury, AI zbudowało resztę.

Kilka dni później badacze Wiz znaleźli źle skonfigurowaną bazę Supabase. Dostęp obejmował około 4,75 miliona rekordów, 35 tysięcy adresów e-mail i 1,5 miliona tokenów uwierzytelniających agentów. Można było czytać dane, przejmować konta i modyfikować treści w działającym systemie.

Najciekawszy szczegół nie dotyczy samego klucza widocznego w JavaScript. Publiczny klucz Supabase może znajdować się po stronie klienta. Bezpieczeństwo opiera się wtedy na regułach Row Level Security. W Moltbooku reguł nie włączono. Klucz, który w poprawnie skonfigurowanym systemie działa jak identyfikator projektu otworzył całą bazę.

To nie jest dowód, że AI zawsze tworzy niebezpieczny kod. Człowiek mógł popełnić identyczny błąd i ludzie robili takie rzeczy długo przed ChatGPT. AI zmieniło tempo oraz próg wejścia. Osoba bez doświadczenia w bezpieczeństwie mogła złożyć produkcyjny system, obsłużyć tysiące użytkowników i dojść do momentu, w którym jeden brakujący element konfiguracji miał ogromny zasięg.

W tym miejscu kończy się wygodna narracja o tym, że wystarczy oceniać efekt. System działał. Interfejs odpowiadał. Użytkownicy mogli zakładać konta. Problem leżał w modelu uprawnień, którego nie było widać na ekranie.

„Core business” to zła mapa ryzyka

Przez pewien czas dzieliłem kod na dwie grupy. Pierwsza obejmowała to, co firma naprawdę sprzedaje i na czym zna się najlepiej. Tam trzeba rozumieć sposób wykonania. W pozostałych obszarach miał liczyć się głównie wynik.

Ten podział jest kuszący. Jest też zbyt prosty.

Uwierzytelnianie rzadko odróżnia firmę od konkurencji. Backupy nie są jej głównym produktem. Rozliczenia, migracje danych i kontrola dostępu również. Błąd w jednym z tych miejsc może jednak zatrzymać działalność albo skończyć się wyciekiem danych. Z drugiej strony firmowa strona marketingowa może być daleko od głównego produktu i mieć niewielkie ryzyko, dopóki nie zbiera danych klientów ani nie steruje płatnościami.

Lepsze pytanie brzmi: co się stanie, jeśli ten fragment zawiedzie? Czy błąd zauważymy od razu? Czy można cofnąć zmianę bez utraty danych? Kto poniesie skutki?

To przesuwa granicę. Nie trzeba czytać każdej linii wygenerowanego kodu z takim samym skupieniem. Trzeba dobrać poziom kontroli do szkody, jaką może zrobić błąd. Kod formularza kontaktowego i mechanizm naliczania prowizji nie zasługują na ten sam proces tylko dlatego, że oba powstały przy pomocy Claude.

AI obniża także koszt utrzymania

Często słyszę zdanie: AI obniżyło koszt napisania kodu, ale nie obniżyło kosztu jego posiadania. Pierwsza część jest oczywista. Druga brzmi dobrze, lecz jest zbyt kategoryczna.

Model potrafi wyjaśnić obcy moduł, znaleźć zależności, przygotować migrację, dopisać test regresyjny i wykonać mechaniczny refaktor w kilkudziesięciu plikach. To są zadania utrzymaniowe. Ich koszt spada. Czasem mocno.

Nie spada wszędzie jednakowo. W kodzie dobrze znanym zespołowi AI przyspiesza pracę, bo człowiek potrafi ocenić proponowaną zmianę. W obszarze, którego nikt nie rozumie, model może produkować kolejne poprawki na podstawie poprzednich poprawek. Każda lokalnie sensowna. Całość coraz bardziej obca.

Badania produktywności nie dają dziś jednego wyniku. W kontrolowanym badaniu METR z 2025 roku szesnastu doświadczonych programistów wykonywało 246 prawdziwych zadań w repozytoriach, które znali od lat. Z narzędziami AI pracowali średnio o 19% dłużej, chociaż byli przekonani, że AI ich przyspieszyło. Badanie dotyczyło modeli z początku 2025 roku i specyficznej grupy ekspertów, więc nie opisuje całej branży.

GitHub opublikował z kolei kontrolowane badanie, w którym kod napisany z Copilotem był częściej poprawny, łatwiejszy do odczytania i częściej akceptowany przez recenzentów. Próba oraz zadanie były ograniczone, a badanie prowadził producent narzędzia. Nadal jest to dowód, którego nie można po prostu wyrzucić, bo nie pasuje do opowieści o spadku jakości.

Oba wyniki mogą być prawdziwe. AI pomaga w jednych zadaniach i przeszkadza w innych. Nowy moduł, dobrze opisane API i mechaniczna zmiana to inne środowisko niż dojrzałe repozytorium z niepisanymi zasadami, historią kompromisów i maintainerem, który pamięta, dlaczego dziwny warunek z 2019 roku nadal tam jest.

Kod rośnie szybciej niż uwaga

Najbardziej prawdopodobny problem nie polega na tym, że AI zawsze pisze gorszy kod. Problem polega na tym, że potrafi produkować kod szybciej, niż zespół potrafi go oceniać.

Łatwość generowania kodu stwarza ryzyko „długu syntetycznego”. Zespoły bez twardych zasad inżynieryjnych produkują masę niespójnego kodu, który trudno utrzymywać.

CloudBees w raporcie State of Code Abundance 2026 zapytało ponad dwustu liderów technologicznych o gotowość firm na kod generowany przez AI. 92% deklarowało zaufanie do jego gotowości produkcyjnej. Jednocześnie 81% zauważyło wzrost incydentów produkcyjnych powiązanych z takim kodem.

To ankieta dostawcy narzędzi DevOps, oparta na samoocenie liderów. Nie dowodzi, że AI spowodowało każdy z tych incydentów. Pokazuje jednak nieprzyjemną różnicę między pewnością a obserwowanym skutkiem. Organizacje czują się gotowe, ponieważ pipeline jest zielony, zmiana przeszła review i wdrożenie zakończyło się sukcesem. Produkcja ma później własne zdanie.

Większa podaż kodu zwiększa kolejkę do przeglądu. Jeśli liczba osób odpowiedzialnych za review nie rośnie, pozostają trzy możliwości: przeglądy trwają dłużej, stają się płytsze albo blokują dostarczanie zmian. Zwykle firma próbuje po trochu każdego wariantu. Potem nazywa to transformacją procesu.

Odpowiedzialność bez autorstwa

Kiedy kod pisał konkretny programista, odpowiedzialność wydawała się prosta. Autor naprawiał błąd. Firma odpowiadała wobec klienta. W praktyce nigdy nie było to aż tak czyste, bo kod przechodził przez recenzje, zależał od wcześniejszych decyzji i działał w środowisku, którego autor nie kontrolował.

Agenci jeszcze bardziej rozmywają autorstwo. Jeden człowiek pisze specyfikację. Model tworzy zmianę. Drugi model robi review. Programista zatwierdza pull request po przeczytaniu podsumowania, a pipeline wdraża całość. Kto napisał błąd? To pytanie ma coraz mniejsze znaczenie operacyjne.

Znaczenie ma to, kto podjął decyzję o wdrożeniu, kto rozumie ryzyko i kto ma obowiązek zareagować, kiedy system zawiedzie. Model nie odbierze telefonu od klienta. Nie ma dyżuru, odpowiedzialności zawodowej ani własnej reputacji, którą może stracić. Dostawca modelu zwykle nie zna nawet kontekstu konkretnej decyzji.

Nie oznacza to, że człowiek musi ręcznie odtworzyć każdą linię rozumowania agenta. Odpowiedzialność wymaga wystarczających dowodów i jasnego właściciela. Przy drobnej zmianie dowodem może być test oraz szybki review. Przy zmianie modelu uprawnień potrzebny jest ktoś, kto rozumie bezpieczeństwo. Przy migracji danych trzeba wiedzieć, jak wrócić do poprzedniego stanu, zanim zacznie się klikać „deploy”.

Metryki będą złe, zanim staną się użyteczne

Firmy będą próbowały mierzyć AI. Muszą. Bez pomiaru nie wiadomo, czy licencje oraz tokeny dają efekt, czy tylko przesuwają koszt z pisania kodu na jego poprawianie.

Koszt tokenów na funkcję jest łatwy do policzenia i prawie bezużyteczny bez reszty kontekstu. Funkcje nie mają stałego rozmiaru. Jedna zmiana dodaje ikonę, druga przebudowuje model danych. Tani pull request może wygenerować tydzień pracy po wdrożeniu. Droga sesja z mocniejszym modelem może oszczędzić awarii, której nigdy nie zobaczymy w raporcie.

„Procent zaufania” jest jeszcze gorszy, bo udaje pomiar czegoś, czego organizacja nie zdefiniowała. Można za to obserwować skutki: ile zmian wraca do poprawy, jak często wdrożenia powodują awarie, ile błędów wykrywają klienci, jak długo trwa naprawa i jak dużo czasu zespół poświęca na review kodu wygenerowanego przez AI. Te wskaźniki też da się zepsuć. Przynajmniej dotyczą działania systemu, nie liczby tokenów spalonych po drodze.

Najbardziej zdradliwa będzie różnica między produktywnością odczuwaną a mierzoną. Badanie METR pokazało ją bardzo wyraźnie: uczestnicy czuli przyspieszenie, choć wykonanie zadań trwało dłużej. Możliwe, że praca z AI była mniej męcząca. To również ma wartość. Tylko nie należy mylić wygody z przepustowością.

Co zostaje z programisty

Pytanie „czy AI zastąpi programistów?” robi się coraz mniej przydatne. Ukrywa kilka różnych zmian.

Część programistów napisze mniej kodu i będzie pilnować wielu agentów. Część pójdzie głębiej w wydajność, bezpieczeństwo albo architekturę, bo właśnie tam automatyczna odpowiedź nadal wymaga najwięcej oceny. Inni zaczną budować rzeczy poza swoją dawną specjalizacją. Frontendowiec postawi backend. Analityk przygotuje wewnętrzną aplikację. Administrator napisze narzędzie, na które wcześniej nie dostałby budżetu.

To zwiększa możliwości i liczbę błędów. Jednocześnie.

Niepokoi mnie też ścieżka juniorów. Jeśli pierwszą wersję kodu tworzy model, młodszy programista może szybciej dostarczać funkcje. Może również ominąć lata pracy, podczas których człowiek uczył się rozpoznawać zły kod właśnie dlatego, że sam napisał go dużo. Nie ma jeszcze pewnej odpowiedzi, jak zbudować doświadczenie w świecie, w którym najłatwiejsze zadania wykonuje agent. Być może firmy wrócą do świadomie ograniczonych ćwiczeń bez AI. Być może uznają to za koszt, którego nie chcą ponosić, a potem będą się dziwić brakowi seniorów. Ten rachunek przyjdzie później.

Ręczne pisanie kodu nie było celem programowania. Było metodą zamiany wymagań na działający system. AI zmienia metodę. Nie usuwa potrzeby rozumienia wymagań, przewidywania awarii i podejmowania decyzji przy niepełnej informacji.

Dziś nie jestem pewien, czy potrafię pracować bez Claude. Jest też druga część tego zdania: nie jestem pewien, czy potrafię bezpiecznie pracować, kiedy ufam mu za bardzo.

Oba problemy będą rosły równocześnie. Modele będą lepsze. Zespoły oddadzą im więcej pracy. Kontrola zacznie przechodzić z czytania kodu na kontrolę procesu, testów i zachowania systemu po wdrożeniu. Czasem to wystarczy. Czasem brakujący przełącznik otworzy bazę z 1,5 miliona tokenów.

Nie mam tu wygodnego zakończenia. Za dwa lata część tego tekstu może brzmieć naiwnie, bo modele poradzą sobie z problemami, które dziś zajmują seniorom cały dzień. Równie możliwe, że będziemy wtedy utrzymywać ogromną warstwę kodu wygenerowanego w 2026 roku, którego nikt nie chciał napisać i którego nikt nie zdążył zrozumieć. I którego nawet AI nie będzie w stanie utrzymać.

Na razie kod stał się tani. Uwaga nadal jest droga.