Inżynieria ograniczania: dlaczego koszty agentów AI gwałtownie rosną

Przez dwa lata nagłówki mówiły to samo: inżynierowie są drodzy, agenci AI tanie, a pracownik cyfrowy, który nigdy nie śpi ani nie narzeka za ułamek pensji, sprawiłby, że zastąpienie go stałoby się nieuniknione. Ostatnio, na spotkaniach planistycznych niektórych bardzo nowoczesnych firm, arkusze kalkulacyjne zaczęły podważać tę narrację.

Dwie firmy, dwa sygnały ostrzegawcze

Microsoft udostępnił Claude Code swoim wewnętrznym zespołom inżynieryjnym pod koniec 2025 roku. Głęboko wtopił się on w codzienne procesy pracy i programiści go polubili. Do połowy 2026 roku firma zaczęła wycofywać te licencje, skierowując ludzi ku tańszym rozwiązaniom wewnętrznym, takim jak GitHub Copilot CLI.

Sytuacja Ubera była jeszcze bardziej skomplikowana. W kwietniu 2026 roku ich dyrektor techniczny przyznał, że cały budżet na narzędzia do programowania oparte na sztucznej inteligencji na rok 2026 został wykorzystany już po zaledwie czterech miesiącach. Narzędzie to zostało przyjęte przez 84% inżynierów, jego używanie przekształciło się w rodzaj konkursu pomiędzy pracownikami całej firmy, a jeden z kierowników technicznych wydał 1200 dolarów na tokeny podczas pojedynczej dwugodzinnej demonstracji.

Sztuczna inteligencja nigdy nie przestała działać – po prostu stała się nieznośnie droga w utrzymaniu. Dla wszystkich, którzy tworzą systemy oparte na agentach, ta sytuacja pokazuje łatwo osiągalny limit: koszty obliczeniowe autonomicznego pracownika cyfrowego mogą przewyższyć pensję osoby, którą miał zastąpić.

Rozwiązaniem jest dyscyplina, która wkrótce stanie się obowiązkowa – nazywa się ona inżynierią kontroli.

Dlaczego agenci kosztują o wiele więcej niż czaty

Wskazówka do czatu i autonomiczny agent to zupełnie różne rzeczy. Gdy zadajesz pytanie standardowemu modelowi językowemu, proces kończy się po jednym kroku: zadajesz pytanie, on odpowiada, transakcja jest zakończona.

Agent natomiast ma cel otwarty. Gdy ma za zadanie naprawić błąd, czyta pliki, opracowuje plan, pisze poprawki, uruchamia testy i ocenia własne wyniki. Nieudany test restartuje cykl, więc agent ponownie przemyśla sprawę, przepisze kod i spróbuje ponownie. Każdy krok jest opłacany oddzielnie.

Prawdziwa praca nad oprogramowaniem stanowi poważne ryzyko finansowe w tym kontekście. SWE-bench to standardowy test branżowy składający się z błędów z rzeczywistego kodu produkcyjnego, a najlepsze dostępne obecnie agenty rozwiązują mniej niż połowę jego zadań. Dlatego w przypadku ponad połowy błędów agent próbuje, ponosi porażkę, próbuje ponownie, ponownie ponosi porażkę i w końcu rezygnuje.

Wyobraź sobie hydraulika, który pobiera pełną stawkę godzinową za każdym razem, gdy upuści klucz, nalicza opłatę za każdy krok do furgonetki i odchodzi, gdy rura wciąż kapa. Na poziomie przedsiębiorstwa takim hydraulikiem jest nieudana zadanie agenta – za upuszczony klucz płaci się w pełnej wysokości.

Spójlność tokenów nie podwaja się tylko w przypadku okna czatu. Średnio agent zużywa od 5 do 30 razy więcej, a agent, który wymyka się spod kontroli w trudnym scenariuszu debugowania, może generować koszty ponad 1000 razy wyższe niż przy zwykłym zapytaniu.

Dwie krzywe kosztów, które się rozchodzą

