Claude Sonnet: model roboczy dla agentów i kodu

Sonnet jest środkową linią Claude: łączy zdolność planowania i używania narzędzi z kosztem niższym niż modele najwyższej klasy. Sonnet 5, ogłoszony 30 czerwca 2026 r., jest aktualnym punktem odniesienia w tej serii. Źródłem opisu bieżącej wersji jest komunikat Anthropic o Sonnet 5. To opis zastosowań i kryteriów wyboru, nie deklaracja, że model zawsze wygrywa z każdym konkurentem.

Co potrafi w pracy z tekstem i danymi?

Do tekstu Sonnet sprawdza się tam, gdzie samo skrócenie dokumentu nie wystarcza: trzeba porównać wersje umowy, wskazać rozbieżności w wymaganiach lub napisać zwięzłe uzasadnienie decyzji. W analityce może formułować hipotezy i zapytania, ale wynik SQL musi pochodzić z bazy. Przy kilkudziesięciu dokumentach lepiej pobrać właściwe fragmenty i wymagać cytatów niż wkleić cały korpus i zaufać jednemu podsumowaniu.

Co wnosi do kodowania i AI SDLC?

Według Anthropic Sonnet 5 poprawia planowanie, użycie terminala i przeglądarki oraz agentowe kodowanie względem Sonnet 4.6. Praktyczny scenariusz to zmiana przechodząca przez API, walidację, test i dokumentację. Agent powinien dostać warunki akceptacji, wykonać testy i pokazać diff; sam wynik benchmarku SWE-bench nie mówi, jak poradzi sobie z lokalną architekturą.

Gdzie sprawdzi się w biznesie?

Sonnet może być domyślnym modelem roboczym w wewnętrznym asystencie projektowym: zbiera kontekst, proponuje plan, a przed zapisem przekazuje akcję przez politykę uprawnień i zatwierdzenie. W obsłudze klienta warto dać mu narzędzia odczytowe osobno od narzędzi modyfikujących CRM. Miernikiem jest odsetek poprawnie zamkniętych spraw oraz liczba interwencji, nie liczba wygenerowanych odpowiedzi.

Jakie są alternatywy?

Haiku jest lepszym kandydatem przy dużym wolumenie krótkich zadań. Opus lub Fable rozważ dla złożonych, długotrwałych problemów. GPT-6 Sol to mocna alternatywa w kodowaniu i workflow agentowym, zwłaszcza gdy organizacja używa już Responses API.

Na co uważać?

Sonnet bywa rozsądnym domyślnym wyborem, ale nie jest gwarancją poprawności. Testuj osobno jakość polskiego tekstu, rozumowanie na danych, zachowanie narzędzi i naprawę kodu. Zadania o wysokim koszcie błędu wymagają niezależnego sprawdzenia.

Przykład: zmiana wymagania w produkcie

Załóżmy, że nowy status zamówienia ma pojawić się w API, panelu i raportowaniu. Sonnet najpierw identyfikuje moduły i istniejące testy, potem proponuje plan zmian. Po akceptacji wykonuje małe kroki, uruchamia testy i pokazuje diff. Recenzent sprawdza zwłaszcza migrację danych oraz zachowanie starych klientów API. To zadanie ujawnia więcej niż pojedynczy benchmark kodowania: model musi zachować spójność między tekstem wymagania, schematem i kodem. Wynik porównaj z Opus oraz GPT-6 Sol przy identycznych uprawnieniach i limicie czasu.

Jak sprawdzić model przed wyborem?

Przygotuj niewielki, ale reprezentatywny zestaw własnych przypadków: zwykłe zadania, rzadkie wyjątki, niepełne dane i próby wymuszenia odpowiedzi. Dla tekstu oceniaj zgodność z faktami, kompletność i przydatność do dalszej pracy. Dla analityki sprawdzaj, czy zapytanie używa właściwej definicji metryki, a opis zgadza się z wynikiem systemu źródłowego. Dla kodu wymagaj działających testów, czytelnego diffu i braku zmian poza zakresem. Mierz pełny koszt zaakceptowanego wyniku wraz z czasem review, nie jedynie cenę tokenów.

W systemie produkcyjnym zapisuj wersję modelu, prompt, użyte narzędzia i wynik oceny. Dzięki temu po aktualizacji modelu można wykryć regresję oraz zdecydować, które sprawy nadal obsługiwać automatycznie. Więcej o tej praktyce opisuje filar AI SDLC.

Źródła i dalsza lektura

• komunikat Anthropic o Sonnet 5 — dokumentacja lub komunikat producenta dotyczący Sonnet 5.