Nowsze modele Claude, włącznie z flagowym Opus 4.8, mają problemy z poprawnym używaniem custom'owych narzędzi edycji, które wyliczają dodatkowe, wymyślone pola w nesowanych tablicach edits. Samo edytowanie zazwyczaj jest poprawne, ale argumenty nie pasują do zdefiniowanego schematu, przez co systemy takie jak Pi odrzucają wywołanie i proszą o ponowną próbę.
Co zaskakujące, problem pogarsza się z każdą nowszą wersją modelu. Zarówno Opus 4.8 jak i Sonnet 5 wykazują to zachowanie, podczas gdy starsze wersje Claude radzą sobie znacznie lepiej. To zupełnie odwrotne od tego, czego byśmy się spodziewali - najlepsze modele w rodzinie powinny być najlepsze we wszystkim. Przyczyna jest fascinująca: Anthropic specjalnie trenował nowsze modele, prawdopodobnie poprzez reinforcement learning, aby doskonale obsługiwały narzędzia edycji wbudowane w Claude Code. Ta specjalizacja ma niechciany efekt uboczny - inne systemy kodowania z własnymi narzędziami edit, takie jak Pi, doświadczają częstszych błędów w wywołaniach.
To ilustruje głębszy problem w budowaniu wielofunkcyjnych modeli sztucznej inteligencji. Kiedy trenujesz model na obsługę konkretnego interfejsu czy narzędzia, może on zoptymalizować się w taki sposób, że gorzej radzi sobie z alternatywnymi interfejsami, nawet jeśli logicznie powinien byłby gorzej działać. OpenAI napotykał podobne wyzwania przy swoim podejściu opartym na apply_patch, ale zdaje się, że mieli lepsze rezultaty. Teraz pojawiają się pytania, czy narzędzia trzecie powinny implementować wiele wersji edytorów tylko po to, aby znaleźć ten, który dany model obsługuje najlepiej.