Gospodarka ludzka i gospodarka AI podążają różnymi krzywymi. W miarę doskonalenia się juniorowego programisty jakość jego pracy rośnie, podczas gdy pensja pozostaje mniej więcej stała. Po prostu staje się szybszy i bardziej wydajny.

Agent stojący przed trudnym problemem potrzebuje znacznie więcej kroków rozumowania, prób ponownych oraz wykorzystania okna kontekstowego, przez co koszt tokenów gwałtownie rośnie. Im trudniejszy problem, tym wyższy koszt.

Ulepszenia sprzętowe nie ratują sytuacji, ponieważ popyt na oprogramowanie przewyższa oszczędności. Procesory Maia 200 firmy Microsoft, obecnie używane w jej centrach danych, zapewniają wyraźnie więcej tokenów za dolar niż starszy sprzęt. Mimo to obciążenia agentów pochłaniają wszystkie te oszczędności jednocześnie. Tańsze tokeny oznaczają po prostu, że agenci proszą o ich znacznie większą ilość.

Dlatego pomysł wypuszczenia agenta na całą bazę kodową przedsiębiorstwa i pozostawienia go samemu jest już przestarzały, ponieważ matematyka tego nie wytrzymuje. Agenty jednak nie są bezużyteczne. Architektura wokół nich musi ulec zmianie, i to szybko.

Inżynieria kontroli

Dla wszystkich, którzy tworzą aplikacje AI, inżynieria promptów nie jest już jedynym zadaniem. Rzeczywistym zadaniem jest inżynieria kontroli: tworzenie twardych granic, ograniczeń stanu oraz mechanizmów bezpieczeństwa finansowego wokół modeli, aby maszyna mogła udowodnić swoją wartość, zanim powstanie wysoka rachunek.

Obawy są konkretnie określone. Wyobraźmy sobie system zarządzania zapasami w Next.js 16, z użyciem TypeScript i Azure OpenAI. Opóźnienia i halucynacje nie mają tam większego znaczenia w porównaniu z lękiem przed autonomicznym agentem uwięzionym w pętli rozumowania, który w ciągu nocy wyczerpie kredyty chmurowe. Podobne obawy dotyczą również zadań przetwarzania danych genetycznych na platformie Modal, które analizują tysiące sekwencji referencyjnych ClinVar i osiągają twardy limit czasu wykonywania dokładnie po dwóch godzinach. To była zwykła obsługa obliczeniowa naliczana za sekundę. Recurencyjny agent naliczany za token w tej samej sytuacji spowodowałby ogromne koszty.

Cztery praktyki sprawiają, że kontrola staje się możliwa do zastosowania.

1. Kierowanie zapytaniami według trudności

Najczęstszym błędem jest kierowanie każdego wywołania API do najnowocześniejszych modeli, takich jak GPT-5 czy Claude 4.5 Opus. To metoda siły brute, która szybko wyczerpuje zasoby. Zamiast tego warstwa kierowania powinna znajdować się na samym początku struktury. Router to lekki, niezwykle tani model, który analizuje każde przychodzące zapytanie i decyduje, który model LLM jest w stanie je obsłużyć.

[ Incoming User Request ]
           |
      [ Router ]
      /        \
[ Simple ]  [ Complex ]
      |          |
[ Llama 3 ] [ Flagship LLM ]

Prosta ekstrakcja danych lub podstawowe formatowanie można przeprowadzić za pomocą modelu open-source o pojemności 8B lub dostosowanego mini-modelu. Zadania wymagające złożonej logiki wymagają droższego modelu flagowego. Ta jedna zmiana może obniżyć koszty API o aż 80%, bez widocznego spadku jakości aplikacji.

2. Nigdy nie zezwalaj na nieskończony cykl prób

Agent, który może pisać kod, go testować i próbować ponownie w przypadku niepowodzenia, potrzebuje sztywno ustalonego limitu prób. Zwykły liczebnik nie wystarczy, ponieważ kontekst zmienia się z każdą próbą. Trzecia próba jest znacznie droższa od pierwszej, gdyż prompt zawiera już informacje o dwóch wcześniejszych niepowodzeniach.

