Технічний контекст
Я тут не про гучний реліз, а про значно кориснішу новину: у реальній роботі з Opus 4.7 та Codex знову випливає стара хвороба. На рівні плану вони звучать розумно, але щойно я починаю читати дифф рядок за рядком, AI integration у розробку різко перестає виглядати безпечною.
Конкретика неприємна. В одному кейсі модель у проєкті з доменними моделями просто оминула доменний шар, створила новий репозиторій і почала жити за своїми правилами. В іншому випадку я попросив додати доменний шар, а отримав папку з інтерфейсом репозиторію та дивний value object з масивом, але без entity. Формально щось зроблено. Архітектурно — це сміття.
І ось тут важливий момент: із зовнішніх джерел я не маю підтвердження, що саме Opus 4.7 або Codex систематично провалюють DDD як клас завдань. Є багато скарг на шум, буквальне слідування інструкціям, сумнівні автономні дії та загальну ненадійність у коді, але не на конкретний патерн із доменними шарами. Тому я б чесно називав це не доведеною властивістю моделі, а повторюваним практичним ризиком, який я б закладав у процес уже зараз.
Мене найбільше чіпляє не сама помилка, а її стиль. Модель не каже: «я не зрозумів архітектуру». Вона впевнено добудовує зручну для себе структуру, наче шар домену, інваріанти та межі агрегатів — це декоративна частина проєкту.
Якщо в плані немає залізобетонних обмежень, вона довигадує. Якщо обмеження є, вона все одно може тихо з'їхати на простіший шлях. Саме тому красиві план та коментарі я давно не вважаю сигналом якості.
Вплив на бізнес та автоматизацію
Для команди це означає просту річ: AI automation у коді не можна пускати в архітектурно чутливі місця без рамок. CRUD, тести, міграції, рутинний рефакторинг — так. Домен, контракти, інваріанти — ні, без ручного контролю.
Виграють ті, у кого є архітектурні чек-листи, правила для агента та рев'ю по шарах. Програють команди, які міряють якість швидкістю генерації та кількістю закритих завдань.
Я в себе вже дивлюся на це як на завдання AI architecture, а не просто на вибір моделі. Потрібні guardrails у промптах, лінтери на архітектурні порушення, шаблони каталогів, тести на межі шарів та обов'язковий diff-review людиною. Ми в Nahornyi AI Lab якраз такі речі й збираємо для клієнтів, коли потрібно build AI automation без сюрпризів у проді.
Якщо у вас агент начебто прискорив розробку, а код почав розповзатися по шарах, краще зупинитися зараз, ніж потім оплачувати переписування. Можемо разом розібрати ваш workflow і в Nahornyi AI Lab зібрати AI solution development так, щоб автоматизація економила час, а не руйнувала систему зсередини.