Model decyduje o czasie, spec o jakości: jak dobierać effort w Claude Code

TL;DR: Kiedy agent zrobi coś źle, odruch podpowiada: większy model albo wyższy poziom rozumowania (effort). Po miesiącach codziennej pracy z agentami działam według zasady niemal odwrotnej: przy dobrze wyspecyfikowanej pracy model to dźwignia czasu odpowiedzi, a nie jakości. Jakość niesie specyfikacja. Ciężkie myślenie, wykonane raz w planie, szybsze ustawienie przepisuje na kod bez większej straty. Większość błędów, które ludzie próbują naprawić, podkręcając effort, bierze się z za dużych kawałków pracy, dziur w specu albo z tego, że model nie zna konwencji w kodzie. Żadnej z tych przyczyn więcej effortu nie usunie. Tak decyduję, na co i gdzie wydać zasoby.

Prawda, na której wisi cała reszta

Przy zadaniu, które jest naprawdę dobrze wyspecyfikowane, przejście z szybszego ustawienia na najwolniejsze i najdroższe kupuje głównie czas odpowiedzi, a nie poprawność. Rozumowanie, od którego zależy, czy wynik jest dobry, już się odbyło w planie. Jeśli plan jest szczelny, a konwencje spisane, szybsze ustawienie bez problemu przepisze go na działający kod. Błędy, które się jednak pojawiają, prowadzą do czegoś, co plan zostawił niejednoznaczne, do kawałka zbyt dużego, żeby go ogarnąć, albo do konwencji, o której modelowi nikt nie powiedział. Podkręcenie pokrętła effortu brakującego speca nie dopisze.

To ważne, bo odwraca domyślną reakcję. Kiedy wynik jest zły, produktywny ruch to zwykle doprecyzowanie speca albo zmniejszenie kawałka, a nie sięgnięcie po mocniejszy model. Eskalacja jest na konkretny, węższy przypadek.

Dwa koszyki

Przy każdym zadaniu przełączam się w głowie jednym pytaniem: czy to wymaga myślenia, czy przepisania planu na kod?

Myślenie idzie na górę skali, przepisywanie na jej szybką część. Cała praktyczna reguła to właśnie to pytanie, zadane uczciwie, zanim zacznie się praca.

Dziel także wewnątrz złożonej funkcji

Błędem jest traktowanie implementacji trudnej funkcji jak jednego, jednolitego bloku. To nie jest jeden blok. Koszyki działają także wewnątrz pojedynczej funkcji:

• Plan i architektura (jak działa algorytm, jakie podejście, jaki kształt systemu) dostają górę skali. Tu mieszka myślenie.
• Logika główna (serce algorytmu, to, co naprawdę wyróżnia produkt) zostaje na najmocniejszym modelu. To jedyne miejsce, w którym nie ryzykuję słabszego ustawienia, bo różnica między modelami jest największa właśnie przy trudnej, nowej logice. A jeśli koszt nie jest ograniczeniem, to nie ma tu czego oszczędzać.
• Rusztowanie (schema, endpointy, łączenie elementów, panel admina, klej między nimi) idzie na szybkie ustawienie. To praca mechaniczna i ma iść szybko.

"Dużo szybciej w sumie" bierze się z uruchomienia logiki głównej na mocnym modelu z niższym effortem i rusztowania na szybkim, a nie z obniżania ustawień dla logiki głównej. Klejnot w koronie zachowuje swoje ustawienie. Wszystko wokół niego przyspiesza.

Większa dźwignia: nie wpaść w spiralę

Prawdziwym zabójcą produktywności nie jest wybór modelu, tylko spirala dziesięciu rund poprawek. Wyjście z niej nie ma prawie nic wspólnego z tym, jaki model wybrałeś. Pracuj małymi kawałkami z przeglądem przy każdym kamieniu milowym, żeby wyłapać błąd na fragmencie, a nie po pięciuset linijkach. Pilnuj, żeby plany były szczelne, a konwencje spisane, bo model je czyta. Stawiaj na szybkie cykle, a nie w idealny pierwszy strzał. A przy wszystkim, co algorytmiczne, mierz, zamiast oceniać na oko. Nie ocenisz, czy wynik dopasowania jest dobry, patrząc na jeden przykład. Dlatego obok budujesz mały harness do ewaluacji i pozwalasz metrykom powiedzieć, czy jest lepiej, czy gorzej. Bez tego kręcisz się w kółko, niezależnie od tego, jaki model pracuje.

Eskalacja ma swoje miejsce w tej pętli, ale jako reakcja, a nie ustawienie domyślne. Zacznij od średniego ustawienia i podbijaj na maksimum dopiero wtedy, gdy dwie uczciwe próby nie trafiły. Zmiana zajmuje sekundy, więc strzał za nisko na start nic nie kosztuje. A to znaczy, że nie ma powodu płacić czasem odpowiedzi maksymalnego ustawienia za pracę, która nigdy go nie potrzebowała.

Kontekst to stosunek sygnału do szumu, a nie procent

Pokrewny nawyk, który się opłaca: stara zasada "kompaktuj rozmowę przy połowie okna" jest nieaktualna, kiedy okna kontekstu są ogromne. Ale zasada, która pod nią leży, przetrwała i nigdy nie dotyczyła procentów. Zagracony kontekst obniża jakość na długo przed jakimkolwiek limitem. Długa, meandrująca rozmowa jest gorsza niż krótka i skupiona, która zawiera te same fakty. Lepsza praktyka to więc jedna sesja na jedno skupione zadanie, nowa sesja przy zmianie tematu i ręczne kompaktowanie dopiero wtedy, gdy czujesz, że jakość spada (model gubi wątek, powtarza się, gubi wcześniejsze szczegóły), a nie przy jakiejś konkretnej liczbie. Spisywanie trwałej wiedzy w docsach projektu sprawia, że nowe sesje są tanie. Dzięki temu każda sesja może zostać skupiona, a właśnie wtedy modele są w najlepszej formie.

Co warto przenieść do siebie

• Spec niesie jakość, model niesie czas odpowiedzi. Przy dobrze wyspecyfikowanej pracy większy model kupuje głównie szybkość, a nie poprawność.
• Przy każdym zadaniu pytaj: "myśleć czy przepisać?" Myślenie idzie na górę skali, przepisywanie na szybką część.
• Nie obniżaj ustawień dla klejnotu w koronie. Różnica między modelami jest największa przy trudnej, nowej logice. Trzymaj rdzeń na mocnym ustawieniu, a przyspieszaj rusztowanie.
• Małe kawałki są ważniejsze niż wybór modelu. Przegląd przy każdym kamieniu milowym to prawdziwa obrona przed spiralą niekończących się poprawek.
• Algorytmy mierz, zamiast oceniać na oko. Harness do ewaluacji mówi, czy jest lepiej, czy gorzej. Intuicja tylko kręci się w kółko.
• Eskaluj w reakcji, a nie domyślnie. Zacznij od środka, podbijaj dopiero po dwóch nietrafionych próbach. Zmiana nic nie kosztuje.