Roczne rachunki za tokeny AI zaczynają dorównywać wypłatom inżynierów w niektórych firmach, a kierownictwo nie wie, czy ma świętować, czy wpadać w panikę. Przedsiębiorstwa poświęciły ostatnie lata na pompowanie kapitału w duże modele językowe, spodziewając się, że tańszy proces wnioskowania (inference) automatycznie przełoży się na mniejszą liczbę etatów i szybsze cykle dostarczania oprogramowania. Zamiast tego wiele organizacji inżynieryjnych płaci podwójnie: raz za talenty, które miały zostać wzmocnione, a drugi raz za moc obliczeniową, która miała ich zastąpić. Pytanie nie brzmi już, czy AI potrafi pisać kod. Pytanie brzmi, czy kod, który pisze, uzasadnia fortunę wydawaną na jego wyprodukowanie.

Benchmark połowy pensji

Jensen Huang przedstawił te obliczenia wprost na zakończenie GTC 2026, występując w podcaście All-In. CEO Nvidii zaproponował mierzenie wydajności inżyniera poprzez bezpośrednie porównanie jego wynagrodzenia do zużycia tokenów AI. Jego próg był surowy. Weźmy inżyniera oprogramowania zarabiającego 500 000 USD rocznie. Jeśli ten inżynier zużywa mniej niż 250 000 USD w tokenach rocznie – czyli mniej więcej połowę swojej pensji – Huang uznaje to za sygnał ostrzegawczy. Kierownictwo powinno być „głęboko zaniepokojone”, według jego słów, nie dlatego, że firma wydaje zbyt dużo na ludzi, ale dlatego, że prawdopodobnie nie wykorzystuje ich w pełni.

Ta logika odwraca tradycyjne podejście do kontroli kosztów. Przez lata zespoły finansowe traktowały moc obliczeniową jako koszt zmienny, który należy minimalizować. Huang twierdzi coś przeciwnego. Drogi inżynier, który prawie nie korzysta z modelu, to drogi inżynier pracujący bez mnożnika siły (force multiplier). Oczekuje się, że wysoko opłacany talent powinien działać jak lejek, przepychając ogromne ilości pracy przez systemy AI, weryfikując wyniki i koordynując rezultaty. Niski wydatek na tokeny nie jest sygnałem oszczędności. Jest sygnałem, że człowiek wciąż wykonuje mechaniczną pracę, którą mógłby wykonać model.

Jak te wydatki wyglądają w praktyce

Aby zrozumieć, dlaczego ten benchmark jest istotny, rozważmy, co faktycznie reprezentuje 250 000 USD w tokenach. Przy obecnych stawkach za modele typu frontier, nie są to tylko kilka sugestii autouzupełniania. To miliony tokenów przetwarzanych każdego dnia roboczego w szerokim zakresie zadań. Sugeruje to inżyniera, który nie tylko akceptuje propozycje edytorskie, ale prowadzi rozległe rozumowanie architektoniczne, masową refaktoryzację za pomocą inteligentnych agentów, automatyczne potoki testowe, generowanie syntetycznych danych i iteracyjne eksplorowanie projektów.

Starszy inżynier pracujący w ten sposób może łączyć wiele wywołań modelu dla pojedynczej funkcji: generowanie szkieletu kodu (scaffolding), analizowanie zależności pod kątem zmian naruszających kompatybilność (breaking changes), symulowanie zachowań w przypadkach brzegowych (edge cases) i równoległe tworzenie dokumentacji. Przepustowość jest ogromna, ponieważ człowiek nie wpisuje już każdej linii. On steruje. Dla Huanga wynagrodzenie uzasadnia się tylko wtedy, gdy człowiek operuje na takiej skali, mnożąc swoją wydajność poprzez nieustanną interakcję z modelem.

Gdzie giną zwroty z inwestycji

Mimo tej wizji, branża mierzy się z pogłębiającą się luką między wydatkami na infrastrukturę a dostarczanymi rezultatami. Firmy rzuciły się na strategie oparte na dużej liczbie tokenów, zawierając kontrakty korporacyjne z dostawcami AI i dostosowując swoje potoki deweloperskie do narzędzi generatywnych. Wydatki kapitałowe były oszałamiające. Zwroty z produktywności dla wielu okazały się rozczarowujące.

Deweloperzy rzeczywiście szybciej radzą sobie z nudnymi rzeczami. Kod boilerplate, szkielety testów jednostkowych i powtarzalne operacje CRUD idą błyskawicznie, gdy model generuje pierwszy szkic. Ale inżynieria oprogramowania nigdy tak naprawdę nie polegała na szybkości pisania. Trudna i kosztowna praca polega na utrzymywaniu rozległych systemów, rozumowaniu w kontekście rozproszonych trybów awarii, zapewnianiu bezpieczeństwa w warstwowych zależnościach i zarządzaniu długiem technicznym, który narasta przy każdym skrócie. Te