Tokenowi milionerzy

Jednym z łatwych do popełnienia błędów przy wdrażaniu AI jest danie programistom nieograniczonego dostępu do najlepszych modeli już pierwszego dnia. Taki komfort szybko staje się normą. Nikt nie musi sprawdzać, czy do prostego zadania potrzebny jest najmocniejszy model, czy prompt nie obejmuje zbyt dużej części systemu i czy kolejna iteracja rzeczywiście przybliża do rozwiązania.

Nie zakładam złej woli po stronie programistów. Reguły kształtują zachowanie. Gdy koszt kolejnych prób jest niewidoczny, łatwo traktować je jak darmowe. Wtedy model dostaje duże zadanie, szeroki kontekst i swobodę podejmowania dziesiątek decyzji. Człowiek sprawdza wynik, poprawia prompt, prosi o kolejną wersję, a potem naprawia skutki wcześniejszych poprawek. Wygenerowany kod powstaje szybko. Ocena, czy nadaje się do utrzymania, już niekoniecznie.

Budżet zmienia pytanie

U mnie punktem wyjścia było GitHub Copilot Enterprise za 39 dolarów miesięcznie za użytkownika oraz lokalny Qwen, który działał wyraźnie wolniej. Warto doprecyzować liczby: według aktualnej dokumentacji GitHuba Enterprise obejmuje miesięczną pulę 3 900 kredytów AI na użytkownika, współdzieloną w organizacji. Kredyty nie są tym samym co tokeny, a sposób rozliczania i ceny mogą się zmienić. Chodzi mi o konkretny model pracy z określonym limitem, nie o uniwersalną rekomendację zakupową.

Limit szybko zmienia pierwsze pytanie. Zamiast od razu wrzucać do modelu polecenie: „Przerób cały feature, zmień API, popraw frontend i dopisz testy”, warto ustalić, co dokładnie ma się zmienić i jak sprawdzimy rezultat. Przy dużym zadaniu model musi sam przyjąć wiele założeń. Im więcej ich przyjmie, tym więcej rzeczy człowiek musi później zweryfikować.

Rozsądniej najpierw opisać problem, kontrakt i zależności. Potem podzielić pracę na kawałki: osobno zmiana API, osobno walidacja, osobno komponent i testy. Każdy wynik da się wtedy sprawdzić, zanim pójdziemy dalej. Model może pomóc ułożyć plan, ale decyzja o kolejności i zakresie zostaje po stronie programisty.

Nie warto też rozbijać każdej czynności na najmniejsze możliwe kroki. Przy zadaniu, które wymaga analizy wielu modułów naraz, szeroki kontekst może być potrzebny. Człowiek powinien wiedzieć, dlaczego go przekazuje i czego oczekuje od odpowiedzi. Nie deleguje całego problemu tylko dlatego, że może.

Właściwy model do właściwej pracy

Każda zmiana nie wymaga najmocniejszego modelu. Prosta transformacja danych, szkic testu czy porządkowanie dokumentacji mogą pójść do tańszego narzędzia albo lokalnego modelu. Trudna diagnoza błędu, analiza kilku możliwych rozwiązań czy decyzja architektoniczna mogą uzasadniać droższy model. Czasem szybszy model kosztuje mniej w rozliczeniu, ale więcej w czasie poprawek. Trzeba liczyć jedno i drugie.

Z czasem zespół lepiej formułuje pracę. Przed uruchomieniem modelu częściej padają pytania: co wiemy, czego nie wiemy, jaki fragment systemu jest istotny i po czym poznamy, że wynik jest dobry? To są pytania inżynierskie. AI sprawia, że zaniedbanie ich szybciej produkuje więcej kodu.

Właścicielem rozwiązania nadal pozostaje programista. Model może napisać funkcję, ale nie ponosi kosztu awarii, błędnej migracji ani kolejnego roku utrzymywania nietrafionej abstrakcji. Dlatego sprawdzenie kodu nie może sprowadzać się do pytania, czy się kompiluje. Trzeba ocenić założenia, zachowanie na granicznych przypadkach i zgodność z systemem, w którym ta zmiana ma żyć.

Oszczędność też ma koszt

Ograniczenia potrafią nauczyć dyscypliny, ale nie robią tego automatycznie. Zbyt mały budżet może zniechęcić do eksperymentów, skłonić ludzi do omijania narzędzi albo sprawić, że złożone zadania będą trafiały do zbyt słabego modelu. Wtedy organizacja oszczędza na rachunku, a płaci czasem pracowników i poprawkami.

Dlatego nie mierzyłbym dojrzałości samym zużyciem tokenów czy kredytów. Niskie zużycie może oznaczać dobrą selekcję zadań. Może też oznaczać, że narzędzie stoi nieużywane albo ludzie boją się przekroczyć arbitralny limit. Z kolei wysokie zużycie bywa uzasadnione, jeśli skraca trudną analizę i zmniejsza ryzyko kosztownej pomyłki.

Lepiej zacząć od widocznego, sensownego budżetu, wyboru kilku modeli i obserwacji konkretnych zadań. Porównać czas pracy razem z weryfikacją i poprawkami. Zobaczyć, gdzie model rzeczywiście pomaga, a gdzie tylko zwiększa liczbę propozycji do oceny. W ten sposób rozmawiamy o alokacji zasobów i jakości decyzji, a nie o tym, kto zużył najwięcej kredytów.

W moim zespole z czasem coraz rzadziej słyszę pytanie o większy limit tokenów. Rzadziej też pada automatyczna propozycja, żeby na każdy problem odpowiedzieć kolejnym etatem. Nie wyciągam z tego wniosku, że wszystkie problemy wydajności zniknęły. Zmienił się pierwszy odruch: zanim poprosimy o więcej, sprawdzamy, czy dobrze wykorzystujemy obecne zasoby.

Nieograniczony dostęp może mieć sens, kiedy organizacja wie, co mierzy i jak kontroluje koszt. Na starcie łatwiej jednak zobaczyć błędy, gdy budżet jest ograniczony, jawny i wystarczający do nauki. Liczy się wiedza, kiedy mocniejszy model jest wart ceny, a kiedy lepsze zadanie i węższy kontekst załatwią sprawę.

Milion tokenów na koncie niewiele znaczy, jeśli nikt nie umie powiedzieć, jaki wynik za nie kupił.