Технічний контекст
Я люблю такі новини не за гучний реліз, а за чесний інженерний висновок: одна модель не зобов'язана робити все. В обговоренні якраз виплив дуже життєвий патерн для AI implementation: Claude Opus беруть на планування та специфікацію, а Codex або Composer 2.0 пускають в імплементацію.
І це звучить банально рівно до того моменту, поки не відкриваєш стару кодову базу. Там будь-яка недомовленість у плані швидко перетворюється на дивний код, втрачений контекст і кілька годин на розбір, де модель вирішила «зрозуміти задачу по-своєму».
Я сам багато разів бачив ту саму проблему. Якщо модель одразу йде писати код без нормальної специфікації, вона надто охоче додумує архітектуру, зв'язки між модулями та побічні ефекти, особливо в legacy.
А от коли Opus спочатку збирає детальний план, картина змінюється. Я б назвав це не магією, а нормальним розподілом ролей: дорогий і вдумливий мозок робить карту, швидкий виконавець іде по ній.
У початковому досвіді цікавий навіть не сам успіх зв'язки, а провал одного з експериментів. Codex не зміг нормально реалізувати план Claude, якщо цей план не проходив додаткове рев'ю з боку самого Codex, і ось це місце я б не пропускав.
Виходить важлива деталь: між «зробити план» і «віддати план іншому агенту» потрібен шар узгодження. Інакше план може бути логічним для автора, але погано виконуваним для моделі, яка потім пише код.
Я б збирав такий workflow так: Opus робить специфікацію, потім другий прохід спрощує її до виконуваного формату, а вже потім Codex або Composer 2.0 йде в код. Іноді достатньо короткого anchor-файлу: мета, обмеження, файли, критерії готовності, заборони.
На папері це зайвий крок. На практиці це якраз те, що ріже галюцинації та зменшує кількість циклів «перероби, ти не туди пішов».
Вплив на бізнес та автоматизацію
Для бізнесу тут немає жодної романтики, лише економіка. Якщо дорога модель витрачає токени на глибокий аналіз, а дешевша і швидша робить основну імплементацію, я отримую краще співвідношення ціни, швидкості та якості, ніж у сценарії «запускаємо найрозумніший режим на все підряд».
Особливо добре це працює там, де код вже існує і ламати його не можна. У greenfield-проєкті модель ще може красиво імпровізувати, а в legacy будь-яка красива імпровізація потім виходить дорогим рев'ю та регресіями.
Хто виграє? Команди з великими кодовими базами, інтеграціями, внутрішніми сервісами, купою історичних компромісів. Там multi-model routing реально корисніший, ніж чергова суперечка про те, яка модель «розумніша загалом».
Хто програє? Ті, хто намагається наосліп впхнути одного агента в повний цикл розробки. Я б навіть сказав жорсткіше: без маршрутизації завдань і нормальної AI architecture такі експерименти швидко перетворюються на дорогий театр автодоповнення.
Є й менш очевидний ефект. Коли я розділяю планування і кодинг, мені простіше контролювати якість команди: один артефакт перевіряє архітектуру, другий артефакт перевіряє реалізацію. Це вже не розмова з чорною скринькою, а керований pipeline.
Саме тому я дивлюся на такі кейси не як на «лайфхак для промптів», а як на шаблон AI solution development. Сьогодні це допомагає писати код, завтра той самий принцип переноситься в підтримку, обробку документів, клієнтський сервіс і внутрішні AI automation workflows.
Ми в Nahornyi AI Lab вирішуємо для клієнтів рівно такі задачі: де поставити дорогу модель, де дешеву, що давати агенту в контекст, де потрібен human-in-the-loop, а де достатньо суворої специфікації. І якщо у вас команда вже втрачає години на хаотичну artificial intelligence integration у коді чи процесах, я б спочатку розібрав ваш маршрут завдань, а потім зібрав AI automation без зайвої магії та зайвих рахунків. Якщо відгукується, напишіть, і ми з Vadym Nahornyi подивимося, як перетворити цей хаос на робочу систему.