Технічний контекст
Я звернув увагу на цей аналіз не через чергову битву моделей, а через економіку. Команда прогнала різні SDD-методології на простому проєкті з п'яти ендпоінтів через Claude Code і отримала дуже зрілий висновок: якість результату приблизно однакова, а вартість може відрізнятися вп'ятеро. Для AI automation це чи не головний сигнал року.
Мені тут особливо подобається зміщення фокуса. Не «яка модель розумніша на бенчмарку», а «яка найдешевша модель чи агент можуть імплементувати специфікацію без помилок». Ось це вже інженерне питання, а не фетиш на SOTA-моделі.
З обговорення видно, що тестували не абстрактні ідеї, а цілком прикладні режими роботи: кастомні навички для специфікації, планування, однофазної реалізації, review з pushback. Runner за замовчуванням працює на Claude reasoning medium плюс Opus. Далі хочуть прогнати ті самі сценарії на Codex Max, і це логічний наступний крок.
Найбільш жорсткий інсайт я б сформулював так: якщо вам вже потрібен spec-kit, claude-plan і ще купа складних милиць, щоб задача поїхала, то проблема не в моделі. Проблема в тому, що система занадто велика, погано декомпозована або специфікація написана так, що її важко виконувати навіть хорошому агенту.
І ось тут я прямо киваю, бо в реальних AI solutions for business я бачу те саме. Коли специфікація чиста, обмежена і перевіряється, навіть слабша модель часто доїжджає до результату без драми. Коли специфікація розмита, дорогий агент просто дорожче помиляється.
Що це змінює для бізнесу та автоматизації
Для бізнесу висновок майже непристойно практичний. Бюджет на artificial intelligence implementation тепер є сенс витрачати не тільки на моделі, а на дисципліну специфікацій, інтерфейси, критерії приймання та нормальну декомпозицію. Це нудніше, ніж купувати новий Opus, але окупається краще.
Виграють команди, які вміють описувати систему як набір маленьких контрактів, що перевіряються. Програють ті, хто намагається лікувати архітектурний хаос дорожчим inference.
Я б ще додав важливий шар. Якщо якість справді вирівнюється між методологіями, то ринок поступово зміщується від «хто дав потужнішу модель» до «хто вибудував процес так, щоб будь-яку задачу можна було віддати дешевшому виконавцю». Це вже не просто розробка, це AI integration як операційна система компанії.
Звідси й інтерес до ідеї «машини Геделя-Дарвіна» для масштабування гіпотез всередині організації. Звучить голосно, але суть приземлена: ви проганяєте варіанти специфікацій, агентів і пайплайнів як еволюційні гіпотези, а потім дивитеся на метрики часу, вартості та якості. Не сперечаєтесь про смаки, а відбираєте те, що вижило.
Я б не робив з цього універсальну істину, тому що кейс маленький: п'ять ендпоінтів — це не моноліт, не легасі-ERP і не messy enterprise backend. Але як сигнал напрямку він сильний. Якщо на простому проєкті ціна гуляє в 5 разів без помітної різниці в якості, на потоці завдань економічний ефект може стати дуже жирним.
Ми якраз такі вузькі місця й аналізуємо у клієнтів в Nahornyi AI Lab. Не «яку модель купити», а де у вас ламається декомпозиція, як переписати специфікації під надійне виконання і де build AI automation справді дасть економію, а не красиве демо. Якщо відчуваєте, що команда вже переплачує за хаос у процесах, можна спокійно сісти й розкласти це в робочу AI architecture без магії та зайвих токенів.