Pracuję z AI jak z zespołem. A w każdym zespole każdy ma swoją stawkę.
W tym moim zespole są trzy „etaty”. Najmocniejszy model — ten, który radzi sobie z trudnymi decyzjami architektonicznymi, dłuższym rozumowaniem, analizą bezpieczeństwa — kosztuje najwięcej. Słabszy, ale wciąż solidny — kilka razy tańszy. Najmniejszy, do prostej, mechanicznej roboty — tani do tego stopnia, że ginie w rachunku.
Przez sześć miesięcy używałem najmocniejszego do wszystkiego. Także do zadań, które wymagały tyle samo myślenia, co wybieranie z listy. Dzisiaj patrzę na to i widzę, że nie miałem problemu z modelami. Miałem problem z tym, że zatrudniłem najdroższego specjalistę i kazałem mu robić ksero.
Większość pracy zespołu wcale nie jest myśleniem
Jak zacząłem przyglądać się temu, co właściwie robią moi agenci AI w ciągu dnia, okazało się, że większość z nich w ogóle nie podejmuje decyzji.
Agent-koordynator, który dostaje moje zadanie i rozdziela je dalej — przesuwa pracę między rolami. To planowanie, ale takie typu „kto wchodzi pierwszy, kto drugi” — nie ma tu architektury, tylko routing.
Agent-zwiadowca, który przeszukuje repozytorium i znajduje właściwe pliki —
robi grep i find w bardziej inteligentnej formie. Czyta krótko, decyduje
„to się nadaje, to nie”, podaje wynik dalej.
Agent-skryba, który streszcza tydzień commitów do zapisu w kronice projektu. Tu jest trochę rozumienia kontekstu, ale w gruncie rzeczy robi opis tego, co już się stało — kompresję, nie syntezę.
Agent-recepcjonista, który pyta o brakujące dane wejściowe, zanim w ogóle zaczniemy. Sprawdza checklistę i się upomina, jeśli czegoś brakuje.
Wszystkie cztery to są role typu „przynieś, znajdź, przekaż”. Robią je porządnie i konsekwentnie, ale nie potrzebują do tego głębokiego rozumowania. Najtańszy model radzi sobie z nimi nieodróżnialnie od najdroższego, a kosztuje ułamek — mowa o różnicy rzędu dziewięćdziesięciu kilku procent na tych samych zadaniach.
I jest jeszcze druga część zespołu, która naprawdę myśli: agent projektujący architekturę, agent sprawdzający spójność architektury domain-driven, agent robiący audyt bezpieczeństwa nowego endpointu. Tu nie ma o czym dyskutować — wchodzi najmocniejszy model. Błąd w jego ocenie kosztuje więcej niż jego godzina pracy. Ale to jest mniejszość zespołu, nie większość.
Gdzie się jednak sparzyłem na tanim modelu
Zanim zabrzmi to jak ewangelizacja oszczędzania — przyznam się do tego, co poszło nie tak, kiedy zacząłem optymalizować zbyt agresywnie.
Po pierwsze: dałem tańszemu modelowi zadanie, które wyglądało jak rutyna, a okazało się myśleniem. „Wyszukaj w repo, gdzie używamy biblioteki X, i podsumuj, co wymaga aktualizacji” — brzmi jak praca zwiadowcy. Ale właściwe „podsumowanie” wymagało zrozumienia, po co używamy biblioteki w każdym z miejsc, czy te użycia są spójne, które się duplikują. To była architektura, ubrana w słowa wyszukiwania. Wynik taniego modelu był poprawny powierzchownie i bezużyteczny w praktyce — musiałem wszystko zrobić od nowa.
Po drugie: kazałem najmniejszemu modelowi pisać prozą posty na ten blog, żeby zaoszczędzić. Brzmiało rozsądnie — w końcu to „pisanie”, nie kod. Tylko że dobre pisanie wymaga decyzji o strukturze, rytmie, o tym, co utne, a czego nie utnie. Tani model produkował tekst gramatycznie poprawny i pozbawiony charakteru. Trzeba było przepisywać od zera. Oszczędność wyparowała w stracie czasu na poprawki.
Wniosek nie jest „tani model jest zły”. Wniosek jest taki, że tanie ≠ szybsze ani lepsze, jeśli źle dobierzesz. Tania praca dobrze dobrana jest tanim zyskiem. Tania praca źle dobrana potrafi być droższa niż droga praca dobrze dobrana, bo płacisz dwa razy: raz za marny wynik, drugi raz za poprawianie.
Próg „jedna trzecia” jako alarm
Po tych pomyłkach ustawiłem sobie konkretny cel proporcji — taki, do którego sprawdzam zespół raz na jakiś czas.
Najdroższy model ma odpowiadać za mniej niż jedną trzecią pracy zespołu. Średni — za jakąś połowę. Najtańszy — za pozostałe kilkanaście procent.
Te proporcje to nie są dogmat. To jest alarm. Jeśli najdroższy przekracza trzydzieści procent, wracam i pytam każdą rolę: co tu robisz, że potrzebujesz najmądrzejszego w pokoju? Czasem odpowiedź brzmi „nic, da się zejść niżej” — i schodzę. Czasem brzmi „cała ta robota to projektowanie kontraktu między kontekstami” — i zostaje, gdzie był.
I odwrotnie: jeśli najtańszy przekracza dwadzieścia procent zadań, sprawdzam, czy gdzieś nie dałem mu pracy, którą powinien dostać średni — czyli czy wynik trzymał jakość, czy tylko wyglądał na trzymający.
Co to mówi o projektowaniu samej pracy
Najciekawsze nie była oszczędność. Najciekawsze było to, że samo pytanie „czy to zadanie naprawdę wymaga najmądrzejszego?” zmieniło sposób, w jaki projektuję pracę zespołu.
Zacząłem mocniej rozkładać duże zadania na proste kroki. Coś, co kiedyś puszczałem jako jeden duży prompt do najdroższego modelu — „zaprojektuj i zbuduj X” — okazało się, że da się rozłożyć na pięć mniejszych: dwa „znajdź i podaj” (tanio), jeden „zaprojektuj kontrakt” (drogo), dwa „napisz i sprawdź” (średnio). Suma kosztów była dwa, trzy razy niższa niż jeden monolitowy strzał, a jakość — wyższa, bo każdy krok robił to, w czym jest dobry, a nie udawał uniwersalnego.
Mniej więcej w tym samym czasie ktoś gdzieś napisał, że dobre prompty projektuje się jak dobre interfejsy: jasne, wąskie, jednorzeczowe. Tak samo jest z dobrym rozkładem zadań w zespole AI. Wąsko, jednorzeczowo, do roli odpowiedniej dla zadania.
Dla jednoosobowej firmy to nie kosmetyka. Każda złotówka, której nie spalę na źle dobranym modelu, przedłuża pas startowy — a pas startowy to po prostu więcej tygodni, w których mogę pracować, zanim skończą się pieniądze. I to jest być może najbardziej prozaiczne wyjaśnienie tego, czemu się tym w ogóle zajmuję: nie jakiś ideał inżynierski. Po prostu chcę dotrwać z budżetem do momentu, gdy pierwsi ludzie naprawdę zaczną używać tego, co robię — i już niczego nie da się robić od nowa.