Należy dodać mechanizm kontrolny budżetu. Zanim agent rozpocznie kolejny krok rekurencyjny, funkcja middleware ocenia koszt tokena dla przychodzącej żądania. Jeśli łączna kwota z sesji przekroczy ustalony limit, proces jest natychmiast zatrzymywany i oznaczany do sprawdzenia przez ludzkiego programistę.

3. Ograniczanie kontekstu

Po nieudanej próbie agent zazwyczaj dołącza surowy dziennik błędów do swojego wcześniejszego zapytania i próbuje ponownie. Stąd pochodzi wykres eksponencjalnego wzrostu kosztów. Ograniczanie kontekstu temu przeciwdziała. Zamiast przekazywać całą rozbudowaną historię błędów do głównego modelu, tańszy model routera skraca opis stanu błędu.

Dziennik błędów przekazuje się taniemu modelowi za pomocą instrukcji typu „Wyciągnij dokładną techniczną przyczynę tego błędu w dwóch krótkich zdaniach”. Tylko te dwa zdania trafiają z powrotem do głównego agenta w celu kolejnej próby. Okno kontekstowe jest celowo ograniczane, dzięki czemu liczba tokenów rośnie liniowo, a nie eksponencjalnie.

4. Zachowanie człowieka jako mechanizmu awaryjnego wyłączenia

Długo uważano, że obecność człowieka w procesie jest jedynie tymczasowym środkiem bezpieczeństwa. Obecnie jest to ścisły wymóg finansowy. Rolą programisty stało się obserwowanie agenta i natychmiastowe interwencje, gdy ten popada w kosztowny stan awarii: sprawdzanie wyników, potwierdzanie kierunku działań technicznych oraz zatrzymywanie wymykającego się spod kontroli procesu, zanim doprowadzi on do bankructwa budżetu sprintu.

Co oznacza ta zmiana

Duolingo niedawno złagodziło swoją publiczną postawę wobec zastępowania pracowników przez sztuczną inteligencję. Podobnie jak Microsoft i Uber, musiało uznać prosty fakt: ludzie to najtańsze dostępne „silniki myślenia”. Elastyczny umysł programisty funkcjonuje dzięki kanapce i porządnej nocy snu, a nigdy nie nalicza firmie tysięcy kosztów tylko po to, by się zatrzymać i pomyśleć.

Bużdżan nieskończonych, tanich agentów został przebity zwykłą tabelą kalkulacyjną. Dla programistów, którzy dopiero wchodzą na ten rynek, jest to pocieszające, ponieważ role pozostają bezpieczne mimo zmian codziennych obowiązków. Praca przechodzi od ręcznego pisania każdej linijki do projektowania i zarządzania systemami, które je tworzą.

Praktyczna rada jest krótka: wstawiajcie ścisłe mechanizmy kontrolne do struktur AI, stosujcie rygorystyczne zasady ograniczania działania agentów oraz traktujcie budżet tokenów z takim samym szacunkiem jak pamięć komputera. Przyszłość inżynierii oprogramowania należy do tych, którzy potrafią kontrolować maszyny, ograniczać ich koszty i wyłączać je, gdy przestają funkcjonować prawidłowo.

Literatura pokrewna

• Lokalny agent AI z Ollamą: wąskie narzędzia, weryfikacja oraz ograniczenia liczby kroków — Odbudowa agenta do śledzenia faktur przy użyciu Ollamy i Pythona: listy dozwolonych narzędzi, ograniczone pętle, wyjścia w formacie Pydantic, wyraźny stan, zasady bezpieczeństwa oraz zestaw testów przypadków awarii.
• Dlaczego agenty programistyczne wciąż mają problemy z kodem prywatnych firm — Testy Real-SWE obejmują osiem agentów programistycznych na licencjonowanych bazach kodu prywatnych. Najlepszy z nich rozwiązuje 38,8 procent zadań, a pięć kategorii niepowodzeń pokazuje, gdzie agenty popełniają błędy.