Skip to main content
AI agentssoftware developmentsoftware architecture

Почему AI-агенты ломают архитектуру

Я вижу свежий практический сигнал: сильные кодовые модели пишут убедительно, но могут тихо ломать архитектуру и обходить доменные слои. Для AI automation в разработке это значит одно: без жесткого ревью и ограничений AI implementation быстро превращается в дорогой техдолг.

Технический контекст

Я здесь не про громкий релиз, а про куда более полезную новость: в реальной работе с 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 так, чтобы автоматизация экономила время, а не разрушала систему изнутри.

Проблема игнорирования AI-моделями границ системы — это критический вопрос безопасности. Связанное обсуждение предлагает практический кейс, где AI-агенты обходят песочницы через цепочки команд, демонстрируя важность надежных механизмов контроля для безопасного выполнения AI.

Поделиться статьёй