Технічний контекст
Я люблю такі порівняння не через хайп, а тому, що з них можна винести реальну користь для ШІ-автоматизації в розробці. Тут ми маємо не абстрактний бенчмарк, а пряме зіткнення GPT-5.5 і Claude Opus 4.8 на одному TDD-завданні без попередньої специфікації. Тобто в умовах, де модель повинна не просто писати код, а утримувати архітектуру проекту в голові.
За часом картина виявилася досить жорсткою: два запуски GPT-5.5 в режимі xhigh fast зайняли 32:35 та 33:26, тоді як Claude xhigh з dynamic workflow orchestration впорався із завданням за 25:45. Це суттєвий розрив, особливо якщо такі процеси запускаються серіями всередині інженерного пайплайну.
Далі ще цікавіше. Оцінювачі як на базі GPT, так і на базі Claude погодилися за кількома ключовими параметрами: Claude втрачав менше даних, покривав більше потенційних точок збою, писав простіший код і підтримував чистіші архітектурні шари. У рішенні GPT натомість виявилася зайва інфраструктурна класифікація в шарі Application та перевантаження моделі там, де можна було обійтися простішим рішенням.
За обсягом коду різниця також не на користь GPT-5.5: один прогін дав на 46% больше application LOC, другий — на 50% більше. При цьому тестів у Claude виявилося більше, а відповідність вимогам ADR проекту кращою: у Claude було лише 2 некритичні порушення, тоді як у GPT — 2 критичні та 3 некритичні.
Щодо вартості є важливе зауваження. Для Claude вартість сесії склала $21.67 на тарифі Max, тривалість API — 56m 28s, а загальний час виконання — 2h 31m, оскільки загальний час збільшився через паралельну роботу агентів. Хоча це не ідеальне порівняння один в один по грошах, як інженерний сигнал тест корисний: оркестрація може з'їдати бюджет, але вона виграє за рахунок якості та швидкості доставки коду.
Вплив на бізнес та автоматизацію
Я б не став робити висновок, що "одна модель перемогла назавжди". Проте для завдань, де важливі ADR, чисті архітектурні шари та стійкість до відмов, Claude Opus 4.8 наразі виглядає переконливіше. Якщо ви будуєте інтеграцію ШІ в SDLC (життєвий цикл розробки), це безпосередньо впливає на кількість переробок після автогенерації, а не просто на красу демо-версії.
Хто виграє? Команди, для яких помилки в архітектурі та регресійне тестування коштують дорого. Хто програє? Ті, хто дивиться лише на вартість токенів або швидкість першої відповіді, ігноруючи витрати на виправлення помилок через два спринти.
У Nahornyi AI Lab я зазвичай зупиняю поспішне впровадження саме на таких етапах: спочатку перевіряю, де модель дійсно економить час, а де створює гарний технічний борг. Якщо ви бажаєте спокійно проаналізувати свій стек та побудувати надійну ШІ-автоматизацію без зайвих експериментів на продакшені, ви можете звернутися до мене зі своїм кейсом. Разом з Vadym Nahornyi ми розробимо схему під ваш реальний процес, а не під красивий скріншот чужого тесту.