Andrej Karpathy: Są dwa rodzaje programistów — ci, którzy kodują z AI, i ci, którzy zostają w tyle

Andrej Karpathy wie, o czym mówi. Były dyrektor AI w Tesli, wczesny badacz OpenAI, twórca legendarnego kursu wizji komputerowej Stanfordu — pisze kod i wdraża produkcyjne systemy AI od ponad dekady. Kiedy mówi, że jego workflow deweloperski właśnie przeszedł największą transformację od 20 lat, warto zwrócić uwagę.

Jego kluczowy argument: narzędzia takie jak Deep Code nie są tylko ozdobnym autouzupełnianiem. Są mnożnikiem dźwigni. W tym samym czasie, który wcześniej poświęcałeś, możesz dostarczyć dziesięć razy więcej. Co ważniejsze, możesz podjąć projekty, które wcześniej wydawały się zupełnie poza zasięgiem. AI wciąż popełnia błędy — nadmiernie komplikuje, popełnia złe założenia i nie sprzeciwia się, gdy powinno — ale zysk netto jest niezaprzeczalny. Im szybciej się przystosujesz, tym większą przewagę zyskasz.

Przez ostatnie kilka tygodni dużo kodowałem z Claude Code. Oto, czego się nauczyłem.

Workflow kodowania

Najnowsza fala ulepszeń LLM-ów w kodowaniu wywróciła mój workflow do góry nogami. W listopadzie byłem mniej więcej na 80% ręcznego pisania z autouzupełnianiem IDE i 20% agenta. W grudniu było odwrotnie: 80% kodu napisanego przez agenta i 20% mojego sprzątania.

Teraz głównie po prostu mówię kodowi, żeby powstał. Opisuję w zwykłym angielskim, czego chcę, i patrzę, jak się materializuje. Szczerze mówiąc, to trochę rani programistyczną dumę. Ale zdolność operowania na całym projekcie naraz — refaktoryzacja, budowanie szkieletu, łączenie elementów — jest zbyt dobra, by z niej zrezygnować. Zwłaszcza gdy poznasz rytm: dostrojenie konfiguracji, wyczucie, co trafia celnie, a co chybiło.

To największa zmiana w moim workflow deweloperskim w ciągu około 20 lat pisania kodu. I wydarzyła się w ciągu kilku tygodni. Przypuszczam, że znaczna część inżynierów (dwucyfrowe procenty) już przechodzi to samo. Ogół społeczeństwa? Może niskie jednocyfrowe procenty mają pojęcie, że to się dzieje.

IDE / Roje agentów / Nieuchronność błędów

Krążą dwie narracje: „IDE są martwe" i „roje autonomicznych agentów zajmą się wszystkim". Obie są dziś przesadzone.

Modele wciąż popełniają błędy. Jeśli naprawdę zależy ci na projekcie, miej oko na sprawy. Trzymam pełne IDE otwarte w bocznym oknie i obserwuję jak sokół.

Błędy są jednak teraz inne. Nie chodzi o błędy składniowe. Są bardziej podstępne — błędy koncepcyjne, jakie popełniłby spieszący się junior developer. Model cicho wypełnia założenia za ciebie, myli się, nigdy nie weryfikuje i buduje na tym błędnym założeniu aż do końca.

Nie zarządza też dobrze własną niepewnością. Nie zatrzyma się i nie zapyta: „hej, czy chcesz tu A czy B?" Nie wskaże niespójności. Rzadko się sprzeciwia. Jest trochę zbyt chętny do przypodobania się. Kazanie mu najpierw napisać plan, a potem go realizować, bardzo pomaga. Szczerze uważam, że istnieje realna potrzeba lekkiego, wbudowanego trybu planowania.

Uwielbia też nadmiernie komplikować. Warstwy abstrakcji naokoło. Kod, który wydaje się rozdęty. I prawie nigdy nie sprząta martwego kodu, który sam tworzy.

Widziałem, jak wyrzuca rozległą implementację na tysiąc linii — wolną, kruchą, pełną zbędnych objazdów. Wtedy pytam: „Czy nie moglibyśmy tego zrobić prościej?" i natychmiast odpowiada: „O, oczywiście!" i skraca wszystko do stu linii.

Czasem usuwa lub przepisuje komentarze i kod, które nie miały nic wspólnego z zadaniem, po prostu dlatego, że ich nie zrozumiał albo mu się nie podobały. Dosłownie dodałem notatki w moim CLAUDE.md, mówiąc mu, żeby tego nie robił, i wciąż się to zdarza. Ale mimo wszystko, zysk netto jest ogromny. Naprawdę nie mogę sobie wyobrazić powrotu.

Każdy znajduje swój własny styl. Mój: kilka sesji Claude Code w Ghostty po lewej, IDE po prawej do czytania kodu i chirurgicznych edycji.

Wytrwałość

Obserwowanie, jak agent zmaga się z problemem, jest naprawdę fascynujące. Nie męczy się. Nie traci zapału. Człowiek powiedziałby „do diabła, spróbuję jutro" godzinę temu. On po prostu... ciągnie dalej.

Czasem obserwujesz, jak walczy przez coś, co wydaje się wiecznością. Potem, 30 minut później, w końcu łamie problem. W tym momencie masz to prawdziwe uczucie „wow, to ma posmak AGI."

