У щотижневому технологічному шоу «MVC» на каналі УТ‑2 розробники й ведучі Юрко, Ілля та Саня діляться тим, як вони реально працюють з сучасними LLM для програмування. Окремий блок ефіру перетворився на неформальний, але дуже приземлений бенчмарк: як нова модель Fable від Anthropic поводиться на великій кодовій базі порівняно з Opus і GPT‑5.5, що вона робить краще — і скільки це насправді коштує в токенах.
Новий клас задач: де Fable виривається вперед
Головне враження від Fable — вона не просто «ще одна велика модель», а інструмент, який нарешті тягне задачі, що попередні генерації стабільно «просідали».
Один із ведучих описує дуже конкретний кейс. Є велика частина коду, до якої він практично не торкався власноруч, ідеальний кандидат для стороннього архітектурного рев’ю:
«Є штука, доволі багато коду, яку я сам своїми руками не чіпав… коли я просив зробить йому рев’ю… GPT‑5 знаходив дуже поверхневі дрібниці. А цей пацан прямо викупив пару моментів».
Різниця не в тому, що GPT‑5.5 зовсім безпорадний: він знаходить «дрібну чухню», лінтерного рівня. Проте Fable поводиться як уважний сеньйор, який бачить не окремі рядки, а цілісну систему:
«Він прям знайшов дві доволі серйозні трабли, які по написанню тестів реально вилазили проблемою».
Мова про випадки, коли одна і та сама концепція реалізована в різних файлах «трошечки по‑різному», бо код шматками дописували моделі. Саме такі відхилення в інваріантах і контрактних очікуваннях потім вибухають на рівні тестів і продакшн‑багів. Fable ці неузгодженості бачить.
На противагу, попередні моделі — GPT‑5.5 і Opus — у подібних задачах часто губляться навіть у базових налаштуваннях:
- забувають, що зараз тренують саме ту версію фреймворку, про яку їх просили;
- «відкочуються» до старих варіантів бібліотек, які «краще пам’ятають»;
- починають раптом стверджувати, що запитуваної версії взагалі не існує.
У Fable таких «фантомних» помилок, за словами ведучих, не спостерігалось. Це або наслідок свіжішого набору даних (наприклад, кращого знання сучасних стеків типу «як тренувати конкретну модель»), або реальні покращення в тому, як вона користується локальною документацією та контекстом.
У будь‑якому разі, практичний висновок простий: Fable вперше відчувається інструментом для повноцінного архітектурного рев’ю, а не лише для автодоповнення та косметичного рефакторингу.
Коли AI рев’ює рефакторинг: пам’ять і глибина
Цікава деталь роботи Fable проявляється не лише у виявленні проблем, а й у здатності «тримати в голові» незавершені зміни.
Після великого проходу по кодовій базі ведучий перезапускає сесію з моделлю — і чує від неї не банальне резюме, а цілком конкретний вказівник:
«Я перезапускаю Fable, він каже: “Ти знаєш, тут був рефактор, він не доведений до кінця. Отуди подивись, отуди”».
Фактично, модель відмічає «висячі» місця, де рефакторинг почали, але не довели до логічного завершення, і повертає розробника до цих точок. Для великих систем, де змінювали шматки модулів або API, це схоже на поєднання статичного аналізатора з дуже уважним рев’ювером, який вміє формулювати: «ось ця сім’я змін не закрита до кінця».
У поєднанні з вмінням знаходити несумісності в реалізаціях це робить Fable natural‑choice саме для архітектурного рев’ю та узгодження інваріантів, а не лише для дрібного «code style policing».
Ціна питання: $700 за сесію і з’їдений ліміт
Технічний захват від можливостей Fable швидко упирається у фінансову й операційну реальність.
Проблем дві: швидкість і вартість.
По‑перше, швидкодія:
«Але дуже довго, дуже дорого… юзать його, ну, типу day to day, от як GPT‑5.5 якийсь неможливо, тому що… не знаю, де набратися терпіння. Він реально на тупняке капітальному дуже повільний».
По‑друге, токени й гроші. Одна сесія архітектурного рев’ю:
«В мене просто за вчора в одній сесії він нажрав токенів на 700 баксів».
І це не одиничний виняток. Для аналізу всієї архітектури:
«Він мені на це архітектурне рев’ю вижрав по півліміта оцього… маленького, який там 5 годин… просто і нема».
Йдеться про тімовий ліміт у Anthropic, що прив’язаний до часових інтервалів. Після інтенсивної сесії Fable code review інструмент просто «з’їдає» половину цього бюджету, і до ресета залишається вже не п’ять годин, а «15 хвилин до кінця».
Фактично Fable поводиться як надпотужний, але надзвичайно дорогий консультант, якого не тримають «у чаті» постійно, а викликають під точкові, критичні задачі.
Це накладається й на обмеження за передплатами: ведучі очікують, що через кілька тижнів Anthropic може прибрати Fable з стандартних підписок або ще жорсткіше закрутити ліміти. Уже зараз модель часто повертає помилки про надмірний попит і брак ресурсів, що ще раз підкреслює її статус «дефіцитного ресурсу».
Найкраща схема — комбінувати: Fable планує, GPT‑5.5 виконує
На цьому фоні звучить, можливо, найпрактичніша порада з усього обговорення: не намагатися робити все однією моделлю.
Замість того, щоб змушувати Fable і шукати проблеми, і виправляти їх, ведучі пропонують поділити ролі:
«Фable’ом задать задачу, а потім GPT‑5 екзек’ютнуть, мені здається, вообще нормальна тема».
Сценарій виглядає так:
- Fable отримує велику кодову базу й завдання на рівні «знайди архітектурні неузгодженості, концептуальні розходження, недотягнуті рефакторинги».
- Модель повертає структуроване рев’ю: список проблем, конкретні файли, де одна й та сама абстракція реалізована по‑різному, підозрілі місця, що вилазять через тести.
- Далі в тому ж контексті або з перенесеним описом задачі підключається GPT‑5.5, який:
- швидше працює;
- значно дешевший у токенах;
- добре справляється з локальними правками й механічним рефакторингом.
У результаті Fable використовується як архітектор і рев’ювер високого рівня, а GPT‑5.5 — як виконавець, що впевнено «допилює» конкретні патчі.
У реальному експерименті це виглядало доволі переконливо: Fable знаходив дві суттєві проблеми, які проявлялися лише при написанні тестів, а GPT‑5.5 «фантастично» їх виправляв, коли йому прямо формулювали: «фікси першу», «фікси другу».
За такої моделі використання вартість Fable залишається високою, але вже не неконтрольованою: вона концентрується на задачах, де модель реально має додану вартість, а не витрачається на рутинні зміни, які інші LLM виконують не гірше.
Чому фанатизм за одну модель — тупикова гілка
Фінальний меседж розмови — радше стратегічний, ніж суто технічний. Попри очевидні переваги Fable в архітектурному аналізі, ведучі не радять перетворювати її на «універсальний молоток».
Причин кілька.
По‑перше, токенна економіка: при поточних тарифах і лімітах тримати Fable як day‑to‑day інструмент просто нерентабельно, особливо для невеликих команд чи індивідуальних розробників.
По‑друге, поведінка самого ринку. Anthropic уже показала готовність жорстко змінювати правила гри: від експериментів з обмеженням використання підписок до автоматичного перемикання на інші моделі (Opus) у сценаріях, які компанія вважає «небезпечними» — наприклад, для тренування конкурентних моделей. Це не додає впевненості тим, хто хоче цілком покласти свою розробку на одну платформу.
По‑третє, чисто практичний досвід: GPT‑5.5 і Opus залишаються корисними та більш збалансованими за співвідношенням «швидкість / якість / ціна» для повсякденної роботи з кодом. Той самий ведучий, який заплатив $700 за сесію Fable, відверто зізнається, що для звичайних задач «де набратися терпіння» працювати з такою повільною та дорогою моделлю — відкрите питання.
Звідси й ідея, що оптимальною стає гібридна схема: Fable — для вузького класу задач, де її додана вартість очевидна, GPT‑5.5 — для масового флоу, Opus — як ще один баланс між ціною і якістю в окремих сценаріях.
Так виглядає реальний сьогоднішній досвід інженерів, які не читають маркетингові слайди, а платять за кожен токен.
Висновок
Практичний тест Fable, Opus і GPT‑5.5 у руках розробників з УТ‑2 показує, як насправді змінюється робота з великими кодовими базами.
Fable дійсно «прикольна тим, що потенційно вона вирішує клас задач, які минулі моделі не вирішували»: глибоке архітектурне рев’ю, виявлення концептуальних неузгодженостей, вказівка на незавершені рефакторинги. Але ці переваги приходять із ціною — у прямому сенсі слова, в сотнях доларів за сесію та з’їдених лімітах.
Звідси випливає тверезий підхід: не шукати «одну правильну модель», а будувати стек, де різні LLM виконують різні ролі — від архітектора до «кодового робота», що швидко і недорого реалізує знайдені зміни.
У такій конфігурації не доводиться фанатіти від чергового релізу: моделі стають змінними інструментами в коробці, а не релігією.
Джерело
Обговорення в подкасті «MVC #30» на каналі УТ‑2:
https://www.youtube.com/watch?v=O5ncXXAwexs