Технічний контекст
Мені тут сподобалася не сама новина, а робочий прийом: я вважаю, що AI automation починає приносити реальну користь саме тоді, коли ми перестаємо чекати ідеалу від однієї моделі. Натомість я розводжу ролі. Claude даю plan mode і прошу зібрати короткий план змін, а Codex підключаю як другий мозок, який шукає пропуски, слабкі місця та сумнівні технічні припущення.
Це не теоретична схема зі слайдів. Вона вже виглядає як нормальна AI integration у повсякденну розробку: один агент думає архітектурно, другий перевіряє план на приземленість, типи, API-стики та edge cases. Потім я можу знову віддати результат Claude, щоб він зібрав усі зауваження в єдиний change plan без зайвої балаканини.
Ключовий момент тут не в тому, що Claude «розумніший» чи Codex «суворіший». У них просто різні звички мислення. Claude зазвичай краще тримає загальну структуру завдання і не розвалює її на хаотичний список, а Codex частіше чіпляється за конкретику: де зламається контракт, де не вистачає кроку міграції, де план звучить гарно, але не переживе реальний репозиторій.
Я б ще жорстко обмежував довжину плану. Як тільки агент починає писати роман, він сам же починає втрачати важливі кроки. Короткі атомарні пункти працюють краще, особливо якщо далі цей план піде на виконання іншим агентам або в automation with AI для команди.
Вплив на бізнес та автоматизацію
Для команди це дає три дуже приземлені ефекти. Перший: менше пропусків перед реалізацією, а отже менше дорогих переробок після merge. Другий: швидше рев'ю змін, тому що обговорюється вже не хаос, а структурований план. Третій: простіше масштабувати розробку, коли частина планування та перевірки йде агентам.
Виграють ті, у кого багато паралельних завдань, інтеграцій і змін у продукті. Програють ті, хто як і раніше жене одного агента в режимі «зроби все сам» і потім дивується, чому в проді спливають діри між кроками.
Я такі речі регулярно бачу в клієнтських процесах: проблема рідко в самій моделі, проблема в поганій постановці ролей. У Nahornyi AI Lab ми вирішуємо саме це на практиці, коли збираємо AI solutions for business і розкладаємо, де потрібен планувальник, де перевіряючий, а де виконавець.
Якщо у вас зміни в продукті постійно губляться між ідеєю, тікетом і кодом, можна не латати це вручну. Я разом з Nahornyi AI Lab можу допомогти вибудувати таку AI implementation, де агенти не просто шумлять у чаті, а реально знімають навантаження з команди та зменшують кількість помилок до релізу.