Anthropic випустила Sonnet 5.5 наприкінці вересня і заявляє: понад 30% швидша генерація, до 30% нижча вартість типової задачі та різкий стрибок на агентних бенчмарках – найгучніший на Terminal-Bench 4.0, із 10.3% у Sonnet 5 до 70.6%. Усе це – vendor-цифри за методикою самої Anthropic. Вони корисні як сигнал, але не відповідають на головне питання: чи стане модель кращою у твоєму workflow. Нижче – що саме заявлено, де нюанси і як перевірити чесно.

Що заявляє Anthropic

За офіційною сторінкою моделі (всі цифри – vendor-reported):

  • Швидкість: Sonnet 5.5 генерує відповіді на 30%+ швидше за Sonnet 5.
  • Вартість: «до 30% дешевше на задачу». Важливий нюанс, який губиться в переказах: прайс не змінився – $2 за мільйон вхідних токенів, $10 за мільйон вихідних, $0.20 за cache reads. Економія виникає з того, що модель, за даними Anthropic, витрачає помітно менше токенів на ту саму роботу. Тобто «дешевше» – це про ефективність, а не про знижку.
  • Terminal-Bench 4.0 (агентна робота в терміналі): 70.6% проти 10.3% у Sonnet 5.
  • Інші заявлені зрізи: CursorBench 4.0 – 55.5% проти 34.1%; OSWorld 2.1 – 80.1% проти 57.0% (partial); FrontierCode 1.1 – 46.2% проти 42.4%.

Стрибок на Terminal-Bench у ~7 разів виглядає вражаюче. І водночас зверни увагу на FrontierCode: +3.8 відсоткових пунктів. Та сама модель, різні задачі – зовсім різний масштаб покращення. Це перший дзвіночок, чому «модель стала у 7 разів кращою» – беззмістовне речення без уточнення «в чому саме».

Benchmark ≠ production

У production мене цікавить зовсім інший список:

  • чи читає модель architecture conventions проєкту, чи пише «правильний код» у вакуумі;
  • чи не ламає unrelated code, поки чинить баг;
  • чи пише тести – і чи пише їх до того, як я попрошу;
  • чи розуміє migration constraints («це поле не можна перейменувати, на ньому сидить мобільний клієнт трирічної давнини»);
  • скільки циклів review потрібно до mergeable PR.

Жоден публічний benchmark цього не вимірює, бо все це залежить від твого repo, твоїх конвенцій і твого визначення «готово». Модель може бути топ-1 у терміналі й буксувати на твоєму monorepo через контекст, tooling або стильові обмеження.

Правильний eval: 30 issues зі свого repo

Методика проста і чесна (детальний розбір підходу – у статті про evals для AI-агентів, тут – коротка версія для вибору моделі):

  1. Візьми 30 закритих issues із реальної історії свого repo – для них уже існує еталонне рішення, яке пройшло review.
  2. Дай моделі clean checkout на коміті до фікса, однакові інструкції, tools і timeout.
  3. Зроби blind review результатів – без підпису, яка модель що згенерувала. Оцінюй чотири речі: correct? mergeable? regression? maintainable?
  4. Порівняй із тим, що реально змерджила команда.

Тільки після цього можна говорити про ROI конкретної моделі для конкретного проєкту. Так, це день роботи. Але це день, який заощадить місяці сліпої віри в чужі скріншоти.

Що це означає для твоєї кар'єри

Найважливіший висновок із релізу – не про Anthropic. Моделі реально стають сильнішими, і стрибки на агентних бенчмарках, навіть із поправкою на vendor-методику, відображають справжній тренд: агент довше тримає складну задачу й частіше доводить її до кінця.

Це зміщує навичку розробника. Цінність «написати більше коду руками» падає. Зростає цінність трьох речей:

  • правильно поставити задачу – з контекстом, обмеженнями і критерієм готовності;
  • побудувати validation – тести, лінтери, евали, які ловлять проблему без твоєї участі;
  • впіймати subtle wrongness – код, який виглядає правильним, компілюється, проходить happy path і тихо бреше на edge case.

Третє – найцінніше. І його жоден benchmark за тебе не прокачає. Ширший контекст про те, як вбудувати AI у щоденну роботу без деградації цих навичок, – у базовій статті про AI для програміста.

Як не треба зустрічати новий реліз

  • Міняти модель за замовчуванням у всій команді в день релізу. Спочатку eval, потім rollout.
  • Порівнювати цифри різних вендорів між собою. Terminal-Bench від Anthropic і внутрішній тест GitHub – різні методики; зіставляти їх напряму некоректно.
  • Плутати «дешевше на задачу» зі «нижчий прайс». Якщо твої задачі нетипові, токен-ефективність може не відтворитись – а прайс лишиться тим самим.
  • Ігнорувати latency. Швидша генерація – це приємно, але для агентних циклів із десятками викликів вона множиться: заміряй end-to-end час свого workflow, а не окремої відповіді.

Eval на п'ять issues за один вечір

Міні-версія власного eval на вечір: вибери 5 закритих issues зі свого repo (різної складності), прожени через поточну модель і через Sonnet 5.5 з однаковими інструкціями, і для кожного результату дай відповідь на одне питання: «я б змерджив це після одного review-циклу?» Рахунок 5:2 скаже тобі про моделі більше, ніж усі скріншоти бенчмарків цього тижня.