Uświadamiasz sobie: wytrzymałość psychiczna i fizyczna jest kluczowym wąskim gardłem w realizacji pracy. LLM-y właśnie zdmuchnęły ten sufit.

Przyspieszenie

Trudno podać liczbę, o ile szybciej LLM-y cię czynią. Na pewno jestem szybszy w rzeczach, które już robiłem. Ale większą zmianą jest to, że teraz podejmuję rzeczy, których wcześniej bym się nie odważył.

Dwa powody:

1. Masa małych zadań, które wcześniej wydawały się „nie warte wysiłku", jest teraz trywialnie łatwa.
2. Projekty, których bym unikał — bo brakowało mi wiedzy lub umiejętności — nagle wydają się osiągalne.

Tak, to przyspieszenie. Ale coś więcej — to ekspansja. Zakres rzeczy, które jestem w stanie zrobić, się powiększył.

Dźwignia

Oto jedna z najpotężniejszych rzeczy w LLM-ach: naprawdę dobrze iterują w pętli, dopóki nie osiągną zdefiniowanego celu. Wiele z tych momentów „o posmaku AGI" wynika dokładnie z tego.

Klucz: nie mikrozarządzaj. Powiedz mu, jak wygląda sukces, i pozwól znaleźć drogę.

Możesz kazać mu najpierw napisać testy, a potem zmusić do ich przejścia. Podłącz go do przeglądarki przez MFC i niech iteruje. Napisz prosty, oczywisty algorytm i powiedz: „teraz zoptymalizuj wydajność, zachowując dokładnie te same wyniki."

Przesunięcie mentalne jest z trybu imperatywnego na deklaratwny. Zamiast „zrób A, potem B, potem C" mówisz: „tak wygląda oczekiwany wynik." Agent sam iteruje przez kilka rund, a ty zyskujesz dodatkową warstwę dźwigni za darmo.

Zabawa

Nie spodziewałem się tego, ale kodowanie stało się faktycznie bardziej zabawne. Cała żmudna, mechaniczna praca jest absorbowana przez agenta. Zostają te twórcze części.

Rzadziej też utykam. Utknięcie jest dołujące. Teraz prawie zawsze istnieje droga, by „współpracować z nim i przynajmniej poczynić pewne postępy", co ułatwia po prostu zaczęcie.

Z drugiej strony, spotkałem ludzi, którzy czują odwrotnie — kodowanie z LLM-ami czyni ich mniej szczęśliwymi.

W dłuższej perspektywie uważam, że to podzieli inżynierów na dwa obozy: ludzi, którzy kochają sam akt pisania kodu, i ludzi, którzy kochają budowanie rzeczy.

Zanik

Już to czuję: moja zdolność do pisania kodu od zera powoli zanika. W mózgu „generowanie" (pisanie kodu) i „dyskryminacja" (czytanie i przeglądanie kodu) to dwie odrębne umiejętności. Pisanie kodu wymaga zapamiętania ton drobnej składni. Czytanie kodu to rozumienie logiki i struktury. Więc nawet gdy twoje mięśnie generowania słabną, wciąż możesz skutecznie przeglądać kod — dostrzegać, co wygląda nie tak, znajdować błędy.

Słupocalypse

Przygotowuję się: 2026 może być rokiem wielkiej eksplozji treściowej papki.

GitHub, Substack, arXiv, YouTube, Reddit — każda cyfrowa platforma treściowa zostanie zalana materiałem generowanym przez AI. Zobaczymy falę teatru produktywności napędzanego AI, efektownych demo, które wyglądają niesamowicie, ale nie wytrzymują próby czasu. Wśród nich będą też prawdziwe, wymierne zyski produktywności. Ale trzeba będzie ich szukać.

Pytania

Jak wygląda programista 10x w przyszłości? Czy przepaść między przeciętnymi a najlepszymi inżynierami się jeszcze pogłębi? Moja zgadywanka: znacznie się pogłębi.

Czy generaliści zaczną przewyższać specjalistów? LLM-y są wyjątkowo dobre w uzupełnianiu szczegółów (mikro), ale słabsze w myśleniu strategicznym i długoterminowej strategii (makro). Ta tendencja sprzyja ludziom, którzy widzą całą planszę.

Jak będzie wyglądać kodowanie z LLM-ami za pięć lat? StarCraft? Factorio? Wykonanie utworu muzycznego?

Ile społeczeństwa jest faktycznie ograniczone przez cyfrową pracę wiedzy?

Podsumowanie: gdzie nas to stawia?

Możliwości agentów LLM — w szczególności Claude Code — przekroczyły próg ogólnej spójności w okolicach grudnia 2025. To wywołało fazową transformację w inżynierii oprogramowania. Sposób, w jaki rzeczy się realizują, zmienił się o rząd wielkości, praktycznie z dnia na dzień.

Teraz wydaje się, że inteligencja wyprzedziła wszystko wokół. Integracja narzędzi nie nadąża. Zespoły potrzebują nowych workflowów i wzorców współpracy. Branża wciąż trawi to, co się właśnie wydarzyło.

2026 będzie intensywny. Wszyscy ścigają się, by zaabsorbować i upowszechnić tę nową zdolność. Okno jest teraz otwarte. Ludzie, którzy rozgryzą to wcześnie, będą mieli ogromną przewagę.