Technical Context
Я дивлюся на дискусію навколо Claude Opus 4.5 vs Opus 4.6 не як на «яка модель розумніша», а як на сигнал про зміну продуктової стратегії. Мене як архітектора цікавить не абсолютний бал, а те, де саме розробник моделі інвестував бюджет навчання: у SWE-поведінку чи в «офісну» агентність.
За публічними даними та непрямими порівняннями, що зараз найчастіше спливають в оглядах, картина така: Opus 4.6 зберігає невелику перевагу на SWE-bench Verified (в районі 80.8%), а Sonnet 4.6 підтягується майже впритул (близько 79.6%). Це не революція, це ущільнення. На практиці це означає: для агентного кодингу різниця між «дорогим» і «середнім» класом у Anthropic продовжує стискатися, і це свідомий продуктовий хід.
Далі починається найцікавіше: на GDPval-AA (умовно «B2B-офісні» мультикрокові задачі: фінанси, страхування, медицина як проксі-домени) Sonnet 4.6 опиняється в топі лідербордів (1633 Elo), і в ряді публікацій виглядає як #1 або статистично не відрізняється від Opus 4.6 у межах довірчих інтервалів. Я сприймаю це як пряму оптимізацію під комерціалізацію «в маси»: не стільки писати код, скільки закривати ланцюжки дій у документах, таблицях, CRM та внутрішніх порталах.
Ще один технічний маркер, який я завжди перевіряю: tool use / MCP-сумісність та стійкість при довгих сценаріях. Sonnet 4.6 по MCP-Atlas фігурує як дуже сильний (близько 61%+), а це вже не «якість тексту», а якість інтеграції: наскільки модель стабільно викликає інструменти, не втрачає контекст, не ламає план на 8–12 кроках. У реальному впровадженні штучного інтелекту це часто важливіше за ще +2% до вирішення олімпіадних задач.
В обговоренні спливає і відсутність Gemini 3 Pro «у списках». Я не роблю з цього висновок «моделі немає» або «модель слабка» — я роблю архітектурний висновок: якщо модель відсутня у ваших цільових лідербордах і немає репрезентативних eval'ів за вашими сценаріями, то її не можна закладати як базову в критичний контур. У проді ми купуємо не «модель», а передбачуваність поведінки, вимірюваність та вартість помилки.
Business & Automation Impact
Я бачу, як у багатьох компаній ламається звична логіка закупівлі: «беремо найновішу і найбільшу — отже, буде краще у всьому». На практиці нова версія може дати приріст в офісних ланцюжках (GDPval-AA-подібні сценарії), але не дати очікуваного стрибка в SWE. А якщо ваш KPI — швидкість закриття тікетів і якість патчів, ви раптово переплачуєте за не той профіль компетенції.
У проектах Nahornyi AI Lab я найчастіше стикаюся з двома класами задач, і вони вимагають різних моделей і різної AI-архітектури:
- SWE та інженерні контури: генерація PR, рефакторинг, автолагодження тестів, аналіз логів, міграції. Тут важливі точність, дисципліна в діффах (diffs) і здатність дотримуватися репо-конвенцій. «Трохи краще на SWE-bench» може реально заощадити години рев'ю.
- Офісні та операційні контури: розбір документів, звірка рахунків, комплаєнс-чек-листи, страхові кейси, медичні виписки, підготовка листів, заповнення ERP/CRM, звіти. Тут виграє модель, яка менше галюцинує, краще тримає мультикроковий план і стабільно викликає інструменти.
Якщо Sonnet 4.6 дійсно «закриває» офісні ланцюжки краще, то виграють компанії з великим обсягом повторюваних операцій: фінанси, страхування, клініки, логістика, back-office у рітейлі. Програють ті, хто продовжить оцінювати моделі тільки за «кодерськими» бенчмарками та ігнорувати вартість процесу: скільки кроків пройде агент, скільки разів зірветься, скільки разів оператор буде виправляти.
Впровадження AI в таких процесах я майже ніколи не роблю «однією моделлю на все». Я збираю контур: маршрутизація запитів за типами задач, різні політики безпеки, різні ліміти на tool use, різні стратегії пам'яті. Тоді «офісна» модель дійсно дає ROI, тому що вона не просто відповідає, а проходить шлях до результату: знайшла потрібний документ, звірила поля, сформувала запис у системі, залишила слід аудиту.
І тут же з'являється жорсткий нюанс щодо вартості: «краще в офісі» часто означає більше токенів і довші траєкторії агента. Якщо не контролювати бюджет (ліміти, кешування, chunking, дедуплікація, контроль повторних викликів), то AI автоматизація перетворюється на статтю витрат без керованої маржинальності. Я волію спочатку проектувати економіку запиту, а вже потім обирати модель.
Strategic Vision & Deep Dive
Мене не дивує зсув прогнозів щодо «super-coding-agent» з 2027 на 2029 рік. Я бачу це по реальних контурах: автономність впирається не в «розум», а в інженерні обмеження — доступи, детермінізм, перевірюваність, відтворюваність, права на зміни, якість тестового покриття, і головне — ціна помилки.
Зараз ринок, за моїми спостереженнями, раціонально обирає не максимальний IQ, а максимальну монетизацію: агент, який закриває страховий кейс або фінансову звірку без ескалацій, приносить бізнесу гроші сьогодні. Агент, який «майже» сам пише продукт, все ще вимагає занадто багато страховок: sandbox, policy-контури, обов'язкові перевірки, комплаєнс-логи, staging-прогони. Це дорога експлуатація, і вона погано масштабується в компаніях без зрілої інженерної культури.
В архітектурі AI-рішень я все частіше закладаю принцип: «кодинг — це інструмент, офіс — це ринок». Тому я очікую, що наступні релізи будуть продовжувати покращувати: інструментальні виклики, стійкість до довгих сценаріїв, зниження галюцинацій у документах, роботу з таблицями та формами, а не тільки чистий SWE. Для бізнесу це хороша новина: цінність приходитиме через процеси, а не через демо.
Пастка, яку я бачу у клієнтів, проста: вони намагаються вимірювати B2B-агентів «як кодера» і потім розчаровуються. Я роблю інакше: визначаю 10–20 еталонних бізнес-сценаріїв, будую evaluation під їхні дані, додаю контроль якості (human-in-the-loop там, де потрібно), і тільки потім вирішую, де виправданий Opus-рівень, а де Sonnet-рівень дає той самий результат дешевше. Це і є практична розробка AI рішень, а не полювання за цифрами.
Якщо резюмувати мій прогноз: до 2029 року «супер-кодер» з'являтиметься точково — у компаніях з ідеальними репозиторіями та тестами. Масовий ефект дадуть моделі, заточені під операційні ланцюжки, і переможуть ті, хто швидше вбудує їх у процеси та дані, а не ті, хто раніше всіх купить нову версію.
Хочете зрозуміти, яка модель і яка AI-архітектура дадуть ROI саме у вашому процесі? Я запрошую обговорити задачу з Nahornyi AI Lab: розберемо сценарії, ризики, економіку токенів і спроектуємо впровадження AI без «магії» та сюрпризів у проді. Напишіть мені — консультацію веду особисто, Вадим Нагорний.